Stafan_Salewski, yes, thanks for reminding about that again. The twinprimes code is old (almost a year, using 0.17.x), when I was just getting seriously into converting C++ code into Nim. Using the original construct for that loop worked, because I always compiled with `gc` on. Then I started playing with compiling with `--gc:none` to see the difference. If you open a terminal window with `htop` while the program ran you can see memory being eaten up in real time - fascinating. I ultimately found that problem too, and all current versions of all my code has corrected that implementation. But when 0.18.0 came out, I realized I had never updated THAT original code, and used it to update with (it works fine doing a default compile). As soon as you showed me that I looked at my current codebase and they all had the correction, so they can run without `gc` and not eat up memory.
But to the original issue, I `think` I've traced it to the differences in `gcc` versions. My base system on my laptop is old, and I've never (yet) gotten around to updating it. It uses `gcc 4.9.2`. So what I observed occurred on that configuration. Today I installed 0.18.0 in a VB with the updated distro of my base system, which uses `gcc 7.3.0` and voila! the programs run with-or-without compiling with `gc` on|off. So that `seems` to be the cause of the different behaviors in runtimes (as they all compile on both systems). (Actually, this is one reason|excuse I keep my old configuration around, to see what stuff breaks on it.) One lesson learned: don't change the compiler option settings I put in my code for the exact reason why it's there. I'm going to run tests in other VB distro instances, to make sure the code runs on those systems too. But this makes me feel better that its not 0.18.0 per se, but which compiler is used with it. If I really feel motivated to experiment, I may see what the behavior is on both systems compiling with `clang`.
