Fork me on GitHub
#calva
<
2024-05-15
>
Tommi Martin11:05:53

Hello everyone question about calva i'm a bit confused about. While using calva and using (prn ... to push a map into the repl output the output randomly gets corrupted. It almost looks like it's trying to print two things at the exact same execution of the print and producing a garbled result. to extract a snippet from a map i pushed into repl you get values and content like this: :state [[""OONNLLINE"I]NE", ]:alert, or {{:opts:role {":hostM A"SwTeEsRt"-sample-svc., defau:namel t".esavsct."clus, ter.local" I haven't figured out an exact method of reproducing this but it seems to happen when you push relatively big maps repeatedly to repl output such as from inside a data reading loop. even when it happens it is not a 'consistent' problem, you might get the error in 1 in 20. messages, every message or sometimes you go through a 100 messages without an issue. The issue is only tied to the printing of the data into the repl output. Stopping the loop and reading the output separately from a state atom always produces a healthy map.

pez12:05:42

Hi! Thanks for reporting. Even without a stable reproduction it would be great with an issue about this on the repository. The repl window has some output buffering going on. Maybe this is related to that. You could run with the terminal Output destination to see if it still happens.

Alexander Kouznetsov16:05:38

Are you printing from multiple threads? And you do not exeprience this when using repl without calva?

Tommi Martin06:05:41

Yes I am using multiple threads, I haven't tested this without calva.

pez06:05:29

You can run Calva with nREPL logging on (there’s a command for toggling this). Though it will print a lot. Especially for the scenario you are describing. But maybe you can search in the output, when you have observed the behavior, and we can see if the messages are received in some (dis)order. Calva makes no attempt into ordering the messages in any other way than they arrive.

👀 1
Alexander Kouznetsov17:05:10

Some of the Clojure printing (if not all), is not thread safe. So printing from multiple sources can easily result in a garbage like that. You can try locking those prn statements as in (locking *out* (prn x)) and see if the issue reproduces.

Tommi Martin06:05:32

@UHS6PHL31 Thank you for letting me know, I'm quite conviced this is the issue and not Calva itself. I'll have to backtrack a littlebit and study what is and isn't threadsafe in clojure.

phill16:05:55

As far as "threadsafe in Clojure" goes - It isn't really a Clojure phenomenon - Java doesn't synchronize stdout/stderr, and gibberish routinely results if more than one thread prints at the same time. This is commonly seen in stack dumps, because programmers take some care to avoid uncontrolled printing on "the happy path", but they have no qualms about putting a printStackTrace in any catch clause without regard to the circumstances... Another cause of such confusing output, without multithreading, can be alternating use of stdout and one or more BufferedWriters that wrap stdout.

👍 2