Clojurians Log v2

@cichli I've had a bug report come my way which appears to be a bug in nrepl 0.6.0's printing stack. https://github.com/rgm/reframe-template/issues/1 I can't see how the replying-PrintWriter function is ever being called, because vim will never send stream? true. Somehow it looks related to the piggieback stack? But I'm not sure of that much either. I was hoping something might stand out to you as why that would be called with that particular stack?

https://github.com/nrepl/nrepl/blob/7721f2f8910faa00a278b52d608a1a6781c2fe0e/src/clojure/nrepl/middleware/interruptible_eval.clj#L76 looks like interruptible eval uses this directly.

It might be a piggieback issue, it does some manual bookkeeping to make sure *out* and *err* are bound correctly. But I’m not sure why transport would be nil

What exactly does :Piggieback eval to start the cljs repl?

java.lang.Exception: Stack trace
        at java.base/java.lang.Thread.dumpStack(Thread.java:1387)
        at nrepl.middleware.print$replying_PrintWriter.invokeStatic(print.clj:105)
        at nrepl.middleware.print$replying_PrintWriter.invoke(print.clj:99)
        at nrepl.middleware.interruptible_eval$evaluate.invokeStatic(interruptible_eval.clj:76)
        at nrepl.middleware.interruptible_eval$evaluate.invoke(interruptible_eval.clj:55)
        at nrepl.middleware.session$create_session$fn__8988.invoke(session.clj:143)
        at nrepl.middleware.session$create_session.invokeStatic(session.clj:142)
        at nrepl.middleware.session$create_session.invoke(session.clj:124)
        at nrepl.middleware.session$register_session.invokeStatic(session.clj:201)
        at nrepl.middleware.session$register_session.invoke(session.clj:197)
        at nrepl.middleware.session$session$fn__9029.invoke(session.clj:267)
        at nrepl.middleware$wrap_conj_descriptor$fn__8584.invoke(middleware.clj:16)
        at cider.nrepl$wrap_enlighten$fn__9440.invoke(nrepl.clj:162)
        at nrepl.middleware$wrap_conj_descriptor$fn__8584.invoke(middleware.clj:16)
        at nrepl.middleware.print$wrap_print$fn__8808.invoke(print.clj:238)
        at nrepl.middleware$wrap_conj_descriptor$fn__8584.invoke(middleware.clj:16)
        at nrepl.server$handle_STAR_.invokeStatic(server.clj:18)
        at nrepl.server$handle_STAR_.invoke(server.clj:15)
        at nrepl.server$handle$fn__9066.invoke(server.clj:27)
        at clojure.core$binding_conveyor_fn$fn__5739.invoke(core.clj:2030)
        at clojure.lang.AFn.call(AFn.java:18)
        at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
        at java.base/java.lang.Thread.run(Thread.java:834)

Piggieback does https://github.com/tpope/vim-fireplace/blob/1ef0f0726cadd96547a5f79103b66339f170da02/plugin/fireplace.vim#L323-L325 So (cider.piggieback/cljs-repl (whatever-you-give-it))

^ some of the numbers in the stack may be out a little, I've been sprinkling println debugging in

https://github.com/nrepl/nrepl/blob/7721f2f8910faa00a278b52d608a1a6781c2fe0e/src/clojure/nrepl/middleware/session.clj#L140 this looks like it could be the issue? Transport isn't being conveyed here

Adding :transport there fixes the bug for me

Just realised the same thing 😄

As a workaround: just make sure you eval something in the session before calling piggieback

I think we don’t want to pass transport there – otherwise initialising the bindings would cause responses to be sent on the transport

But piggieback should definitely be creating new PrintWriters for each eval message, same as nrepl does. Capturing them from @session is relying on nrepl implementation details

That workaround may not work. I think fireplace creates a new session for cljs, which is only available there.

You might be able to poke at fireplace to figure it out, but it's not an easy workaround 🙂

You’re right, it doesn’t use persistent sessions at all IIRC

I have to go catch a train in a few minutes but I’ll get a fix into piggieback this afternoon

@cichli that's awesome, thank you! ❤️ This was an interesting one to poke at, reminded me that I need to spend some more time working on nrepl 🙂

@rgm @dominicm any chance you could retest with [cider/piggieback "0.4.1-SNAPSHOT"]?

Just tried it and with 0.5.3 and 0.6.0/pback 0.4.1-snapshot I get the same ... progress (?) from this comment: https://github.com/rgm/reframe-template/issues/1#issuecomment-466411581

Running into a morning of meetings but (again) thanks so much for looking into this.

(This has that feeling like there’s a stack of errors of use, my own misconceptions and new-to-discover minor bugs that I’ll just have to pop one by one, so I really appreciate the help).

Just looking at the fireplace code, it looks like it does clone up a new session (see line 308). Does adding connection.eval("nil") on the line before the piggieback eval workaround the problem?

@rgm you'll be at a keyboard sooner than me ^^ :)

It shouldn’t be needed with the new piggieback though

If I connect to a regular Clojure REPL and start a CLJS REPL manually with: (cider.piggieback/cljs-repl (figwheel.main.api/repl-env "config/dev")) then I don’t get the nil IReplEnvOption error, but the first evaluation does raise that same Error: Cannot find module '@cljs-oss/module-deps'

Possibly related? https://github.com/bhauman/figwheel-main/issues/21

That message is normal, yeah