ShadowCat’s “Enlightened Perl Iron Man Competition”

Bingo!

ShadowCat Systems, an open-source development company from the UK posted an entry on their blog today which hits the nail on the head. Perl needs marketing and it needs it within the realms that the rest of the world moves.

We, the collective Perl consciousness, do not really like all this modern internet stuff. We don’t appear to like blogging, we don’t appear to like forums and pretty web 2.0 stuff? That’s right out. As Matt so correctly described it

Perl people hang out on mailing lists. We bottom post, carefully interleaved, with 76 character lines. We have signatures that meet the McQ standard for acceptable size. We hang out on IRC servers and bitch, moan, interact and collaborate with the aid of an 80×25 xterm with irssi, BitchX or IrcII in it[3]. Sometimes we sit at home with a beer and do one or more of the above. Forums? Meh. Those are the things the PHPtards like because they can’t figure out how to work a mailing list, right? Blogs? That’s not even a fucking word!

I hate to quote so much at once, but this paragraph captures the issue completely. The reason for all of the “Perl is fading” nonsense is almost entirely because we don’t seem to like to talk about Perl in any format which is post-1997.

But it seems that we have finally started to realize that this is a problem and have, to paraphrase, “become the change that we want to see” because we’re actually seeing blogs about Perl which if not exactly web 2.0 are at least not from 1997.

The most popular “new” site of course is Perl Buzz, but it isn’t the only site. There are many small blogs where people post infrequent articles about Perl, but finding them can be tricky. To help address this issue Shadowcat’s Matt Trought has decided to start handing out awards to people for frequent postings on Perl through his Enlightened Perl Iron Man Competition.

If you haven’t already read the article then you should do. Really. Matt expresses his frustrations with what can only be described as proper English enthusiasm – yeah, that does mean with lots of swearing. And frankly he’s right. Every word of it is true.

Indeed I can remember posting a similar rant on starting to post at perladmin.oreally.co.uk blog. Sadly the server behind it was a freebie server hosted by a friend and it needed to be ditched and, as yet, I’ve not seen the data since to resurrect the blog else where. My irritations were something similar – although I also went on to criticize the fact that for years we’ve been told that Perl 6 will be better and “is coming”. For my efforts I got a couple of snarky comments telling me that I shouldn’t criticize Perl 6 , that I was only adding to the problems by doing so, and one note saying that “I did go on..”.

Well that was my rant, and Matt has posted his. But Matt has also gone on to proposed a solution, his “Perl Iron Man Competition“. To paraphrase a commonly used term about the current economy, perhaps we are seeing Perl’s green shoots of recovery?

I hope so. Rock on Matt!

Fix for SVN::Web and ’subversion/libsvn_ra/deprecated.c’ line 289: assertion failed (*path != ‘/’)

Updated: April 22nd 2009:
This issue is actually SVN::Web Bug 37388. I didn’t see that because I that bug was filed using the error messages for SVN v1.5.0 and the function svn_ra_get_log() that is called is in a totally different library in v1.6.0 so searches for the v1.6.0 error do not find that bug report or the patches. Thanks to commenter Alexandr for drawing this to my attention.

The use base.pm and SIGDIE problem, still not fixed in Perl 5.8.8

This weekend I’ve been playing around with a “from scratch” idea for an app/framework thingy. I’ve been assembling the pieces in my head, in notes and in reading around. While I doubt its going to become the next “IT” framework, even if it gets released to the public, I’m hoping it will give me a clearer understanding of how to make a modern web app in Perl.

On of the things I’ve been trying to do is make the core of the app fairly sensible in terms of setting up lots of stuff by default. So, for example, to default to using UTF8 encoding and Localization as well as basic stuff like signal handlers. I cheerily set up my SIGDIE handler in my initApp() method to handle stuff like checking if headers need sending before dumping the error message back to the browser and moved on.

