Hi Attila, Attila Lendvai <att...@lendvai.name> writes:
>> 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. > > > i've made my judgement that the logger in guile-lib was never applied > seriously when i relized that it stores the enabled state in a > hashtable (which must be looked up for every log statement). > > i made sure the log statements have a unique syntax, so the underlying > machinery can be replaced easily later, and then i moved on. I guess if we were serious at giving Scheme/Guile a great logging library we would try to design it with the help of everyone as a SRFI; it could then be integrated to Guile and any other Scheme, benefiting the ecosystem at large. Is this something you could be interested in trying? I've found the Scheme community around SRFIs very knowledgeable and helpful. >> 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. > > > my experience is different. i found myself only ever looking at log > statements when i'm debugging something, regardless of the level, and > including other people's code. and then i just toggle line wrap with > the press of a button. > > must be related to my habit that i usually put more effort into making > the code more self-documenting (readable) than i put into writing > informal comments and documentation. and rethinking my "executable > comment" metaphore: these log statements serve much less as comments > than reporting the temporal state and program flow. > > but my primary aim is to color it all gray, and i don't immediately > know how to do that in emacs for multiline sexp's (i.e. balanced > parens). this is the primary reason our team just kept them on one > line, but the flexibility of toggling word wrap as needed is also > nice: the essetial part is always within a reasonable margin, and the > rest can be read when word-wrap is enabled. I'm sure there's a way; have you consulted in #emacs on Libera? > if requested, then i'm willing to re-format the log statements if i > can find a way to still color it all gray. it's important that logging > stays out of sight while reading the code. OK; I'll let other voices their preference (because it's down to that, and current conventions). > >> Thanks for working on this, I'm sure it'll help many, myself included, >> following the execution of Shepherd more easily. > > > my pleasure! > > in my experience when a project doesn't have proper logging, > backtraces, error handling hygene, and warning-free compilation, then > inefficient debugging quickly eats up more time than it would take to > implement these features properly. > > unfortunately, guix and guile is not very good on this front, so i > found myself working on these, too. such investment rarely pays off > for the first bug, but it pays off very well in the long run. I wholly agree. Sadly, I find the debugging facilities of Guile are also lacking compared to what other programming languages have, which further exacerbate that situation. -- Thanks, Maxim
