Hi David, David Pirotte <da...@altosw.be> writes:
> Hello Maxim, > guile-devel followers, > >> * src/logging/logger.scm (<log-handler>): Add new >> optional flush-after-each-emit? slot, initialized to #t. >> ... > > Maxim and i have been talking about both the v4 1-7 series of patches > that Maxim have been working on - now pushed to the devel branch if > someone wants to look at them ... as well as about this little > enhancement i wanted ... > > to avoid 'repeating the all chat' here, those interested may read our > last words about this here: > > https://logs.guix.gnu.org/guile/2024-03-02.log#043834 > > and my answers slightly below: > > https://logs.guix.gnu.org/guile/2024-03-02.log#235822 > > So, to make it short, i am asking Maxim to write this patch so it uses > buffering-mode as the new slot name, kw .. and accept either 'emit or > 'line to cover our current need, to be extended with other mode if we > wish or need to later ... My only concern about doing this, rephrasing what I wrote on the chat, is that it'd be hard to validate the input value, as that validation would need to be specialized to handlers, e.g. for some class we'd want to disallow 'line as it wouldn't apply. That's why I suggested keeping the flush on emit switch as an on/off boolean, which can live in the base class of all <log-handler>, and perhaps subclass <log-handler> into <stream-handler> which would accept a #:buffering-mode keyword whose accepted values would mirror what setvbuf allows (line, block or none). I think that'd simplify things at the implementation level and avoid user error or surprises. Our current loggers could be derived from the new <stream-handler> class, while something like a <syslog-handler> would inherit directly from <log-handler>, avoiding to handle users providing 'line or 'block to #:buffering-mode, which would need to throw a user error. Does that explain my point better (does it make sense?) If so, we can keep the patch here as-is, and the work to add a new <stream-handler> with a #:buffering-mode keyword would become future work. -- Thanks, Maxim
