Detect and kill rampant Nim processes

[omentic]

There is a known issue with nimsuggest and nim check eating up CPU usage on certain files: nim-lang/Nim#11679

This issue is a couple of years old, and might take a while to be fully resolved - different things appear to trigger it. In the meantime: could this extension detect and kill rampant processes? I'm unfamiliar with the design and limitations of VS Code extensions, so I don't know if that is technically feasible, but it would be a great improvement.

[saem]

it already does that, if you're having this issue chances are you didn't set nim.project, see the readme https://github.com/saem/vscode-nim#options

[omentic]

Sorry, but could you explain how nim.project works? I didn't understand just from the README. If you set a specific project.nim file, isn't that going to change from project to project?

[saem]

if nim.project is not defined then all nim files will be used as separate project

Yes, set it per Nim project, that's how it works. If you think it sucks, I agree. It's not a tractable problem for the extension, however.

[quantimnot]

@saem
I am confused about the nim.project too. So given this hypothetical package:

somedir_maybe_not_the_pkgident
|__ pkgident.nimble <-- package named pkgident
|__ pkgident.nim <-- main bin module
|__ src
     |__ lib.nim <-- imported in pkgident.nim and utils/tool.nim
|__ utils
     |__ tool.nim <-- is a support bin module

Would the project files be both pkgident.nim and tool.nim?

The compiler uses the presence of a nimble file to identify and create package symbols that own module symbols. You already have the code in vscode-nim to walk the tree and determine the package.
How about:

1. find all modules in the package
2. generate the dependencies of each module (nim genDepend)
3. filter out foreign package module deps
4. find the modules that are not a dependency of any of the others
5. assign those modules as the project files

I think that would yield the desired result.

[saem]

Yes, that trivial case works. Now please enumerate all the other possibilities because none of this stuff is well specified.

If you spelunk through the git history I bet you you'll find this silly command I wrote that did file system traversal to try and test the variants. There is also a forum post where I tried to solicit more test scenarios when the combinatorial explosion seemed bonkers. At best one can get a heuristic and it's not great. But please try, maybe I'm wrong.

Remember, cfg files, nims, folder and nim source naming conventions, etc all confer "projectness". The compiler (itself, nimsuggest, or check) can't really reason about things unless the project is correct. Not to mention people don't understand configuration basics, the amount of times people can't figure out that you need to specify the js backend in the config for nimsuggest and check to use it is amazing. Oh yeah, also one Nimble file can mean many projects, multiple binaries and/or hybrid. That last one is extra nice because name mapping destroys this information.

So yeah, I gave up trying to come up with a reasonable heuristic.

[saem]

Oh, I forgot, the gendepend bit is another thing I considered, but it's was slow.

It's the closet to a working solution, but just imagine the compiler where one has like 2000 test files. :D