Pigeon 0.2

Is there any way for you to expose the "Prologue" object of prologue? I've written a prologue extension that adds routes for an Admin Route (server side rendering) and it pretty much only needs access to the "app" object so that one can call. It isn't yet fully finished due to an issue in one of

How to manually free/clear memory used by ref

Hi @Araq, Thanks for the suggestion. My current solution already uses `orc`, but using `-d:useMalloc` was actually helping on smaller files and loops, but when the files are +500mb it is status quo and it still does not free the memory. I have tested with newest stable nim (`1.6.8`) and various

Nim 1.6.10 RC2

Good to hear. I wonder if any of that is because of the on-going work on incremental compilation?

Pigeon 0.2

Can't help but bump this really lovely project as I'm not on github, I'll just comment quick, and dirty and say; I think exactly this effects system as the universal composer of threaded programs that MonAaraj proposes is a category error. Or rather it is almost as interesting and deep as abstra

Opportunity to adopt a new linker?

Thank you for taking the time to reply. Stefan_Salewski >And that takes only a few seconds. That update procedure is a bit hidden in the documentation, but I assume devs know it. Thank you for letting us know. I had imagined that the difference in link times would be more pronounced with differ

Opportunity to adopt a new linker?

> I don't know how many committers there are, but even assuming 20, that would > save 90 hours a year if they compile 3 times a day. Most times the compiler is compiled is in debug mode with a cache which means at most it takes ~20s. I did try mold on multiple projects with my 5600x and I have

Nim 1.6.10 RC2

>20 minutes nimc + *tools vs 15 now.

Nim 1.6.10 RC2

Are you sure? Any benchmarks?

Nim 1.6.10 RC2

My own tests, nimc is now compiled noticeable faster than before. But this is my perception using a very old computer. 20 minutes nimc + plus vs 15 now.

Nim Table, type iterators and lent type

Because `mapIt` isn't an iterator transformer/adapter, it acts on elements of the iteration in a consuming way (returns a sequence). You can't `fold` if your iterator is already consumed. So almost any code where the used sequtils templates aren't meant to be final is worse than manual looping.

Nim Table, type iterators and lent type

Why not use the existing `sugar.collect` or `sequtils.mapIt`?

Nim Table, type iterators and lent type

Last time I checked, `iterable` was useless as it's designed to work only in templates. Native iterators in Nim don't compose without macro-trickery, such as zero_functional. Actually, the only good thing I can say about them is when they _do_ work, they are as fast as loops (which they are).

Opportunity to adopt a new linker?

> Obviously completed faster. about 15sec. I saw this thread a week ago and have set mold as the default for my Gentoo box now. Note that mold does not work with glibc and the Linux kernel, see Actually mold seems to generate smaller executables, maybe by 2%,

Opportunity to adopt a new linker?

It would be a shame to end the conversation with this, as it is a good proposal, so I investigated it in more detail. The following was added to config/config.nims from the Nim compiler devel branch and compared before the change. (I am ashamed to admit that my last post seemed completely amateu

Nim Table, type iterators and lent type

I guess this is related to this type system "issue": proc add(x: int): int = x + 2 echo type(add(2)) echo type(add) Run returns int None Run Why `None` ? Shouldn't this be `proc (it: int): int` ?

Nim Table, type iterators and lent type

I am trying to understand the problem depicted in this [Stack Overflow post — implementing map min that takes the tables keys iterator as argument in nim](https://stackoverflow.com/questions/70240040/implementing-map-min-that-takes-the-tables-keys-iterator-as-argument-in-nim). The author of the

Nim 1.6.10 RC2

Compiler is now faster. Is this due to ARC/ORC ?