Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Yanick (3196)

  (email not shown publicly)

Journal of Yanick (3196)

Sunday May 10, 2009
06:40 PM

Breaking off from the mothership

For the last couple of months, as a concession between visibility and control, I'd been double-posting my blog entries both here and on my personal blog. But now that my blog is registered on both the Perlsphere and IronMan aggregators, the need for the second posts here has dwindled. So... I'm going on a limb and tentatively turn off the echoing. See y'all on Hacking Thy Fearful Symmetry!

Tuesday April 21, 2009
07:31 PM Die Meister des Psycho-Lamas

reposted from Hacking Thy Fearful Symmetry

Last month, thanks to a concerted effort of German Perl Mongers[1] I was able to meet with the wonderful folks of

It turns out that not only the Ruhr-area mongers are a superlatively friendly bunch, but they have pretty cool presentations too.

The feature presentation of the night was Fuse mit Perl, by Simon Wilper. After he was done, I also got treated with a quick replay of two previous presentations dealing with image manipulation. One was about openCV, a facial recognition software, and its Perl interface, and the other one was about the uses of Image::Magick, including the detailed instructions on how to create a psycho-llama. That last bit, I daresay, was worth the trip to Germany all by itself. The script to create the thing is in the presentation companion tarball, check it out (well, unless you suffer from epilepsy, in which case you want to stay as far away as possible).

So, bottom-line: rocks big time. If you're ever passing in the vicinity, I highly recommend paying them a visit. :-)

[1] Renée Bäcker saw my blog entry and forwarded the information to, Veit Wahlich -- fearless leader of the Ruhrgebiet mongers -- contacted me and arranged the details, and René Knopp was dispatched to pick me up from the train station. Many thanks to the whole bunch!

Wednesday March 04, 2009
01:28 PM

Just another Perl Ausländer

(cross-posted from Hacking Thy Fearful Symmetry)

Ever since I've learned about the existence of $foo - Perl Magazin, I've been awfully curious to take a peek at it. Unfortunately, they don't ship subscriptions internationally. So I went for the obvious workaround: I hunted high and low for the loveliest German lass I could find, asked her to marry me, and coaxed her family to get and forward me a subscription for the magazine as this year's Christmas gift. Worked like a charm.

And it was worth it too. The magazine is even better than I expected, and it's high praises to the authors that I learned quite a few things from the articles even though my German is still at a protozoic stage. Whether you're a German wanting to learn Perl, or a Perl hacker wanting to learn German, I heartily recommend it.

And talking of Germany, I'll embark tomorrow on a three-week vacation trip across the republic. If there are any Perl mongers meeting this month around Duisburg, Morsbach or Schwieberdigen who wouldn't mind having an Ausländer in their midst, please feel free to drop me an email. :-)

Tuesday December 30, 2008
01:26 PM

Variation on the Faces of CPAN

Faces of CPAN + GD::Image + blissfully idle holiday morning = this.

Monday December 29, 2008
01:32 PM

CPAN Patching with Git

A few months ago, brian posted a blog entry about patching modules using Git. In the ensuing discussion, I pointed at a possible way to automatise the process a step further by punting the generated patch to The hack was well-received and, with (very) minimal coaxing, I was subsequently convinced to expand on the idea for the Perl Review.

The resulting piece is now available in TPR 5.1. In the article, the initial command-line hack has morphed into four scripts -- git-cpan-init, git-cpan-clone, git-cpan-update and git-cpan-sendpatch -- that pretty much take care of all the administrative overhead of module patching. In most cases, grabbing a distro, fixing a bug and sending the patch can be done in four lines:

    $ git cpan-init Some::Module
    $ git checkout -b mypatch
    ...hack hack hack...
    $ git rebase -i cpan
    $ git cpan-sendpatch

And, no, the lack of hyphen between git and cpan-X isn't a typo; the article also covers how to seamlessly integrate the new scripts into the git infrastructure (as Edna Mode would say, it's a non-feature, dahling).

Of course, I'm burning to say more, but I'll have to stop here. To know the whole story, you'll have to wait for The Perl Review to land in your mailbox (you are subscribed to TPR, right?).

cross-posted from Hacking Thy Fearful Symmetry.

Monday November 10, 2008
11:01 PM

introducing Dist::Release

(cross-posted from Hacking Thy Fearful Symmetry )

I know, I know, there's already more module release managers out there than there are Elvis impersonators in Vegas. Still, module releasing seems to be a very personal kind of itch, and like so many before I couldn't resist and came up with my very own scratching stick.

Of course, I've tried Module::Release. But, although it is intended to be customized to suit each author's specific needs, one has to dig fairly deep in the module's guts to do so. What I really wanted was something even more plug'n'play, something that would be brain-dead easy to plop new components in. Hence Dist::Release.

In Dist::Release, the release process is seen as a sequence of steps. There are two different kind of steps: checks and actions. Checks are non-intrusive verifications (i.e., they're not supposed to touch anything), and actions are the steps that do the active part of the release. When one launches a release, checks are done first. If some fail, we abort the process. If they all pass, then we are good to go and the actions are done as well.

Implementing a check

To create a check, all that is needed is one module with a 'check' method. For example, here is the code to verify that the distribution's MANIFEST is up-to-date:

    package Dist::Release::Check::Manifest::Build;

    use Moose;

    use IPC::Cmd 'run';

    extends 'Dist::Release::Step';

    sub check {
        my $self = shift;

        $self->diag( q{running 'Build distcheck'} )

        my ( $success, $error_code, $full_buf, $stdout_buf, $stderr_buf ) =
        run( command => [qw# ./Build distcheck #] );

        return $self->error( join '', @$full_buf )
            if not $success or grep /not in sync/ => @$stderr_buf;


Dist::Release considers the check to have failed if there is any call made to error(). If there is no complain, then it assumes that everything is peachy.

Implementing an action

Actions are only marginally more complicated than checks. The module implementing the action can have an optional check() method, which is going to be run with all the other checks, and must have a release(), which make the release-related changes.

For example, here's the CPANUpload action:

    package Dist::Release::Action::CPANUpload;

    use Moose;

    use CPAN::Uploader;

    extends 'Dist::Release::Action';

    sub check {
        my ($self) = @_;

        # do we have a pause id?
        unless ($self->distrel->config->{pause}{id}
            and $self->distrel->config->{pause}{password} ) {
            $self->error('pause id or password missing from config file');

    sub release {
        my $self = shift;

        $self->diag('verifying that the tarball is present');

        my @archives = <*.tar.gz> or return $self->error('no tarball found');

        if ( @archives > 1 ) {
            return $self->error( 'more than one tarball file found: ' . join ',',
                @archives );

        my $tarball = $archives[0];

        $self->diag(&quot;found tarball: $tarball&quot;);

        $self->diag(&quot;uploading tarball '$tarball' to CPAN&quot;);

        my ( $id, $password ) =
            map { $self->distrel->config->{pause}{$_} } qw/ id password /;

        $self->diag(&quot;using user '$id'&quot;);

        my $args = { user => $id, password => $password };

        unless ( $self->distrel->pretend ) {
            CPAN::Uploader->upload_file( $tarball, $args );


As for the check(), Dist::Release figures out that a release() failed if there's a call to error().

Configuring for a module

Configuration is done via a 'distrelease.yml' file dropped in the root directory of the project. The file looks like this:

        id: yanick
        password: hush
        - VCS::WorkingDirClean
        - Manifest
        - GenerateDistribution
        - CPANUpload
        - Github

It's pretty self-explanatory. The checks and actions are applied in the order they are given in the file.

Crying havoc...

And once the configuration file is present, all that remains to be done is to run distrelease, sit back and enjoy the show:

    $ distrelease
    Dist::Release will only pretend to perform the actions (use --doit for the real deal)
    running check cycle...
    regular checks
    VCS::WorkingDirClean              [failed]
    working directory is not clean
    # On branch master
    # Changed but not updated:
    #   (use &quot;git add <file>...&quot; to update what will be committed)
    #       modified:   Build.PL
    #       modified:   Changes
    #       modified:   README
    #       modified:   distrelease.yml
    #       modified:   lib/Dist/Release/Check/
    #       modified:   script/distrelease
    # Untracked files:
    #   (use &quot;git add <file>...&quot; to include in what will be committed)
    #       STDOUT
    #       a
    #       blog
    #       xml
    #       xt/dependencies.t
    #       xxx
    no changes added to commit (use &quot;git add&quot; and/or &quot;git commit -a&quot;)
    Manifest                          [failed]
    No such file: lib/Dist/Release/Action/
    Not in MANIFEST: a
    Not in MANIFEST: blog
    Not in MANIFEST: lib/Dist/Release/Action/
    Not in MANIFEST: xml
    Not in MANIFEST: xt/dependencies.t
    Not in MANIFEST: xxx
    MANIFEST appears to be out of sync with the distribution
    pre-action checks
    GenerateDistribution              [passed]
    no check implemented
    CPANUpload                        [passed]
    Github                            [passed]
    2 checks failed
    some checks failed, aborting the release

Getting the good

A first release of Dist::Release is already waiting for you on CPAN. It's beta, has no documentation, is probably buggy as hell, but it's there. And the code is also available on Github. Comments, suggestions, forks and patches are welcome, as always. :-)

Saturday September 06, 2008
10:06 AM

Me at OsBootCamp 8

OS Bootcamp is a cool initiative to inform and initiate university students to the wonders of the Open Source world.

OsBootCamp 8, which took place on August 28th, was about interpreted programming languages. On the agenda were short introductions of the three big kids on the block (Perl, Python and Ruby). And yup, the honor to ramble about Perl was given to li'll old me. For the morbidly curious, there's a video of the resulting show. :-)

Tuesday August 12, 2008
08:58 PM

Pasting repository info on CPAN page

Out of the comments generated by a post by grink, I've learned that the location of the distribution's repository can be inserted in the META.yml. Neato!

And when grink asked if someone could come up with a Greasemonkey script to extract that information and show it on the distro's page... well, that's no simian fun I could let pass untackled. The resulting greasemonkey script can be found here.

Monday August 04, 2008
07:55 PM

Mohlohpoly game

While working on WWW::Ohloh::API, I caught myself wondering how one could use Ohloh for some kind of game. A few bus trips later with no book to keep my mind out of trouble, I came up with the variant of Monopoly given below. I'm recording it here to get it out of my system. Maybe one day, when I'll have time (ah!), I'll implement it. It'd be worth it just for the fun of collecting famous hackers like Pokémons. :-)


  • Every player start with a given amount of "money" (or moohlah).
  • Developers can be bought for a price inversely proportional to their Ohloh rank. A developer can only be owned by a single player at any given time.
  • A player can sell one of his developers at market price at any time. The player can also sell a developer directly to another player for any agreed price between them. Or he can auction the developer in an open auction to the rest of the players.
  • Any time a developer receives a kudo, the player owning him or her gets a dividend proportional to the rank of the kudo giver.
  • If a player possesses all developers of a project, they "own" that project.
  • Each turn, each player gets to "use" a random project picked from the set of all projects owned by a player, and must pay a fee proportional to the review score and number of users of that project. If the player doesn't have enough moohlah to pay up, one his or her developer is picked at random and sold at market value until the player becomes solvent again. If the player ends up without moohlah or hackers, he or she goes under.
Saturday July 19, 2008
08:31 PM

Object::InsideOut Cheatsheet

Everybody is raving about Moose these days, but I must say that I still prefer Object::InsideOut. One of the things I love about OIO is its extensive documentation (70 glorious pages worth of pod!). One of things that I find daunting about it is, well, finding back the attribute I'm looking for as I thumb through those seventy-something blasted pages.

So I made myself a cheatsheet. It's not complete yet, but it's already containing what most mortals would use on a daily basis.

(btw, I've used Scribus to generate the 3-fold. Although I really, really want to like that software, I must say that it makes me miss Quark XPress real bad. If anyone has any suggestion for an alternative Desktop Publishing tool, please feel free to let me know.)