-
-
Notifications
You must be signed in to change notification settings - Fork 646
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
nrepl-el appears to swallow *err* output and *out* output from futures? #237
Comments
This seems like it might be related to #217 |
@ptaoussanis what version of nrepl.el and leiningen are you using? Futures are working for me on nrepl.el 0.1.6. Also, here is relevant link about output from the nrepl server: |
Thanks for the response (and sorry for the delay replying to this) - I can confirm that 0.1.6 seems to solve both the std-err and future printing. Much appreciated! |
Spoke too soon; had forgotten I'd already put a workaround in place for std-err. 0.1.6 seems to solve future printing, but not printing to std-err: (binding [*out* *err*] (println "Test")) ; Still seems to get swallowed as of 0.1.6 |
Quick update that this still seems to be an issue as of 0.1.8-preview |
This is still a problem: user> (future (println "starting")
(Thread/sleep 3000)
(println "3s"))
starting
#<core$future_call$reify__6272@3ce8b3f7: :pending>
user>
(I'm using nrepl.el 0.2.0alpha, so apologies if this is fixed on HEAD; I leave my emacs environment in emacs-live's hands still.) |
Thinking about this a bit more, I'll bet that cider stops routing output properly as soon as it sees an nREPL status of |
Right; here is where the callback for a particular message is being removed from the hash that holds them. And here is where messages fall through to the default handler if their ID has been noted as already "done". It may be presumptuous of me to offer design advice on an elisp project…but, I would suggest that, for the majority of nREPL messages, the session is the important identifier, not each individual request ID. The latter are helpful when pairing up evaluations with results in a programmatic way, but not much else; session IDs are what are generally associated with user-visible entities, like the REPL buffer. They also have the benefit of being relatively long-lived, and of small number, so you can often not worry about GC'ing handlers for them (or, even better, use some editor/IDE-provided "metadata" on windows/buffers in order to dynamically look up where results/output should be routed, rather than maintaining that mapping explicitly [either via fns or a hashmap]). |
@cemerick This is definitely a bug. Thanks for your suggestion regarding a potential solution. Hopefully I'll be able to cook some fix sooner rather than later. |
@bbatsov Happy to help however I can. Real tangible assistance may need to wait until I understand (even a little bit) the whole emacs packaging thing. Sorry for the peanut gallery-style "you know what you should do…" B.S. in the meantime. |
@cemerick I'm finally trying to fix this now and there a few points I wanted to discuss with you:
I was also contemplating where is the output from interactive form evaluation supposed to go. Currently all output is routed to the REPL, but it seems to me the minibuffer is a more sensible place for it. I wonder how they handle this in other Clojure IDEs. |
@bbatsov Sorry for the absurd delay in replying, this one fell through the cracks. Within a Clojure context, because an expression can spin off new threads, agent sends, futures, etc., it's not really sensible to ask "is an evaluation 'outstanding'". In principle, the scope of each evaluation's effects and "running time" is unbounded. You could certainly get fancy with program analysis to determine the actual effective scope of an evaluation's effects (in terms of provoking running computation), but that's far afield. I don't exactly know what @samaaron is getting at in #155 (I haven't looked at swank in years, and wasn't super-familiar with it then), but I suspect SLIME/swank didn't enforce one-at-a-time evaluation within the scope of a given REPL session as nREPL does? (I infer this from his statement that swank creates a new thread for each evaluation.) If that's the case, then the answer there is that the number of running evaluations is always capped by the number of active nREPL sessions; depending on what you wanted to report, you could also be interested in the number of pending evaluations. That would be ~ I'm not sure what you're referring to re: "rogue requests". |
By rogue requests I meant responses from requests for which we already receive |
The text was updated successfully, but these errors were encountered: