Yes I understand. What I generally would do is first open the main file
fancygl.nim, and jump from there to other symbols (Ctrl W for my editor).
Explicitely opening additional related files should work as well. But when I
additional open shadingDsl.nim nimsuggest does not work properly any more
Ah, I got confused about macros. I made the loop body a normal, dull `proc`
again and it actually ran _faster_. Premature optimisation, I guess. Thanks for
your help! My little toy brainf*ck interpreter is looking good.
@Stefan_Salewsk Well that file is included like all other files from the
includes folder from the main nim file, here:
[https://github.com/krux02/opengl-sandbox/blob/master/fancygl.nim](https://github.com/krux02/opengl-sandbox/blob/master/fancygl.nim)
The entire discussion is about autodetecting
Sorry, do not understand. Your linked file gives a lot errors about missing
symbols when I try to compile it, so I do not wonder that nimsuggest shows
errors.
Thanks for the ideas. I did not get much info from running boehm. When I have
more time, I'll try markandsweep, and also tlsemulation.
> It's often best to limit the number of threads to the number of cores on a
> processor...
I don't know how to do that. Nim's threadpool does not offer a way.
Well for me it simply does not work at all. I tried out both emacs and VS-Code
with this file here from my project:
[includes/shadingDsl.nim](https://github.com/krux02/opengl-sandbox/blob/master/includes/shadingDsl.nim)
Emacs shows a lot of error messages for unknown symbols. The same was for th
I use the UI0.9 module examples, compiled by release model program, first run
in the windows environment, you need to wait a few seconds before they can be
displayed. And the interface with IUP compiler module does not have this
problem. It's weird.Is there a problem with libui.dll?
