if for some reason (spoilers: i have a reason) you would want to have
dispatched stuff go to a file, that can now be done. prepend the
(fully-qualified) filename with FILE: in the database and off you go
we're switching to an idiom where the bot is only on one connection, so
we don't need to care about connection tracking. new_sendmsg accordingly
doesn't take a connection argument. now i can remove the old sendmsg
caught in the wake, a bunch of connections being passed here and there
can be removed, changing some module method signatures and such. there
might be more to remove still
a bunch of logic is moved around, some queries are improved, max_size
does what it's actually supposed to do. all in all this is a much
clearer chainer, even if the actual results are more or less the same.
it's probably a bit faster in most cases but slower in situations when
all the seed words have been consumed and it needs to do
__start1,__start2 chains (since there's so many of them, it's rather
slow). otherwise, it tries to use seed words in sentences, combining
multiple sentences when possible. there's a lot more in the periphery,
but that's the general idea
whether or not we went backwards and forwards, or just forwards, this
cycle of the loop, end the iteration by calling the end of the sentence
our hit word. if it was our seed word, this will trigger a new seed
selection
get one random v for a k1,k2 via SQL. prefer a word to show up in the
results, though there's no guarantee it will. this simplifies the
general looking forward case, and could possibly even work ok on the new
sentence stuff, though i haven't tried to update that portion of the
code yet
only add the reverse-search result to list of words if it isn't __start2
(and if it is __start2, just carry on, giving the code one last chance
to find something else)
rather than getting all k2s for a value from the database, then walking
the list and picking one at random, pick one for a value at random via
a query
this simplifies the code, and is (usually) faster than the old way,
which has been removed. it would be even faster if it weren't for that
context_id stuff, but so it goes
the code, in a kind of trial state, would very quickly stop trying to
work backwards. (part of this was for performance reasons, i believe.)
since that seems to have proven stable, let's mess with it --- the
backwards chainer can now go backwards a random distance, rather than
just what almost always turned out to be 2
this is to let any sort of autosend commands apply before joining
channels. for example, i have my bot set to turn on its hostserv cloak,
which was sometimes happening after channel joins, making its hostname
appear different in various channels. this solves that
as a total aside, this module is becoming really poorly named, i should
probably do something about that
keep a collection of key-channel pairs that, when receiving an XML-RPC
dispatch message with a key and message, sends the message to the
associated channel. this allows for various notification bus style stuff
this is the barebones version, there's no IRC admin interaction yet, so
all key-channel pairs need to be managed by direct database access. it
is possible i won't bother changing this. there are also some
not-so-clever assumptions, like that the bot is already in the channel
it is trying to speak in
since we've been saying that the rule is one bot, one connection, we
don't need to pass said connections around as much. this new_sendmsg(),
which should eventually become sendmsg(), uses that, and leans on
irc.server instead
probably, once all of the modules are using regex handlers, there won't
need to be a method for member for it at all, since the only thing that
will need to refer to it will be the module itself
this serves as a good example of how to reuse code for the XML-RPC
interface. we wrap it for convenience, so that all that needs to be
supplied to the web service method is the message to echo. of course,
other modules can wrap things how they feel the need to, even adding
authentication, i guess, if they wanted
note that it doesn't unregister the XML-RPC method. for starters, i
didn't add an unregister to DrBotIRC, so it can't, and secondly, it
looks like reregistering overwrites the old one. this hasn't been
extensively tested but that's what i'm seeing
this is the first implementer of the new regex handler code, by all
accounts it's working fine, hopefully the underlying code in DrBotIRC
won't need to change as i go forward, but it might
Brian S. Stephan