Perl 5 source repository now hosted in git

Perl 5’s source code is no longer locked into the odious proprietary Perforce repository where it’s been hosted for years. It’s now hosted in the git distributed version control system. This is a huge win. [The announcement]( lists a number of benefits:
– With a public repository and Git’s extensive support for distributed
and offline work, working on Perl 5’s source becomes easier for everyone
– Because Git is open source, all developers now have equal access to
the tools required to work on Perl’s codebase.
– Core committers have less administrative work to do when integrating
contributed changes.
– Developers outside the core team can more easily work on experimental
changes to Perl before proposing them for inclusion in the next release.
– A vast array of improved repository and change analysis tools are now
available to Perl’s developers.
– The new Git repository includes every version of Perl 5 ever released,
as well as every revision made during development.
Before this move, if you wanted to submit a patch to Perl 5, you had to submit the patch against bleadperl, the main development branch, which was an always moving target. The repository wasn’t directly available, so you had to either keep your own repository that got updated with patches as they were applied, or just deal with your local changes getting stomped on.
Now, that’s all over. It’s butt simple to get the Perl source:

$ sudo yum install git
(Your package manager may vary)
$ git clone git://
(Time passes as much downloading happens)
$ ls
AUTHORS    perl.h
Artistic      configure.gnu*
Changes       cop.h            perlapi.c

That’s it. Now you have a copy of everything, and can make patches much more easily.
Thanks to Sam Vilain and everyone else involved in this huge move. puts their money where their infrastructure is

[](, a global hotel reservation service based in the Netherlands, has [donated $50,000 to the Perl Foundation]( to help in further Perl development, specifically Perl 5.10.
As Richard Dice, president of TPF says, “ has demonstrated extraordinary vision and community spirit,” but they also know that their infrastructure needs ongoing support. Their IT team is 50+ persons, and Perl is the “language of choice.”
Thanks to for this donation, and let’s hope it is part of an ongoing trend.
Now, if only TPF could get, say, $5 from every company that used Perl. Think how many programmer-years that could buy to help get [Rakudo]( out the door.

How to spot bad Perl code, 2008 edition

[Max Kanat-Alexander]( posted an article called [“How Not To Get Hired.”]( Since I’m in the end stages of finishing [my book on geek hiring](, I was hoping there would be swell interview horror stories. The first bullet talks about not following instructions in a job ad, but the rest is really a laundry list of Perl practices that nobody should be doing any more, and a few more on what we should be doing, starting with using Moose.
I’m sure there’ll be some crabs out there who say “Aw, that’s just all common sense,” but common sense rarely is. It’s well worth a read.

Perl 5.8.9 is out

Perl 5.8.9 is [available for download]( From reading the changelog, it doesn’t seem like there’s too much earth-shaking in it.
There is a wonderful new utility added. An analogue to *perlbug*, the [new *perlthanks* program]( lets you send your thanks to the development team. What a great idea that is.

Perl Mongers at work: adds warn() to Rakudo

This makes me so happy. Eric Wilhelm writes in [this use.perl posting](
> Our [December Meeting]( was a rakudo workshop, where we realized that rakudo had no implementation of `warn()`. While the implementation that got checked-in by the end of the meeting is not fully compliant with the spec’s requirement that warn() throws a certain sort of resumable exception, it does now at least exist, and prints your message on stderr.
While I love any given gathering of Perl Mongers, whether to have a technical talk or just to drink beer, I’ve always thought that it would be great to have PM groups use their collected talents to add directly to the Perl community. My long-dormant [Phalanx project]( was an attempt to take advantage of that.
Now, has made a concrete contribution to the #1 need of the Perl community today: Getting a Perl 6 implementation out the door.
Bravo to!

Two advent calendars to choose from

In addition to the yearly [Perl Advent Calendar]( from Jerrad Pierce, originally started by Mark Fowler, the Catalyst Team have put together their own [Catalyst Advent Calendar](
Each calendar gives a new tip or trick or module to use each day. [Today’s tip]( on the Perl Advent Calendar is about how to use IPC::Filter to communicate between processes, while [yesterday’s entry on the Catalyst Advent Calendar]( discusses how to create PDFs for your web application.

“Higher-Order Perl” available for free download

Mark-Jason Dominus’ fantastic book *Higher-Order Perl* is now available for free download at [](
MJD notes:
> This is better than the bootleg copies available from download sites in at least three ways:
> > – It is the complete text of the second printing, which incorporates many minor corrections; the bootleg copies are all bootlegs of the first printing.
> > – It does not have a nasty little grafitto advertising a vainglorious bootlegger plastered on every page.
> > – It was come by honestly, not stolen from the printer.
Everyone is now out of excuses for not having read it. Go read it now if you have not. You will not be sorry.

CPAN Testers gives module authors new flexibility

The CPAN Testers group do some pretty cool work. According to the group itself, they are
> … a group of over 100 volunteers who test as much of
> CPAN as possible across a plethora of Perl versions and operating
> systems, which is usually many more environments than authors have
> available to themselves.
Don’t write for Windows, and don’t have [access to a Windows VM courtesy of Microsoft]( At least the CPAN Testers will send you the error report from a failed attempt to build on Windows.
The downside of CPAN Testers is that you may not care about certain configurations. If one of the CPAN Testers mistakenly tries to build Win32::OLE on a Mac system, the author of Win32::OLE isn’t going to be very interested. Along those same lines, if your module for Perl 5.8 doesn’t degrade nicely for 5.6 or earlier, then you’re going to get error reports as well.
Now, [the CPAN Testers site gives authors flexibility]( in how they’d like to tests on their modules reported. I can specify which types of reports (pass, fail, NA, etc) I get, and on which versions of Perl I’m interested. I can set up a default profile and then set up per-distribution profiles as well.
It’s fantastic. Anyone who is doing CPAN modules should take a look at [this excellent service]( and its new customizations. Thanks to the CPAN Testers for making it available.

Write your tests before you fix the bugs: A shining example from PHP

I went to upgrade our PHP install today, but found that:
> [PHP 5.2.7 has been removed from distribution](
> Due to a security bug found in the PHP 5.2.7 release, it has been removed from distribution. The bug affects configurations where `magic_quotes_gpc` is enabled, because it remains off even when set to on. In the meantime, use PHP 5.2.6 until PHP 5.2.8 is later released.
This is one of those cases of “you write a test for anything that has ever gone wrong.” If the PHP guys have any clue at all, they will have written many tests of all the possible ways that `magic_quotes_gpc` can get set incorrectly, *before* fixing a single line of source code.
(For those unfamiliar with this peculiar misfeature of PHP, `magic_quotes_gpc` lets you automagically instantiate global variables based on GET and POST variables, which allows bad guys to muck with your code by passing in parameters that they know will mess with your code when turned into globals.)