literal thoughts

POE::Component::IRC 6.00 is here

Thu, 05 Mar 2009 03:03:00 +0000

POE::Component::IRC version 6.00 has just been released on CPAN. I’ve neglected to blog about PoCo::IRC since I started contributing to it, but since a new major release has been rolled out[1], now would be a good time. Also, as it turns out, next May will be the tenth anniversary of the project’s first release.

For the uninitiated, POE::Component::IRC is an event-driven IRC client library built on top of POE. People mostly use it to write bots. Some have made that even easier by creating a simpler interface suited to that task (see Bot::BasicBot).

I became involved in the project about 14 months ago, fixing bugs and adding features. There’ve been about 50 releases during that time, so there’s something for everybody. Following is a list of the most prominent ones.

Important squashed bugs

Quite a few DCC-related bugs have been fixed, error handling and diagnostics have been improved.
A bug causing the NickReclaim plugin to only try to reclaim the nick once has been fixed.
POE::Component::IRC::State was reacting incorrectly to some WHO replies sent by IRC servers that veered from the RFCs, causing it to hold inconsistent information. This has been fixed.
When raw messages were enabled, the raw line was not provided with CTCP-related events. Fixed.
POE::Component::IRC::State would issue more WHO commands than necessary when another user would join more than one of the component’s channels. No more.

New major features

POE::Component::IRC::Common, which provides many helper functions, now has functions for identifying and stripping color/formatting from IRC messages. It also defines IRC color constants for use in messages.
We now handle FreeNode’s IDENTIFY-MSG capability, which means that can you always know whether a user had identified with NickServ when s/he wrote a particular message.
Sending and receiving files with spaces in them over DCC is now supported.
All DCC-related events now provide the IP address of the peer.
DCC resume support has been implemented.
The BotTraffic plugin now send an event for every CTCP ACTION issued by the client.
We now guard against sending IRC protocol messages that are too long and might get us booted off the server.
The Connector plugin (takes care of maintaining the connection to the IRC server) now supports cycling through a list of servers when reconnecting.
The CTCP plugin can now respond to CTCP SOURCE requests for you.
POE::Component::IRC::State and can now track the away status of users for you.
POE::Component::IRC::State now keeps track of a channel’s creation time.
Added NICKSERV, SERVLIST, and SQUERY commands.
Plugins can now respond to custom events which have not been explicitly defined by POE::Component::IRC.

New plugins

I wrote 5 additional core plugins:

First of all, the Logger plugin. It logs channel/private/dcc chat activity to files on disk like normal IRC clients do.
Then there’s AutoJoin, which takes care of keeping you on your favorite channels, whatever happens.
NickServID deals with identifying your user to NickServ.
A CycleEmpty plugin which reclaims ops on channels that become empty.
BotCommand, which allows you to register commands that your bot handles, and get back an appropriate event when one is issued.

Testing

The test suite has been reorganized, many tests improved and more added. The test coverage (as reported by Devel::Cover) has increased from 40% (version 5.48) to 61% (version 6.00).

Refactoring

Much refactoring was done. The coding and indenting style has also been made consistent across the project, and many spotty coding practices have been eliminated (thanks, Perl::Critic).

POE::Filter::CTCP was merged with POE::Filter::IRC:Compat, and the former was removed. DCC support has been moved into its own plugin, and the plugin system itself has been ripped out in favor of POE::Component::Pluggable (which is based on the aforementioned plugin system).

Using the project’s current Perl::Critic parameters, version 6.00 has zero policy violations in 11,791 lines of code, compared to version 5.48’s 242 violations in 10,634 lines of code. The average McCabe score of subroutines also dropped from 4.21 to 3.45.

Documentation

Last but not least, the Pod docs have been improved. Errors have been fixed, much more formatting and linking has been added for easier reading and browsing, consistency has been improved, and many sections have been expanded.

I also added a cookbook with a few recipes showing off some of the things one can do with POE::Component::IRC.

Credits

Thanks to all the users who provided feedback, bug reports and patches. You helped make this happen. I also couldn’t have done many of these things without the help of Chris ‘BinGOs’ Williams, the senior maintainer of POE::Component::IRC.

Now go write some IRC bots (or clients)!

Notes:

It’s actually quite an insignificant release. Historically, POE::Component::IRC versions have always passed the whole-number boundaries naturally as part of a regular “bump the version number up by 0.02 for the next release” process.

Spicing up IRC with MegaHAL

Fri, 29 Aug 2008 04:45:00 +0000

I released POE::Component::IRC::Plugin::MegaHAL the other day, a POE::Component::IRC plugin for the esteemed and humorous conversation simulator known as MegaHAL. This makes it very easy to add a MegaHAL brain to an IRC bot. I wrote one and fed him IRC logs of a channel that I frequent, then let him loose online (he’s a “he” because the IRC logs primarily include ramblings from male users). Some examples of his brilliance follow.

