Do you have to use 'ref' for the field types within ref objects?

We avoid `ref object` unless semantics explicitly require it for the type (ie a linked list or a tree) - if we need `ref` semantics, we annotate the sites where it's used instead (`ref X` vs `X = ref object`). In this specifi

Do you have to use 'ref' for the field types within ref objects?

> It is a strange thing to be told that to understand something in Nim you > first have to go and understand it in another language. Yes, I agree, and that was the reason that in 2019 I decided to write a book for kids and beginners. I still think that it was a good idea to write it, and I thin

Atomic ARC option?

> The graph can be modified safely by any number of threads concurrently, > however concurrent updates result in different graph versions. A graph > version is just another another root 'SharedPtr[ref T]`. (To be clear, a > graph version is not a full copy of the graph -- it's merely a copy of t

Do you have to use 'ref' for the field types within ref objects?

It is a strange thing to be told that to understand something in Nim you first have to go and understand it in another language. The prevalence of the `ref` issue is a clear indication that the existing didactic material is insufficient.

ARC and {.requiresInit.} issue

What is the problem of zero initialization for objects? In the case of your code, it seems `nimZeroMem` is removed by GCC. I just changed magic numbers in your code so that I can easily find them in assembly output: # testzero.nim import std/volatile type Foo {.r

Nim 1.6.10 released

[soleil@Z600 ~]$ choosenim update stable could not import: SSL_get_peer_certificate

Is there a way to see all or older threads of a user?

Ok. Just thought it would be handy if I remember that there was an older post and I can't find it through the search...

nimNx: a compilable nintendo switch example

Hi everyone. I've been struggling for three days to compile basic helloworld app written in Nim. I've created this little example project to ease these steps for other people, trying to find an alternative to c / c++. It shows real basic functionality but it is still a great starting example! I

ARC and {.requiresInit.} issue

I believe this might be related to/caused by

ARC and {.requiresInit.} issue

Another embedded programming issue. Manual says: `The implicit initialization can also be prevented by the requiresInit type pragma.` But the compiler generates an unnecessary zero initialization for the object, although it is marked with a `{.requiresInit.}`. # init.nim impor

Nim 1.6.10 released

`nlvm` updated to 1.6.10 as well ;)

Initial OS porting experience

> How does this work when you first generate cmake? When you have a completely > new build there is nothing in the nimcache directory and cmake sees nothing, > no c files or dependency files. Yah that's a bit of a sticker. :) Currently I have a Nimble task that runs `nim c` and also runs `cmake

Initial OS porting experience

> Hacking on the compiler to enable this seems extreme to me. Nah, overall it's the cleanest solution IMHO. Also the compiler PR is pretty trivial and self-contained, however it helps simplify the CMake side a great deal. CMake is a de facto standard for C/C++ projects so making Nim play nice w

nimble master

ah ok, than I think this is a bug. You could open an issue in nimble repo. Actually the fix is probably as easy as changing to `doCmd("git init --initial-branch=" & defaultBranch)` this line:

nimble master

> git config --global init.defaultBranch main I just used this command recently. The bug can be reproduced by running the above command and trying to publish a package. Also it can be (temporaryly) solved on the local host, by running the following command: git config --global init

nimble master

ah ok. But why the local branch of is main? you changed it yourself?

nimble master

> I do not think that nimble needs to know default branch of your git repo when > publishing I don't mean that. It went wrong when `nimble` copied and tried to push it onto , the branch of it on the github is `master`,

Importing generic variables

how about {.emit:""" template constexpr T pi = T(3.1415926535897932385L); template const static size_t ALIGN_MASK = 64 / sizeof(T) - 1; """.} proc pi[T](t:typedesc[T]):T{.importcpp:"pi<'1>".} proc alignMask[T](t:typedesc[T]):csize_t{.importcpp:"

Initial OS porting experience

Hacking on the compiler to enable this seems extreme to me. > However, you'd still need to do post processing of the json file, which isn't > great in CMake. #!/usr/bin/bash if [ $# -ne 1 ] then echo "usage: $0 /path/to/main.json" exit 1 fi jfile=$1

Choosing Nim out of a crowded market for systems programming languages

> it's not a productive way to have a discussion True, but who argues online for the sake of productivity? 😂

nimble master

I never run into this and I do have published packages with default branch `main`. I did check the [code of `nimble publish`](https://github.com/nim-lang/nimble/blob/master/src/nimblepkg/publish.nim#L164) and indeed it does assume a `defaultBranch` of `master` but this refers to the default br

Initial OS porting experience

> I got a working example with the esp-idf library and the above PR! > > Here's the main part of the CMakeLists.txt: > > > (CDEPS "${CMAKE_CURRENT_LIST_DIR}/.nimcache/main.cdeps") > >set(NIMBASE "${CMAKE_CURRENT_LIST_DIR}/.nimcache/nimbase.h") > > >set_directory_properti

Importing generic variables

What's the best way to wrap this C++ code: template T my_var; Run As a `proc` proc myVar[T](): T {.importcpp: "my_var<'0>".} echo myVar[int]() Run or a variable? type S = distinct string const myVar = S("my_var")

Initial OS porting experience

> However, you can trigger on nimcache/myproject.json if Nim updates this file > after each build. It's a bit coarse though. I solved it by forcing the Nim > build each time because cmake doesn't know about if I change any library > files either. Good point! I created a PR to help with this. In

Plans for improving tagged enum (ADT) syntax?

Due to alignment. And it's hard to gain it back because the sum type is reified and can be used independently from where it is embedded. Consider: type SomeEnum = enum strVal, intVal, nothing Node = object # size: 3 words flags: uint8 case e: SomeE

Plans for improving tagged enum (ADT) syntax?

> It does lead to a loss of efficiency though as in many important cases the > discriminator is a single byte that can be combined into a word with some > "flags" field. How do you mean? Because of alignment, or by doing magic optimizations? The latter would have ABI implications, and there are

Choosing Nim out of a crowded market for systems programming languages

@sekao Please stop it, it's not a productive way to have a discussion. It's now clear what @ricky222 meant and you disagree. Can happen.