Fork me on GitHub
#nrepl
<
2019-02-22
>
dominicm09:02:13

@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?

cichli09:02:22

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

cichli09:02:06

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

dominicm10:02:18

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)
Oh, fwiw, this is the trace of creating the printwriter

dominicm10:02:17

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

dominicm10:02:38

Adding :transport there fixes the bug for me

cichli10:02:06

Just realised the same thing 😄

cichli10:02:26

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

cichli10:02:08

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

cichli10:02:59

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

dominicm10:02:27

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

cichli18:02:30

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?

dominicm18:02:55

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

cichli19:02:25

It shouldn’t be needed with the new piggieback though

rgm05:02:33

Victory! OK … so I needed to do a couple things:

rgm05:02:48

1. bump to 0.4.1-SNAPSHOT, 2. Patch fireplace.vim, 3. Make sure a cljs-repl was started in the terminal REPL, before trying to run :Piggieback

rgm05:02:59

so it’s finally working (piggieback + vim/fireplace + figwheel + deps.edn) and I made some notes here: https://github.com/rgm/reframe-template/issues/1#issuecomment-466619263

dominicm14:02:42

@cichli that's working perfectly for me, thanks!

dominicm10:02:01

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

cichli10:02:34

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

cichli10:02:48

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

dominicm10:02:24

@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 🙂

cichli15:02:33

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

rgm17:02:14

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

rgm17:02:45

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

rgm17:02:50

(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).

cichli19:02:45

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'

dominicm20:02:03

That message is normal, yeah