After getting the basic thing working a little I decided to approach Localization (L10N). I’ve never tried this before and I have to be honest the suggestions on how to do this in Perl … err.. lack. I found myself hitting the same few articles time and time again. Heck even Bugzilla’s roadmap uses the same list of articles quoted else where (TJP13, Locale::Maketext::Lexicon, and the Cpanel.net roadmap for the future of Cpanel), but as with most things Perl trying and poking seems to get you somewhere.

In my case it got me more than I’d bargained for because in trying to make my app flexible the localization is optional, and more so, tried to make the use of Locale::Maketext::Lexicon optional so you can use other modules if you prefer. This meant that I was a prime candidate for the “use base” bug.

If you haven’t come across this bug then its pretty simple. There’s a bug in base.pm in which the die signal handler entry in %SIG is local()ized for part of import(). This is great because its localized and the author makes an attempt to restore it afterward to ensure it was reset correctly. Unfortunately it goes horribly wrong. And I’ve just wasted another couple of hours tracking this crap down only to discover that because this is a relatively new machine I hadn’t patched base.pm on it unlike my other servers … *grr*.

If you don’t know the bug a solution is documented on the perl5 mailing list. The code block in question is this:

 85             my $sigdie;
 86             {
 87                 local $SIG{__DIE__};
 88                 eval "require $base";
 89                 # Only ignore "Can't locate" errors from our eval require.
 90                 # Other fatal errors (syntax etc) must be reported.
 91                 die if $@ && $@ !~ /^Can't locate .*? at \(eval /;
 92                 unless (%{"$base\::"}) {
 93                     require Carp;
 94                     Carp::croak(<<ERROR);
 95 Base class package "$base" is empty.
 96     (Perhaps you need to 'use' the module which defines that package first.)
 97 ERROR
 98                 }
 99                 $sigdie = $SIG{__DIE__};
100             }
101             # Make sure a global $SIG{__DIE__} makes it out of the localization.
102             $SIG{__DIE__} = $sigdie if defined $sigdie;

The general idea here is that base.pm doesn’t want a custom SIGDIE handler interfering with what’s going on and so overrides it and tries to reset it. The bug is that this doesn’t happen. What happens is that your signal handler is always removed. Why? Well that’s because line 87 causes SIGDIE to be defined, but to be defined with no value. It seems that this is the default for signal handlers, even though it doesn’t appear to happen for other variables, including hashes:

#!/usr/bin/perl
use strict;
use warnings;
use vars qw(%A);

print "\$A{B} def: ", defined($A{B}) ? 'Yes' : 'No', "\n";
$A{B} = 1;
print "\$A{B} def: ", defined($A{B}) ? 'Yes' : 'No', "\n";
local($A{B});
print "\$A{B} def: ", defined($A{B}) ? 'Yes' : 'No', "\n";

print "\$SIG{__DIE__} def: ", defined($SIG{__DIE__}) ? 'Yes' : 'No', "\n";
$SIG{__DIE__} = 'IGNORE';
print "\$SIG{__DIE__} def: ", defined($SIG{__DIE__}) ? 'Yes' : 'No', "\n";
local($SIG{__DIE__});
print "\$SIG{__DIE__} def: ", defined($SIG{__DIE__}) ? 'Yes' : 'No', "\n";

This outputs the following. Can you spot the problem?

$A{B} def: No
$A{B} def: Yes
$A{B} def: No
$SIG{__DIE__} def: No
$SIG{__DIE__} def: Yes
$SIG{__DIE__} def: Yes

That’s right. In a normal hash once we localize a hash variable then we end up with it not being defined, irregardless of whether or not the original var was defined. This doesn’t hold true for %SIG. In the case of %SIG localizing it causes the elements to be defined. ALWAYS.

Normally this isn’t a problem because you don’t use these, and besides which the value is defined but zero. But in the way this is handled in base.pm, its a problem because of the strange way that SIGDIE is restored from the var $sigdie, but $sigdie is assigned to after the call to local():

 99                 $sigdie = $SIG{__DIE__};
100             }
101             # Make sure a global $SIG{__DIE__} makes it out of the localization.
102             $SIG{__DIE__} = $sigdie if defined $sigdie;

Thanks to above quirk with %SIG and local in this situation $sigdie (line 99) is ALWAYS defined, but because $sigdie is assigned to after local() is used, $sigdie doesn’t contain your signal handler, but instead contains “”. So we hit line 102 where the block is conditional on $sigdie being defined, which it always is, remember, and thus the code always assigns “” to $SIG{__DIE__} after loading the given module. As line 102 is outside of the block in which local() is used at this point %SIG is the actual %SIG (the global copy if you prefer). Therefore this assignation has the effect of wiping out any signal handler you may have installed despite the fact that it is trying to achieve exactly the opposite and restore the original signal handler.

The solution mentioned above is to use || undef on line 99. This has the effect of assigning undef to $sigdie because the signal handler is “”, or false, thus line 102 doesn’t pass the conditional and install this “” as the SIGDIE handler. It works, but I have to ask, why bother? It seems like the better way is to simply remove all of the $sigdie stuff and localize %SIG resetting it to its default, and then let the code exit the block. When it does the localized version of %SIG is removed and there’s no risk of clobbering an existing handler.

An alternative, if you must use $sigdie, is to assign the current SIGDIE handler as you’re declaring it, thus:

 85             my $sigdie = $SIG{__DIE__};
 86             {
 87                 local $SIG{__DIE__};

Then remove line 99 where the value is messed up:

 99                 $sigdie = $SIG{__DIE__};

Having just checked for updated modules the other day, I have to say, I’m very surprised that there isn’t a patched version of this which has been sent out to versions of Perl with broken versions. As I understand it 5.10 doesn’t suffer this problem, but since the stable version is still considered to be 5.8.8 it seems like it should be updated too. It would save people like me wasting a few hours trying to track down what’s going on with their code….

Colin.

Perl 6 and the “Vaporware” Label

Perusing Perlbuzz, as I tend to do on a rainy saturday afternoon, I was intrigued by Andy Lester’s latest post “Perl 6 isn’t exactly vaporware” in which he comments on the vaporware label that is often used around Perl 6.

I must say that I found it quite interesting to see Andy calling for an early adopter’s release of Rakudo because as he notes,

but the fact still stands that Perl 6 is vapor enough for most organizations wanting to do anything useful.

A while ago I moved this blog to my own site on perladmin.oreally.co.uk. Posting about the move I tried to explain what I was hoping to achieve with the blog – to do my part in building attention to Perl. As part of this I made the observation that I believe one of the reasons that industry interest has turned away from Perl is because, in part, that we keep being promised that P6 is coming, but there is no usable implementation.

The comments I received about the post concentrated only on this part of the post and it was noted that by “bashing” Perl 6 in this way I was only adding to the problem. I suppose that a comment such as this from someone who claims to support Perl could be construed as in-fighting, but this was not the intent of my comment. Rather I was pointing out what I believe to be a very simple flaw in our collective front; that by talking about how great this language will be, but never having anything substantial in circulation, we look bad. Think about the disparaging comments that circulated about Microsoft and its repeated resetting of release dates for various versions of Windows and Office.

I’m not, of course, knocking Perl 6, its hard working designers or developers, or any such thing. Indeed quite the opposite I’m trying to say how I think Perl can be improved after all more interest in Perl means more, and sustained, interesting in Perl 6. Having tried to explain my thoughts, I was amused to read Andy’s post stating exactly the same point that I was trying to get across – that I think Perl is already the best solution to many problems, and that the descriptions we get of Perl 6 make me curious and want to use it, but that I cannot because it isn’t yet available in a form which is stable enough for general use.

Of further interest to those in the Perl community who have a similar view to mine are some of the comments posted in response to Andy’s posting. Indeed the second commenter asks

Have you actually looked at the November source code? It’s full of ugly workarounds and quirky hacks to work around Rakudo bugs

This is a rather disconcerting comment is further strengthened as the author makes mention of some of the issues and while supporters can easily wave off most of them the comment author provides one example as:

3. List assignment. my ($x, $y) = 1, 2; doesn’t work right now

If something like this doesn’t work then it seems to be a long way from being usable. Now your definition of usable may be different from mine, but in my definition it means I can write my apps using it. It doesn’t, of course, mean that I don’t want/like Perl 6 or its designers or developers. I don’t have anything against it, I just don’t think that it is ready and both Andy’s post and the associated comments appear to emphasize that point.

So while it is being developed IMO that the rest of us can help rebuild the love for Perl by concentrating on what Perl can do right now and just accept that Perl 6 isn’t going to be in a cinema near you soon. So lets go Team Perl! :)

