Send output from all threads to nrepl buffer #83

Closed
kingtim opened this Issue Aug 26, 2012 · 19 comments

Projects

None yet

5 participants

@kingtim
Member
kingtim commented Aug 26, 2012

@metajack reported this against #81. I am not sure if/now we can support this, but I am creating this issue to track it separately.

From #81:
Say you launch a thread that outputs to stdout. In slime/swank, this output appears in the swank buffer instead of the slime repl buffer. Only output from the current thread in the repl appears in the repl buffer by default. You can override this by doing alter-var-root!, but it's quite annoying, and you see people asking where their output went occasionally.

This is also the current behavior in nrepl as well, which you can see by running:

(.start (Thread. #(println "foo")))

This will print only in the nrepl-server buffer.

@lnostdal
lnostdal commented Sep 9, 2012

Possibly related:

Doing nrepl-eval-region, nrepl-eval-last-expression, nrepl-eval-buffer or nrepl-eval-expression-at-point with (top level) forms like:

(println "hi, i'm a top level form")

..results in no output; not even in the nrepl-server buffer.

@kingtim
Member
kingtim commented Sep 9, 2012

@lnostdal In which version of nrepl are you seeing this behavior?

Those should be working on master now. See issue #81.

@lnostdal
lnostdal commented Sep 9, 2012

Indeed. I switched from marmalade to melpa and top-level (println "....") works.

Stuff like (.start (Thread. #(println "foo"))) doesn't though, but I guess that's known. Same goes for exceptions: (.start (Thread. #(/ 42 0))

@Raynes
Raynes commented Sep 23, 2012

(future (println "foo")) I'm not getting any output at all anywhere. I'm seriously about to hurt things.

@kingtim
Member
kingtim commented Sep 23, 2012

@raynes which version of nrepl.el / lein? This seems to work for me.

; nREPL 0.1.5-preview user> (future (print "hi")) hi #<core$future_call$reify__6110@7cf42466: nil> user>

@Raynes
Raynes commented Sep 23, 2012
; nREPL 0.1.5-preview
user> (future (println "hi"))
#<core$future_call$reify__6110@3f8771dc: :pending>
user> 
[nrepl.el (master)]$ git rev-parse HEAD
21245f4c64bf89c17ea805f4c74fca5b86b64ab5
[leiningen (master)]$ git rev-parse HEAD
b86095c61b4e400fb64d883466b9839f81ca0a29

Latest master of both.

@Raynes
Raynes commented Sep 23, 2012

Also, print does work.

user> (future (print "hi"))
#<core$future_call$reify__6110@718df055: :pending>
hi

println doesn't.

@kingtim
Member
kingtim commented Sep 25, 2012

Sigh.... I'm still not able to repro this with print or println. Not sure what the difference is.

; nREPL 0.1.5-preview
user> (future (print "hi"))
hi
#<core$future_call$reify__6110@3d29c838: nil>
user> (future (println "hi"))
hi
#<core$future_call$reify__6110@3301e56: nil>
@ryfow
Contributor
ryfow commented Sep 25, 2012

Same here. println and print both work for me when futured.

@Raynes
Raynes commented Sep 25, 2012

I've tried everything I can think of. It isn't your fault. Just one of those broke-for-me-but-nobody-else things.

@lnostdal

Side question (or note) here; I just did an upgrade and now the *nrepl-server* buffer is gone which means it is now 100% impossible to see what's going on in background threads. Everything is gone or invisible; debug (println etc.) output and stack traces..

@Raynes
Raynes commented Sep 25, 2012

I think you and I are having the exact same problem, only I could never see output at all even in those buffers.

@lnostdal

Hmm, well not exactly. Output and exceptions from futures and agents etc. work as before here.

By threads I meant "Java threads" spawned by things like netty (Aleph); those have never worked proper for me (and I'm pretty sure no one else), but their output and exceptions did end up in the *nrepl-server* buffer which at least made it possible to still use this..

..again; something has changed very recently; the *nrepl-server* buffer is gone.

edit: @kingtim below: i see, ok, thank you! :)

@kingtim
Member
kingtim commented Sep 25, 2012

@lnostdal there was a recent pull request which changed the name of "*nrepl-server*" to " *nrepl-server*" (leading -space). I guess this is an emacs convention to treat them as special buffers.

From http://www.gnu.org/software/emacs/manual/html_node/elisp/Buffer-Names.html

Buffers that are ephemeral and generally uninteresting to the user 
have names starting with a space,
so that the list-buffers and buffer-menu commands don't mention them 
(but if such a buffer visits a file, it is mentioned). 
A name starting with space also initially 
disables recording undo information; see Undo.

In any case, I have switched it back because so you can find these buffers.

@Raynes Sorry you are having problems. I have a few ideas of what might be happening and I am looking at it.

@deflexor

Hello, have same problem (emacs 24), just fetched recent nrepl.el from github:

; nREPL 0.1.5-preview
user> (future (print "hi"))
#<core$future_call$reify__5508@6c089bd6: nil>
user> (future (println "hi"))
#<core$future_call$reify__5508@641e8314: nil>
user> 
@kingtim
Member
kingtim commented Oct 20, 2012

Hey all, I have made some progress on this. I have just made a commit to master which handles the case where stdout messages from the nREPL server after the evaluation is "done". I think this will help fix some of these cases.

user> (future (do (println "before sleep") (Thread/sleep 10000) (println "after sleep")))
#<core$future_call$reify__6110@4b7385be: :pending>
before sleep
after sleep

user>

This still doesn't fix the (.start (Thread. ...)) case.

@deflexor

Hello, just fetched latest el from repository, now it works, thank you.

@Raynes
Raynes commented Oct 22, 2012

This is fixed as of my pull 10 seconds ago too.

@kingtim
Member
kingtim commented Dec 11, 2012

I am going to go ahead and close this issue.

For the (.start (Thread. ...)) case, the solution will have to come from the server side I believe.

See https://github.com/clojure/tools.nrepl/wiki/nREPL.Next (in the Unknowns - *out* /`err`` section for more details.

@kingtim kingtim closed this Dec 11, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment