Rather than this (today):

# Assuming $data->{$key1}{$key2} = [ qw/foo bar/ ]
push @{ $data->{$key1}{$key2} }, @stuff;

I wanted this (in the future):

# Assuming $data->{$key1}{$key2} = [ qw/foo bar/ ]
push $data->{$key1}{$key2}, @stuff;

I've finished a draft implementation that works for push, pop, shift, unshift and splice. All existing Perl tests pass, as do new tests I've written that explore this new functionality. It will even auto-vivify as needed:

my $foo;
push $foo, @stuff; # $foo is now an arrayref

I'm still working on keys, values and each and those look much harder, but I hope to have something to share by next week.

Updated: I added example data to the "given $data..." comments to clarify that it's an example, not a recommendation about how to initialize a data structure.

The big advantage of Git::Wrapper is that it wraps the binary version of git, which keeps your perl and git independent. Upgrade perl and not git? Add Git::Wrapper and you're done. Upgrade git while keeping your existing perl? No problem. If you get your git from an OS distribution package, but roll your own perl, then Git::Wrapper is for you!

Git::Wrapper just makes it really easy to pass git commands and get back useful data. It really shines on "git log" commands, as it parses each commit message into Git::Wrapper::Log objects with accessors for id, author, date, and message. For everything else, it's not much more than a wrapper around qx(), but it returns arrays of lines and throws exceptions when things go wrong, which just saves a little time and code.

Here is a short example that I whipped up recently to automate the process of adding a github repository remote for someone when they send me a pull request. (It also uses my Getopt::Lucid module, but as the name suggests, it should be clear what that does.)

#!/usr/bin/env perl
use 5.010;
use strict;
use warnings;
use autodie;
use Git::Wrapper;
use Getopt::Lucid qw/:all/;

# USAGE: github-remote [-r REPO] [NAME]
#     NAME -- a github user name (or defaults to 'dagolden')
#     REPO -- a github repository path (or is parsed out of my private origin repo)

my $opts = Getopt::Lucid->getopt([
  Param('repo|r'),
]);

my $who = shift @ARGV;

# Get a wrapper for the current directory
my $git = Git::Wrapper->new(".");

