Fork me on GitHub
#cider
<
2016-12-30
>
bhagany00:12:56

yep. I definitely don’t understand why or how the output prints before the prompt

bhagany00:12:33

I probably need a break

bhagany06:12:42

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

bhagany06:12:16

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 *out* or *err*, 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.

bhagany06:12:05

However, for a reason I haven’t been able to get to yet, when printing to java’s System/out or System/err, 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.

bhagany06:12:46

even if I end up being right about that, I don’t see a very obvious way of working around it.

bhagany06:12:20

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 🙂

bhagany17:12:44

in case anyone’s following along with my public rubber duck session here - I have disproved my guess about cider-repl-input-start-mark above

dpsutton18:12:35

i'm gonna jump on this with you later

dpsutton18:12:46

there's thing with eval id's that it might try to reorder things

dpsutton18:12:50

and start marks

dpsutton18:12:59

either way i'm looking into this with you today after lunch

bhagany18:12:21

that’s fantastic, thank you!

bhagany18:12:37

more info sharing is in order, then - If I write a function that alternates writing to System/out and *out*, and then run it from a cider repl, it will alternate putting the output before and after the same prompt.

bhagany18:12:20

So unless cider-repl-input-start-mark is dynamically changing multiple times during one eval, my guess above is invalid

dpsutton18:12:00

you're running lein install on your updated copy of cider-nrepl to install it?

bhagany18:12:42

I simplified things a bit as well… I’ll push my branch

dpsutton20:12:02

@bhagany what's the significant difference between printwriter and printstream?

bhagany20:12:19

@dpsutton type-wise, writers work on strings, and streams work on bytes

bhagany20:12:51

but also, the java outputs have to be streams, and the clojure ones need to be writers

dpsutton20:12:56

so there were bytes hanging around and when it called print on the bytes nothing was happening?

dpsutton20:12:12

did the proxy not have anything to handle bytes?

bhagany20:12:22

you mean, before my changes?

dpsutton20:12:37

trying to understand why your changes rectify anything

dpsutton20:12:30

you seem to be calling (String. bytes)

bhagany20:12:30

so before, System/out and 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.

bhagany20:12:34

here’s a stab at explanation: *out* wraps 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.

bhagany20:12:10

However, java is writing directly to System/out, without first going through *out*. So, redirecting *out* has no effect on those java processes

dpsutton20:12:20

that's the redirect to the sessions it needs

dpsutton20:12:41

and how do you notice that's the case and redirect it when needed

dpsutton20:12:57

or is that what the system/setout stuff is doing

dpsutton20:12:08

when you get a call to java's systemout, use my forking printer

dpsutton20:12:11

forking stream

dpsutton20:12:24

and that does what it normally does and then sends it to all relevant sessions as well

bhagany20:12:39

I create a new System/out that does the session redirection, and then wrap that stream with a PrintWriter, which gets set to *out*

bhagany20:12:02

so now with my changes, System/out is the point of redirection, instead of *out*

dpsutton20:12:04

PrintWriter for clojure's \out\ and print streams for java's out?

dpsutton20:12:25

ah excellent

dpsutton20:12:28

thanks for explaining

bhagany20:12:53

no problem 🙂

dpsutton20:12:01

is it dangerous to hijack a jvm's notion of out?

dpsutton20:12:08

i'm very much a novice in jvm land

dpsutton20:12:16

or is that considered one of the things you have to do

bhagany20:12:48

I don’t think it’s dangerous - the way cider does the redirection still includes the original out

bhagany20:12:55

so from the outside, it looks the same

dpsutton20:12:11

i really like when this channel has discussions of ongoing development

bhagany20:12:24

hopefully others do too 🙂

qqq22:12:58

Is there an instructive video showing cider features for debugging macros? I'm looking for anything more useful than (pprint (macroexpand-1 ...))

bhagany23:12:18

@dpsutton earlier you mentioned something about eval id’s. could you point me to where that is?

dpsutton23:12:27

the idea is that everything to nrepl sent has a session and an id

dpsutton23:12:36

cider uses just an incrementing integer

dpsutton23:12:07

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

dpsutton23:12:12

you'll see that each thing has an id

dpsutton23:12:22

i have no idea if that's what the cause of the prompt shuffling is

dpsutton23:12:26

but that's where i would start

bhagany23:12:14

alright, thank you

bhagany23:12:57

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.

bhagany23:12:54

in fact, it seems like the returned output always has an id of “7”, no matter what the sent id was. So that’s weird.