@flowthing the issue with nREPL is the completions namespace which spawns futures at the top level. if you change that to delays, it works.
I have a native version of REPL-y in a private repo. I can invite you if you want. I'm not ready to publish this code, since it's hacky
Yes, I did manage to compile a native image from the nREPL repo, but is that useful?
The future -> delay change I think we should make in any case.
Or maybe I've misunderstood something and you actually can use clojure.core/eval
with a native image?
no, you can't
this is the entire point of sci basically
Right, that's what I thought. I'm just trying to understand why it's useful to compile nREPL into a native image, then. 🙂
I think a native nREPL client (like REPL-y) could be useful. A server probably not so much, unless it's hooked to an evaluator which can run inside a native image, like sci. This is why babashka has an nREPL server
Right, I can see that a client might be useful. Is an nREPL client what clojure-lsp needs?
I think they just added it as a dev dependency
I think the largest effort in making nREPL compile into a native image is to add checks to ensure that nobody breaks native image compatibility in the future.
which is basically why I rolled my own version of an nREPL server
also to keep the image size down