Regarding the future of --gc:none and --gc:regions

Yeah, the quality is clearly not the best, i have to give you that, sorry :P

Regarding the future of --gc:none and --gc:regions

> adds debug checks so that you don't create invalid cross-region pointers... Sounds like a return for the long gone memory regions feature? I didn't follow Nim closely at the time to know why it was phased out, though.

Regarding the future of --gc:none and --gc:regions

Well this is all very interesting but for now it's good enough to keep the `--gc:regions` switch. But in theory with the right collection libraries and maybe a polymorphic allocator and the `=hooks` mechanisms you can create a much better `withRegion` construct. One that works with ORC and adds

Library for making lightweight Electron-like HTML/JS GUI applications

What are you using instead?

Library for making lightweight Electron-like HTML/JS GUI applications

What's up guys, v0.2.3 has just released. I fixed a bug that was preventing Windows from using the library, and other minor bug fixes and optimizations. Also, I dropped an example in the repository. It's a simple Neel app that picks a random file from a directory (something impossible from the

How to avoid deprecation notice for libraies supporting multi-version of Nim?

Thanks, I've pin pointed the issue and opened [#15650](https://github.com/nim-lang/Nim/issues/15650) to track it. Currently there is no walkaround for this issue so you'll have to wait until the issue is fixed.

Views of a non thread local var

> 1\. Why is this not allowed? The manual doesn't explain it. (also the link in > the error message both doesn't work and why it doesn't work is described in a > different section) The anchor is now `#view-types-path-expressions`, I suppose the error message wasn't up-to-date. > 2\. Is my work

How to avoid deprecation notice for libraies supporting multi-version of Nim?

I use `choosenim 1.4.0` on linux. To reproduce git clone https://github.com/jackhftang/lrucache.nim.git -b remove_rightsize nimble test Run

How to avoid deprecation notice for libraies supporting multi-version of Nim?

Hmm, what version of Nim are you running? I tried to make a small reproduction of the issue on the playground but there were no deprecation warnings:

How to avoid deprecation notice for libraies supporting multi-version of Nim?

For example, I have an old code like this initTable[K,V](rightSize(capacity)) Run Since `rightSize` is deprecated in 1.4.0, I modify the code to the following when (1,0) <= (NimMajor, NimMinor) and (NimMajor, NimMinor) < (1,4): initTable[K,V](rightSi

Views of a non thread local var

It's not possible to make a view of a [non thread local variable declared as var](https://nim-lang.github.io/Nim/manual_experimental.html#view-types). So the following code doesn't compile: {.experimental: "views".} var someArray = [0] proc main() = let viewO

Regarding the future of --gc:none and --gc:regions

Yes but at that point you can just use a memory pool and those are not hard to implement (see the implementation linked in my previous message). The memory pool can be used side-by-side with ARC/ORC and provide speed up for only the type of objects that need them due to heavy allocation/dealloca

Regarding the future of --gc:none and --gc:regions

> both regions (because you didn't use them in thavlak) Thavlak does seem to use them btw, did you mean gc_test?

Regarding the future of --gc:none and --gc:regions

Did you compile with -d:useMalloc and ran under valgrind to confirm that there are no leaks? For a fair comparison

Regarding the future of --gc:none and --gc:regions

As leorize said above, both regions (because you didn't use them in thavlak) and arc (havlak specifically tests the cycle collector and arc doesn't deal with them) will leak for thavlak, that's why it's fast, much faster than ORC might be

Regarding the future of --gc:none and --gc:regions

I didnt confirm it with valgrind, basically because i am on windows

Ubuntu, snap install, "Error: cannot open file: strutils"

> First of there's a prefix on all of the nim cmds like "nim-lang.nim, > nim-lang.nimble" etc. That's how snap work, so you can't change that unfortunately. The snap versions are not provided by the Nim project but is instead maintained by members of our community. I'd recommend you to raise an

Regarding the future of --gc:none and --gc:regions

The regions test was slightly changed to actually use regions, it was not just the same code.

Regarding the future of --gc:none and --gc:regions

> In the other tests however, regions was slightly faster, and it seems to have > a clear advantage when it comes to threads. It's very simple, really. Regions doesn't free the memory since you're not making and/or destroying regions. The best optimization for this use case is to use a memory p

Regarding the future of --gc:none and --gc:regions

withRegion is used when you need to allocate something on the heap usually, so outside a withRegion block you write your stack allocated code usually or code that doesnt need to be heap allocated.

Regarding the future of --gc:none and --gc:regions

"I think we need to understand why ARC was faster for Thavlak. That's strange." because it was leaking :) AFAIK, freeing memory is slower than just forgetting about it :)

Passing X to a sink parameter introduces an implicit copy

Nice explanation. Thanks! I'll give it a try to see the results...

Regarding the future of --gc:none and --gc:regions

I think we need to understand why ARC was faster for Thavlak. That's strange. Anyway, aside from performance, there is another reason why regions can be helpful: cryptography. With a slight change to "withRegions()", there could be secure and efficient zero-ing of the previously used memory. I

Passing X to a sink parameter introduces an implicit copy

a couple simple illustrations: proc sinkingLen(x: sink seq[int]):int = x.len var s = @[1,2,3,4] echo s.sinkingLen Run this warns, because s is a global variable. you can either explicitly move s: echo sinkingLen(move(s)) echo s #s becomes @[]

Impressive results with --gc:orc

Utf-8 output might work, but the 'getKey' function does only support ascii. Patching it should be easy, though by introducing another proc like 'getKeyUnicode' or similar. (Have done this on an unmerged experimental branch already)

Passing X to a sink parameter introduces an implicit copy

Was wondering the same thing

Passing X to a sink parameter introduces an implicit copy

`...; if possible, rearrange your program's control flow to prevent it.` This is a common hint message I've been getting. Are there any guidelines as to how to deal with that? (I know about `move`, but I'm not really sure what it implies...)

