blogs.perl.org

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.

It's been pointed out to me that many programmers have issues with my blog because I'm writing about allomorphism, exceptions as flow control and other topics that are, frankly, not something a beginner programmer is going to warm to. I think that's a fair point and I'm going to try to start including information aimed at those new to Perl and those new to programming.

I'll start with subroutines. Specifically, an old, horrible example.

Last night I finished and released the first version of Dancer::Plugin::Database, a plugin for the Dancer web framework to provide easy database connections using the venerable DBI.

It takes the database connection details from the app config file, and provides a database keyword which will return you a connected database handle (taking care of ensuring that the DB connection is still alive, etc).

So, usage can be as simple as:

my $books = database->selectall_arrayref(
    'select * from books where author = ?', 
    { Slice => {}}, $author
);

(Calling database() simply returns a DBI database handle, so you can obviously do anything you can do with DBI).

Also, at the moment, if a database connection could not be established for any reason, database() will just return undef, so you will need to handle errors appropriately. After considering whether it's wise, I may tweak it to die, so that Dancer will handle the failure with a pretty 500 error for you (in which case, I'll make it possible to disable that via the config).

One of the first things a Perl programmer will notice when learning about Data::Dumper is: how weird and "inside out" the OO interface is. This is, I think, another unfortunate accident in the Perl history, as Data::Dumper, being the first of such modules, gets into the core in early Perl 5 and remains popular up until this day. But the interface and default settings apparently annoy a lot of people so much that alternatives and wrappers like Data::Dump, Data::Dumper::Again, Data::Dumper::Concise, among others, sprung up to life.

A loose analogy would be CVS which was popular for (too long) a time, and following it the explosion of alternative version control systems. Eventually after this phase a winner will emerge or dominate. In the version control system case it appears to be git. And in the Perl case I think it will be a builtin perl() method/function, like in Perl 6. Probably in 5.14? 5.16? 5.18? Don't you think it's about time Perl can "natively" dump its own structures in Perl, just like Python, Ruby, PHP, etc have been able to for a long time?

(Btw, lest anyone thinks otherwise: I do love DD. It has lots of options and has served its purpose well over the years.)

Dear lazyweb,

I am about to upload a new Alien:: distribution that downloads, builds, and installs a very, very large library. The installation of this Alien:: distribution occupies about 240MB on my laptop and compile times are huge even on my fast computer.

Is there a way to flag a distribution as unsuitable for CPAN testers? I'd rather not abuse the volunteer infrastructure by having them compile a library over night.

Over the weekend of the QA Hackathon, which by all accounts was another great success (and I think David, Ricardo aand I all wish we could have been there too), various work on CPAN Testers 2.0 was underway. With the submission to the Metabase and the feed from the Metabase into the cpanstats database being two very distinct parts of the eco-system, it has made work on both parts a lot easier as it only requires one interface between them. While much of the interface has been evolving, it has for the most part been fairly straightforward. However, unfortunately while testing the interface, I noticed that several reports had been posted with no text report. Seeing as this is the part that authors really need to see, it means that we now have to discard those reports. In addition, David also found a problem with how S3 names objects, which was causing a problem for storing facts within the Metabase.

I recently blogged about extending the Perl debugger. Basically, if you use xx $some_var, you get love Data::Dumper output instead of the confusing debugger output:

The dichotomy of List::Util and List::MoreUtils is one of the unfortunate annoyances in Perl. One is without s, one is with s. Which function belongs to which? And no, you can't simply say, "f*ck it, just import everything!" as List::Util doesn't provide the usual ":all" import tag (RT).

Some thoughts (from someone who is largely ignorant on the history of both modules), all IMO:

1. Since List::Util is basically a convenient library, convenience should've been its main design goal. It should've been inclusive enough. The decision to deny the inclusion of any(), all(), none() just because they are too "trivial" to implement in one line of Perl was a bit strange, since max(), min(), etc are also trivial to implement in Perl.

2. List::MoreUtils should've included all the functionalities of List::Util, so one can use it *instead of* List::Util.

But hey, what happened happened.

Btw, we also have Perl 6's junction taking the "all", "any", "none" keyword.

OH YEAH!

Just finished installing the brand spanking new Perl 5.12 on the netbook on my "perl" account, with which I tested already earlier -RC releases with my personal code.

