KNOWN PROBLEMS AND BUGS

Problem #1:
	'topic [#channel] shuffle' will produce 1 in n! (where n
	is number of subtopics in topic. IS THIS CORRECT PROBABILITY?)
	chance that it will be the same as before.

	If someone wants to experiment a fix for this, do so.
	Here is a hint:
	'while (!defined $newtopic || $topic{$talkchannel} eq $newtopic) {'

Problem #2: [UPDATED 20000224]
	A race condition is observed if the topic is changed very
	quickly. If the bot is told to change the topic twice but
	has not received notification of the new topic before
	changing to the second modification of the topic, it
	would use the absolute first (0) topic as a reference,
	therefore missing out on the first alteration of the
	topic.

	A very cheap solution exists. Edit IrcHooks.pl, search for
	'topic', alter '1' to '0'. This will only cache topics made by the
	bot (I hope). I have a faint feeling that bot-only topics are
	stored elsewhere (history I think) but I'm not quite sure.

	Yet another (ultimate and preferable) solution would be to have
	topic queueing, altering the topic once the first alteration has
	been done, changing the topic until the queue is empty. However,
	topic floods will eventuate unfortunately. If a queue of 2 or more
	is detected, no more topic changes are done until a time of
	5-10seconds (how can this be done?). This is a challenge to
	implement.

Problem #3: 19991110
	It appears that if the last string separated by a whitespace
	of the topic will be chopped off (if it's "()") because the
	ownership is null. At first I thought it was a bug in the regex
	but it was okay. I guess it's a minor problem but why should
	there be a semi-ownerless subtopic :) If it's annoying, please
	investigate the &topicCipher() function in Topic.pl in relation to
	&topicDecipher().

Problem #4: 199912xx
	mysql overload...

	DBD::mysql::st execute failed: Duplicate entry 'xk' for key 1 at
	./src/Freshmeat.pl line 85.
	when freshmeat.pl is building the table and something's said in the
	channel... seen code tries to update table but fails.

	[UPDATE 20000224]
	This may be eliminated by reducing 4-5 INSERT/UPDATE requests to
	just 1 (total of 2), depending on the return of SELECT. If this
	still persists and memory leaks are happening, first make
	sure you are not using broken mysql tables, secondly bitch at the
	mysql-perl author that there is a memory leak when a broken table
	is in use.

Problem #5:
	doWarn is called when perl catches a "warning".

	=>
	[   44] !WARN! PERL: Use of uninitialized value at ./src/Modules.pl line 316.
	[   45] !WARN! PERL: offending line => '        if ($query eq "") {'.
	[   46] !DEBUG! test1.
	[   47] !DEBUG! test2.
	[   48] !DEBUG! test3.

	### From 'perlfunc'...
	Note that this is quite safe and will not produce an endless loop,
	since __WARN__ hooks are not called from inside one.

	### From 'perlvar'...
	Note that __DIE__/__WARN__ handlers are very special in one
	respect: they may be called to report (probable) errors found by
	the parser.  In such a case the parser may be in inconsistent
	state, so any attempt to evaluate Perl code from such a handler
	will probably result in a segfault.

Problem #6:
!   14! Debian: 12.87 sec to complete query.
!   15! </#debian-bots> Debian Search of 'testing' (2 shown): ...
[   38] disconnect from irc.home.org (Connection reset by peer).
[   39] reconnection... cleaning out channel cache.

	Solution #6:
		Edit /usr/lib/perl5/Net/IRC.pm
		Comment out *->quit() on 'sub DESTROY'
		Alternatively, bitch at author of Net::IRC.

Problem #7: why...
	<\ifvoid> apt, cellwave?
	<apt> i haven't a clue, \ifvoid
	<tapt> bugger all, i dunno, \ifvoid

Problem #8:
	<egamI-rorriM> apt: lart
	* apt/#debian strangles  with a doohicky mouse cord

Problem #9:
	[Flugh] i say 'rom, rom is a mud server', it says 'ok'. then
		'rom, rom?' it says 'yes? <nick>'

# info package dist doesn't recognise dist.