Planet Perl is going dormant.  This will be the last post there for a while.

Why?  There are better ways to get your Perl blog fix these days.

You might enjoy some of the following:

• blogs.perl.org
• PerlSphere
• Iron Man Perl Blogging Challenge
• Perl.com

Will Planet Perl awaken again in the future?  It might!  The universe is a big place, filled with interesting places, people and things.  You never know what might happen, so keep your towel handy.  

A few years ago, I wrote about cheap wooden discs as D&D minis, and I've been using them ever since. They do a great job, and cost nearly nothing. For the most part, we've used a few for the PCs, marked with the characters' initials, and the rest for NPCs and enemies, usually marked with numbers.

With D&D 4E, we've tended to have combats with more and more varied enemies. (Minions are wonderful things.) Numbering has become insufficient. It's too hard to remember what numbers are what monster, and to keep initiative order separate from token numbers. In the past, I've colored a few tokens in with the red or green whiteboard markers, and that has been useful. So, this afternoon I found my old paints and painted six sets of five colors. (The black ones I'd already made with sharpies.)

I'm not sure what I'll want next: either I'll want five more of each color or I'll want five more colors. More colors will require that I pick up some white paint, while more of those colors will only require that I re-match the secondary colors when mixing. I think I'll wait to see which I end up wanting during real combats.

These colored tokens should work together well with my previous post about using a whiteboard for combat overview. Like-type monsters will get one color, and will all get grouped to one slot on initiative. Last night, for example, the two halfling warriors were red and acted in the same initiative slot. The three halfling minions were unpainted, and acted in another, later slot. Only PCs get their own initiative.

I think that it did a good amount to speed up combat, and that's even when I totally forgot to bring the combat whiteboard (and the character sheets!) with me. Next time, we'll see how it works when it's all brought together.

In Pisa I gave a lightning talk about Perl Vogue. People enjoyed it and for a while I thought that it might actually turn into a project.

I won’t though. It would just take far too much effort. And, besides, a couple of people have pointed out to be that the real Vogue are rather protective of their brand.

So it’s not going to happen, I’m afraid. But as a subtle reminder of the ideas behind Perl Vogue I’ve created some t-shirts containing the article titles from the talk. You can get them from my Spreadshirt shop.

 

CPAN has gotten its first real update in a while tonight; the content is from the cpanorg git repository.

