| Subcribe via RSS

Perl Module Monday: Try::Tiny

October 26th, 2009 | No Comments | Posted in CPAN, Perl

While I am a devout and enthusiastic Perl proponent, there are things that I wish Perl had, or had done differently. One of these is the lack of a clearly-defined exception framework. It’s one of the (very) few things I think Java does better than Perl. Over the years, CPAN has been host to several variations on try/catch-style syntactic sugar. But  I now have a favorite: Try::Tiny.

While I had noticed the module scroll by the CPAN Twitter feed, I hadn’t paid much attention to it at first. I like the idea of clean try/catch, but I haven’t used it in any of my modules because I didn’t want to make the lists of dependencies any longer than they have to be. TryCatch, for example, uses Moose, which is a lot to install simply to have a clean exception model.

Then I read this blog post about it, and became much more interested. First off, Tatsuhiko was showing a lot of enthusiasm for something for something that isn’t Plack or PSGI (just teasing!). But mostly, it was just the relief of having a nice try/catch pair with no dependencies.

Let me say that part again, just in case you’re skimming: NO DEPENDENCIES.

Well, aside from Test::More at build-time, but you have that lying around already, right?

This one is absolutely going into the toolbox for future use. I’m also going to look for places where it seems to be an especially-good fit with other modules. (More on that, later.)

Try::Tiny. Give it a, errrr, try…

Tags: , ,

Perl Module Release: Image::Size 3.210

October 21st, 2009 | 1 Comment | Posted in CPAN, Perl, Software

(Eventually, when I am more comfy with playing around with my WordPress components, these posts will be automated by my release process, and the content will be much more nicely-formatted.)

Version: 3.210 Released: Wednesday October 21, 2009, 06:50:00 PM -0700

Changes:

  • t/magick.t

Removed a stray colon causing errors with some Perl versions.

  • t/00_load.t (added)
  • t/00_signature.t (deleted)
  • t/01_pod.t (added)
  • t/02_pod_coverage.t (added)
  • t/03_meta.t (added)
  • t/04_minimumversion.t (added)
  • t/05_critic.t (added)
  • t/magick.t
  • t/pod.t (deleted)
  • t/pod_coverage.t (deleted)

Removed useless signature test, added QA tests, removed a duplicate test.

  • lib/Image/Size.pm

Moved around some conditionally-needed libs to delay loading until/unless needed. Also made a small fix per Perl::Critic.

Tags: , , ,

Perl Module Monday: Timeout::Queue

October 12th, 2009 | No Comments | Posted in CPAN, Perl

This week, another in the modules-I-plan-to-use series. For my current CPAN Twitter-bot, I essentially wrote the infrastructure that Timeout::Queue would have provided me with, had I known about it at the time. So I plan to use it in my ongoing re-write (which isn’t much further along than the last time I mentioned it).

What it does, in a nutshell, is manage a queue in terms of how soon each item is supposed to occur in time. As an element is enqueued, part of the process is specifying how soon the item should “time-out” in reference to the current moment. Then the object referent can be used to sleep until the next element’s time-out occurs, at which point you can retrieve all the items that are currently “timed-out”.

In my current bot, I poll the RDF feed from search.cpan.org every 15 minutes. When there are new items to post to the Twitter stream, I try to space them out over the next 15 minutes so that the bot doesn’t spew too many updates at once. I do this by dividing the 15 minute interval by the number of updates to post, then queuing them up with appropriate gaps between them. I also use the same queue approach to set the next poll of the feed, to check for changes/updates.

The code isn’t overly-complex, but it does lend itself to some subtle errors. In the early stages, I would often see updates come in “clumps”, because I had mis-managed the offset calculations. Had I known about this module, I could have saved myself some work. It does everything my code does, and does a few things more that I didn’t think to write.

If I could change anything about the module, I’d probably just have it offer a sleep() method to avoid having to explicitly ask for the current amount of time to wait, then having to do the sleep myself. It seems like that will always be the usage pattern, so it would make sense to have it be an available method. Then again, if it’s a good OO citizen and can be easily sub-classed, maybe I’ll just sub-class it and add the method myself! Then I can make the other change– the name. Call me pedantic, but I feel that “Queue” should have been the first element of the namespace, and I’m not really keen on the use of “Timeout”, since the items don’t really “time-out” in the sense of waiting for an alarm signal or anything. But these are minor nits.

This will be Yet Another piece of code that makes my coding task easier. (Once I get enough tuits to get back to that project.)

Tags: , ,

Idle Thoughts on Parsing XML (slightly Perlish)

October 7th, 2009 | No Comments | Posted in Perl, XML

(Side note: There was no Module Monday post this week, as I was too swamped to look for one to cover. Check back next week…)

I’m in the (achingly slow) process of writing a new XML-RPC parser using XML::LibXML. Because (according to their own docs) their SAX support is spotty, I’m letting the library parse the whole message into a DOM object and then using that object to get the request or response. This has proven to be a serious pain in the lower regions.

The XML::Parser approach I’ve had since RPC::XML’s inception is an event-based parser: I use a state-machine/stack approach and push/pop items as needed, based on whether my event is a tag-start, tag-end, text, etc. As a side effect, I validate the document, since the stack/state machine will throw an exception if some event doesn’t fit in to what it is expecting.

Taking a DOM approach means more work, as not only am I drilling down for the data I need, I also have to do some checking for validity as well. (Some might point out that XML::LibXML supports checking document validity against any of a DTD, XML Schema or RelaxNG schema… I’m actually familiar with that. But there is no “real” (i.e., “official”) DTD or schema for XML-RPC for me to use in this case.)

So here’s my observation, which is probably blindingly-obvious to everyone else who’s worked with XML: SAX/event-based parsing is the way to go for processing a whole document, and DOM is better for cherry-picking pieces from different parts of it.

Like I said, probably pretty obvious to the rest of you, but it’s hitting me over the head pretty hard these days.

Tags: , ,