# Locate the origin repository URL
my ($origin) = grep { /origin/ } $git->remote("-v");
die "Couldn't determine origin\n" unless $origin;
$origin =~ s/^origin\s+//;
$origin =~ s/\s+\(.*$//;

# Parse out the repository path
my $repo = $opts->get_repo;
unless ( $repo ) {
  # me@git.example.com:my-repo-name.git
  ($repo) = $origin =~ m/^[^:]+:(.+)$/;
}

# Set up someone else's github repo
if ( $who ) {
  $git->remote("add", $who, "git://github.com/${who}/${repo}");
}
# Or set up my own github mirror
else {
  $git->remote("add", "github", "git\@github.com:dagolden/${repo}");
}

That's it. I admit the program is a little crufty because of how I manage my repositories with a private origin that I mirror to a github repository, but there's almost no cruft around interactions with git. Consider this:

  $git->remote("add", $who, "git://github.com/${who}/${repo}");

If the command fails (if there's already $who as a remote name), an exception will be thrown. That means I don't have to write any error handling myself, which is perfect for a simple automation program like this one.

I've just updated the "quick-start" documentation on the CPAN Testers wiki: Quick HowTo for CPAN Testers 2.0

It's not perfect, but it's a lot better than it used to be. If you are still submitting reports by email, please read and follow the instructions before the end of August. If you have trouble, please ask for help on the cpan-testers-discuss mailing list or on #cpantesters-discuss on irc.perl.org.

Here is what I have to write today to use array functions on an array reference:

# Given $obj->foo() that returns an array reference

shift @{ $obj->foo };
push @{ $obj->foo }, @stuff;
splice @{ $obj->foo }, 0, 2;

Here is how I wish it would work:

shift $obj->foo;
push $obj->foo, @stuff;
splice $obj->foo, 0, 2;

Isn't that second block a lot cleaner to read? Getting rid of the @{} declutters the code and, at least for me, it's still clear from the context that I expect the first argument to act like an array.

Likewise, I'd like to have the same magic work for functions like values or keys, which would let me flatten array references or get an index list in a more readable way:

# from this:
for ( @{ $obj->foo } ) { ... }
for ( $#{ $obj->foo } ) { ... }

# to this:
for ( values $obj->foo ) { ... }
for ( keys $obj->foo ) { ... }

I suspect something similar would make sense for hash references, too.

On reflection, I think this would mean that checking that the first argument indeed held an array reference would have to be done at run-time, but I suspect there might be a way within the Perl op-codes to avoid such a checks except when necessary. (Thus, you could still use @{} for a slight bit of hand-optimization, if desired.)

I wish I knew more Perl guts to work on a draft implementation, because right now I think this would be one of the coolest features to see in a future Perl.

Factually, Rakudo is not new -- there have been thirty-one development releases of it. But Rakudo Star is the first prototype of an end-user distribution tarball that includes the latest Rakudo, the Parrot virtual machine, existing documentation, build instructions and so on. I would say it is designed for Perl 6 experimenters, rather than Perl 6 implementors. It means that anyone interested in Perl 6 can now just do this:

$ tar xzf rakudo-star-2010.07.tar.gz
$ cd rakudo-star-2010.07/
$ more README
... satisfy library prereqs ...
$ perl Configure.pl --gen-parrot
$ make
$ make install
$ ./perl6 -e 'say "Hello World"'

For the Perl 6 project team -- or more broadly, anyone carrying the Perl 6 torch for the last ten years -- the release of Rakudo Star has huge symbolic importance. They're saying, in effect, "look at this cool project we've been working on! We want you to get as excited as we are about what Perl 6 will be able to do". And, you know what, if I were working on something for ten years, I'd be wanting to celebrate, too.

For those outside the project team, the significance of the release isn't so obvious. I can imagine a wide range of reactions:

• "Cool! I've been wanting to try some Perl 6 but didn't know where to start."
• "What's the big deal? I can't use it for anything real yet."
• "This sucks. It's too (big|slow|buggy|incomplete)."
• "Gee, thanks. Perl 6 gets the attention and Perl 5 gets ignored... again"
• "Perl 6?"

There is no way reactions to Rakudo Star can possibly live up to the hopes and dreams of those involved the project. I'm not surprised that some of the project members seem defensive in the face of criticism.

Leaving the emotional reactions aside, Rakudo Star still is a significant step forward for Perl 6, as it means inviting a less dedicated group of participants to test and react to the evolution of both the language and the implementation. Some of that will be negative, but some will be positive. More importantly, it will provide focus to the project going forward and shift the mentality -- gradually, one hopes -- from "get it absolutely right" to "get it done".

In the past, I've felt that the Perl 6 effort has been a distraction for Perl 5. On reflection, I've decided that the release of Rakudo Star is good for Perl 5 because it makes it easier for people to assess the relative status of both. Now, more than ever, it's clear that Perl 6 is not going to sweep Perl 5 away any time soon, but people who are interested in the comparison can watch both evolve and decide where they want to invest their time.

It's also pretty clear that Perl 6 is not going to make substantial inroads against Python, Ruby, PHP and other dynamic languages any time soon, either. If anyone was waiting for Perl 6 to rescue Perl, then they'll need to keep waiting.

However, Rakudo Star will help demonstrate common strengths of the current incarnation of both Perl 5 and Perl 6 language development.

• Timeboxed delivery -- both projects are now delivering regular, packaged development releases that users can unpack, install and explore to see how new features evolve and how it works with previously written code.
• Tests and a testing culture -- both Perl 5 and Perl 6 are backed by thousands of tests that help catch potential errors or behavior regressions
• CPAN -- Perl 5 already has it (and it's adding 1,000 distributions a month) and some of the early work by the Perl 6 community has been to start porting some of the more popular Perl 5 modules into Perl 6.
• Community -- there are dozens (or more) Perl conferences each year. These have often included talks on Perl 6 and this trend will likely continue. While Perl 5 and Perl 6 are different languages, they share not only a common heritage but a common culture as well

I suggest that people put the release of Rakudo Star in perspective. It is not a game-changer, but it is still a big step forward. Those who delivered it deserve kudos not brickbats, and I look forward to a next release that is even better.

$ dzil new My::Module

If you've ever tried this, you've seen that the built-in boilerplate is very, very minimal and you probably want to know how to customize it to fit your dzil style.

I wrote up the tutorial below and submitted it for consideration for dzil.org. If you use dzil, I hope you'll find it to be a useful step-by-step guide. Feedback is welcome, either in comments below or via my dzil.org branch on github. I also want to thank xenoterracide for writing "Creating new projects with dzil new and templates", which was a huge help to me in figuring out how this works. Several of the examples below were taken or adapted from his article.

Customizing the Minting Process

Dist::Zilla lets you create any number of "minting profiles" to create distributions with different default contents. You might have one for work and one for personal code; one for object-oriented code and one for functional code; or one for web applications and one for command-line applications, etc.

Preparation

For the tasks below you'll want to:

• install Dist::Zilla, version 4.101780 or later
• run "dzil setup"

The rest of this document assumes that you haven't already made a custom minting profile, meaning that you haven't got anything in ~/.dzil/profiles. If you have a default profile, just rename it if you want to follow the steps exactly as described below.

Create a default profile

Create a directory called ~/.dzil/profiles/default. This will hold your default minting profile, overriding the very simple default that ships with Dist::Zilla.

The first thing you want to do is change into that directory and create a profile.ini file with the following content:

[TemplateModule/:DefaultModuleMaker]
template = Module.pm

[GatherDir::Template]
root = skel
include_dotfiles = 1

The profile.ini file defines two components for minting your new distribution. The first one, TemplateModule, is given a special name :DefaultModuleMaker, to tell Dist::Zilla that this component will be used for creating the new module file. The template parameter tells it a file to use, so create a Module.pm file (in the same directory as profile.ini) with the following content:

use strict;
use warnings;
package {{$name}};

1;

The second component in profile.ini is GatherDir::Template, which specifies a directory of templates that will also be created in your new distribution. That is where you'll be putting your custom dist.ini, Changes or other files.

Create ~/.dzil/profiles/default/skel and change to that directory.

Next, create a dist.ini file with the following content:

{{
    $license = ref $dist->license;
    if ( $license =~ /^Software::License::(.+)$/ ) {
        $license = $1;
    } else {
        $license = "=$license";
    }

    $authors = join( "\n", map { "author  = $_" } @{$dist->authors} );
    $copyright_year = (localtime)[5] + 1900;
    '';
}}name    = {{$dist->name}}
{{$authors}}
license = {{$license}}
copyright_holder = {{$dist->copyright_holder}}
copyright_year   = {{$copyright_year}}

[@Basic]

Ignore all the gobbledy-gook at the top and notice the [@Basic] line. this will give you a dist.ini in your new directory that uses the @Basic plugin bundle. As you become more familiar with Dist::Zilla, this is where you'll want to add more plugins to customize what Dist::Zilla can do for you.

Change to your work directory and run dzil new My::Module. You should get a new distribution that is almost exactly like the original default included with Dist::Zilla, except that it has the addition of the @Basic plugin bundle in the new dist.ini file.

Now, all you have to do is customize the dist.ini and Module.pm files in minting profile to suit your own personal style.

Enhancing your minting profile

You can create other files in skel as well. For example, if you use git, you might want to create a starter .gitignore:

/{{$dist->name}}*
.build

Or, if you start using the NextRelease plugin, you probably want to have a Changes file that takes advantage of it:

Revision history for {{$dist->name}}

{{ '{{$NEXT}}' }}
    -

In the sample above, you can see the syntax for including template text inside a template, which might be useful for other skeleton files as well.

Setting up an alternate minting profile

The easiest way to set up an alternate profile is to copy your default profile to a new directory. For example, if you wanted to set up a profile that provided a Moose-specific starter module, you could create a copy like this:

$ cp -a ~/.dzil/profiles/default ~/.dzil/profiles/moose

Then, customize the ~/.dzil/profiles/moose/Module.pm file to load Moose and provide any boilerplate you like.

You can run dzil new with the -p flag to use the alternate profile:

$ dzil new -p moose My::Moose::Module

Parallel::Iterator provides a very simple API to execute a "map" function in parallel across multiple processes. It handles all the forking and inter-process communication for you, so all you have to do is focus on the task at hand. This is useful for a CPU-intensive task that you'd like to spread across multiple cores or for tasks with relatively long I/O delays.

Here is a very simple example, adapted from the documentation. Suppose you need to fetch a lot of web-pages from URL's provided on STDIN. You just need to write the "worker" subroutine to fetch a page and Parallel::Iterator does the rest.

use strict;
use warnings;
use LWP::UserAgent;
use Parallel::Iterator qw/iterate_as_array/;

# this worker fetches a page or returns undef
my $ua = LWP::UserAgent->new( env_proxy => 1 );
my $worker = sub {
  my $url = shift;
  my $resp = $ua->get($url);
  return undef unless $resp->is_success;
  return $resp->decoded_content;
};

# this gets a list of pages and fetches them in parallel
my @urls = split "\n", do { local $/; <STDIN> };
my @pages = iterate_as_array( $worker, @urls );

# now do stuff with the results
...

With just that little code, the URL's to fetch are split across 10 sub-processes, the page fetching happens in parallel and the results are collected into the @pages array.

Parallel::Iterator has a number of additional features for customizing the number of subprocesses, or iterating the results (instead of getting back an array) and for batching the input to subprocesses.

It may not be the right tool all of the time, but if you need to parallelize a task quickly, Parallel::Iterator should be in your tool-box.

• Free QA! -- a non-technical talk about the history and social architecture choices of the CPAN Testers project
• Perl 5, Version 13 -- a lightning talk summarizing notable changes in the Perl 5.13 development series

Look at Crowley, doing 110 mph on the M40 heading towards
Oxfordshire. Even the most resolutely casual observer would
notice a number of strange things about him. The clenched teeth,
for example, or the dull red glow coming from behind his
sunglasses. And the car. The car was a definite hint.

Crowley had started the journey in his Bentley, and he was
dammned if he wasn't going to finish it in the Bentley as well.
Not that even the kind of car buff who owns his own pair of
motoring goggles would have been able to tell it was a vintage
Bentley. Not any more. They wouldn't have been able to tell
that it was a Bentley. They would only offer fifty-fifty that it
had ever even been a car.

There was no paint left on it, for a start. It might still have
been black, where it wasn't a rusty, smudged reddish-brown, but
this was a dull charcoal black. It traveled in its own ball of
flame, like a space capsule making a particularly difficult
re-entry.

There was a thin skin of crusted, melted rubber left around the
metal wheel rims, but seeing that the wheel rims were still
somhow riding an inch above the road surface this didn't seem to
make an awful lot of difference to the suspension.

It should have fallen apart miles back.

-- Neil Gaiman and Terry Pratchett, "Good Omens"

It gives me great pleasure to announce the release of Perl 5.13.3.

This is the fourth DEVELOPMENT release in the 5.13.x series leading to a stable release of Perl 5.14.0. You can find a list of high-profile changes in this release in the file "perl5133delta.pod" inside the distribution.

You can (or will shortly be able to) download the 5.13.3 release from:

http://search.cpan.org/~dagolden/perl-5.13.3/

The release's SHA1 signatures are:

• SHA1: 58e802bcae597ca08a6933265d03b37420c80076 perl-5.13.3.tar.bz2
• SHA1: 75b1bb2585fcbc75bfa473fcf77318b3872d61a2 perl-5.13.3.tar.gz

This release corresponds to commit 414abf8 in Perl's git repository. It is tagged as 'v5.13.3'.

We welcome your feedback on this release.

If Perl 5.13.3 works well for you, please use the 'perlthanks' tool included with this distribution to tell the all-volunteer development team how much you appreciate their work.

If you discover issues with Perl 5.13.3, please use the 'perlbug' tool included in this distribution to report them.

If you write software in Perl, it is particularly important that you test your software against development releases. While we strive to maintain source compatibility with prior stable versions of Perl wherever possible, it is always possible that a well-intentioned change can have unexpected consequences. If you spot a change in a development version which breaks your code, it's much more likely that we will be able to fix it before the next stable release. If you only test your code against stable releases of Perl, it may not be possible to undo a backwards-incompatible change which breaks your code.

Perl 5.13.3 represents approximately one month of development since Perl 5.13.2, and contains 12,184 lines of changes across 575 files from 104 authors and committers.

Notable changes in this release:

• \o{...} has been added as a string escape for octals.
• \N{} and charnames::vianame now know about the abbreviated character names listed by Unicode, such as NBSP, SHY, etc.
• Most dual-life module have been synchronized with the latest production release on CPAN.
• There is a new internal function PL_blockhook_register for XS code to hook into Perl's lexical scope mechanism

There is one major known issue:

• Bug fixes involving CvGV reference counting break Sub::Name (currently version 0.04). A patch has been sent upstream to the maintainer.

Thank you to the following for contributing to this release:

Abhijit Menon-Sen, Abigail, Alex Davies, Alex Vandiver, Alexandr Ciornii, Andreas J. Koenig, Andrew Rodland, Andy Dougherty, Aristotle Pagaltzis, Arkturuz, Ben Morrow, Bo Borgerson, Bo Lindbergh, Brad Gilbert, Bram, Brian Phillips, Chas. Owens, Chip Salzenberg, Chris Williams, Craig A. Berry, Curtis Jewell, Dan Dascalescu, Daniel Frederick Crisman, Dave Rolsky, David Caldwell, David E. Wheeler, David Golden, David Leadbeater, David Mitchell, Dennis Kaarsemaker, Eric Brine, Father Chrysostomos, Florian Ragwitz, Frank Wiegand, Gene Sullivan, George Greer, Gerard Goossen, Gisle Aas, Goro Fuji, Graham Barr, H.Merijn Brand, Harmen, Hugo van der Sanden, James E Keenan, James Mastros, Jan Dubois, Jerry D. Hedden, Jesse Vincent, Jim Cromie, John Peacock, Jos Boumans, Josh ben Jore, Karl Williamson, Kevin Ryde, Leon Brocard, Lubomir Rintel, Maik Hentsche, Marcus Holland-Moritz, Matt Johnson, Matt S Trout, Max Maischein, Michael Breen, Michael G Schwern, Moritz Lenz, Nga Tang Chan, Nicholas Clark, Nick Cleaton, Nick Johnston, Niko Tyni, Offer Kaye, Paul Marquess, Philip Hazel, Philippe Bruhat, Rafael Garcia-Suarez, Rainer Tammer, Reini Urban, Ricardo Signes, Richard Soderberg, Robin Barker, Ruslan Zakirov, Salvador Fandino, Salvador Ortiz Garcia, Shlomi Fish, Sinan Unur, Sisyphus, Slaven Rezic, Steffen Mueller, Stepan Kasal, Steve Hay, Steve Peters, Sullivan Beck, Tim Bunce, Todd Rinaldo, Tom Christiansen, Tom Hukins, Tony Cook, Vincent Pit, Yuval Kogman, Yves Orton, Zefram, brian d foy, chromatic, kmx, Ævar Arnfjörð Bjarmason

Many of the changes included in this version originated in the CPAN modules included in Perl's core. We're grateful to the entire CPAN community for helping Perl to flourish.

Development versions of Perl are released monthly on or about the 20th of the month by a monthly "release manager". You can expect following upcoming releases:

• August 20 - Florian Ragwitz
• September 20 - Steve Hay
• October 20 - Tatsuhiko Miyagawa
• November 20 - Chris Williams