Tag: perl


YAPC Back, see

After spending the bank holiday in Wales, I trotted off to Brum for YAPC::Europe 2006. It’s my first YAPC and a heck of an experience. 3 days of being immersed in Perl and Perl people. I took in a heck of a lot…

  • I have to learn how to get Catalyst working. Actually, I did a bit of that on the train on the way back thanks to the CPAN mirror that they handed out in the goodie bag and the power sockets on Virgin trains. I wish I had understood more of Matt Trout’s presentation, but it whizzed past at hypersonic speed.
  • Jos Boumans is a sick puppy. He did the funniest presentation of the conference, “Barely Legal XXX Perl”. An exploration of how to twist Perl into successfully compiling and running Acme::BadExample. As amusing as it was, it also provides a keen insight into techniques that might come in useful if sufficiently encapsulated…
  • Moose needs to be investigated further. It seems like a good bid at providing a sane OO environment for Perl. It looks like a good step towards Perl 6. It’s still using a blessed hash, but that’s probably a good thing on the whole; it means Data::Dumper still works.
  • I attended two talks on POE. Firstly, Merijn Broeren gave an overview of all the weird terminology associated with it. At this point, I wasn’t completely put off. But Jan-Pieter Cornet’s “Fun with POE” on the second day really helped bring things into perspective. We spent an hour and a half creating an IRC bot that did various things up to and including acting as a DNS server! It’s definitely something I’m going to try and use as soon as I get a chance.
  • I missed Tatsuhiko Miyagawa’s Plagger talk, but it was a good one by all accounts (certainly the slides I read afterwards piqued my interest). Unfortunately, I don’t have a use for an utterly pluggable RSS/Atom aggregator. Yet. Good to know it’s there though. It does pull in half of CPAN, however. I seem to recall somebody saying afterwards that it completely overheated their laptop and used up all the battery installing it.
  • The Lightning Talks were mostly pretty good.
    • Tatsuhiko Miyagawa demonstrating scrolling google maps by tilting his thinkpad was brilliant. I am in awe of being able to think that one up and make it work…
    • “undef isn’t” was hilarious and succeeded in its goal of making undef a lot less well defined. Although it did remind me of Python, which allows you to assign a new value to None (at least it warns at you for doing this these days).
    • Jifty rocks. Must look at that too. It seems more rails like than Catalyst, which is preferable for some of the things I’m looking at right now.
    • HTTP::Async by Edmund van der Burg is a neat module that appears to solve a common problem in a nice simple way.
    • Tim Bunce’s work on DBI for parrot looks fascinating. I really appreciated his humility when he talked about reusing the JDBC API where possible…
    • I have a request to people: Please stop creating more XML Writers! Aaron Crane did a talk about the 30+ Getopt modules on CPAN. I feel that it’s getting that way about XML Writers… (disclaimer: I’ve written two and they both suck).
  • Acme did a superb talk about searching in Perl. He covered KinoSearch, Search::ContextGraph and Algorithm::Cluster. For me, this really built on Kevin Falcone’s talk summing up the options for searching in Perl.
  • If you haven’t used profiling in DBI yet, learn how. You can do a heck of a lot with it. Oh, and if you’re doing bulk loading, check out execute_for_fetch().
  • There were two non-Perl talks: Marty Pauley on lithp (a discussion of where lisp came from and why you should learn it) and Bernd Ullman on APL, which was hilarious (most people debug APL by throwing it away and writing it again). Scarily, APL is still seeing active use in financial institutions…
  • Bernd also gave a great insight into the sheer pain of getting Perl running on an IBM mainframe. It scared and delighted me in almost equal measure.
  • Smylers talk on recruiting Perl programmers was full of useful advice. It really gave you some good ways to think about how to test your candidates.

Unicode Depresses Me

Perl is meant to have reasonable Unicode support. So why do I still have to write this at the top of a test?

  use utf8;
  use Test::More 'no_plan';
      my $Test = Test::Builder->new;
      binmode( $Test->output,         ":utf8" );
      binmode( $Test->failure_output, ":utf8" );
      binmode( $Test->todo_output,    ":utf8" );

I would have thought that adding the -CS flag to the #! line would have fixed this. But that doesn’t do it. Ah well, I’ve filed a wishlist bug: RT#21091.

Lexical Attributes

A week or two ago, I took an idea from Aristotle about “shortcut” functions and made it into a little module: Attribute-Shortcut. Aristotle pointed out in the comments that the attributes should also work on coderefs as well as named subs. i.e.

  sub basename :Shortcut { s!.*/!! for @_ };
  my $basename = sub :Shortcut { s!.*/!! for @_ };

However, I can’t seem to find a way to make this work. Attribute::Handlers passes you the string “ANON” instead of a glob reference.

Looking deeper at the documentation for attributes, it seems to imply that attributes on lexical variables aren’t really very well supported anyway.

I think I may have to conclude that this isn’t going to work for now…

Constant Pain

Trelane was complaining about Image::Imlib2 the other day. Apparently, it accepts any method call without error. i.e. it’s a blackhole object.

