I released perl 5.13.10 today. I might write more about that later. But one significant change in it is that Perl now has many more regex flags.

So I wrote a short one-off script to find out what words I cound construct from the flags.

Now it just gives you one word that contains as many of the flags as possible, and gives you the remainder. What would be more interesting would be to detect cases where multiple valid words can be made from the flags. E.g. "mix" and "uploads". It just detected that by accident.

I leave that as an exercise for the reader.

In May I decided to stop using Debian's perl 5.10.1 in favor of using a 5.13.1 built with perlbrew, and CPAN modules built with cpanminus. It's been great, here's how I did it.

Before switching over I ignored Debian's perl library packages, and installed everything with cpanm into /usr/local. But since I wanted to use the new post-5.10 features of Perl I thought I might as well replace all of it and use a newer perl.

What I did:

• Created a v-perlbrew user. All users on the server can use this centrally managed Perl and its modules
• Added this to everyone's .bashrc: test -f ~/perl5/perlbrew/etc/bashrc && source ~/perl5/perlbrew/etc/bashrc
• Made a list of CPAN modules that I need. When I upgrade the perlbrew perl I can just run grep -v ^# cpan-modules | cpanm to get all the required modules with the new perl.
• Ran around changing PATH in crontabs, Apache settings etc. so that everything that isn't internal to Debian itself uses perlbrew's perl instead of /usr/bin/perl.

Getting the PATHs right everywhere turned out to be the hardest part. A lot of things in Debian have a path like /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin. I haven't found out how to change that, presumably some of them are hardcoded into executables like bash.

To get around that I have to hardcode the PATH to perlbrew in every crontab that uses perl. For a full list of these and other changes I've made the output of git --git-dir /etc/.git log -p --reverse -Sperlbrew available as a Gist.

The only caveat I've encountered is that there's one global perlbrew bashrc in ~/perl5/perlbrew/etc/bashrc. So if I can't use perlbrew switch to only switch some users onto a given perl. It would be neat if perlbrew supported having the current symlinks in a local ~/perl5 while the actual binaries and modules were in ~v-perlbrew/perl5.

I have an RFC patch series to Git to add gettext localization support to it. So that eventually you'll be able to configure Git to e.g. shout error messages at you in German. Won't that be a nice variant of the current abuse? I think so.

Here's the latest version of the patch series I posted to the Git mailing list.

For the Perl side of things (Git is partially implemented in Perl) I'm using libintl-perl's Locale::Messages. It was very pleasant to work with it. I wonder why more Perl projects don't use it instead of Perl-y libraries like Locale::Maketext.

Maybe it's just the GNU gettext dependency they're trying to get rid of, although libintl-perl includes a Pure-Perl version of the tools it provides .mo, so probably not.

Actually the way most open source projects do localization is "not at all". I don't blame them, I certainly can't be bothered most of the time. But I wonder to what degree we're losing potential users & contributors because of this.

There was a recent-ish study of social networks on GitHub where it was evident that a lot of Japanese Perl users had formed a social-ghetto amongst themselves. I've seen a few trending Perl repositories that only have README files in Japanese.

Maybe better localization tools - and most of all - a commitment to use them would help to bridge some of that.

I previously wrote about trying out MooseX::Method::Signatures. That module is neat, but incurs a significant runtime penalty per subroutine call.

Now I've tested out Method::Signatures::Simple. It's powered by Devel::Declare and doesn't seem to incur a any runtime penalty. However, since it needs to do some work when the subroutines are compiled, there's a 3-4% compilation hit for my tests:

But on runtime there's no hit at all:

Here's what I needed to do to convert Hailo to it. Unfortunately using it breaks interaction with Devel::NYTProf. When I generate profiling output with nytprofhtml what were previously links to my subroutines aren't links at all.

That's a big price to pay for just turning this:

Into this:

So unless I can figure out a workaround for that I won't be merging that branch.

Since 5.12 got released a lot of bugfixes have been flowing into blead and one new feature. The prctl() support for $0 that I previously blogged about just got commited by Steffen Mueller.

With this patch you can finally killall programs you write in perl on Linux without killing all of your perl processes indiscriminately.

Jesse Vincent uploaded the perl-5.12.0-RC3 release to the CPAN. It's important that that this release is tested to flag any potential release blockers. If none are found it'll be released as 5.12 on April 9.

Here's how you can do that:

All tests should have been successful. To install it (without touching your existing perl!) do:

Now you have an installed perl-5.12.0-RC3 in ~/perl5-rc3/installed/bin/perl. Now just configure CPAN to install modules without nagging:

And then maybe try installing your favorite CPAN modules, or bundles that suck down a lot of them (using sudo here because my ~/.cpan is owned by root):

Of course the most useful think you can do is test it on your own in-house code. All the code on the CPAN has probably been tested with 5.12 already.

If you encounter any issues first check if they're listed in the errata or mentioned in the perldelta for 5.12.

if you think you've found a new bug please report it with the perlbug tool installed with perl-5.12.0-RC3.

According to git log I've submitted 33 patches to perl core, I just submitted another one which on Linux changes this:

Into this:

If this patch gets applied doing killall onion on 5.14 will get you a dead process instead of onion: no process found, the same goes for ps(1) and top(1) which read the legacy process name by default. Before this patch the behavior of $0 assignment on Linux hadn't changed since perl 4.000 came out.