I've been browsing the source of nimsuggest, and I realized markAndSweep is enabled for it, see: https://github.com/nim-lang/Nim/blob/devel/nimsuggest/nimsuggest.nim.cfg#L3
I'm curious: is there a specific reason why this flag hasn't been changed to arc or orc? Is there some limitation in the current implementation or the compiler itself?
Related: what's the plan for tooling with Nimony? Is the plan to build tooling directly on top of the NIF format? How would LSP features work with Nimony's new macro system (if at all)?
If it's possible to building tooling on top of NIF: would this enable writing a version of nimsuggest (ideally with LSP support) without the use of cyclical data-structures, and thus enable --mm:atomicArc / --mm:arc?
Or alternatively, does nimony's internal data-structures not have this design flaw?
For Nim2: has there been any effort in improving nimsuggest's performance? nimsuggest pegs the CPU at 100% at times (this issue pops up frequently on forums/github/etc.), nimlangserver has zombie processes, etc. I wonder if markAndSweep is the culprit for at least some of these issues? Also a nit on nimsuggest: after reading nimsuggest's code, the various v1/v2/v3+ codepaths in nimsuggest cause the codebase to be more verbose than necessary - why aren't old codepaths removed?
Sorry if that last paragraph came off as a rant - not my intention.
Or alternatively, does nimony's internal data-structures not have this design flaw?
Yes, that one. Nimony doesn't create cycles to begin with.
Also a nit on nimsuggest: after reading nimsuggest's code, the various v1/v2/v3+ codepaths in nimsuggest cause the codebase to be more verbose than necessary - why aren't old codepaths removed?
Stability is important for editor integration. Most of this integration code has to be written in the editor's terrible bullshit scripting language and never gets an update...