kellan's Journal

Improving CPAN's RSS feed?

kellan — 2003-03-01T17:23:58+00:00

So who would one talk to about improving CPAN's RSS feed of recent uploads?

It seems silly that at the very least the feed doesn't include the short descriptions visible on the recent upload page.

From there we could go on to a feed that included the full pod, pointers to the Changes and README files, the related modules info, etc...

We've got the metadata, lets use it.

Writing this journal entry probably took as long as writing a scraper would have, but hopefully it will lead to better things.

Why doesn't XML::RSS encode entities?

kellan — 2002-07-29T01:07:30+00:00

Why doesn't XML::RSS encode entities automatically when outputting XML? (or with a flag?) If I parse an RSS file with XML::RSS I get a nice datastructure out that I can tweak and play with, but if I want to pass that datastructure back into XML::RSS I have to worry about walking the mess of nested hashes, and re-encoding every stray ampersand.

Not so hard you say? True. Simply in fact. I can cut and paste lines 658 thru 897 out of XML::RSS and into my script, and then add a handful of calls to encode(). Somehow though, cutting and pasting 240 lines into my script seems the wrong way to go.

Is there a logic behind this that I'm missing? In general its a very nice module, and I feel like maybe I'm over looking a perfectly valid reason for building a tool that encourages broken XML.

Any insights appreciated. Thanks.

Mail::Mailer, and the frustrating From header

kellan — 2002-03-01T06:56:17+00:00

I wrote up a little script using Mail::Send. Mail::Send doesn't explicity have a from() method, but $msg->set('From', 'quxx@example.com') works fine. Or at least it worked fine on my laptop. However when I moved the same script to my server, I mail was now being sent out from 'apache@protest.net'.

I was puzzled. I tried making apache a trusted Exim user, double checked that example.com was acknowledged as a local domain, etc, etc. In mounting frustration I was tempted to throw it all out, and revert to the bad old days of talking to sendmail (well Exim in sendmail clothing) directly.

Then it hit me, Mail::Send is using Mail::Mailer under the covers, Mail::Mailer first attempts to send mail out using the unix mail program, and then falls back on using sendmail.

My laptop doesn't have mail installed, the server does.

So if I change: $fh = $msg->open(); # $msg is an instance of mail send
to
$fh = $msg->open('sendmail');

Now everything works like a charm.

I mention this here, because surprisingly a quick google search turned up no mentions of anyone ever running into a similiar problem. So hopefully the next person (assuming anyone else is as slow) will stumble across this.

Exceptions, Exception::Class, and a quick hack

kellan — 2002-01-29T04:15:50+00:00

I've just recently returned to the land of complex Perl applications after many years wandering in foreign climes. And while it feels good to be back, I sorely miss some of elements of those exotic cultures. For example, exceptions.

So, surpised, and very happy, was I to find Error.pm, clean of interface, with a nicely developed try/catch syntax.(plus an otherwise keyword, which I forcely ignored)

However it was not to be. Dire were the warnings against Error.pm and its memory leaks.

So I've started playing with Exception::Class. While it does not have the comfortable familiarity of an old friend that Error.pm had, it comes reccomended, and with some of its one pleasures.

But, I'm stuck using the

eval {}; if ($@)

syntax, which is, for all intents and purposes new to me.

And I hit a snag.

See, my code would be merrily executing along, and then throw some nice, explicitly named execption like:

throw RW::Exception::App::BadPassword();

Now I don't feel any need to pass an error message to this throw, the name of the exception makes clear what it does.(its self-documenting ;)

However when I go to catch it, with some code like:

if ($@ and $@->isa('RW::Exception::App::BadPassword') )

the first test fails. And it fails because Exception::Class overloads stringification.

Exception::Class's as_string method returns the error you passed to throw (nada in my case) and possibly the stack trace. (which I didn't have enabled) So when I tested for the existence of an exception, I was testing the truth value of an empty string.

So after 30 frustrating minutes of wondering why my exceptions where disappearing into thin air, I overrode Exception::Class's as_string with my own:

sub as_string {
my $self = shift;
my $str = Exception::Class::Base::as_string( $self );
my $name = ref($self);
return "$name: $str";

}

Now all my exceptions test true. Yeh. 30 minutes to debug, 5 minutes to code, and 20 minutes to write a usePerl journal entry, leaving 5 minutes to grab a cup of coffee, and make a well spent hour.