Reliably locating nimbase.h

You can do this: It's possible to get the path from Nim on the cli using the dump flags.

Reliably locating nimbase.h

I'm trying to make some improvements to [nim-platformio](https://github.com/markspanbroek/nim-platformio), a tool that makes it easy to cross-compile nim to microcontrollers. One of the needs is to have `nimbase.h` in the project's include path. The current solution keeps a copy of nimbase.h in

Collectors, heap, sharedRam, threads.

Great!

Collectors, heap, sharedRam, threads.

@elcritch, @Araq, @termer I was wrong about GC. This issue related to the kernel. I found the way how to release freed ram by GCback. proc malloc_trim*(size: csize_t): cint {.importc, varargs, header: "malloc.h", discardable.} Run Usage example: discard mall

Collectors, heap, sharedRam, threads.

Greetings @ML! > I thought --d:useMalloc used in my example should do the same? Meanwhile here > compiler prints: Error: invalid command line option: '\--useMalloc' Yah, my bad it's `-d:useMalloc`. > I use Google Sanitizers, while valgrind is indeed a good tool! I suggest you > to try Dr.Memor

Nim library interoperability with other GC languages (NodeJs, Golang)

Thanks for the rapid response and the feedback! I will check everything carefully. The code I shared is a bit messy due to the N-API layer but it actually calls `NimMain`. wakuMod.init() ... static napi_value InitAddon(napi_env env, napi_callback_info info) { Nim

Nim library interoperability with other GC languages (NodeJs, Golang)

Thanks @juancarlospaco! Is this intended for making Nim to targe Javascript? In my case I'm interested in generating a C shared library.

Nim library interoperability with other GC languages (NodeJs, Golang)

when it comes to intermingling managed code in which multiple memory management schemes have no actual knowledge of each other, you need to use the language's built-in utilities to preclude object destruction. C#, for instance, has [`unsafe` contexts](https://learn.microsoft.com/en-us/dotnet/cs

DLL Terms

imo Win32/NT is for the most part more sensibly designed than UNIX (and even then, MacOS tries to hide its UNIX heritage very frequently, aside from the most basic OS bookkeeping substrata) in any case it matters little because (being a cross-platform language, as most languages tend to be) Nim

DLL crashes - can't figure out why

OK, I've tried to get a reasonably compact version for testing. There are 3 nim files: TESTmain, TESTmodule and Testlang. * Testmain * sets things up and creates a test text file to work with * does the loading and calling of TESTmodule * TESTmodule * 3 callable procs : initModule

Nim library interoperability with other GC languages (NodeJs, Golang)

Maybe something like is useful.

Nim library interoperability with other GC languages (NodeJs, Golang)

Well you don't call `NimMain` at startup but you need to. And then there a gazillion things that can still go wrong, use at least `--mm:arc` or `--mm:orc` and a Nim version that is actually officially supported because "Nim Compiler Version 1.6.11" surely is not. And sorry but a newcomer (that

DLL Terms

I don't "deflect criticism", I try to say things that you haven't heard a million times on social media already. And I'm well aware that there is a certain percentage of people out there that treats Unix like a religion.

DLL Terms

araq try not to deflect criticism by throwing pointless jabs at unix challenge (impossible)

DLL Terms

But I think it's better to make the documentation more friendly to those from different systems. In this case, it could be described as "`nimrtl.dll`, also known as `libnimrtl`, is ..."

Nim library interoperability with other GC languages (NodeJs, Golang)

Hi all, I'm working in the creation of a C-bindings nim library. The library is built with `nim c ...`. This library integrates correctly in a C example but I have issues to make it properly work on another environments. Concretely, I'm interested in NodeJS. It is quite evident that there is a

End of function in Nim binary

`-ffunction-sections` provides another, slightly more explicit, mechanism for achieving this:

End of function in Nim binary

I have done this in github.com/treeform/hottie. I used objdump to disassemble the binary, then parsed the objdump dwarf text format. The text format contains information about where functions start and end, as well as whether they get broken up into multiple chunks or have multiple 'ret' instruc

End of function in Nim binary

Compile them with `-fstack-protector-strong` and use the call to the stack protection function to mark the end of the function. Otherwise what's wrong with scanning for `RET` instruction?

End of function in Nim binary

yeah, that's clear, using a good disasm would work (and actually this is my workarounf itm), but I am talking about automation. I am reading in several Nim std lib files and compile them. This produces several executables which I parse the symbols from which include the functions and their start

How to get operating system information in nim-lang?

At the bottom of that link is a further link to here, which explains it is hoped that this format is widely adopted even on non-systemd distros: The date on that post is 2012, so the concept has been in existence for quite some time now. /etc/os-rele

Collectors, heap, sharedRam, threads.

Hello termer! >: If I remember correctly, -d:useMalloc only works for ARC/ORC, so if you're not using those, it has no effect. The reason I compare other GC's is to show the problem persists with them too. Arc/Orc ram consumption results was included in my first message. > : I've dealt with the

How to get operating system information in nim-lang?

> On Linux, the file /etc/os-release can be helpful in most cases According to the SE post, these are distros shipped with systemd. > Please use a good search engine before posting. Sorry, I have been quite harsh here. You asked for operating system information contrarily to the SO post asking

DLL crashes - can't figure out why

> It's actually not true btw, if you don't heap allocate or use your own memory > management (no ref, seq, strings) you don't need nimrtl.dll / nimrtl.so / > nimrtl.dylib And how does that additional knowledge helps newcomers? "Use DLLs, C style memory management and malloc, it works". - "Actua

Collectors, heap, sharedRam, threads.

Hello elcritch! Thanks for reply. > : Generally allocators will hold on to a certain amount of memory for > performance reasons. I believe wrapper around malloc does that? Since I used malloc() with my own manual memory management in C, and only free() will return back to the OS. In our case w

DLL Terms

I simply use the terms that make more sense and Unix tends to lose these "fights": * "binary": it's a digital computer, everything is in binary, including text. "exe": yes, that's it, it's an executable. * "shared object": Well they don't have to be shared and are not "object" files plus an

DLL crashes - can't figure out why

> Every DLL needs to use nimrtl.dll so that they all agree on the used memory > manager. (This is not Nim specific, it's just the way the world works.) I think we need a tutorial on DLLs, on the Nim website, even @PMunch article doesn't mention that. It's actually not true btw, if you don't hea

Collectors, heap, sharedRam, threads.

@ML >So regarding the GC, does it mean, that even with --d:malloc the allocator will hold that memory until whole process quits? If I remember correctly, `-d:useMalloc` only works for ARC/ORC, so if you're not using those, it has no effect. I've dealt with the same issue, thinking the program w

DLL Terms

Nim being Windows-centric is probably a good thing, given the fact that C itself is very Unix-centric. Balances things out a bit and makes sure people can actually write cross-platform applications with it.

End of function in Nim binary

Nim binaries aren't inherently different to any other binaries that are compiled from other native languages, especially considering that Nim compiles to C which is then compiled by the C compiler. So you don't need any techniques that are exclusive to Nim here.