We tried to get the FAQ cleaned up a bit (though there's plenty of work left) and Leo Lapworth pretty heroically also did a first pass on cleaning up the ports page.

You might also notice a search box for search.cpan.org which we find appropriate, a list of recently uploaded modules on the homepage and a new page on how to mirror CPAN.

If you read the latter page, you'll see that the master mirror is now cpan-rsync.perl.org::CPAN (rsync only).  In the coming weeks we'll work on encouraging the CPAN mirrors to switch to mirror from here to ease the load on FUnet, the sponsor of the master mirror for the last 15 years.

Work is also coming along well on the instant update mirroring system.

 - ask

LWP 6 makes hostname verification the default -- so note this from LWP::UserAgent:

If hostname verification is requested, and neither SSL_ca_file nor SSL_ca_path is set, then SSL_ca_file is implied to be the one provided by Mozilla::CA. If the Mozilla::CA module isn't available SSL requests will fail. Either install this module, set up an alternative SSL_ca_file or disable hostname verification.

If you use LWP and want SSL, you need IO::Socket::SSL (recommended) and Mozilla::CA.

Remember use.perl? It’s moth-balled now, but for years it provided two valuable services to the Perl community.

Firstly it provided a hosted blog platform which many people used to write about many things – sometimes even Perl. Of course we now have blogs.perl.org which provides a very similar service.

And secondly, it provided a place where people could submit stories related to Perl and then editors would approve the stories and publish them on the front page. Since use.perl closed down, the Perl community hasn’t really had a centralised site for that.

Over the last eighteen months or so I’ve had conversations with people about building a site that replaced that part of use.perl. But there’s always been something more interesting to work on.

Then, at  the start of this week, Leo asked if I knew of a good Perl news feed that he could use on the front page of perl.org. And I realised that I’d been putting it off so too long. A few hours of WordPress configuration and Perl News was ready to go.

So if you have any interesting Perl news to share, please submit it to the site.

http://perlnews.org/ has just launched and will be providing a source for major announcements related to The Perl Programming Language (http://www.perl.org/). Find out more at http://perlnews.org/about/ - or if you have a story submit it http://perlnews.org/submit/.

All stories are approved to ensure relevance.

Thanks

The Perl News Team.

I'm still blogging five days a week, but obviously not here. That's largely because my new daughter is forcing me to choose where I spend my time and I can't blog too much about what I do lest I reveal trade secrets. So, just to keep my hand in, here's an ugly little "80% hack" that lets me find bugs like mad in OO code. I should really combine this with my warnings::unused hack and start building up a tool find find issues in legacy code.

First, an "80% Hack" is based on the Pareto Principle which states that 80% of the results stem from 20% of the effort. So I often write what I call 80% hacks which are simply quick and dirty tools which get things done.

The idea is simple. In legacy OO code where we're not using Moose, we have a nasty tendency to reach inside a blessed hashref. However, as classes start getting old and crufty, particularly in legacy code which is earning the company a ton of money, it's easy for someone to either misspell a hash key or refer to keys which are no longer used. What I've done is assume that each of these keys are used once and only once and I also assume they look like this:

$self->{ foo } $_[0] -> { "bar" } # yeah, we need arbitrary whitespace shift->{'something'} # and quotes

Yes, this code could be improved tremendously, but 80% hacks are personal hack which I simply don't pour a lot of time and effort into. Besides, they're fun.

#!/usr/bin/env perl use strict; use warnings; use autodie ':all'; use Regexp::Common; my $module = shift or die "usage: $0 pm_file"; #my $module = '/home/cpoe/git_tree/main/test_slot'; my $key_found = qr/ (?: \$self | \$_\[0\] | shift ) # $self or $_[0] or shift \s* -> # -> \s* { # { \s* ($RE{quoted}|\w*) # $hash_key \s* } # } /x; open my $fh, '<', $module; my %count_for; while (<$fh>) { while (/$key_found/g) { my $key = $1; $key =~ s/^["']|['"]$//g; # try and strip the quotes no warnings 'uninitialized'; $count_for{$key}{count}++; $count_for{$key}{line} = $.; } } foreach my $key ( sort keys %count_for ) { next if $count_for{$key}{count} > 1; print "Possibly unused key '$key' at line $count_for{$key}{line}\n"; }

I run that with a .pm file as an argument and I get a report like:

Possibly unused key '_key1' at line 1338 Possibly unused key '_key2' at line 5325 ... Possibly unused key '_keyX' at line 4031

It's amazing how many bugs I've found with this.

I can't blog as much as I used to, but they make it all worth it.

A goal of the MyCPAN work was to start with an existing Perl distribution and work backward to the MiniCPAN that would re-install the same thing. I hadn't had time to work on that part of the project until this month.

The first step I've had for awhile. I've created a database of any information I can collect about a file in the 150,000 distributions on BackPAN. There are about 3,000,000 candidate Perl module or script files. That includes basics such as MD5 digest of the file, the file size, the Perl packages declared in the file, and the package versions.

The next step is what I've been doing this week: collect the same information on the files in a Perl installation, which is much easier to do. There's not wacky distribution stuff involved.

Putting those two together should find the distributions that could make up the installation. With that list of distros, it's just a matter of creating the right 02packages file that a CPAN client can use. Easy peasy, I thought.

But, it's not that easy. Each file in the existing installation might have come from several distributions. That is, between different versions of a distribution, it's likely that many of the modules didn't change. So, looking at a single file doesn't lead to a single distribution. It might list several possible distributions.

But that's a start. Other files from that distribution should be present, and they each might come from several distributions even if one of them changed. If there's any file that only belongs to one distribution, that collapses everything for that distribution. If not, I have to find the overlap in possible distributions. There should be one distribution that overlaps more than all of the others, and that should be the right distribution.

That's not quite right either though, because some distribution versions don't change the module files. They update a test or the build file or something besides whatever is in lib. You'd think that at least the $VERSION would change, but think of any exception and you'll probably find it on BackPAN. That's not as horrible as it seems though. If all of the module files are the same, it doesn't matter which distribution I use, does it?

But then, there are some files that not only might come from more than one version of a particular distribution, but might also be in a completely different distribution. Some distributions have lifted files from other distributions. Files from the URI and LWP modules show up in other distributions. How should I figure out which one should be the candidate distribution?

The database I was using was just an extract of all of the information I have on each distribution and it's oriented to individual files. I select records to match up MD5 digests. However, when I get records back with different distributions, which one might be installed? If an installed file might have come from both Foo-Bar and Baz-Quux, I have to remove one of the distributions somehow. In that case, I have to step back to look at what else either distribution might have been installed. If the other files from Foo-Bar aren't there, it's probably not Foo-Bar.

That might be the end of the story, but what if both Foo-Bar and Baz-Quux are installed? That part I haven't figured out, but it's likely that the previous step will be inconclusive since the files from both distributions will all be there. However, there's also the chance that an older version of Foo-Bar and a newer Baz-Quux is there. If they both install a Foo.pm file, the older version in Foo-Bar might have been over written by an updated version from Baz-Quux. So, Every file except one from Foo-Bar is there. That means that there's possibly some path independence there so I would have to make sure I install modules in the right order to recreate the installation.

If the module installation order matters, I think that might rule out creating a Task::* distribution, which can't guarantee the installation order, I think. A Bundle::* might be able to do it though.

So, you think that's the end of it? Think about configure_requires and build_requires. Anything those need to be in the MiniCPAN too, even if they aren't in the installation. You have the option of not permanently installing those modules, so you might not see them in the analysis. Even when I get a list of distributions, I then have to check their dependencies to see if there's anything extra I need to add.

So, not so bad.

I've been spending a fair bit of time working on Perl 5 core documentation. I started by editing and reorganizing some of the documents related to core hacking. This update will be in 5.14, due to be released in April. I'm also working on replacing the existing OO tutorials and updating the OO reference docs, though this won't make it into the 5.14 release.

There's been a lot of discussion on my OO doc changes, some of it useful, some of it useless, and some of it very rude (welcome to p5p!). Many of the people in the discussion don't have a clear vision of who the docs are for. Without that vision, it's really not possible to say whether a particular piece of documentation is good or not. A piece of documentation has to be good for a particular audience.

There's a number of audiences for the Perl 5 core docs, and they fall along several axes. Here are the axes I've identified.

Newbies vs experienced users

Newbie-ness is about being new to a particular concept. You could be an experienced Perl user and still be new to OO programming in general, or new to OO in Perl.

For my OO docs, I'm writing for two audiences. First, I'm writing for people who are learning OO. That's why the document starts with a general introduction to OO concepts. Second, I'm writing for people who want to learn more about how to do OO in Perl 5. For those people, the tutorial points them at several good OO systems on CPAN.

I'm not writing for people who already know Perl 5 OO and want to learn more, that's what the perlobj document is for.

From the discussion on p5p, I can see that many people there have trouble understanding how newbies think. I like how chromatic addresses these issues in a couple of his blog posts.

How the reader uses Perl

Perl is used for lots of different tasks, including sysadmin scripts, glue code in a mostly non-Perl environment, full app development, etc.

Ideally, we'd have tutorial documents that are appropriate for each of these areas. I think the OO tutorial is most likely to be of interest to people writing full Perl applications. If you're just whipping up some glue code, OO is probably overkill.

It would also be great to see some job-focused tutorials, like "Basic Perl Concepts for Sysadmins" or "Intro to Web Dev in Perl 5". Yes, I know there are books on these topics, but having at least some pointers to modules/books/websites in the core docs is useful.

Constraints on the reader's coding

If you're doing green field development, you have the luxury of using the latest and greatest stuff on CPAN. If you're maintaining a 10-year old Perl web app (I'm so sorry), then you probably don't. Some readers may not be able to install CPAN modules. Some readers are stuck with in house web frameworks.

People stuck with old code need good reference docs that explain all the weird shit they come across. People writing new code should be guided to modern best practices. They don't need to know that you can implement Perl 5 OO by hand using array references, ties, and lvalue methods

My OO tutorial is obviously aimed toward the green field developers. It's all about pointing them at good options on CPAN. As I revise perlobj, I'm trying to make sure that I cover every nook and cranny so that the poor developer stuck with (2001 Perl OO code can understand what they're maintaining.

(Sadly, that's probably my code they're stuck with.)

Conclusion

I'd like to see more explicit discussion of who the intended readers are when we discuss core documentation. Any major doc revision should start with a vision of who the docs are for.

There's probably other axes we can think about when writing documentation as well. Comments on this are most welcome.

Basic integration of software and web sites with Facebook, Twitter, and other social networking systems has become a litmus test for business these days. Depending on the software or site you might need to fetch some data, make a post, create events, upload photos, or use one or more of the social networking sites as a single sign-on system. This series will show you how to do exactly those things on Facebook using Facebook::Graph.

This first article starts small by using Facebook as an authentication mechanism. There are certainly simpler things to do, but this is one of the more popular things people want to be able to do. Before you can do anything, you need to have a Facebook account. Then register your new application (Figure 1).

Figure 1. Registering a Facebook application.

Then fill out the "Web Site" section of your new app (Figure 2).

Figure 2. Registering your application's web site.

Registering an application with Facebook gives you a unique identifier for your application as well as a secret key. This allows your app to communicate with Facebook and use its API. Without it, you can't do much (besides screen scraping and hoping).

Now you're ready to start creating your app. I've used the Dancer web app framework, but feel free to use your favorite. Start with a basic Dancer module:

package MyFacebook; use strict; use Dancer ':syntax'; use Facebook::Graph; get '/' => sub { template 'home.tt' }; true;

That's sufficient to give the app a home page. The next step is to force people to log in if they haven't already:

before sub { if (request->path_info !~ m{^/facebook}) { if (session->{access_token} eq '') { request->path_info('/facebook/login') } } };

This little bit of Dancer magic says that if the path is not /facebook and the user has no access_token attached to their session, then redirect them to our login page. Speaking of our login page, create that now:

get '/facebook/login' => sub { my $fb = Facebook::Graph->new( config->{facebook} ); redirect $fb->authorize->uri_as_string; };

This creates a page that will redirect the user to Facebook, and ask them if it's ok for the app to use their basic Facebook information. That code passes Facebook::Graph some configuration information, so remember to add a section to Dancer's config.yml to keep track of that:

facebook: postback: "http://www.madmongers.org/facebook/postback/" app_id: "XXXXXXXXXXXXXXXX" secret: "XXXXXXXXXXXXXXXXXXXXXXXXXXX"

Remember, you get the app_id and the secret from Facebook's developer application after you create the app. The postback tells Facebook where to post back to after the user has granted the app authorization. Note that Facebook requires a slash (/) on the end of the URL for the postback. With Facebook ready to post to a URL, it's time to create it:

get '/facebook/postback/' => sub { my $authorization_code = params->{code}; my $fb = Facebook::Graph->new( config->{facebook} ); $fb->request_access_token($authorization_code); session access_token => $fb->access_token; redirect '/'; };

NOTE: I know it's called a postback, but for whatever reason Facebook does the POST as a GET.

Facebook's postback passes an authorization code—a sort of temporary password. Use that code to ask Facebook for an access token (like a session id). An access token allows you to request information from Facebook on behalf of the user, so all of those steps are, essentially, your app logging in to Facebook. However, unless you store that access token to use again in the future, the next request to Facebook will log you out. Therefore, the example shoves the access token into a Dancer session to store it for future use before redirecting the user back to the front page of the site.

NOTE: The access token we have will only last for two hours. After that, you have to request it again.

Now you can update the front page to include a little bit of information from Facebook. Replace the existing front page with this one:

get '/' => sub { my $fb = Facebook::Graph->new( config->{facebook} ); $fb->access_token(session->{access_token}); my $response = $fb->query->find('me')->request; my $user = $response->as_hashref; template 'home.tt', { name => $user->{name} } };

This code fetches the access token back out of the session and uses it to find out some information about the current user. It passes the name of that user into the home template as a template parameter so that the home page can display the user's name. (How do you know what to request and what responses you get? See the Facebook Graph API documentation.)

While there is a bit of a trick to using Facebook as an authentication system, it's not terribly difficult. Stay tuned for Part II where I'll show you how to post something to a user's wall.

For anyone who may have been affacted by the upgrade to LWP, the situation should now be resolved. David has put in place a 3rd party verified SSL certificate on the Metabase server, so all submissions should now be able to resolve certificate authenticity.

If you have implemented any short term fixes, you may need to remove them, before accepting the new certificate.

We now return you to your scheduled programming :)

Cross-posted from the CPAN Testers Blog

As Barbie reported, CPAN Testers broke under LWP version 6, as this version of LWP now defaults to rejecting unverifiable SSL connection (e.g. self-signed certificates). That meant that CPAN Testers upgrading their LWP could no longer submit reports (at least via https). The quick and obvious solution was to buy an SSL certificate and that's now done. If you visit https://metabase.cpantesters.org/, you can see the new certificate in action.

I spent a good few hours today attempting to use the MailboxGUID returned from the WMI Exchange provider to search for the associated Active Directory account, using the msExchMailboxGuid attribute.

Here's two functions I came up with in the end. One to convert MailboxGUID to something that a search on msExchMailboxGuid will like:

sub exch_to_ad { my $guid = shift; $guid =~ s/[\{\}]+//g; my $string = ''; my $count = 0; foreach my $part ( split /\-/, $guid ) { $count++; if ( $count >= 4 ) { $string .= "\\$_" for unpack "(A2)*", $part; } else { $string .= "\\$_" for reverse unpack "(A2)*", $part; } } return $string; }

And another to take a msExchMailboxGuid field, which is a byte array, and convert it to a MailboxGUID.

sub ad_to_exch { my $guid = shift; my @vals = map { sprintf("%.2X", ord $_) } unpack "(a1)*", $guid; my $string = '{'; $string .= join '', @vals[3,2,1,0], '-', @vals[5,4], '-', @vals[7,6], '-', @vals[8,9], '-', @vals[10..$#vals], '}'; return $string; }

Hopefully this should save other people some time.

If you're an existing CPAN Tester, and have recently upgraded LWP, you may have noticed that your report submissions have been failing. The reason being that LWP::UserAgent now requires that any https protocol request, needs to verify the certificate associated with it. With the Metabase having a self-signed certificate, this doesn't provide enough verification and so fails.

In the short term if you don't need to update LWP (libwww-perl), refrain from doing so for the time being. For those that have already done so, or have recently built test machines from a clean starting point, you will either need to wait until we have put a long term solution in place, or may wish to look at a solution from Douglas Wilson. Douglas has created a "hypothetical distribution", which you can see via a gist.

Others have also blogged about the problem, and have suggests and insights as to how to overcome this for the short term:

• CPAN::Reporter, Transport::Metabase, and libwww-lwp 6 by Douglas Wilson
• CPAN::Reporter fails to send through Metabase with new LWP 6 by Randy Stauner
• SSL host checking and LWP::UserAgent by Colin Newell

We will have more details of the longer term solution soon.

Cross-posted from the CPAN Testers Blog

We've decided we're gonna start releasing Dancer under codenames that relate to people who've worked on the release.

This release (1.3020) we've seen the continued (and blessed!) involvement of a one "Michael G. Schwern". To some of you he might just be a "mike" or "michael" (or perhaps "the schwern"), but none of us in the core knew Schwern personally before his involvement with Dancer, and this came as a very welcomed and pleasant surprise.

Considering the storm of issues and pull requests done by Schwern, we decided the next version should be named after him, hence "The Schwern Cometh". :)

The latest version is only a week-or-so of development but carries the following statistics:

• 6 contributors


• 6 bug fixes


• 12 features and enhancements


• 10+ issues closed

I really do see this as exceptional work. Other than Schwern I also want to thank Naveed Massjouni and Maurice Mengel for their contributions to this release (and any previous release!).

In the near future we'll also unveil the most elaborate hooks subsystem in the micro web framework world. I already know whose names will be splashes on that release. :)

Recently I've been working on revising the Perl 5 core OO documentation, starting with a new OO tutorial.

My first draft used Person and Employee as my example classes, where Employee is a subclass of Person. After I posted the first draft, several people objected to these particular classes. I realized that I agreed with their objections, but I wasn't able to come up with anything better.

I brought this up on the #moose IRC channel, and we had a really interesting discussion. Mostly it consisted of people coming up with various ideas and me shooting them down. The rejected suggestions included:

• Person/Employee
• Number/Integer
• Real/Complex (numbers)
• Window/ScrollableWindow
• Animal/Moose
• CD/Single
• Assessment/Survey (in the context of teaching assessments)
• Others I'm probably forgetting

Let's go through my criteria and talk about why each of these examples was rejected.

No Abstract Base Classes

The base class must be meaningful on its own. It must be something you might instantiate. This ruled out Animal/Moose, we don't want instantiate a generic Animal. Our understanding of animals is always more specific. At the very least, we recognize them as Birds, Mammals, Fish, and so on, if not as specific species.

Instead, Animal is really more of a role. In fact, thinking back to high school biology, deciding whether something is an animal is based entirely on its behavior (its interface).

If the parent class is better as a role, the suggestion doesn't work.

The other suggestions all passed this test.

Must Not Be Too Domain Specific

The example classes should not require domain knowledge to understand. The Real/Complex and Assessment/Survey suggestions are clearly too domain specific. The Window/ScrollableWindow suggestion may also fail this. Yes, everyone knows that some windows scroll and some don't, but very few people would know how that's implemented.

The example needs to be something that any programmer can be expected to understand.

Must Lend Itself to Example Methods

I need an example that lends itself well to writing small example methods. The Window/ScrollableWindow suggestion fails this criterion. The actual implementation of a windowing toolkit is quite complex, and extremely domain-specific.

The Subclass's Specialization Must Be Intrinsic to Its Nature

This one is best explained through an example that doesn't pass the test, Person/Employee. Being a Person is intrinsic to the class. However, when a person is an Employee, that's not really intrinsic to the Employee, it's just something a Person does. A Person can also be a spouse, a parent, a child, etc.

In other words, these are all roles that a Person plays. Clearly, this example is better implemented through roles.

Must Not Be Useless

The classic shapes example used in so many books falls into this category. It's really hard for me to imagine a program where I need to model Ellipse and Circle classes. I suppose I might do this if I were writing MS Paint.

The shapes example is useful for illustrating some technical ideas, but it's too abstract for a good tutorial.

Must Not Raise the Idea of Specialization By Constraint

Specialization by constraint is an object orientation concept defined by Chris Date and Hugh Darwen in their book The Third Manifesto.

This is a complex idea perhaps best illustrated by an example:

my $number = Number->new(3.9); $number->add(0.1);

Under the system proposed by Date and Darwen, the $number object would automatically become an Integer object when that is appropriate.

This is a fascinating idea, but something that's best left out of a basic OO tutorial.

As an aside, if you're interested in DBMS theory and design, you should really read The Third Manifesto, which I think has now been renamed as Databases, Types and the Relational Model (their website is horrible and confusing).

The Subclass Should Add Attributes and Behavior

The Number/Integer suggestion fails in this regard because the subclass takes away an attribute.

The Subclass Should Not Be Better As an Attribute

The CD/Single suggestion fails this criterion, since there's really no behavior or attribute difference between a CD and a Single. Instead, "single-ness" is better modeled as a simple attribute on a CD class.

The Winner

So after a lot of discussion, Jesse Luehrs (doy) suggested File/File::MP3. This example satisfies (almost) every criteria.

The File/File::MP3 example works really well in a number of ways:

• The base class is not abstract.
• A generic File makes perfect sense.
• We can expect every programmer to understand the nature of the classes.
• It lends itself well to simple example methods.
• The subclass's nature is intrinsic. Files have one specific type, or we don't know their type. Yes, I know it's possible to have a file that satisfies multiple format requirements, but that's a bizarre special case.
• It is clearly not useless, and is in fact something you might find yourself writing in real world code.
• The subclass adds behavior (track title attribute, play() method, etc.).
• The subclass is clearly not better modeled as an attribute.

The only negative is that this example does bring up the idea of specialization by constraint. In a real world implementation, you might have a File factory that looked at the file's contents and returned an appropriate File subclass.

There's no perfect example, but this one is significantly better than Person/Employee, and it's what I'll be using in my work on the core docs.

Thanks, Jesse!

Today I’ve updated my spreadsheets of the CPAN modules that are available as RPMs from various repositories for Fedora and Centos. I see that in many cases the “official” repos are now more up to date than my own repo (which I originally set up because the official repos are sometimes out of date).

This is all a precursor to doing a lot more work on my repo. I need to know which RPMs are being kept up to date by other people so that I can ignore those modules.

But I thought that other people might find the data useful or interesting.

If you've ever built Perl from scratch, you probably know how much faster it can be to make and test in parallel. On the other hand, if you use perlbrew on a multi-core processor, you probably already figured out that it wasn't using all your processors.

I was very pleased to discover an undocumented '-j' option in perlbrew 0.17 that switches on parallel make:

$ perlbrew -j 5 install perl-5.12.3

Currently, this only runs make in parallel, but I've submitted a patch to make it switch on parallel testing as well (for recent Perl's that support it). The patch also documents the option.

I hope the new version will be out soon, but if you have 0.17, you can already start using '-j' for a small speed boost.

We're almost finished with the updates to Learning Perl, 6th Edition. The big changes for this edition are beginner-appropriate features up to Perl 5.14 and a lot more Unicode. I've keep keeping a diary of my progress at www.learning-perl.com. Now that we are mostly done, it's time for some tech reviewers to catch any lies (outright or by omission) that we've told. If you've done that for me before and would like to do it again, let me know and we'll make the proper arrangements.

In previous editions, we've also let let watch the progress of the book by reading the sources as we worked on them. Since then, we converted to the O'Reilly DocBook system that allows us to turn our work into PDF files that look very close to what the final book will present. Those PDF files are available to subscribers to The Perl Review in the Works in Progress section. Not only can you see the book as it stands now, in the middle of editing warts and all, but you can give us feedback before the book actually commits to dead trees.