It's fair to say that the user experience has gone a long way from the "old days" of manual configuration, installation, swearing and $ENV madness. Hell, one doesn't even need local::lib anymore!

All I had to do to test 5.12 after creating my "perl" account was:

Perl 5 core development was in a downward spiral for a couple of years. Releases happened less and less frequently, the number of contributors dropped and the general outlook was getting worse and worse. For the Perl 5.12 release I wrote a post on the ActiveState blog how the downward trend has been reversed and how fun, optimism and even excitement has returned to Perl 5 language development.

Perl is far from dead/dying nowadays, with 5.12 being released recently, and the yearly timed-based release plan and all. In fact, just after I start to be comfortable using some of the 5.10 niceties, here comes a whole new version with even more niceties waiting to be explored!

Features in 5.10 I'm using regularly.

Defined-or (if there's only one feature I can have in 5.10, I pick this one).

State variables (love it!).

Features in 5.10 I'm starting to use.

-E switch (but my reflex still says -e all the time).

Recursive pattern in regex (e.g., via Regexp::Grammars).

say() (maybe if I say it often enough I'll start to say say more).

Features in 5.10 I rarely/ever touch.

Smart match (I know it's a godsend, but strangely I never feel the need for it so far).

given/when (I'm sticking with if/elsif/else, especially since given/when cannot be used as an expression yet).

There are some tests which pass, but routinely fail in the debugger. Here's one example:

This is the video from the final stand-up on everyone's progress for the entire 2010 Vienna Perl QA Workshop.

Module versions can be found using several ways. I know two.

You can use the module in a one liner and print the module's $VERSION variable:
perl -MSVG -le'print $SVG::VERSION'

This gets annoying when the module name gets long:
perl -MWWW::Mechanize -le'print $WWW::Mechanize::VERSION'

Or the insane:
perl -MPOE::Component::WWW::Pastebin::Bot::Pastebot::Create -le'print $POE::Component::WWW::Pastebin::Bot::Pastebot::Create::VERSION'

Another method I've seen people use is to actually cause an error. Try to load the module in a high version that doesn't exist. The error will show what version it is:
perl -MWWW::Mechanize\ 9999
perl -MPOE::Component::WWW::PasteBin::Bot::Pastebot::Create\ 9999

This is pretty good, since it's short to write and most likely you won't find many versions above 9999 (except perhaps, File::Slurp - last version 9999.13). However, this is a bit confusing to newbies, trying to cause an error on purpose to simply find the version.

Moreover, since it causes a compilation error, you can't easily check multiple versions.

I actually don't believe there isn't something like this in CPAN yet. Well, actually there is PHP::Var, but it has bugs, doesn't handle scalars, and doesn't do recursive structure. But then I am equally surprised to be able to hack Data::Dump::PHP in just a couple of hours, by blatantly copying from Gisle Aas' Data::Dump and just modifying only what's necessary.

And another note, PHP's var_export() currently can't dump recursive structures, which Data::Dump::PHP can.

For various reasons I was only able to attend a few hours in the moring, and all of that time was spent organising stuff (even though most of the organising is done by daxim and pst). At least I took some photos:

In the evening I joined the rest of the attendees again at Der Wiener Deewan for delicious pakistani food, sponsored by 123people.

I had been looking around for the ancient Perl sources to add to my collection, but Schwern told me that they are already in the Perl git repository. I just have to checkout the correct tag:

$ git tag -l
perl-1.0
perl-1.0.15
perl-1.0.16
perl-2.0
perl-2.001
perl-3.000
perl-3.044
perl-4.0.00
perl-4.0.36

Now I just need to get these to compile on my MacBook Air.

I've suggested that Schwern needs to make a git archive of the internets now.

For the syntax and semantics of Prolog, Parrotlog is based on a draft of the ISO/IEC Prolog standard (seeing how the actual standard costs muchos dineros).

Now, the good news are that the Prolog spec is actually an operator precedence grammar, which happens to be how NQP does its expression parsing as well. The bad news are that the spec uses term for everything, while NQP makes a distinction between terms (atomic expressions) and expressions (expressions, with or without operators). This means that I have to figure out if I should use term or EXPR whenever the spec says term. Let's see how deep the rabbit hole is.

A few folks have talked about adding tags to Test::Class. This would allow us to do things like load 'customer' fixtures if something is tagged 'customer', or only run tests tagged 'model'.

Here's what I have working now: