Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Missing stdout output #129

Open
sitepodmatt opened this issue Dec 7, 2013 · 5 comments
Open

Missing stdout output #129

sitepodmatt opened this issue Dec 7, 2013 · 5 comments

Comments

@sitepodmatt
Copy link

I think this stackoverflow thread sums it up pretty well as behavior is observed via lein repl (and indirectly via vim-fireplace):
http://stackoverflow.com/questions/20437767/what-happens-to-second-println-statement-clojure-repl?noredirect=1#comment30532207_20437767

Thanks.

Okay so its look like REPL-y tries captures the result of the whole expression first as this prints nothing for 15 seconds
(map (fn [x] Thread/sleep 5000 (println "x") x) [1 2 3])

Should ideally stdout buffer be flushed if an exception occurs like on vanilla clojure repl? Or would this side effect confiict with the idea of printing the result of the expression

@trptcolin
Copy link
Owner

Interesting - now when you saw via vim-fireplace, does that mean you spin up a lein repl and then send commands to it via vim? If so, that makes me think there may be something on the server side of nREPL that does this.

After not-yet-enough digging, I suspect what's happening is this: nREPL sets up session bindings for *out*, which since we're creating a lazy seq are lost before nREPL goes to print out the seq for transport back to the nREPL client (REPLy, vim-fireplace, etc.).

This experiment would seem to support that theory:

user=> (doall (foo nil))
nil Hello, World!
Hello, Mars

Exception talking to many planets  user/foo/fn--668 (NO_SOURCE_FILE:5)

I opened an nREPL ticket in JIRA to track this: http://dev.clojure.org/jira/browse/NREPL-45

@cemerick
Copy link
Contributor

Replying here instead of on JIRA, because I cannot replicate this in at least one nREPL environment (cider). There, I get:

user> (foo nil)
nil Hello, World!
Hello, Mars
Exception talking to many planets  user/eval7991/foo--7992/fn--7993 (form-init3244858523243413901.clj:5)

This is with Clojure 1.6.0-alpha3, nREPL 0.2.3, cider 0.6.0alpha (basically the current HEAD). FWIW, lein repl doesn't output the 'Mars' line, so there's definitely something going on there; but, I'm reasonably sure it's not nREPL itself given the results I see via cider.

@trptcolin
Copy link
Owner

OK, I don't know much about cider but it does appears to set up some middleware (maybe it changes the forcing behavior?). I'll try and install it sometime soon and see what's happening there.

Can you see why/how any *out* output forced during the (with-out-str (pr val)) could possibly escape out of the nrepl pr-values middleware? I'm stumped, I thought the test case in my patch proved that it doesn't.

@trptcolin
Copy link
Owner

OK, I got cider 0.6.0alpha (from Melpa - I tried Marmalade first but got 0.5.0), nREPL 0.2.3, clojure 1.6.0-alpha3, and I'm still seeing:

user> (foo nil)
nil Hello, World!
Exception talking to many planets  user/foo/fn--1208 (form-init8029966451087486244.clj:5)

But! When I turn on cider-repl-toggle-pretty-printing, that does the trick. It turns out it's actually wrapping the execution in a pprint instead of using the actual :value:
https://github.com/clojure-emacs/cider/blob/5d650ba612a3be3fc0de79272ed7525d599d920f/cider-util.el#L74-L76 It would be unfortunate for all clients to have to do something like that, but if that's the path we have to go down I can work on that.

@cemerick let me know what you think.

@cemerick
Copy link
Contributor

Gah, you're right. Pretty-printing trolls me again. :-P

Taking a second look at the proposed patch now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants