Fork me on GitHub
#calva
<
2023-09-05
>
Thierry07:09:30

I have a question about this git issue https://github.com/BetterThanTomorrow/calva/issues/2300 . I use vscode-insiders and always update to the latest Calva. Am I correct in thinking that it should be normal operation for any output printed to the stdout terminal that Calva opens to also be printed in the .output.calva-repl window/file? This is happening since about a week or so which coincides wit the v2.0.388 release. If this is meant to be like this, is there a way to turn it off? The application I work on does 'stuff' in the background which creates a huge amount of clutter in my repl window and makes repl development quite challenging :rolling_on_the_floor_laughing:

pez07:09:38

Yes, you can change this behaviour back to how it used to be. See https://calva.io/output/#repl-process-output-stdout-and-stderr Please let us know if that description makes sense to you. I hade a bit of struggle trying to describe it and don’t know how I fared.

Thierry07:09:01

Thanks, will have a look right away!

Thierry07:09:12

Makes sense to me, thanks for pointing it out. Going to turn it off 🙂

🙏 2
Thierry07:09:18

And it works like a charm.. much easier on the eyes haha

Dustin Getz10:09:22

can you tweak your dev logger config instead? presumably “stuff” is logs that are needed in prod but obviously you wish to silence them in dev

Thierry10:09:15

Works fine and just like before with this new setting. No need to tweak dev logging as it runs as is 'production' but with dev data

Thierry10:09:20

Thanks for the tip tho

Steven Lombardi18:09:46

I think it's a common use case to want to keep logs turned up locally. Makes debugging easier. I much prefer the logs going to my terminal in std out instead of the repl window.

Dustin Getz18:09:34

the java loggers (i.e. slf4j) have rich functionality for configuring where logs go, e.g. to a file or to a cloud log scooper

👍 2
pez18:09:00

It’s a bit unfortunate with the lack of options for this. Either the user loses stdout from threaded evaluations or all stdout goes to the repl window. I’ve reasoned a bit around it on that issue, included that there is some little room for improving it, even if ultimately we’re at the mercy of what nrepl (and the repl) allows. Configuring your loggers is always an option, as Dustin suggests.

Dustin Getz18:09:08

you can also intercept only clojure's *out* (println) but not the java stdout, i believe the calva patch intercepts both

Dustin Getz18:09:05

the problem with that @U0ETXRFEW is shadow-cljs still logs the compiler results with println, which absolutely unequivocally must go to out which must be redirected to the repl. (I mention bc i know you prefer the old shadow behavior)

Dustin Getz18:09:19

but java loggers in this case would go to terminal

Steven Lombardi18:09:12

I personally am okay with all my *out* or stdout going to my terminal (in my case it's side by side with my REPL window), but are we saying for ergonomics, we'd prefer println debugging stay in the REPL window, but everything else go to stdout including logs and such?

pez18:09:13

As a parallell stream we are also looking at challenging the repl/output window implementation and behaviour. This is great input, @U02GSTHEX3M. You can add to this issue, if you like: https://github.com/BetterThanTomorrow/calva/issues/1104

👍 2
Steven Lombardi18:09:55

I'm starting to grasp the challenge you're facing. You can only override all of *out* ... not selectively override it. It's a bummer that's not better decoupled.

Steven Lombardi18:09:44

i.e. normal streams wouldn't be able to support metadata I don't think, so you couldn't really write a func that "chooses" where to send output

Steven Lombardi18:09:30

Well, you could selectively override it on a per REPL invocation basis, but within one invocation, you couldn't send i.e. all printlns to one stream and all logging library calls to another

pez18:09:39

We do have a hold that can separate messages stemming from evaluations from those coming from the server process for other reasons. At least it looks like that when examining the message logs. That’s the room for improvement on the structural level that I see. From there it’ll be a question of designing some good defaults and reasonable options without that getting to be a jungle of settings.

👍 2
Steven Lombardi18:09:59

I'm not super familiar with nREPL's protocols / data formats so I'd have to read up on that to fully appreciate what you're saying. But I get the general idea.

Steven Lombardi18:09:15

I'll throw some commentary on the issues 👍

pez19:09:34

Basically it is something like so, afaiu: 1. nREPL structures requests and responses such as that we can know from which request a response stems (via the message ID) 2. By default it also sends back stderr and stdout from the request, tagged with the message ID, but only if it’s in the same thread 3. By default all other output slips through the nREPL server’s watch and the nREPL client never gets them 4. The nREPL server can be instructed to subscribe to stdout and stderr happening in the server process a. So instructed all stdout and stderr will be sent back to the client b. Output from child processes to the main evaluation thread seems to have the evaluation’s message ID c. All other output (I call them out-of-band) is tagged with the same message id (some early ID from the handshaking or something) 4a is the new default, and can be disabled in that setting. 4b and 4c is the room for structural improvement that I keep rambling about. Even if the 4b observation does not hold for all situations, it could still be worth leveraging. The latest issue I linked to suggests to open up for something like what you said you’d be fine with: Sending all stdout/stderr to some other place than the repl window. Then the repl window would be more purely about results exceptions. And users can arrange the repl window and the stdout/stderr view as they see fit.

👀 2