Request for feedback: `destructor` macro

This looks like an interesting learning exercise, but in what situations is this useful? The example you provided should have a correct =destroy generated for SimpleObj and TestObj without you writing one manually. You could confirm this by making name and otherString a custom type with an =des

Nim version 2.0.8 released

On choosenim & the OSX ARM issue: an alternative to patching/fixing choosenim is to provide a universal binary (see Apple's [docs here](https://developer.apple.com/documentation/apple-silicon/building-a-universal-macos-binary)). tl;dr on Apple's docs: it seems to be as simple as: `lipo -create -

StableSeq

Thanks for sharing. I have implemented a very similar data structure for another purpose: editing large files (text) using some tricks with `mmap` / `memfiles` to minimize RAM requirements (& time to load a file); which I have called a PSeq for "partitioned" seq (constant partitions/chunk size t

ARC vs refc

On the `atomics` API design: is there a reason there is no converter to `T` instead of the explicit `load` (which would be equivalent to C++'s [std::atomic operator T](https://en.cppreference.com/w/cpp/atomic/atomic/operator_T))? Or is there a hidden footgun with a converter?

ARC vs refc

> Is there a reason why atomics.load requires a `var Atomic[T]?` i.e. with an > atomic the above iterator would require to be declared as iterator > items(self: var MyContainer): int Is this because if `atomics.load` was declared as `proc load[T](location: Atomic[T]; ...): T` then `location` wo

ARC vs refc

> You have a race condition here where if an item is enqueue, thread 2 can read > uninitialized memory, then thread 1 initializes the memory. That is only true if you increment `len` prior to initializing memory on thread 1. > Any compiler will only read the length once and store it in register

ARC vs refc

> else it can reorder instructions so that your clever tricks fail I don't understand how instruction re-order will cause the example to fail under the constraints given (one writer which strictly increases the shared `len` variable). The reader thread would be simply: iterator it

ARC vs refc

> Also: Don't use linked lists, they are slow. They are, but they have the nice property of retaining the underlying memory as you add to the container, unlike a seq on a realloc due to exceeding capacity. But of course, for this property, it would be better to opt a container similar to `std::

Forum on Firefox is broken

My Grammarly plugin was the culprit here.

Which IDE to use in 2024?

If you want something out the box that works: use VSCode. If you know modal editing and prefer the terminal: use Helix or Neovim. For neovim, don't use a "distro", use kickstart: copy&paste the code, read it and understand how it works, then make it

Forum on Firefox is broken

Many things don't work. Such as Preview when posting, seeing a reply or thread immediately without requiring a page refresh, etc. On Chrome everything seems to work. Thought I'd mention it incase others have noticed this too.

Design Q: Why was result chosen? Why not re-use return?

You could develop some rules, but it would change the current semantics of the language. i.e. for a new language, it might be worth considering, but for Nim, this would not be worth the change e.g. for your example here is a solution by changing some semantic rules proc test(x: int

Design Q: Why was result chosen? Why not re-use return?

I see, with your snippet: `return` doesn't allow for "return expressions" unless you had a specialized rule to handle this edge case.

Nim version 2.0.6 released

If `--threads:on` is the default, why is `-d:useMalloc` not? Is the bug simply a race condition in the default allocator?

Design Q: Why was result chosen? Why not re-use return?

Why was `result` chosen over overloading the `return` keyword to act as a variable? e.g. proc foo(): int = let x = 3 return = x*x Run vs. proc foo(): int = let x = 3 result = x*x Run

Nim version 2.0.6 released

Can you expand on: > NOTE: If your program uses threads (--threads:on became the default in the > 2.0.x line) please also use the -d:useMalloc switch. This problem will be > fixed in a future release, sorry for the inconvenience. What is this issue here? Does this affect 2.0.2, 2.0.4, or just 2

Feedback on site: Scroll to Top or Update Design for Docs

> even if fn + up does the same thing Didn't know this trick. Thanks for this.

Feedback on site: Scroll to Top or Update Design for Docs

No, I use a Macbook Pro keyboard. The design should assume a particular keyboard layout in any case.

Feedback on site: Scroll to Top or Update Design for Docs

> In devel the results are positioned so they are always visible (e.g. search > for something here > ) Thanks didn't realize this was the case. Will use the devel docs from now, since I'm using a devel nim compiler.

Feedback on site: Scroll to Top or Update Design for Docs

Imagine the following scenario: 1. Searching the documentation for a specific function, e.g. `all` 2. Click `all`, read it 3. Search for another function, e.g. `map` 4. At this point the user must scroll to the top of the page manually to see their results I propose (1) a simple "scrol

Nim safety features like Zig & Rust?

Those are fair points for the standard library. The only remaining argument I can see for custom allocators is that specific systems need specific allocators, e.g. fujifilm camera's firmware pre-allocates large arrays for the whole system memory (see

Nim safety features like Zig & Rust?

> You can certainly write libraries against an allocator type and pass it > around everywhere explicitly that doesn't require a new language... >It's > just that the Nim stdlib does not do it and the idea is bullshit. Regarding allocators: as with most things, I believe this depends on the cont

=destroy and enum

Do you have a case in your object on the enum field? i.e. is your object an [object variant](https://nim-lang.org/docs/manual.html#types-object-variants)?

Advent of Nim 2023

Here are my solutions: \- you'll need to redirect stdin to run the examples, e.g. `./build/day4 < input/day4` I'm using AoC to learn Nim better. Day 5 part 2 is slow, I'm sure there's a trick with all the affine tran

Advent of Nim 2023

I would suggest looking at some other solutions. Taking more than 1s for day 4 suggests your solution is inefficient. I would suggest profiling/timing your code or sections of your code to see where the bottleneck is. My solution for day4 part 1 & 2 in a debug build takes <0.02s on my machine.

Advent of Nim 2023

Here are my solutions: you'll need to redirect stdin to run the examples, e.g. `./build/day4 < input/day4` I'm using AoC to learn Nim better. Day 5 part 2 is slow, I'm sure there's a trick with all the affine transfo

Ideas about strings

Questions: 1. Why not enable mutations to the substring? 2. Can we generalize this to a slice for any container? Is the intention behind this design to generalize to other containers, such as seq? As for strings having to end at '0' not enable slicing with O(1). I would argue that convers

Nim#

Is NIR this RFC? Seems like exciting work. What state is it currently in? It would be great for the community to see the state of progress here, e.g. on github as a milestone or checklist on the RFC (does this exist somewhere already?). I assume you

[help] Nim JIT + REPL with clang backend + -emit-llvm + LLVM's ORCv2

Hi all, I have recently been developing an extension to the Nim compiler to support JIT'd code in a private repository. It works by utilizing clang's "-emit-llvm" flag will will emit LLVM IR code, and then with this LLVM IR code we can feed it into LLVM's ORCv2 JIT engine and dynamically compil