"Arthur A. Gleckler" <xxxxxx@speechcode.com> writes:

> On Tue, Dec 29, 2020 at 1:35 PM Lassi Kortela <xxxxxx@lassi.io> wrote:
>
>  If the main point of severity is to have a sliding scale on which
>  logging verbosity can be controlled at runtime, wouldn't it be equally
>  simple and more future-proof to let programmers add mixins to the log
>  callback to filter which entries are logged?
>
> Another, perhaps complementary practice would be to allow a set of
> labels to be attached to each log entry. This would allow people to
> set not only a logging level, but also a set of labels in which they
> were interested. Labels could represent things like components.

This sounds like it is subtly different from the SRFI's current use of
key-value lists on messages. Could you please give a more detailed
description of how this would work? I'm eager to hear if it makes
possible anything that is not possible today.

As I've mentioned before, I've been experimenting with this type of
logging system in Loko Scheme. I have tried tagging messages with which
component generated them and found that it has great benefits. Loko is a
concurrent Scheme and that means that log entries can be generated by
the same line of code, but running in different components. Which
component generated a log entry is very relevant information because it
puts the message in its proper context.

Here's a brief snippet from the code that hooks up a USB controller:

  (spawn-fiber (lambda ()
                 (parameterize ([current-log-fields
                                 (append '(SUBSYSTEM "usb")
                                         (current-log-fields))])
                   (manage-usb-hci controller))))

This appends (SUBSYSTEM "usb") to all log entries generated from inside
the manage-usb-hci procedure.

--
Göran Weinholt   | https://weinholt.se/
Debian Developer | 73 de SA6CJK