Botworks: Trilemabot and Feedbot V patches, the autumn 2019 session

Since we're here, let's do a recap of the botworks series so far:

• Trilemabot: self-voicing and command handling;
• Keccak/manifest regrind of the botworks tree;
• Feedbot: checker, announcer, irc bot.

This is a lot of code, by the way. If there's any brave soul who's willing to a. integrate cl-irc plus all its dependencies (same as I've done with Hunchentoot), then b. surgically remove any and every thing that's not needed for c. IRC bots in general, as well as d. #trilema bots and e. Feedbot in particular, keeping only what's actually used -- then you're more welcome to give it a shot. Anyways, if you're interested, drop by #spyked on Freenode.

As for today's subject, I've been brewing a couple of V patches in my lab over the last month or so. Here they are:

• trilemabot-voicer-tweaks.vpatch (seal)
• feedbot-concurrency-fixes.vpatch (seal)

This comes after about nine months of not touching the code at all; and I sure as hell hope I don't have to add anything new in the next eighteen.

Trilemabot voicer tweaks: a. adds a new method to load the list of voice OTPs (previously emitted by deedbot and saved via the converse method) from a file¹; and b. makes the "filespec" argument for both methods optional, adding a default value there. The reasoning behind b is that I've been using this self-voicing method for months now, and having to type the filename each and every time is annoying. I'm not going to keep multiple files for this purpose, so the parameters remain to be used only in special cases, e.g. backup or something.

Feedbot concurrency fixes: a. fixes those annoying crashes that have been occuring until a month ago; b. improves general performance (delivery, response time etc.) by removing HTTP requests from critical sections; and c. removes some useless functions that in hindsight have proven to be at best useless, and at worst annoying.

The fix for a is already outlined in the logs: don't have message delivery take over the main loop, do it only in pre-defined bursts (see *max-announce-burst*²). This should only be necessary for the rpl_ison handler, but I want the bot to act consistenly, so both PM and in-channel delivery act the same.

I implemented b by adding a new parameter to the update-feed! function, denoting the feed as grabbed by feedparse, and changing update-feed-db so that it calls try-parse-feed outside the critical section, then passing the result to update-feed!.

As for c, I had initially wanted the bot to do some extra management when loading/saving state on the disk, e.g. not overwriting the existing feed list in memory unless necessary, but this is clearly overengineering and really, the basic stuff works just fine. So we can do with just the two basic feedbot-{save,reload}-state methods outlined in the initial patch.

That's about it for now. If you want to use this and need any support from yours truly, I'm in #spyked.