@juhoteperi: I also see :Source printed to browser console.

Eval works with results though :Eval (js/prompt "test") returns my input.

I see this with chestnut btw.

Hm, from the chestnut repl, when I run (cljs.repl/source om.dom/h1) I see it both printed in the browser and outputted to the repl. I think maybe that this PR with piggieback doesn't capture the output for some reason.

So anything that uses (println) isn't working with Figwheel + Piggieback.

Also worth noting that vimscript: echo fireplace#client().eval('(cljs.repl/source om.dom/h1)', {}) returns {'status': ['done'], 'id': 'fireplace-hostnames-1468910433-46', 'session': ['c09f9597-5a6f-4b9e-8b30-f20d0f32e4f1'], 'ns': 'cljs.user', 'value': 'nil'} So the eval implementation isn't picking up the result for whatever reason. Might be a difference between a repl-env and figwheel, unsure.

Funny enough, if I open the figwheel repl cli, and then go back to fireplace to run source I see the output there.

Eval response nil is okay, because source prints the result and returns nothing

There is some problem with Figwheel Repl println redirection, not sure yet what

Yep. But there's no out key.

{'status': ['done'], 'id': 'fireplace-hostname-1468910433-55', 'out': '(gen-react-dom-inline-fns) ', 'session': ['d937ad03-f2d3-46d4-bded-47d0fcef0200'], 'ns': 'user', 'value': 'nil'} This is from clojure for example. Which is what we'd expect. No idea how figwheel is supposed to work.

Figwheel should always redirect the output to both browser console and nrepl

Cljs repls work differently

I think

I'll check with boot-cljs-repl now what the raw return should look like.

Both Weasel and Figwheel print the redirected output to \out\ at the point of repl creation

{'status': ['done'], 'id': 'fireplace-hostname-1468860905-76', 'out': '(defn atom (fn-body))', 'session': ['66da3ad2-a4e6-4638-ac9a-7d78b48d0997'], 'ns': 'cljs.user', 'value': 'nil'} But their raw nrepl op eval, returns an out key.

Aha, something to do how Piggienback catches the output

Or cider-nrepl, because I think that's only thing that is catching the output and adding it to the response

https://github.com/clojure-emacs/cider-nrepl/blob/master/src/cider/nrepl/middleware/out.clj

But why would this work with weasel but not figwheel

Maybe it's piggieback that it works with? Figwheel implements it's own cljs-repl "thingy"

No, Figwheel uses Piggieback

It replaces Weasel

Oh, I really need to get my head round this relationship.

Piggieback is the nrepl middleware which needs to be used to provide eval-op support for cljs repls

Weasel is WebSocket Repl server & client

Figwheel has it's own Repl server & client

server in this case = http server with web socket

Editor sends eval command -> Cider nrepl wraps it (sets \out\ to specific value) -> Piggieback sends it to active Repl which is built using figwheel or weasel env -> Sends command to the browser over WS -> Browsers evals the stuff -> Sends response over WS back to the server (and sends outputs over WS to the server) -> Cider nrepl adds catched output to the response

I see. That's a huge pipeline. I think I get it though.

:Source works if I do boot dev instead of boot cider dev. I agree this is a CIDER problem.

Hmm what does cider task do?

Do you have cider middleware setup at profile.boot?

https://github.com/boot-clj/boot/wiki/Cider-REPL#a-better-way

I wonder if the order of middlewares could matter...

https://github.com/clojure-emacs/cider-nrepl/blob/master/src/cider/nrepl/middleware/out.clj#L105

I'm really stupid. Ignore me.

The problem isn't boot.

Boot works.

I thought this means that out middleware requires piggieback

Lein fails.

Okay, what I said is still true.

When I disable the plugin in leiningen, :Source works.

Trying with manual specification of :nrepl-middleware

I'll try fiddle with order

Which plugin? Cider?

Yes, CIDER. Although I did disable refactor-nrepl also, so it's possible that's a culprit.

Aha, tools.nrepl also takes care of output: https://github.com/clojure/tools.nrepl/blob/master/src/main/clojure/clojure/tools/nrepl/middleware/session.clj

With cemerick.piggieback/wrap-cljs-repl before and after the cider.nrepl.middleware.out/wrap-out middleware, I am unable to run :Source

Hmm, but it's still a problem with that cider middleware enabled.

Not working reliably without cider-nrepl for me

It works sometimes then?

I think it worked once, can't reproduce

Hmm, strange. Maybe it's below cider then, and cider reading *out* just triggers the underlying problem.

Yeah, I can't repro either it seems.

That's frustrating. I thought we had it then.

If we figure out a way to get it to work, it might be worth checking the value of *print-fn*, to see who owns it.

https://github.com/bhauman/lein-figwheel/blob/42f2dbef234e6476bd24386bcd69f60666603df3/support/src/figwheel/client.cljs#L21 might be worth following this code path (as it's the print-fn)

Afaik that works, you can check websocket connection from dev tools and you should see that Figwheel sends the message from browser to repl server

and figwheel server code receives the message and prints it, I have debugged this far, for some reason it prints to wrong buffer

I think it's supposed to print to all buffers.

I do wonder if maybe the output isn't being caught in time?

it is supposed to print to special buffer created by Cider which redirects output to other buffers

Or Tools.nrepl if Cider is not used

ah, I see. You're well ahead of me then.

Piggieback! (cemerick.piggieback/cljs-repl (adzerk.boot-cljs-repl/repl-env)) works seamlessly, which is nice.

https://gist.github.com/SevereOverfl0w/4b173fad16e7d13b2210555604fda8f6 I can talk to figwheel programatically, and it works.

That implies something that vim expects is incorrect. I am completely stuck on what though

I should have perhaps tried that with fireplace's python lib

Works with fireplace's python library also. No way am I releasing this ugly-ass code though.

So it's something about how fireplace interacts with a piggieback I guess

Maybe it is cloning too much.

Piggieback (adzerk.boot-cljs-repl/repl-env) works fine also

I wanted to confirm that it wasn't something to do with the patch