trampoline repl fails

[trptcolin]

I'm having some trouble tracking down why this is exactly, but lein trampoline repl will work without whidbey, but not with it. I tracked it down to the following request/reply sequence, but I'm not sure how this is happening:

# Both of these use pr-str
request: {:id "84c93587-7b69-4f2e-8664-28945c839272", :code "(clojure.core/binding [clojure.core/*ns* (clojure.core/symbol \"reply.eval-modes.nrepl\")] (set! *print-length* nil))", :op "eval"}
response: {:id "84c93587-7b69-4f2e-8664-28945c839272", :ns "user", :session "f10af298-3a82-4351-8d24-c6d537d9e838", :value []}

Note: the value is [] instead of "nil" or even "[]", so REPLy's read-string call fails on it. I actually haven't done much w/ nREPL middleware, but I'm wondering if somehow whidbey only gets partially installed or something under lein trampoline. Any ideas?

[greglook]

Hmm, I can reproduce this locally. I'll have to check out the trampoline setup code. It seems like whidbey is successfully dissoc'ing the default pr-values middleware, but maybe somehow not running and converting the :value in the response to a string?

[trptcolin]

Yeah, that's what I'm seeing. I can even (throw (Exception. "foo")) inside the fn constructed inside render-values. It's just not getting called, which makes me think maybe a lein bug w/ trampoline repl (not used as often) not hooking up middleware? Still not sure where [] comes from though, since it ought to be nil even if it's not printed.

[gfredericks]

Could this be related to NREPL-53?

Here's a leiningen profile that simulates my patch for that issue, which should help test that hypothesis.

[cemerick]

NREPL-53 is fixed as of [org.clojure/tools.nrepl "0.2.7"], so maybe @gfredericks' patch resolves this?

[greglook]

Thanks for the heads up @cemerick, I'll test it out!

[gfredericks]

Related: technomancy/leiningen#1829

[greglook]

Hey, this started working at some point!