A quick inspection of the source revealed two things:

  1. An AUTOLOAD() method, to resolve unknown method calls.
  2. A constant() function in the XS to resolve names to constant values. This was being called from AUTOLOAD().

As it turned out there was a bug in constant()—it wasn’t correctly reporting constants that didn’t exist. But, a one line patch fixed things:

  diff -ruN Image-Imlib2-1.08/lib/Image/Imlib2.xs Image-Imlib2-1.08-dom/lib/Image/Imlib2.xs
  --- Image-Imlib2-1.08/lib/Image/Imlib2.xs       2006-03-01 19:11:15.000000000 +0000
  +++ Image-Imlib2-1.08-dom/lib/Image/Imlib2.xs   2006-06-17 17:25:56.000000000 +0100
  @@ -25,6 +25,7 @@
           if (strEQ(name, "TEXT_TO_ANGLE")) return IMLIB_TEXT_TO_ANGLE;
  +    errno = ENOENT;
       return 0;


But when questioned, the author (acme) didn’t know much about why the constant() function was there at all. And it turns out both constant() and AUTOLOAD() are created automatically by h2xs. Newer versions use ExtUtils::Constant instead of doing things directly.

However, the fact is that we’re still using AUTOLOAD() to load in a bunch of things that we already know. Kind of pointless. Thankfully, Trelane was slightly more determined that I am, and wrote a proper patch getting rid of AUTOLOAD() entirely and creating individual functions for each constant. As a result, we now have Image::Imlib2 1.09.

What’s the moral of this tale? Always question code that gets autogenerated for you. You absolutely have to understand what it’s doing for you. Don’t assume that the person who wrote the generator knew more about your problem than you do.

XML::Genx 0.21

I’ve released a new version, which fixes a blindingly obvious error: you couldn’t pass in characters between \x80 and \xff unless they had the UTF-8 flag turned on. I don’t know how I missed that. 🙁

XML::Genx Plans

I was talking to Mark Fowler yesterday and XML::Genx came up. He had a couple of good points:

  • It’s not absolutely clear in the documentation that any valid Perl string will work correctly (be it UTF-8 encoded or not). I need to double check the tests for this and amend the docs.
  • The API is still fairly horrible. It mirrors the C api almost exactly, but this feels very odd as a Perl programmer. I need to have a think about what would be better. Ideally, I’d like something more like ruby’s builder. In fact, I actually wrote something similar to that before (XML::SAX::Builder), but that uses SAX, which is too slow in Perl.

I really appreciate the feedback. Apart from Aristotle, it’s the only feedback I’ve had since I released it.

If I can figure these out, I should probably slap a 1.0 on it.

I also reckon I should do a talk on “Why we need another XML writer”. There are quite a few on CPAN already and I should say why I wrote another one…

New Releases

I’ve just done a couple of new releases of my modules:

  • JavaScript::JSLint 0.04, which is just renaming from Lint to JSLint to more accurately reflect where it’s come from (pointed out by Matthias Miller).
  • subatom 0.07 which switches from the baroque XML::Atom api to the much nicer XML::Atom::SimpleFeed (thanks, Aristotle).
  • subatom 0.08 because I am a doofus and left a warn statement in.

JavaScript::Lint 0.02

I’ve just put together a new version of JavaScript::Lint. The main new thing is that you can now specify options to control how the lint works. You probably want to enable the undef option, for instance.

I also fixed a problem where I was covering up errors when the lint couldn’t do anything more (e.g. nested comments). After my mailing Douglas Crockford about it, he kindly pointed out that this was mentioned in the comments. I’d entirely missed it. Ah well. Anyway, it now returns a “cannot proceed” message.

Update: after spotting something rather stupid, I’ve now uploaded JavaScript::Lint 0.03 instead.


After whinging gratuitously about how cruddy non-browser JavaScript is, Mark Fowler kindly pointed me in the right direction to get Perl integration working: JavaScript.pm.

So now I’ve wrapped up JSLint into a small command line tool (and Perl lib), JavaScript::Lint.

It’s fairly simple at the moment. I plan to add support for the options in jslint soon.

mod_perl 2 not ready yet

I’ve spent nearly three days this week trying to port one of our sites to Apache 2.2 and mod_perl 2.0.2 (from Apache 1.3.33). It should be a relatively simple exercise thanks to the porting notes available:

Yet sadly, there’s still a lot of problems with mod_perl 2. Firstly, much CPAN software still hasn’t adjusted. In my case it was SOAP-Lite. But I also noticed that libapreq wasn’t classed as “ready” by Mason, so we had to fall back to CGI.pm there.

But the real killer is that they managed to completely break environment variables, in the name of thread safety. Unfortunately, our application uses Inline::Java from inside Apache to talk to Lucene. Now Inline::Java spawns a JVM to run a JAR file and be the server. So that the JVM can find the jar (as well as the lucene jar and our code), it sets $ENV{CLASSPATH}. Except that change never shows up, so the JVM just says “unknown class” and exits.

Basically, mod_perl2 breaks system. This is not clever.

So we won’t be upgrading to Apache 2.2 for a while. This is a shame, as it has a bug fix we really need (>4Gb file support). Instead, we switched to using FTP. Yuck.