Show Nim: Guzba and I are publishing YouTube videos discussing our work in Nim

What a pleasant way to start a Sunday! Thank you for the initiative, love your work 🙏

Channels documentation

Thanks!

Unable to compile nim to wasm on aarch64

The problem is that you're trying to compile for a 32-bit target with a C compiler for 64-bit platforms. On your system, `sizeof(void*)` is 64. But `NIM_INTBITS` was 32.

Show Nim: Guzba and I are publishing YouTube videos discussing our work in Nim

Hey everyone, Guzba and I have been working in Nim together for a long time now and we've decided that it would be fun to start recording us demoing and discussing our work. We hope it will interesting to listen to. We're going for a conversational feel that starts with a demo and focus and then

Channels documentation

Don't have much experience with the built-in channels, but the [current implementation of Nim channels](https://github.com/nim-lang/threading/) for ARC/ORC are MPMC (multiple producer / multiple consumer), so one channel is expected to be safe to use. You can read additional comments in the sou

GC refc crash calling into nim from C++

It seems like the C++ / Unreal subsystem code is creating multiple instances. A Default and "0" version of UNimForUEEngineSubsystem, and the Default is calling Tick without Initialize. The "0" version is calling Initialize(), then Default calls Tick(), then "0" calls Tick(). Why wouldn't calling

GC refc crash calling into nim from C++

Looks like Initialize() and Tick() are on the same thread after all. I have no clue how calling NimMain in Tick() is different from calling it in Initialize().

GC refc crash calling into nim from C++

That doesn't seem to be any different from calling NimMain through initializeHost above. Does NimMain need to be called per thread where the nim function is called? If that's the case somehow the Initialize and Tick functions on the C++ side could be on different threads because having the init

GC refc crash calling into nim from C++

Afaik you should call `NimMain()` from your cpp code

GC refc crash calling into nim from C++

I'm trying to figure out why the gc (refc) is crashing. I have a dll with nim code, that's being called from C++. The nim function is calling NimMain() once and then doing some stuff with paths (allocating strings) and eventually crashes from repeated calls. If I move the NimMain() call outside

Unable to compile nim to wasm on aarch64

I'm on a fresh installation of ubuntu 20 on an OCI VM.Standard.A1.Flex (aarch64). task clientwasm, "client-wasm": exec "nim c -d:danger -d:emscripten --cpu:wasm32 --cc:clang --os:linux src/nimstcorepkg/client.nim" Run I haven't written any code yet, I'm jus

Channels documentation

Is it safe to send messages from a single producer thread to multiple consumer threads using a single channel? Or would separate channels be required, one for producer-consumer thread pair?

Channels documentation

Thanks, that's what I was looking for. Perhaps someone can take down the old page, I didn't see the second, nested link in Google straight away.

Small improvement discussion: Use `let` to lock variable previously declared as `var`

Nice! This seems like a generally useful thing. Maybe it could be part of `std/sugar`?

Channels documentation

What about ?

Channels documentation

Is the latest channels doc page missing? All I could find is a page generated in 2019:

Small improvement discussion: Use `let` to lock variable previously declared as `var`

Simple template based solution I came up with proc computeFoo(foo: var Foo) = ... template withIt*(x: typed, body: untyped): untyped = block: var it {.inject.} = x body it let foo = initFoo().withIt: computeFoo(it)

Small improvement discussion: Use `let` to lock variable previously declared as `var`

> question of how ugly you're willing to go Indeed! Thank you for the macro approach.

Small improvement discussion: Use `let` to lock variable previously declared as `var`

question of how ugly you're willing to go import macros macro letInit(name: untyped{ident}, init: typed, body: untyped): untyped = let initType = init.getType decl = if initType.kind == nnkBracketExpr and initType[0].strVal == "typeDesc":

Small improvement discussion: Use `let` to lock variable previously declared as `var`

IMO the block syntax is good enough but I tried to come up with a template as an exercise. The code below works but can it be improved? How to avoid passing the variable name (e.g. `foo`) to the template? As far as I know this isn't possible. template shadowvar(varname: untyped, in