This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-09-05
Channels
- # announcements (2)
- # babashka (19)
- # beginners (14)
- # biff (10)
- # calva (23)
- # clojure (49)
- # clojure-europe (15)
- # clojure-nl (3)
- # clojure-norway (25)
- # clojure-seattle (1)
- # clojure-uk (4)
- # clojurescript (7)
- # data-science (6)
- # datahike (3)
- # datomic (1)
- # emacs (13)
- # events (2)
- # fulcro (3)
- # graalvm (13)
- # hyperfiddle (32)
- # leiningen (4)
- # lsp (38)
- # malli (1)
- # missionary (34)
- # nbb (28)
- # off-topic (42)
- # other-languages (5)
- # portal (8)
- # practicalli (1)
- # re-frame (3)
- # releases (1)
- # ring (7)
- # shadow-cljs (13)
- # sql (3)
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:
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.
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
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
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.
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
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.
you can also intercept only clojure's *out*
(println) but not the java stdout, i believe the calva patch intercepts both
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)
but java loggers in this case would go to terminal
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?
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
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.
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
Well, you could selectively override it on a per REPL invocation basis, but within one invocation, you couldn't send i.e. all println
s to one stream and all logging library calls to another
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.
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.
I'll throw some commentary on the issues 👍
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.