Impressive results with --gc:orc

in French it does not work (éêç ...) it is to specify on its page it only takes the UTF8 characters of box making

Impressive results with --gc:orc

are you sure that illwill doesn't support UTF-8? for me it seems like it does

Impressive results with --gc:orc

illwill does not support UTF8 and does not support a certain number of function keys, termkey is an import which supports the terminal on linux, I have not to mix also made a lib termcurs which it goes much further, but I admit I was inspired by illwill I say it in my manifesto and other, in add

Impressive results with --gc:orc

your English is great, ne t'inquièt e. [termkey](http://www.leonerd.org.uk/code/libtermkey/) seems deprecated, but there's [illwill](https://github.com/johnnovak/illwill) which might suit?

Impressive results with --gc:orc

tip - you can put a lot of these in a config file (.nims or .cfg) instead of having a very big command Run I have a procedure included in VS or Geany batch or standard makefile for the moment everything goes through this procedure, I did not see the interest of making a .cfg exce

Impressive results with --gc:orc

by removing -d: useMalloc and --opt: size BUILD PROD termScr.nim-> termScr size : 696K --->ARC BUILD PROD termScr.nim-> termScr size : 713K --->ORC on the other hand I have the same memory footprint when working working ORC---> 648k utils by removing --opt: size BUILD PROD termScr.nim-> termSc

Impressive results with --gc:orc

"with ORC i have less memory used when working." this is probably because your app has cycles and ARC can't collect them :) Also why do you care about --opt:size? And why do you use -d:useMalloc (it's really only used for debugging memory leaks or on platforms Nim's TLSF allocator isn't ported

Impressive results with --gc:orc

ORC ---> BUILD PROD termScr.nim-> termScr size : 578K ARC ---> BUILD PROD termScr.nim-> termScr size : 568K c -f --gc: ...ARC/ORC... -d:useMalloc --deadCodeElim:on --verbosity:0 --hints:off --hint[Performance]:off --warning[Un

Version 1.4.0 released

> Go was a consideration and there are a few libraries internally existed for > Go at that point, but nim in the end won out on acceptance and it convinced - > despite the known risks of using a only semi-mature language - on feasibility > in getting it done in time for the initial game release.

push/pop hints on/off not working?

My top level advice was going to be pass --hints:off on the command line, and {.hints:on.} #...usercode you'd like to get [Performance] hints for {.pop.} Run but that doesn't actually work. let me see if i can explain {.push hints:off.} import

Ubuntu, snap install, "Error: cannot open file: strutils"

Hello, you should if you want to test quietly, go to [Nim](https://nim-lang.org/install_unix.html) I personally use curl https://nim-lang.org/choosenim/init.sh -sSf | sh Run This allows me to do my development with ease. So I have nothing in the base system for my tests

Tuple unpacking and '_' - not being discarded?

Good to know. Thanks!

Tuple unpacking and '_' - not being discarded?

known issue

Tuple unpacking and '_' - not being discarded?

That sounds like a significant difference. The unittest.check macro manages to require parentheses that aren't normally required: I'd suggest getting a minimal example and creating an issue for it.

Tuple unpacking and '_' - not being discarded?

As per the documentation, I'm trying to "unpack" a tuple like this: let (a, _) = getSomeTupleValue() Run So, in that sense, I imagine I'm just assigning `a` to the first element of the tuple, and discard the second. However, this is what I'm getting when compiling:

Tuple unpacking and '_' - not being discarded?

I was using 1.5.1 devel and thought I tried 1.4.0 to see if that was the case. However, in 1.4.0, I keep getting the exact same message. I still cannot figure out why I get the Hint and you don't. The only difference I guess would be that I'm using it in a template?

Tuple unpacking and '_' - not being discarded?

You're not missing something. It looks like a bug. But I don't see it in 1.4.0: let (a, _) = (1, 2) echo 2 Run This hints about unused `a` and not about any other unused variable. If I echo `a` instead I get no hints.