Colin.

Incidentally, this is being posted here rather than on my own site, perladmin.oreally.co.uk, because its currently being moved to a new server. It was previously hosted on a box thrown together from junk in 1999. As you might imagine it was slow when receiving any real level of traffic but it was finally withdrawn from service due to its power usage. As a sign of the times, RedBus – the London, England, data center in which the box was hosted – has recently changed its billing calculations to include power consumption and as such a 9 year old box was not a good thing to have around for free and so it needed to be pulled. As a comparison cabinet space and bandwidth, the usual billing metric for data centers, is all but free. The migration has yet to be completed due to various complicating factors. Until then I’ll likely be posting through wordpress again.

Google Search Trends for Scripting Languages

I was poking around on Google earlier and ended up on their search trends page. One of the examples they provided was to compare the searches for the four major script languages, Perl, PHP, Ruby and Python so I decided to see what the data was like for that.

There are no major surprises, sadly, but as you might expect PHP has more searches, but the most noticeable issue after this is that searches for all four languages have decreased since 2004 when the data was first collected.

Will the tightening economy make Perl more attractive?

Based purely on speculation and my own view of the universe, rather than on any material evidence, I was wondering if the tightening of economies around the world may not end up being beneficial for Perl.

Don’t get me wrong. I’m not suggesting something insane like Perl makes you keep your job. But rather I’m speculating that it might help simply because Perl isn’t used soley for the web. So take, for example, the situation where a company has a dedicated web developer and a site written in something other than Perl. If they also have a dedicated Sysadmin then you can bet that much of the stuff in the back end is written in either Perl or Python. Since Perl has been around longer, its more likely to be that.

To be fair, your web developer might be mightily skilled at design and PHP. They may be totally XHTML 1.0/strict and CSS2.1 + firefox/safari proprietary extensions compliant. They may have “mad Javascript skillz”, and they may even be pretty fun to hang out with – say Dex of 17, Chr of 16 and Int of 16. Your sysadmin character is likewise highly skilled at (whatever the hell it is that non-sysadmins think we do and get paid for, because yeah, we can do that :-). Okay, so your techie might have the social skills of a somewhat evolved baboon, easily distracted by shiny objects (or “hi tech gadgets” as we call them now), and the sole demand for raman noodles, but they too are pretty good at their job. Lets call it Chr 12, Dex 15, but an Int of 17 and Wis 17.

In a tightening economy, which would you fire, your Sysadmin or your Web designer?

You see people may believe that “Perl whatever’s“, but it doesn’t. Its actually pretty useful at doing things. At getting the data from your database to your Apache config, to your BIND zone files, to your password files and your websites. Its also pretty handy at quietly monitor the entire network 24/7, and record all of your important information, and parsing your log files.

PHP … not really quite the so handy in that arena. And I do remember a very intelligent developer (of C) friend of mine some 10 years ago back in PHP v3 days trying to admin her box with PHP scripts. More of the kind of thing that developers do when they’re bored than having any practical purpose.

And lets face it. You can let the servers run themselves, or you can let the web site run itself. Which is more likely to break. The fast moving always on, always doing things servers or the website?

I’m not saying that knowing Perl will save your job. I’m certainly not wishing any PHP/Ruby/Python devs lose their jobs. Please guys not spams, we like you, really. I’m just speculating that because Perl isn’t used solely for developing webapps, being a Perl dev might not be a bad thing right now.