FFI - memory management issues

You can use `move(obj)` to force a move.

FFI - memory management issues

Don't forget to set your `handle` to `nil` after freeing it to avoid double frees!

Strange race condition on Windows

I will, but it really feels wrong... This is Mac, not Nix / Arch. Non technical users trying out Nim should not be expected to compile their compiler. I know it's just `koch boot -d:release`, but like for a first time user (maybe coming from python), this is daunting. I really like the idea of d

Strange race condition on Windows

Thank you for this reply! I might also write a PR to add this code as a test if I manage to increase the probability of crashes enough.

Strange race condition on Windows

It is a Mac M1. I'm using clang as the compiler. When calling `cpuRelax` in an empty file, I'm getting: error: unrecognized instruction mnemonic asm volatile("pause" ::: "memory")"; This is because `amd64` is defined. The nim compiler I use was compiled on an intel CPU. I use rosetta to run it.

Strange race condition on Windows

Using `-d:useMalloc` fixes this, but once again, why? What is the default memory allocator for Nim if not malloc? When looking at the source code, I cannot find the difference between `allocShared` and `alloc`, is there one? There is so much documentation missing and even browsing at the source

Strange race condition on Windows

The example with the global string `s` still crashes with `--mm:atomicArc`. But even without it, if a modification of an integer (like a reference count) is only done when a mutex is locked, it should make it atomic? Or the destuctors are called outside the lock sections?

Strange race condition on Windows

If there was no lock, this explanation would make sense, but in my code, the variable access happens behind a lock, so why would there be non-atomic writes

Strange race condition on Windows

The more I try things, the more I'm confused. Even this example, without any ref, does not work: import locks import os var s: string var c: int var l: Lock proc myFunc() {.thread.} = for i in 0..<50: os.sleep(1) {.gcsafe.

Strange race condition on Windows

Moreover, using `Lockers` without `spawn` does not work: import malebolgia / lockers type Example = object s: string c: int proc threadFunc(lockedObj: Locker[Example]) {.thread.} = lock lockedObj as obj: obj.s.add($obj.c)

Strange race condition on Windows

I was interested in implementing a library like malbolgia myself, I'll look at the source code, the locker implementation is what I need. The following works: import malebolgia import malebolgia / lockers type Example = object s: string c: int p

Strange race condition on Windows

How can I share memory between threads? Do I have to use pointers with allocShared and manual memory manager? Do pointer with alloc work ? Is there documentation somewhere about this?

Strange race condition on Windows

By adding an `echo` inside `threadFunc`, I can get it to crash every time: proc threadFunc(obj: Example) {.thread.} = withLock lock: echo "Inside thread" obj.s.add($obj.c) inc obj.c Run Once again, this only occurs on windows.

Strange race condition on Windows

I wanted to add more examples to as I feel that some modules lack documentation. I wrote a small program to show how to share memory between threads in Nim: import locks type Example = ref object s: string c: int

Nim program crashes when using recursivity and openarray

The following Nim program crashes and I don't understand why: proc recursiveExplorer(s: openarray[char]) = if s.len == 0: return # processing(s[^1]) recursiveExplorer(s[ 0 ..< (s.len-1)]) var data = readFile("someLargeFile.txt") var conver

Speeding up compile times

Reading 2 year old posts about IC is kinda depressing. I'd like to help, but I have no idea of what's missing for IC to work.

Speeding up compile times

I tried using clang and I'm getting about the same times. tcc does not work with Nim sadly. I'll try using the compiler you provided.

Speeding up compile times

Hello ! I'm using Nim to make a small game engine and a few games. However, as the engine has grow, the compile time has increased by a lot. Currently, the project has 10102 lines of Nim code (excluding comments and empty lines) and takes about 10 seconds to compile. While this is very impress