Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Send output from all threads to nrepl buffer #83

Closed
kingtim opened this Issue · 19 comments

5 participants

@kingtim
Owner

@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

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
Owner

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

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

@lnostdal

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

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

@kingtim
Owner

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

Also, print does work.

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

println doesn't.

@kingtim
Owner

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

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

@Raynes

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

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
Owner

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

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

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

@kingtim
Owner

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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.