Just found this in the source for PPI:

175 if ( $self->{source_bytes} > 1048576 ) {
176 # Dammit! It’s ALWAYS the “Perl” modules larger than a
177 # meg that seems to blow up the Tokenizer/Lexer.
178 # Nobody actually writes real programs larger than a meg
179 # Perl::Tidy (the largest) is only 800k.
180 # It is always these idiots with massive Data::Dumper
181 # structs or huge RecDescent parser.
182 PPI::Exception::ParserRejection->throw(“File is too large”);

PPI/Tokenizer.pm

Yeah. It’s your fault! :-)

Not actually sure why trying to use Test::Perl::Critic::Progressive results in this since I don’t have any files that are that big, but it made me laugh when I discovered the source of the message.

Little did I know that it triggers once of those dependency cascades that includes the kitchen sink.

The reason is that B:O:WorldPay uses XML::TreeBuilder to parse the XML returned by WorldPay. That is a good reuse of modules.

What isn’t is that XML::TreeBuilder’s author wants to have good Perl Best Practice (PBP) tests and so wrote a test for Perl::Critic. From the naming scheme for this test (xt/author/zz_perlcritic.t) this is clearly not a regular test for most people to use (xt = Extra Tests?).

More over the test itself checks to see if Test::Perl::Critic is installed and if not skips the test:


eval "use Test::Perl::Critic";

