When noJoinsUntilIdentified config is true, the bot holds join messages in a 'waitingJoins' list, and processes them
once nickserv identification comes through. The problem was that when the bot is configured to join multiple networks,
join messages from different networks would get appended to the same list, without any differentiation by which message
belongs to which network. Thus, if there are messages waiting for multiple networks, it would often be the case that
whichever network got identification done first, would 'pick up' other network's join messages.
This fix stores the network name along with the join messages in the list, and has each network pick out only its own
join messages.
Fixed bug in 100% packet loss response.
Errors from ping are now sent to irc.error().
Added packet count, interval, ttl, and wait options.
Added additional test cases.
Also, Enabled threading for Unix plugin, and
for wtf, spell, and ping commands.
Signed-off-by: Daniel Folkinshteyn <nanotube@users.sourceforge.net>
two commits ago, in commit 51cabeea33
it is necessary for the operation of the plugin
(specifically, in the _checkManageCapabilities function)
the tests didn't catch that because it apparently imports re separately.
This should prevent the accumulation of old unclaimed notes in the database,
which is possible due to notes left to misspelled nicks, to temporary nicks
used by regulars, or to one-time visitor nicks.
This allows inclusion of the usual standardSubstitute vars within factoids.
There is no config to disable this, since it is possible to escape the substitutions
by simply doubling the dollar signs, as per the python documentation:
http://docs.python.org/library/string.html#template-strings
Thus, if you want a factoid to output a literal "$channel", for example, all
you'd need to do is use "$$channel" in your factoid text, which will come out
as "$channel" when said by the bot.
Also added tests for this new behavior.
First: if an rss feed is called without the number of headlines argument,
we now have a default number of items it will output.
before, it tried to stuff the whole rss feed into the channel, which is quite
floody, if more than one 'mores' is set, or if oneToOne is false.
Second: when adding a new feed to announce, it again, tried to stuff the
whole rss feed into the channel, which ran into the same floody conditions
as above. now we have a default number of feeds to output when there's no
cached history.