<failo> Or maybe it's about sexual liberation and not perl & python.
<failo> Yes, printing passport photos at home is surely a sign of a flock of aids infected prisoners with big sloppy dicks.
<failo> I heard failo is a fact of evolution that cannot be shown because it looks like he knows what electricity is
<failo> Fucking get your cock out and jerk each other off in proportion to how much dexter's wedding dinner is going your way
<failo> Sir you had me at "balls."
<failo> Every porn dvd has a "grill setting"
<failo> So only 2% of americans also believe that the government is composed of thong-wearing oiled-up muscle boys.
<failo> Increased struggling from the bees made honey in the darkened cubicle, waiting for another musky man-pole to probe its way through the light to go mushroom hunting with me
<failo> I bet all drug users keep a human skull on their myspace page.
<failo> Earle: everybody's gay for a prison system in which millions of our descendants murder each other in prison.
<failo> Either you're gay or associated with all drugs.
<failo> The war on polarbears is going to cum buckets into my gaping /dev/null.

I’m afraid these results say more about the quality of conversation in this channel than they do about anything else…

IRC and character encoding

Thu, 01 May 2008 01:44:00 +0000

A while ago, I wrote an IRC logger for POE::Component::IRC, which is an IRC client module for Perl. The main challenge I faced was the issue of character encodings. Since IRC is ripe with clients that use different encodings, messages must be reliably decoded before they are written to a file.

You see, RFC 1459, the standards document describing the IRC protocol, does not regulate the use of character encodings:

2.2 Character codes

No specific character set is specified. The protocol is based on a
set of codes which are composed of eight (8) bits, making up an
octet. Each message may be composed of any number of these octets;
however, some octet values are used for control codes which act as
message delimiters.

Regardless of being an 8-bit protocol, the delimiters and keywords
are such that protocol is mostly usable from USASCII terminal and a
telnet connection.

ASCII uses the first 7 bits. So, from the looks of it, you should only be able to rely on the first seven bits representing an ASCII character, the interpretation of the last bit being anyone’s guess. That’s bad.

For most of IRC’s history, the most popular IRC client has been mIRC. Until recently, mIRC decoded incoming messages using the ANSI code page that was currently being used on the user’s Windows system. This meant that whenever mIRC users wanted to communicate using anything other than ASCII characters, they’d better be using the same code page. In later versions, mIRC decodes incoming messages as UTF-8 if they look UTF-8 encoded, or code page 1252 (used by most Westerners). As for how it does this, I cannot know since mIRC is closed-source.

The open-source client irssi handles the situation similarly. It uses GLib’s g_utf8_validate() function to check if the incoming message is UTF-8 encoded, otherwise it falls back to CP1252 by default. As for XChat, it uses the same GLib function, but if it determines that the message is not UTF-8, XChat decodes the message in a rather novel way. Here is an excerpt from its src/common/text.c:

/* converts a CP1252/ISO-8859-1(5) hybrid to UTF-8                           */
/* Features: 1. It never fails, all 00-FF chars are converted to valid UTF-8 */
/*           2. Uses CP1252 in the range 80-9f because ISO doesn't have any- */
/*              thing useful in this range and it helps us receive from mIRC */
/*           3. The five undefined chars in CP1252 80-9f are replaced with   */
/*              ISO-8859-15 control codes.                                   */
/*           4. Handles 0xa4 as a Euro symbol ala ISO-8859-15.               */
/*           5. Uses ISO-8859-1 (which matches CP1252) for everything else.  */
/*           6. This routine measured 3x faster than g_convert :)            */

How would I handle this in Perl? I don’t want to depend on GLib, and I don’t want to write any C code (requiring the user to have a C compiler). At first I tried using Encode::Detect, but there are two problems with it. It’s an extra dependency, and more importantly, it works heuristically, deciding which character set is being used based on the number of occurences of each character code. As such, it’s only reliable when large amounts of data are involved. Like a whole web page, for example, which is what the code was written for. Then I learned of Encode::Guess, which is included with Perl as of version 5.6.0. The following decodes $line as UTF-8 if Encode::Guess is sure that it’s UTF-8. Otherwise it decodes it as CP1252.

use Encode qw(decode);
use Encode::Guess;

my $utf8 = guess_encoding($line, 'utf8');
$line = ref $utf8 ? decode('utf8', $line) : decode('cp1252', $line);

So far this method has worked flawlessly for me on channels with mixed encodings. However, I don’t know exactly how Encode::Guess works, so I’m not as confident in this method as I could be. Any feedback on this issue would be quite welcome.