IRC channel logs

<daviid>apteryx: ^^ [doing this to make sure you read my msgs ...]

<apteryx>daviid: calling the kw buffering-mode suggests we'd call setvbuf on the underlying stream

<apteryx>this can be done on the port-log handler, but not on an eventual syslog-log handler, which would introduce special cases

<apteryx>which is why I think it'd be best to remain high level/abstract with a flush-after-emit? on the base handler to tweak its default behavior. Perhaps we'd need a stream-handler base class if we wanted to introduce stream-specifics such as a buffering-mode kw

<apteryx>daviid: I fixed a small bug again, so recreated the devel branch (we can't force push to it) -- please 'git fetch origin && git reset --hard origin/devel' from your devel branch checkout to sync it, to commit af92989

<apteryx>daviid: I've sent my last suggested change w.r.t. to adding a flush-on-emit? kw to the list (you should have been CC'd to it)

<cwebber>dthompson: working on getting my "better feeds" stuff upstream to Haunt... ie, getting podcast support available to everyone

<cwebber>just checking, your preference is still to, instead of having hooks to allow for arbitrary extension of feeds as the branch currently works

<cwebber>to have a *separate* kind of feed type for podcasts specifically?

<cwebber>basically duplicate and modify the code?

<cwebber>the downside of this is it's two similar modules to maintain, the upside is that it's less "hooks into" the current feed system

<daviid>apteryx: '... calling the kw buffering-mode suggests ...' no it doesn't, what it suggests is that the logging facility supports some sort of granularity in the way the log msg end-up being written to the log

<daviid>apteryx: '... which is why I think it'd be best to remain high level/abstract with a flush-after-emit? ...' imo, quite the opposite actually, the #:buffering-mode kw name, that accepts symbols as its value, is a higher level approach, offers a better abstraction and is more flexible and extensible then a boolean

<daviid>apteryx: '... an eventual syslog-log handler ...' if someone wants to define a syslog handler, the best is/would be to subclass and specialize those methods that needs to ... and enhance the log-handler provided granularity by defining and supporting other symbol(s) to reflect what ever they wish to

<daviid>apteryx: '... I fixed a small bug again, so recreated the devel branch (we can't force push to it) ...' ok - but please don't do that ever again - rather, just send a patch to fix the bug ... i was actualy working on that branch to prepare the release ... tx!

<daviid>apteryx: '... I've sent my last suggested change ... the the ml ...' ok, i'll answer there as well, but i made up my mind, so please write the 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 ... tx

IRC channel logs

2024-03-02.log