Managing Boilerplate with Import::Base

Boilerplate is everything I hate about programming:

  • Doing the same thing more than once
  • Leaving clutter in every file
  • Making it harder to change things in the future
  • Eventually blindly copying without understanding (cargo-cult programming)

In an effort to reduce some of my boilerplate, I wrote Import::Base a module to collect and import useful bundles of modules, removing the need for long lists of use ... lines everywhere.

Between Learning and Doing


A long time ago, when I started building my first video game server for Double Cluepon, my video game company, I did a bad thing. I looked at the AMF library for Perl and Python and decided that Python's looked better. I had always meant to learn Python, and this felt like the perfect opportunity. It had cooperative multitasking (Twisted) and it had an ORM (SQLAlchemy), so along with the messaging format (PyAMF), I had everything I needed to build a server for a Flash MMO (later migrated to AIR).

Let me reiterate my mistake: While under time constraints, I chose to learn a new programming language. I didn't realize my mistake until it was too late.

perlsloc - Count Perl Source Lines with Perl::Tidy

While spending some time putting together my own perltidyrc file, I became intimately familiar with the Perl::Tidy documentation.

One day, I decided to find out exactly how much code I was maintaining. Since perltidy can strip comments and POD, and also normalize the source code to make a fair measurement, it's a perfect tool for counting Source Lines of Code (SLOC).

Here's a small shell script using ack, perltidy, xargs, and wc to count the source lines of code in any number of directories.

ack -f --perl $@ | xargs -L 1 perltidy --noprofile --delete-pod --mbl=0 --standard-output | wc -l

ack -f lists the files that would be searched, and --perl searches Perl files, so we get ack's heuristics for finding Perl files. xargs -L 1 invokes the following command for every 1 line of input. The perltidy command strips the pod and tightens up the whitespace and writes the result to stdout, which wc -l will then count, line by line.

So, as an example, the current Statocles release has 50% more test lines than source lines:

» perlsloc lib bin
» perlsloc t

Conflict Resolution: local::lib and git's Perl

I ran into a frustrating problem the other day:

$ git add -i
/usr/bin/perl: symbol lookup error: ~/perl5/lib/perl5/x86_64-linux-thread-multi/auto/List/Util/
undefined symbol: Perl_xs_apiversion_bootcheck
fatal: 'add--interactive' appears to be a git command, but we were not
able to execute it. Maybe git-add--interactive is broken?

I've seen this error message from Perl a lot. It basically means that I'm trying to load an XS module compiled for a different version of Perl. Since git is directly trying to run /usr/bin/perl (5.10.1) as opposed to the perlbrew Perl I have installed (5.16.3), the error comes as no surprise: PERL5LIB is checked before Perl's built-in libraries. So if you have a local::lib (which adds its directories to PERL5LIB) and try to use those modules in a different Perl, things may not work as you expected.

What is more surprising is that Git explicitly uses /usr/bin/perl in the first place. Some Google-fu brought up a thread on the Git mailing list about changing to #!/usr/bin/env perl, but it appears this was rejected. According to another post in that thread, it is possible to set PERL_PATH when running make on Git, but that did not seem to work for me.

Chicago.PM New Website! New Meetup URL! New Presentations Project!

Lots of news for the Chicago.PM group! We've got a new Chicago.PM website, powered by Github, up at The website is completely editable via Github using the Octopress system. We hope to start sharing resources about Perl on our website, increasing the exposure of the good tutorials and learning sites.