Re: [shepherd] several patches that i deem ready

[Maxim Cournoyer]

Hi Attila,

Attila Lendvai <attila@lendvai.name> writes:

> hi Maxim,
>
>> > > - a lightweight logging infrastructure together with plenty of log
>> > > lines throughout the codebase, and some hints in the README on how
>> > > to turn log lines gray in emacs (i.e. easily ignorable).
>>
>>
>> Are you using guile-lib's logging library for it? I've used it in
>> guile-hall if you want to have an example. We should maximize its
>> users, refine it and aim to have it builtin Guile at some point.
>
>
> i looked at that lib first (IIRC by your recommendation), but i ended
> up rolling my own for the cost of two additional pages of code in
> shepherd. i think the main issue i had was the amount of unconditional
> computation that happens on the common code path, and its complexity
> in general, including its API.
>
> shepherd has some non-trivial machinery regarding logging output being
> captured and redirected through sockets to herd and whatnot; i.e. most
> of the handler machinery in guile-lib's logger would be just an
> impedance mismatch instead of being helpful.

Since we can define a custom logger for guile-lib, I'm a bit surprised
by this, but it's true that this logging library is quite minimal/naive.

> for those two pages it's:
>  - one less external dependency
>  - less resource use
>  - more flexibility
>  - cheaper code path when a log level is disabled at runtime
>  - compile-time log level to drop entire log levels
>  - and most importantly much less code complexity.

About "cheaper code path when a log level is disabled at runtime",
perhaps it can be improved in guile-lib, but otherwise that's a nice
list.  I just wish we had a good logging library in Guile and could stop
reinventing the wheel left and right.

> you can find the relevant commit at:
>
> https://codeberg.org/attila-lendvai-patches/shepherd/commits/branch/attila
>
> FWIW, it's a partial bort of a CL lib of mine:
>
> https://github.com/hu-dwim/hu.dwim.logger
>
>
>> > a quick note on the log statements: they are essentially noise when it
>> > comes to reading the code, hence the gray coloring i suggest in
>> > emacs. (although they may often serve also as "executable" comments).
>>
>> > i'd also like to propose to relax the 80 column limit for log lines
>> > for the same reason that i've explained above.
>>
>>
>> I don't think an exception is deserved here; the logging library from
>> guile-lib for example concatenates message strings by default, which
>> makes it easy to brake long messages on multiple lines.
>
>
> my ultimate goal here is to minimize the disruption of code readability. only 
> some emacs (editor) magic and/or code formatting can help with that.
>
> log lines are only relevant when you're debugging something, or when you're 
> trying to understand a codebase. all other times they are essentially noise.
>
> my proposal is what our CL team settled with: always one line per log 
> statement, and setting the foreground color of the entire line gray in emacs.

OK.  For levels greater than debug, they I see them as glorified
comments (executable comments as yo wrote), so I don't see a strong
reason to attempt to hide them or treat them specially.  In Python
(which strives to be readable), we typically break logging lines (which
are concatenated for free inside the parens -- default Python behavior),
and that doesn't hurt readability in my opinion, and means we can just
follow the usual style rules, keeping things simple.

Thanks for working on this, I'm sure it'll help many, myself included,
following the execution of Shepherd more easily.

-- 
Thanks,
Maxim