Re: Logging librarie (Re: Debugging COMM:START-UP-SERVER hang)

Hoping to learn something…

I grabbed a copy of your slog code and studied it for a while. And I am imagining how it functions vs a plain function call.

Seems like the signaling overhead would be heavier than function call/return, no?

Perhaps you get more inherited behaviors due to the class hierarchy of conditions?

I do see that you timestamp each message on the way out to your log file. And serial execution of the streaming of the message would necessarily be required to see the log entries in temporal order - as contrasted with sending an asynchronous message to a concurrent file handler actor. Asynchronous messages could theoretically arrive in any order. And so, while properly timestamped in each message, the messages could appear in jumbled order in the log file.

But perhaps I missed something more devilishly clever about the use of the condition system for logging?

- DM

> On Mar 1, 2026, at 06:54, Tim Bradshaw (as tfb at cley dot com) <[email protected]> wrote:
> 
> On 28 Feb 2026, at 21:22, Alexey Veretennikov (as alexey dot veretennikov at protonmail dot com) <[email protected]> wrote:
>> 
>> Personally I don't like too much dependencies, so I just run a logging thread/process with a mailbox where I send anything I want to log (or eventual shutdown message), take out a message in a loop and print it. Seems easier than to learn yet another library.
> 
> I have the advantage of having written slog (so I'm blowing my own trumpet here), but this is exactly one of the ways I've used it:
> 
> (defmethod slog-to ((destination mailbox)
>                    (entry log-entry)
>                    &key)
>  ;; a mailbox is now a log destination
>  (mailbox-send destination entry)
>  entry)
> 
> (define-condition terminating-log-entry (log-entry)
>  ;; Just a marker
>  ())
> 
> (defun mailbox-log-reader (mailbox &optional (stream *debug-io*))
>  ;; Read log entries and print them till we get a terminating entry
>  (do ((entry (mailbox-read mailbox) (mailbox-read mailbox)))
>      ((typep entry 'terminating-log-entry))
>    (slog-to stream entry)))
> 
> (defvar *log-mailbox* (make-mailbox))
> 
> (defun ts (n (mailbox *log-mailbox*))
>  (process-run-function
>   "foo" ()
>   (lambda ()
>     ...
>     (logging ((t mailbox))
>       ...
>       (slog "World exploded again")
>       ...
>       (slog 'terminating-log-entry)))))
> 
> Slog's trick is that log entries are conditions and logging is signalling them.  LOGGING then establishes condition handlers (which always decline to handle the condition so control flow just continues) which deal with log entries.
> 
> It may be that other logging frameworks do the same thing, but they all looked too complicated to understand.  The S in slog is for *simple*: I wanted to be able to log events not to deal with some awful bureaucracy which has seeped out from the Java mines.
> 
> --tim
> 
> _______________________________________________
> Lisp Hug - the mailing list for LispWorks users
> [email protected]
> http://www.lispworks.com/support/lisp-hug.html


_______________________________________________
Lisp Hug - the mailing list for LispWorks users
[email protected]
http://www.lispworks.com/support/lisp-hug.html