Re: Introducing --gc:arc
Thank you for this Christmas present.
Re: Introducing --gc:arc
> I am also curious about the shared heap, the implication from your post is > that you are still sticking to the "one heap per thread" model and that we > will continue to restrict the sharing of memory between threads. Is that the > case? No. The heap is now shared as it's done in C++, C#, Rust, etc etc. A shared heap allows us to _move_ subgraphs between threads without the deep copies but the subgraph must be "isolated" ensuring the freedom of data races and at the same time allowing us to use non-atomic reference counting operations. How to ensure this "isolation" at compile-time was pioneered by Pony and we can do it too via our `owned ref` syntax. However, we will likely do it at runtime because it's simpler and a variation of the "cycle collection" algorithm. The pieces fit together in a marvelous way. :-)
Re: Introducing --gc:arc
> Does spawn transfer ownership of its arguments and returns ownership of its > result? Exactly. The ownership transfer is also done for channels' `send` and `recv`. We are working on a better thread pool and maybe a more light-weight channel implementation. I'll post some examples here when they are ready. Threadpool wasn't ported and I'll
Re: Introducing --gc:arc
This is awesome, and a great overview thanks for writing it up. I am also curious about the shared heap, the implication from your post is that you are still sticking to the "one heap per thread" model and that we will continue to restrict the sharing of memory between threads. Is that the case?
Re: Introducing --gc:arc
This is great! Could you elaborate on shared heap and how memory is passed from one thread to another? Does spawn transfer ownership of its arguments and returns ownership of its result? Would love to see official examples.
Re: Error converting json to types
Er, JSON doesn't define a standard format for DateTimes so how could the stdlib offer it?
Re: Nimph is a Nim package handler for the rest of us
Extremely awesome :-)
Re: Named Argument Bug?
Ah, many apologies! I saw it in the manual and assumed that it worked in the same thing as Julia.
Re: Named Argument Bug?
I'll not make anymore assumptions and read more carefully.
Introducing --gc:arc
# ARC So ... this feature has been in development for quite some time now, Nim is getting the "one GC to rule them all". However calling it a GC doesn't do it justice, it's plain old reference counting with optimizations thanks to move semantics. It has numerous advantages over the other more classical GC algorithms that Nim 1.0 ships with: * Independent of the heap size. Works well with tiny and enormous heaps. * Independent of the stack size, large arrays on the stack do not cause slowdowns. * Offers a shared heap. Enabled via `--threads:on`. * Works with valgrind and clang's address sanitizers, compile with `-gc:arc -d:useMalloc` (and maybe with `--debuginfo`) for enabling this feature. * No more `setupForeignGC` requirements. * Should work better with hot code reloading and DLLs. * Should work better with fibers, coroutines or whatever C++ ends up providing. ;-) * Should work well with webassembly and Emscripten. However, this is still **beta quality** software: Nim's async does not work with it yet, there are other known and unknown bugs and we haven't optimized it as much as we will. ## Supported language features * Threads and channels * closures * refs * strings * seqs * closure iterators * case objects * the collections in the stdlib * strutils, os, osproc, re, json ## To do * Optimize the stdlib with `sink` and `lent` annotations. * Optimize init+sink pairs into plain copyMem calls. * Optimize away wasMoved+destructor pairs. * Port async to --gc:arc. * Exceptions are known to be buggy, will probably be replaced by a mechanism based on the "quirky exceptions" ideas. * Bugfixing. Omg, still so many bugs left... ## Features that won't work for the foreseeable future * the old runtime type information (RTTI, `typeinfo.nim`) and modules that rely on it such as `marshal.nim` * `system.new` that takes a finalizer, instead use destructors ## Arguments and comebacks Q: My program runs slower than before. A: The old GC was tuned for years and can be hard to beat performance wise. ARC shines because it uses less memory and introduces deterministic behaviour. Having said that, I usually get it to win over Nim's other GCs (both in time and space) by inserting strategic `sink` and `lent` annotations. Q: I cannot be bothered with cycles. A: We have a cycle collector too but it's not even in alpha state yet, you can tinker with it via `--gc:orc` (the "o" indicating it can deal with cycles...) Having said that, cycle detection will not be the default as it in conflict with ARC's strive for deterministic memory management. Q: Atomic reference counting is known to be slow A: We **do not do atomic** reference counting, we have a shared heap where you move subgraphs completely to a different thread. A graph is always owned by a single thread, there is no need to make the reference counting atomic. We have mechanisms in development to ensure this at runtime or at compile-time, inspired by the Pony programming language. Q: Ok, I'm sold! How to get --gc:arc? A: Follow these instructions: git clone https://github.com/nim-lang/nim.git cd nim sh ./build_all.sh # (Linux, Mac) build_all.bat # (Windows) Run Merry Christmas!
Re: Named Argument Bug?
Because of the `(;`, invalid Nim syntax. Named arguments are not separated by other arguments, they simply always exist.
Named Argument Bug?
Why is this not legal code? proc printName(;firstName: string = "Jimmy", lastName: string = "Hendrix") = echo "First Name:", firstName, ", Last Name: ", lastName Run
Re: Advent of Nim 2019 megathread
Having decided to try learning a bit about Nim using AoC2019, I joined the [private leaderboard](https://adventofcode.com/2018/leaderboard/private), but never expected to be in the top 10 (I'm at 5 now, `dougcurrie`). So, I'll list my repo now in case anyone searching for Nim Advent of Code solutions in the future looks here. [https://github.com/dcurrie/AdventOfCode](https://github.com/dcurrie/AdventOfCode)
Re: Object Variants and redefinition of labels or reusbility of field names
@FernandoTorres Maybe this is the posting you had in mind: [https://forum.nim-lang.org/t/5036](https://forum.nim-lang.org/t/5036) The related RFC is [https://github.com/nim-lang/RFCs/issues/19](https://github.com/nim-lang/RFCs/issues/19) I'd like to see one of these approaches implemented. :-)