if ($@) {
Test::More::plan( skip_all =>
"Test::Perl::Critic required for testing PBP compliance" );
}
else {


So no failures will occur if Test::Perl::Critic and thus Perl::Critic isn’t installed. However because of this exuberance the author added Test::Perl::Critic to the list of dependencies and before you know it my server is busy trying to install Perl::Critic.

Thanks, but no thanks.

A quick install with perl Makefile.PL && make && make install fixes this, but cpanm wouldn’t let me install this without P::C, causing the install to take much longer than it should have done…

The author of XML::TreeBuilder handled this correctly by having the test be contingent on having Test::Perl::Critic, but I don’t think that this should be a required module for the module to install as it is not actually used by the module.

I thought that on blogs.perl.org it would at least be seen by Perl people and even if everyone thought what I was writing was dumb, at least it would be seen and I might gain some ideas as to what is good/bad about my attempts to contribute back.

So I finally took the plunge and signed up. I filled out the form and I got this back in response:

To borrow a phrase from Reddit – it is sh*t like this… that is the reason why people think Perl old. We appear to have a universal dislike of UI.

In this case I filled out a very simple form and the error message I get back says

Text entered was wrong. Try again.

What in the world is that meant to mean?

Clearly something I entered isn’t right, but there are the issues with this level of blandness which we should all learn to avoid. I see the following issues;

Generic Message.

You know what test failed so tell me what it was. Don’t just say something went wrong. I can already work that out for myself. What I can’t fathom is what you don’t like.

Cute Quip.

“Try again” seems to simply rub it in. I want to sign up so of course I’m going to try again. You even gave me the form to try again with and so you are expecting me to do this too. Therefore you don’t need to pretend that you were programmed by a bratty 6 year old kid that asks you to guess what number s/he is thinking of. Seriously, drop the cute quips.

Highlight the Problem.

The entry form was redisplayed so why in the world won’t you indicate which field is broken?

Clearly the more appropriate messages is simply:

“[fieldname] is [invald reason]“

No quips are needed. No generic answer that doesn’t actually tell me what is wrong is needed. Just tell me what the problem is in what field. You don’t highlight the field, but it would be nice.

Right now the code for Dancer 2 is reported to cover about 80% of the Dancer functionality. It has been completely rewritten so that it no longer uses any global variables in the core of the application. This is very good news as recent postings on the dancer mailing list have hinted that this may the cause for some random behaviour in Dancer.

In addition Sukria, Dancer’s founder, reports that the back end now is now completely OO through the use of Moo, the light weight clone of Moose.

Testing out Dancer 2 is easy. As noted in the Dancer 2 announcement, all that you need to do is to download Dancer 2 and then use that in preference to your default dancer libraries. E.g.:


$ git clone http://github.com/sukria/dancer2.git
$ cd YOUR_APP
$ perl -I../dancer2/lib bin/app.pl


Somethings to note are that the default template is now Template Toolkit, and Dancer now defaults to using the default TT brackets of [% and %] instead of <% and %> which come from Sinatra.

You can always switch them back in config.yml:

template: “template_toolkit”
engines:
template_toolkit:
encoding: ‘utf8′
start_tag: ‘<%’
end_tag: ‘%>’

So lets test our applications and see if we can catch all of the problems before launch. You can follow development over at Git Hub:

https://github.com/sukria/dancer2

When installing some of those modules I had one of those “I wonder what that does” moments when cpanm showed that it was installing “aliased.pm”. Generally all lower case module names are reserved for pragmas and modules that provide pragma like support, so I was curious to know what this module did.

aliased.pm is written by the talented Curtis “Ovid” Poe, whose name you have most likely seen if you’ve used Perl for a while. “aliased” fills a neat little spot for the programmer who is trying to reduce the clutter in their code because it allows to you “alias” one package name to another. This means that with all of those cases of:

Company::Application::Version::Module

Can now be written so much more clearly as just

Module

It comes with a built in helper routine to shorten your package name to the last section, so all you need to do is this to start using it:


use aliased "Company::Application::Version::Module";
Module->doSomething();


If you don’t like “Module” on its own then you can define the name that is used during the use call, for example:


use aliased "Company::Application::Version::Module" => "MyModule";
MyModule->doSomething();


The downside to using this module this is that you could easily mislead a reader of this code or get name clashes, especially with the automatic aliasing. Accordingly the best option is to assign it to a scalar variable and use that. For example:


use aliased;
my $MyModule = alias "Company::Application::Version::Module";
$MyModule->doSomething();


Amazingly the basis for the code is so very simple. It effectively creates a sub of the given (or calculated) name that returns the original package name. So MyModule->doSomething() is really calling MyModule()->doSomething().

This module also has use in areas were you might change out one library for another. For example CGI => CGI::Lite.

There are definitely areas where it could add confusion, but it seems to be a useful addition to keep around.

But at the same time I can’t help but think how can anyone possibly find the time to know what they all do? How do you find out what modules are relevant or helpful for your daily programming? More over when you are installing a module and it pulls in other modules don’t you want to know why? Perhaps some of those other modules could be useful to you too.

So it occurred to me that perhaps a good way to address this is a little series that looks at modules that are new to me. Possibly they are new to you too. Or perhaps you know of them, but simply haven’t seen them. This is going to be infrequent, but it seems like a nice way to push out some more posts without having to provide lots of back story and detail for a project – to be able to provide a little trickle of information.

More importantly it might bring some extra attention to modules that are otherwise relatively obscure. So clearly we are not talking about LWP, etc. although given recent conversations on what people find when they search for the term “learn perl”, perhaps some blogs on what you can do with LWP might not be a terrible thing.

So today I was looking at learn.perl.org and I noticed a link to Task::Kensho.

Task::Kensho is a module from the Enlightened Perl Organization, a group within the Perl community that has been formed to promote Perl using modern standards.

Task::Kensho is not a module in itself, but rather it provides a method for importing groups of modules from CPAN. Those modules are arranged in groups such as “web dev” and “DB Dev”, “testing”, etc. to provide a simple method of importing a series of modules that would be useful.

The documentation lists all of the available modules so even if you are not sure about this method of installing modules it at least gives you an idea as to which modules are recommended for certain solutions. They may not be appropriate for every situation, but if nothing else it serves as a partial answer to the question of “but how do you know where to start?”

For example I’m currently shying away from Catalyst and looking in preference at Dancer (come on Dancer 2!) so I would not install the Web Dev group. But I did cherry pick some items from the list and I so I would highly recommend this module to everyone. If for no other reason than it gives a nice concise list.

I have to say that I will probably never buy a Scoripo Blue 320gb drive from Dell again after a really annoying experience where the first and then both replacement drives all turned up DOA.

I have no idea why all three arrived like this, but they would go into the machine and immediate issue the “Click of Death”. They were built in different months so it wasn’t a bad batch (unless it was a huge batch) so I can only assume it was a storage/delivery issue. I have to wonder what is happening with the drive though since the prices on these drives undercut the smaller capacity version of the same drive.

Most irritatingly I couldn’t find anyone else on the Dell forums or in general who had a problem with that drive so I could reassure myself that it wasn’t just me.

I finally caved and paid the extra for the Scorpio black drive. It is pretty much the same thing only 7200 RPM. I haven’t noticed the laptop running particularly faster, especially now that I’ve tasted SSD’s @ $work, but at least it works.

I will say that the installer is no where near as slick as Ubuntu’s installer. I’m not really sure quite why it doesn’t feel as easy, but clearly someone at Canonical worked hard to make their installer slick, but still, CentOS 6 installed smoothly.

I would just like to note too that with an SSD in the box the install is ridiculously fast and finally someone has gotten rid of my pet peeve with CentOS / Fedora (and presumably RHEL) for all of these years … CUPS is not installed by default.

The installation of CUPS as part of the LSB has always been a bane for me because I run servers and don’t want them to be able to print and therefore I don’t need CUPS and I don’t need the additional RPM’s that are its prerequisites. Most importantly of all I don’t need to waste valuable seconds during the start-up sequence starting CUPS nor waste any memory/CP resourcse on LKM’s like “lp” “parport” and “parport_pc”.

I have always just wanted the box to run only what it needs. There are already enough security nightmares with having customers on there, so I don’t need additional programs or LKM’s loaded to provide more potential intrusion vectors. It is just basic common sense.

It is nice to finally be able to install a server without being given a GUI or other nonsense that you didn’t ask for. I also like that one reboot later and I have all of the updates installed. Unlike Win 7, which I re-installed on a laptop at home a few weeks ago, which took 7 reboots :p

TIL: Apple wrote CUPS. I assumed it was a community thing.

Their survey of the jobs index show a heartening trend for the Perl community and the software development sector as a whole.

“If an eWEEK survey of a jobs index is any indication, the action—and the jobs—are around Perl, Python, PHP, Ruby, Java, …”

The data is based on information from Simply Hired and it shows that many of the other software languages also increased the number of development positions. Only Fortran seems to have lost out in the development section and surprisingly COBOL jobs have picked up too. Great news for all of those COBOL developers who were suddenly turfed out of a job after the end of the last millennium.

The survey does not list whether or not the data is based on posts that were listed or positions that were filled. I would imagine the former. Similarly the article does not clarify if the positions were permanent or contract.

Certainly there do seem to be positions available though. Interestingly not all jobs are with dot-coms but from a broader sector. I was definitely surprised to see HSBC listed on Perl Jobs.

I would be curious to know how many of the advertised positions are for developers and how many are a “Jack of All Trades” position in which you are the sys admin and the programmer and you should know MySQL, HTML, JavaScript, CSS and often PHP, Java, etc. as well.

Still, it is good news.

cpanm is a replacement/supplement for cpan that provides much less functionality and therefore faster and simpler.

We are accustomed to more – more features, faster speed, etc. – but sometimes we don’t need more features. Sometimes we just want a tool to do the job and do it quickly and efficiently. Over the years the cpan command has grown in response to requirements and, as any dev that has worked with software that has evolved this way knows, this leads to things getting slower and clunkier because you generally can’t strip out how the application used to work, only add new features.

cpanminus is a replacement for cpan which is designed to get modules installed quickly and that is all. This is often all I need and so I find it so useful rather than starting up cpan and having it download the updated module lists from CPAN before I can do anything.

Best of all cpanm is self-installing. So while cpanm is a Perl module (App::cpanminus) you don’t have to use cpan to install the module in order to use it. Instead you can download the perl script and tell it to install itself using:

curl -L http://cpanmin.us | perl - --self-upgrade


This means that it works well with Perlbrew installations of Perl.

Self-installing (bootstrapping, whatever you want to call it) seems to be a trend with some newer Perl applications which only makes them easier to use.

Once installed you simply type:

cpanm -i <module>

and through the powers of the cpanmeta database it will find and install your module. In my experience it is generally faster to use than the regular cpan.

I have two issues with the application which are both factors of the module installation process.

1. cpanm downloads files to a working folder that has a unique name based on a time stamp. If a module that you are installing fails to install then the next time that you try to install the module it is downloaded again to a new folder with a different time stamp. This can lead you to duplicating the downloads numerous times if you have installation issues (missing libraries is usually the reason).

2. If an installation fails then it directs you to read the build.log file:

! Installing XML::Parser failed. See /home/colin/.cpanm/build.log for details.

but that file is a symlink to the build.log file in the latest build folder, so if you build again then a new folder and new build log are created. That is okay except if you want to find the older version. In that case you have to work out what folder is what.

On the whole though these are minor points and cpanm is definitely my go-to installer now.

(Updated 25th Sept to correct spelling mistake and assign to a category)

I haven’t posted due to being busy with work and life, but it seems that I stopped trying to write about Perl at exactly the wrong time because in the past two years Perl has flourished again.

Almost like a play ground that has seen too much use and not enough love, over the years Perl had become slightly dusty and while people were always adding new modules to CPAN it no longer seemed to have the same sparkle as PHP, Python or Ruby.

At the time there was a stirring in the community, a few commentators who suggested that we, Perl developers all, stop hanging out in dingy backwaters of the internet (which IMHO means Perlmonks and IRC) and instead of just writing websites, start using them. Although I didn’t recognise it at the time that was when a little seeding of change was planted.

Over the past two years I’ve been ever more delighted to see those seeds slowly grow putting more information about Perl in the spot light. From those tiny seeds have come the green shoots of new blogs and frameworks.

There is the announcement of an updated release schedule for Perl 5 with their additional features. There are new frameworks (Dancer, Mojolicious, etc.) and blogs popping up all over the place. Perlbuzz is a perfect example.

There are even new books – and with the rise of self-publishing sites such as Lulu.com not all are from major publishers. The increasing numbers of  cell phones and tablets and e-book readers like Kindle and Nook provide a larger audience for such books as well as providing great access to Perl information on Youtube, Vimeo and slideshare.

Needless to say the revamp of perl.org looks great and for me it is a major step forward in presenting Perl well to new audiences. Padre, the Perl IDE, seems to be putting out updates all of the time.

And of course we shouldn’t forget that ActiveState just propelled Perl into the cloud through the launch of their Stackto cloud platform for Perl and Python.

All I can say is WOW!

[Note: This replaces an article I published Sept 17th which is the core for this, but which I felt was awkwardly worded]

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!

After upgrading to subversion 1.6.0 I wanted to use SVN::Web to provide web access to my Subversion repo.

To use SVN::Web you’ll need to install the SVN bindings for Perl. These come with subversion, but they’re not installed by default. You can find the installation information in

subversion/bindings/swig/INSTALL

In summary they require SWIG and SVN be installed. Once you’ve done this from the root of the source directory run

• make swig-pl
• make check-swig-pl
• make install-swig-pl

Pretty simple stuff and then you can install SVN::Web.

Once SVN::Web is installed you can use the command “svnweb-install” to setup the directory for the web site that will serve your SVN repo information. This creates a file called index.cgi and the config.yaml that you need to configure it.

I have a number of repos installed under a single root, so I used the reposparent option to set the root to all of them using this value:

reposparent: '/usr/local/svn/repositories'

Calling up the site in my browser I’m presented with a list of the repos. However this is where things go wrong because when you click on a link you see a blank page . If you check the web server error log then you’ll see the following error message:

svn: In file 'subversion/libsvn_ra/deprecated.c' line 289: assertion failed (*path != '/')
Premature end of script headers: index.cgi

So I began to search through the Perl code, the XS and finally the subversion libraries trying to track down what was wrong with this code. Why did it matter that the path started with /? I wasn’t able to see anything obvious, including doing lots of searches for this error text and variants of it to see what other people had found.

I found nothing until I happened to search for svn_ra_get_log() and in doing so stumbled across this conversion thread from the svn-dev mailing list “subversion/libsvn_ra/ra_loader.c:934: svn_ra_get_log: Assertion `*path != ‘/” failed.“

This thread refers to a different svn lib because it appears that the function svn_ra_get_log() is deprecated in 1.6.0, but for legacy purposes (such as our code) it can’t be removed yet. This chances the library and the line number, but otherwise the error is the same. It turns out that’s because it is the same problem – you used to pass the first parameter as ‘/’ to svn_ra_get_log() (which is known as get_log() in the Perl bindings) to indicate that you wanted any logs. Now you need to pass an empty string.

The reason why this is a problem is that in SVN::Web::action::recent_interesting_rev() $ra->get_log() is called with $path = ‘/’. The fix then is really simple – force $path to be an empty string before get_log() is called. Since I didn’t know what/where else this would break I patched it as close to the error as possible by adding this to line 244 of SVN::Web::action.pm as shown below;

243     my @log_result;
244 $path =~ s!^/!!;
245     $ra->get_log([$path], $rev, 1, 1, 0, 1,
246                  sub { @log_result = @_; });

Hope this helps anyone else who encounters this error.

Colin.

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.

If you haven’t tried it then you’re severely handicapping yourself so I would recommend that you install it and start playing. If you already have it, then you’ll know what I mean – the moment you end up on a computer without it, you feel like you need it installed. But even having used it for a good while (years?) now, I’m constantly amazed by the attention to detail the developers and contributors have paid.

For example I was just poking around with a test site trying out some CSS and discovered something new tonight. Like me you’re probably used to opening up Firebug to tweak the CSS styles to see how things will look without needing to reload the page. I should probably point out that if you’re not used to Firebug and you think it is just for looking at things, then you’re missing a good 50% of the picture… In fact lets try it.

Select an element on screen using the “Inspect” button in the HTML panel. You’ll see the DOM tree open up to that element. Want to try out a change, say a different background color? Select the “BODY” element and then right-click. Lots of options huh? Select “New Attribute” and you’ll get to add a new attribute to the element. So here’s a quick way of testing a new background, border, etc. – add the attribute “style”. Here’s a perfect example of the attention being paid. Instead of typing it all it, you enter only the name, and then hit “tab” and you’ll move on to entering the attribute’s value. You don’t need to worry about the equals symbol or quotes because FB fixes that for you, you just enter the value you want to use.

The alternative to editing this inline is to use the Sub-Panels on the right of the HTML Panel. When you view the DOM tree you’ll see that the sub-panels on the right update. They show the Style, Layout and DOM for the selected element. Here again is an example of the detail. The Style sub-panel shows by default the CSS rules applicable to this element. It strikes through rules which have been superseded as well as the source file and line number. This is extremely handy for working out why your DIV tag has a bright blue background instead of bright red. But by checking an option in the “Options” menu you can see the additional rules set by Firefox (this may be a 1.3 track setting) and view the computed style rules.

Okay so yes, this was available in the DOM inspector, but the packaging is nicer, and it is combined with the particularly useful Layout tab which allows you to see, and modify, the settings for the layout characteristics – border, padding, margin, height, width and top/left offsets. If you haven’t discovered it yet (or read the manual, may be its all in there?), then you can click on any of the numbers in the Layout tab and edit them. Did you also discover (read about?) how when you hit tab you move on to the next number in the square? And how you can tab all the way around from offset to margin to border to padding in a loop? Oh and of course how if you shift-tab you tab backwards in reverse order? Yeah, that’s the kind of attention that I’m talking about.

Well if you found all of that and think that’s cool then there’s the surprise I found tonight back on the “Style” tab. I knew that instead of editing the style attribute you could also edit the styles for an element from with in the Style tab – if you didn’t then select your element and right click in the style sub-panel and you’ll see a host of options for editing the style, adding new properties, editing the existing properties etc.

So here’s the cool bit… Can’t remember what the CSS property is called? No problem they’ve thought of that too. Type whatever you can think it starts with and hit up/down. You’ll scroll through all of the properties that FB knows about. This includes all of the new CSS3 and -moz extensions that FFx supports. If that wasn’t handy enough hit tab to go on to editing the value… and you can do the same thing.

This was the “easter egg” I found tonight, having FB be intelligent enough that I was able to scroll through appropriate values for an attribute (handy with some of the obscure/new -moz… attributes).

For example; If your value is numeric then up will increment and down will decrement, seems reasonable. But if it is a known CSS attribute then you’ll be stepped through a list of possible options. For example, can’t remember what border styles are supported? No problem add an attribute “border-style” tab into the value field and scroll through them all with up/down. Can’t remember the (256?) named web colours? Again, if its a recognized colour attribute then you can scroll up/down through a list of known colours.

If that isn’t good enough try it with a combination attribute such as “border”. Try editing a standard CSS value like “border: 1px solid black”. If you edit this value and hit up/down then the border width will increment/decrement. Okay so you’re not impressed because its only doing it because it starts with a number. So double-click on the border-style (in this case “solid”) and yeah, you can scroll through a list of known border-styles. When you’ve found something you like you can repeat this with colour attribute. If the auto-complete of the names, the tab/shift-tab support wasn’t enough then this while not commonly used, just makes it a much nicer experience.

A huge thank you to Joe Hewitt, John J Barton, and everyone else for this amazing extension.

Colin.

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.

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.

The trends for dynamic languages

In looking at this data I wondered if there what the reasoning was behind it. Of course it should be noted from the start that the data presented here is not the result of an unbiased scientific poll, but simply a number from Google. For all we know these numbers have these values because of something wacky like Python devs only use Yahoo! So what follows is not a general information, it is simply speculation because I was curious if the general trend was downward for all four of these dynamic languages because less people are using scripting languages, or, as seems more likely, that they already know where to go to find information about them without searching through Google.

Obviously there must be a mix of both as in that time Java has improved and C#/.NET have become more popular. However it was in that same time period that a lot of Perl 6′s work has become available, that PHP moved to v5, and Ruby hit the headlines with Rails. It seems highly unlikely that all three of these events, which spawned books, and conferences and the like, didn’t do anything to boost interest in the corresponding language. I added all three of these examples to the list to compare and it seems that the only language to have had any real sustaining power is “C#” which has pretty much flat-lined since 2005. (You can test for yourself)

Google does explain that these numbers are “normalized” to a value between 0-100 rather than being the search numbers, but they don’t explain how that occurs. If this is as a portion of all searches then that clearly explains the trends. You could similarly argue that programmers have places to go for their languages which requires less searching on Google and it seems fair to speculate that programmers are also searching less because these languages are all matured and come with better documentation and thus there’s less trying to find help on how to program in them. This would further agree with Google’s own description of how they normalize the data and the general trend of Google being used for more than geek searches.

Comparing trends for the core script languages

So whether or not this explains the decreases directly, it seems reasonable to assume that the data is comparable. If so then at first glance we are surely seeing  that PHP is “the best”, because people search for it more. Right? Well that’s one interpretation, but remember we’re looking at search numbers here and in that case do more searches really mean that the language is better? It could because it could mean more new users looking for information. But it might be that while there is appeal/interest/intrigue those who try the language find that it isn’t appropriate for them/their work, and so leaving for other languages.

The trend we see here doesn’t match that pattern exactly as I’d expect a sharper drop off, but its fair to say that percentagewise PHP has dropped more than any other language. A quick test from the highest value in the first month of the 2004 period to Oct 2008 shows that PHP dropped 50%, Perl 25% while Python and Ruby remain pretty much flat.

Does this suggest that while PHP is often looked at, there is a trend away from both PHP and Perl towards “newer” (“cooler”?) languages like Python and Ruby? Certainly Ruby has been getting a lot more attention with Rails and these trends show a distinct uptick around march in 2005. According to Wikipedia this would be the month following the opening of Rails to other developers. Consistent releases and updates appear to have helped maintain an interest in Ruby.

Similarly so with Python where newer versions and its popular tie-in to Django, etc., appear to have allowed it to maintain a small but steady “market share” over the same period. Indeed the downward trending of PHP and Perl could be an indication that we are losing developers to Python and Ruby. If this is the case, rather than people just not needing to search for them any more then it would appear that not only is PHP also considered to be “old”, as is often said of Perl, but that it is losing developers much more rapidly.

Influencing the “trends”

As one piece of evidence that this information from Google is easily influenced I noticed that if you zoom into the last month’s data then there appears to be a sudden upswing for Perl. What’s this? Is Perl suddenly cool and popular again?

Sadly, it doesn’t appear so because if you concentrate only on Perl and look at the most popular searches you start seeing queries for variations of the term “X-Perl”. X-Perl? You might ask. What is this? Is it some new Perl-GUI binding? Perl on MacOS X? Is it a new uberfast matrix inspired Perl platform with flashing lights and bells and whistles… ?

No, its none of these things. The “superman” in this case is a new UI for World of Warcraft called X-Perl. And it appears that because people can’t be bothered to type hyphens they’re searching for the term “x perl” and Google is notching up a point for “Perl”… Oops :-)

This is meant as a suggestion as to what this data could mean. It is by no means scientific and I know that.

Colin.

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.

As for why? Well I’ve played with wordpress on and off for a while, but I never really liked the previous versions that much and had given up several revisions ago. I decided to try looking at it again this time around and really prefered the interface. I’m still not at all convinced about much of the rest of it, particularly it being written in PHP since I have issues with that on several levels, but it is what it is. I decided to try it on line via this site with wordpress.com.

Interestingly enough Google must love this place because for certain searches the site is coming up in first place. Which is surprising, if not troubling since its a new site and if I can do it, any spammer can. I’ve even had people start stealing the content already, and there’s barely anything here…

But what I didn’t like is that I couldn’t customize it the way I wanted to. My PHP is limited but I know enough to hack on the code a little and wanted to try doing that on WP 2.6.2 as I have on earlier versions. I also wanted to try a different theme than the half dozen offered, and even something as simple as changing the CSS couldn’t be done without a paid update. This seemed a little much to ask for something so relatively simple, so I decided to move it off to my own box.

I’m not sure how well it will work since my box is about 10 years old, but hopefully it will be upgraded soon, and I have other options if needed :-)

So come on over to the new site, see if you like it:

http://perladmin.oreally.co.uk/

Colin.

I mention this because I just came back from lunch to find my SSH connection wouldn’t respond to input. This has happened occasionally, but as far as I’ve been able to tell (by piecing together information afterwards), it has invariably been because iptables was restarted.

Now me, I just add the new rule to the firewall and if it works and I want to keep it, add it to the config file separately. I don’t believe in restarting iptables because if you f*ck up the new rule and restart the firewall you’re not only screwed then, but if you reboot the server too. For a remote connection that’s bad news. At least if you screw up the rule you know that you did the moment that you add it to the firewall, so if it comes to remotely rebooting the box you know it will come back up without a problem. And yes, I did do that once. It was a case of

“I’ll just update the firewall rules before I leave this morni… oh er.. oh, what did I type? Sh*t!”.

But my colleague believes that you should add it to the config file and restart because that way you’re only entering it once. Which is nice, and does indeed have its merits because there’s less chance of a typo, getting the order wrong, etc., but it also means you need to stop and restart iptables. Aside from the risk of locking yourself out of the server to me that’s a royal pain. You lose any temporary rules, and you worst of all you lose the connection tracking. Which means my nice and quiet SSH session which was working before lunch and has my open Vim session in it … is now not working because its state is not new or established or related, and thus not a valid connection state as far as iptables is concerned and thus the packets are blocked, and the connection gets dropped. *grr*

More irritatingly though is that I can’t *know* that that’s what happened because iptables doesn’t log when it stopped or started. Which is pretty crazy really if you think about the fact that every daemon under the sun logs that kind of information. It never occurred to me before, but its true, at least on my box.

Incidentally, if you’re looking to fiddle with the firewall remotely, a few good tricks are;

1. Add a rule to allow your SSH connection through as a first rule. E.g.iptables -I INPUT 1 -p tcp --dport 22 -s <your ip> -j ACCEPT
2. Use a sleep; undo system. This works for both the command line and restarting iptables. For example;
   1. Add a rule on the command line, knowing the rule number you’ll give it, and then set it to undo a moment later;iptables -I INPUT 23 <what you want to happen>; \
sleep 10; \
iptables -D INPUT 23
   2. Restart iptables, then stop it again if it doesn’t work;/etc/init.d/iptables restart; sleep 10; /etc/init.d/iptables stop

The second tip uses the a chain of commands which do whatever might go wrong, sleep and then undo it. The reason for this is that it will execute a command and then move on to the next command in the list, so if you submit the commands like this, where you must include the semi-colons between the commands, (don’t forget the \’s in the first case, or just ignore them and don’t hit return) , then the shell will execute them one after another like this … do “fiddle with firewall command”, sleep, and do “undo fiddle command”. In the even that you don’t do anything, the firewall will be restarted and then ten seconds later, stopped. This is good because in the event that you f*ck up the firewall rules and can’t type, 10s later you’ll be able to type again because the firewall has been taken down again.

But the best part of this trick is that in the event that you can type you do … you wait a second or so, and then type Ctrl-C to interupt the currently running command. This will be the sleep command, so you’ll interrupt that and interrupt the list of commands to execute so your last command, the “undo” command, is never run. So if you can’t get into the box it unsets its firewall. If you can get in then you kill the sleep command before it finishes thus the “undo” is never executed.

As a tip, if you’re not sure when to hit Ctrl-C, add a command echo “Sleeping” into the list just before the sleep command. If you don’t see that then the firewall was messed up. If you do see it then your changes worked, and you can kill the rest of the commands with Ctrl-C.

Colin.