Is IcedJackIn isolated from other repls?

[mars0i]

I'm not sure whether I'm thinking about this correctly, or whether I understand what is happening.

I'm running exploratory simulations in a repl that take a long time to run. I run lein repl (not iced repl) in a terminal, and then I use IcedJackIn so that vim-iced still works, and so that I can do quick experiments with my code while the long process is running. So I end up with two repl client/server pairs.

But there is one situation in which I see output from the vim-iced repl in the terminal for my other repl. When I require metasoarous/oz.core in Vim with vim-iced, I first see some warnings (because of Clojure 1.11 name conflicts) appearing the iced stdout buffer--that's good. But I also see SLF4J logger errors in the terminal window that I'm running lein repl in. That is, messages about code that I evaluated in vim-iced are showing up in the window for a different repl! (If I don't have a second repl running separately from the JackIn repl, those SLF4J messages don't appear anywhere. Maybe they go to stderr and that's not captured in the stdout buffer?)

I don't care about the SLF4J warnings, but seeing them in the wrong place seems weird. How does the nRepl that vim-iced started know about the client/server repl pair that I started separately from vim-iced? It makes me wonder whether there is some interaction between the two client/server pairs. Or maybe it's just that the SLF4J library does something strange and goes looking for an nRepl client on its own?

I noticed that there is only one .nrepl-port file, and the vim-iced pair overwrites it. I thought that maybe this has something to do with the SLF4J warnings going to the wrong window. But I've run multiple instances of lein repl in the same project directory before, and I never noticed messages from one going to the other.

If this is only a problem about where text output goes, it's strange, but I don't care. I would care, though, if messages affecting state in the two nRepl processes are getting mixed up. That doesn't seem possible to me, but getting the SLF4J messages in the wrong window wouldn't seem possible either.

(Again, I'm not sure I am describing the situation correctly. I don't know a lot about nRepl.)

Thanks again.

[liquidz]

@mars0i Thanks for your reporting!

Ah, I think I may have found the cause. IcedJackIn waits for a successful auto connection from the .nrepl-port file after starting a REPL internally. https://github.com/liquidz/vim-iced/blob/ecb65532a1b8a91df86ac7b3240fd11a4b08c185/autoload/iced/nrepl/connect.vim#L110-L115

If vim-iced detects an existing .nrepl-port file and auto connects to it before the REPL started by IcedJackIn overwrites the .nrepl-port file, it will connect to the REPL started by lein repl separately. At that time, evaluating (require '[oz.core :as oz]) will reproduce this problem.

Are you sure tha the following texts are output to :message?

iced-nrepl is not enabled. Please launch repl with the `iced repl` command.

Workaround for now is to delete the existing .nrepl-port befure executing :IcedJackIn.

On the vim-iced side, it may be good to check if the detected .nprel-port file was generated before the REPL was started by IcedJackIn.

[liquidz]

@mars0i In dev branch, I fixed to check the last modification time for .nrepl-port file for trial. Could you try?

[mars0i]

@liquidz, thanks for responding so quickly! Yes, deleting the .nrepl-port file makes the problem go away, and the new dev branch seems to fix it. (I don't know where the SLF4J messages go, but I don't care. I don't want to see them anyway!) Thank you. Excellent.

(Yes, IcedConnect says "iced-nrepl is not enabled. Please launch repl with the iced repl command." as expected when I run lein repl.)

I had been afraid to delete the .nrepl-port file--I worried that that would break something. I guess it's only used during initial connection.

[liquidz]

@mars0i Just released v3.8.6 #402 .nrepl-port files no longer need to be deleted :)

[mars0i]

Thanks!