timbre 2024-05-15 | Slack Archive

jjttjj14:05:07

Using the timbre 5.2 default println-appender Not entirely sure this is timbre specific or just me misunderstanding something unrelated I am starting up a system that asynchrounously causes a lot of timbre debug statements to be issued. My println appender is created using (timbre/println-appender {:stream :auto}). During this I also need to prompt the user and read-line a response. I'd like for nothing to be logged or printed anywhere between when the prompt is printed and read-line occurs. I'm attempting to accomplish this by using the following for my prompting code

(locking *out*
  (print "Answer:")
  (flush)
  (read-line))

But I'm always getting this line printed as my prompt: Answer: 24-05-15 14:38:47.267 DEBUG [my.ns:27] - My log msg There's always some log message printed from some async process that occurs around the same time Is there a way to ensure this doesn't happen?

✅ 1

jjttjj15:05:48

Hmm I wonder if this is because I'm using a remote clojure socket repl so my *out* isn't the same object timbre is using so the locking wont work as intended

Peter Taoussanis15:05:02

Hi there! > I’m attempting to accomplish this by using the following for my prompting code Just to confirm- you’re really happy to literally cause all your application-wide logging calls on any thread to hard lock on this read-line completing? > Hmm I wonder if this is because I’m using a remote clojure socket repl so my *out* isn’t the same object timbre is using so the locking wont work as intended That’s a reasonable thought to check, but more fundamentally- Timbre’s println appender doesn’t itself lock on *out*. So even if you ensured that you had the same *out* in both cases - Timbre’s println appender won’t care if something is locking *out*. Does that make sense? > Is there a way to ensure this doesn’t happen? TBH I’m a little skeptical of the idea of blocking all your logging for a read-line to finish, but I guess that might make sense in your context. If you want to try this, the simplest thing would probably be to write your own println appender that uses the same lock. You can use the https://github.com/taoensso/timbre/blob/10f7b0436e46ed9af1f83f0a5fad43f4bd317e9d/src/taoensso/timbre/appenders/core.cljc#L38 as a starting point. Hope that helps?

jjttjj15:05:49

Hmm good points I definitely confused myself about how locking works, and you're right that I shouldn't want to block all logging, though it might be fine in practice for this. Probably a better approach is to either temporarily disable or buffer the println appender. Definitely helpful starting points, thanks!

Peter Taoussanis15:05:41

Re: ideal approach - much depends on the context of what you’re actually trying to do. When waiting on the read-line, is anything useful still going on in other/background threads? If not, you might be able to pause/lock your application logic (rather than just logging) while reading. But if there is useful work going on in other/background threads, then an entirely different approach might make sense. Best of luck!

2024-05-15

Channels