This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # adventofcode (11)
- # beginners (155)
- # boot (627)
- # cider (64)
- # cljs-dev (110)
- # cljsrn (36)
- # clojure (290)
- # clojure-austin (21)
- # clojure-russia (2)
- # clojure-spec (2)
- # clojure-uk (21)
- # clojurescript (81)
- # code-reviews (2)
- # core-async (33)
- # cursive (6)
- # datomic (9)
- # emacs (1)
- # hoplon (472)
- # instaparse (1)
- # lein-figwheel (4)
- # luminus (13)
- # om (2)
- # protorepl (10)
- # re-frame (10)
- # reagent (48)
- # schema (2)
- # sql (5)
- # untangled (17)
- # vim (1)
- # yada (108)
okay, I think I can almost see why this is happening. The relevant code is here: https://github.com/clojure-emacs/cider/blob/master/cider-repl.el#L553
The position that is used to start the output is
cider-repl-input-start-mark. I am only guessing as to what’s happening here, but it seems to me that when printing to clojure’s
cider-repl-input-start-mark has already been set to be the beginning of the next prompt, and
cider-repl--emit-output-at-pos inserts the text before that prompt.
However, for a reason I haven’t been able to get to yet, when printing to java’s
cider-repl--emit-output-at-pos is called while
cider-repl-input-start-mark is still set to the beginning of the current prompt, which causes the weird out-of-order behavior I’m seeing.
even if I end up being right about that, I don’t see a very obvious way of working around it.
all the same, it is very late, so I’m done for now. here’s to hoping I wake up to someone who knows their way around this code 🙂
in case anyone’s following along with my public rubber duck session here - I have disproved my guess about
more info sharing is in order, then - If I write a function that alternates writing to
*out*, and then run it from a cider repl, it will alternate putting the output before and after the same prompt.
cider-repl-input-start-mark is dynamically changing multiple times during one eval, my guess above is invalid
but also, the java outputs have to be streams, and the clojure ones need to be writers
so there were bytes hanging around and when it called print on the bytes nothing was happening?
System/err went only to the main process. If you jacked in, that’s the server buffer. If you have a repl running in a terminal, it’s that repl.
here’s a stab at explanation:
System/out by default. You can redirect
*out* so that it doesn’t go to
System/out, and this is basically what cider does to get clojure output where it needs to go.
However, java is writing directly to
System/out, without first going through
*out*. So, redirecting
*out* has no effect on those java processes
and that does what it normally does and then sends it to all relevant sessions as well
I create a new System/out that does the session redirection, and then wrap that stream with a PrintWriter, which gets set to
I don’t think it’s dangerous - the way cider does the redirection still includes the original out
Is there an instructive video showing cider features for debugging macros? I'm looking for anything more useful than (pprint (macroexpand-1 ...))
@dpsutton earlier you mentioned something about eval id’s. could you point me to where that is?
if you turn on
nrepl-toggle-message-logging and then go to the messages buffer for the connection, you can see the info going back and forth from nrepl
well I think you’re on to something there, @dpsutton. For output that works correctly, it sends the code to be eval’d with an id, and then receives a response with that id. When doing something like
(.println (java.lang.System/out) “something”), the id of the message that is sent doesn’t match the id for the stuff that’s printed.