prints to stdout not appearing in 'calva says' output panel when an exception is thrown afterwards or when paused/waiting

[jurjanpaul]

When evaluating a form (when connected to nREPL) which prints to stdout and afterwards throws an exception, the original output never gets displayed in the 'calva says' output panel. (This is especially painful when troubleshooting.) Similarly, when evaluation of a form gets paused (because of I/O wait or hitting a breakpoint in the debugger), anything that was printed before is not (yet) displayed in the 'calva says' output panel (until evaluation successfully completes after all). Note: in neither case does invoking (flush) make any difference.

The desired behaviour would be: prints to stdout should be displayed in near-realtime. (Some buffering is ok of course, as long as (flush) does what is expected).

The issue with the thrown exception is easily reproduced by evaluating the form:

(do
  (println "hello world")
  (flush)
  (/ 1 0))

Note that "hello world" never gets displayed (it would of course if no exception was thrown).

Note: for this case printing to stderr already behaves as desired!

(binding [*out* *err*]
  (println "hello world")
  (/ 1 0))

At this moment I have not been able to come up with a simple reproduction scenario for the paused/waiting case yet, but I might be able to add that later.

Update:
The simplest scenario would of course be:

(do
  (println “hello world”)
  (flush)
  (read-line))

where one would expect the “hello world” to appear as/before the form evaluation is waiting for input.

[bpringe]

This was mentioned in slack but I just want to put it here for later reference: This may be related to the :nrepl.middleware.print/stream? optional param to the eval nrepl operation. See here: https://nrepl.org/nrepl/0.7.0/ops.html#_eval

It could also just be the way we're handling things in nrepl/index.ts, but I think more likely it's the former.

[jurjanpaul]

Just wondering why this is marked as enhancement rather than a bug? (was just bitten by this again; not finding the time to dig into this myself unfortunately; lots of unfamiliar moving parts.)

From the previous comment I do appreciate that this might not be trivial to fix.

[bpringe]

Yeah, I think I should have marked this as bug before. So just to note, this does as you desire if the eval occurs in the repl window (eval top level form in repl window). So some clues could be in the code that handles repl window output - I haven't looked yet myself. Perhaps we should bump this up in priority.

@PEZ What are your thoughts here?

[PEZ]

Not sure I agree it is a bug, but I'm fine with both. 😄

Sounds like you have some grips on this, @bpringe . I agree it should be prioritised .

[bpringe]

@jurjanpaul Would you mind trying this vsix and letting me know if it works for you? https://6275-125431277-gh.circle-artifacts.com/0/tmp/artifacts/calva-2.0.103-fix-stdout-message-streaming-89910f45.vsix

It works from me from what I understand is desired.

[bpringe]

Went ahead and released. If any issues, please reopen.

[jurjanpaul]

Yes! Thank you very much!
Just found the released update and this now works beautifully! :-)

Educational too to read the commit that fixes things... (never having read any actual TypeScript before).

Thanks again!

[bpringe]

Glad I could assist! Thanks for reporting and testing.

[PEZ]

I second that. Thanks for reporting and testing!