All the Perl that's Practical to Extract and Report
use Perl Log In
Yanick (3196)
Breaking off from the use.perl.org 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!
Ruhr.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 Ruhr.pm.
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: Ruhr.pm 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 use.perl.org blog entry and forwarded the information to Ruhr.pm, 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!
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.
Variation on the Faces of CPAN
Faces of CPAN + GD::Image + blissfully idle holiday morning = this.
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 rt.cpan.org. 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.
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;
}
1;
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("found tarball: $tarball");
$self->diag("uploading tarball '$tarball' to CPAN");
my ( $id, $password ) =
map { $self->distrel->config->{pause}{$_} } qw/ id password/;
$self->diag("using user '$id'");
my $args = { user => $id, password => $password };
unless ( $self->distrel->pretend ) {
CPAN::Uploader->upload_file( $tarball, $args );
}
}
1;
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:
pause:
id: yanick
password: hush
checks:
- VCS::WorkingDirClean
- Manifest
actions:
- 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 "git add <file>..." to update what will be committed)
#
# modified: Build.PL
# modified: Changes
# modified: README
# modified: distrelease.yml
# modified: lib/Dist/Release/Check/Manifest.pm
# modified: script/distrelease
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# STDOUT
# a
# blog
# xml
# xt/dependencies.t
# xxx
no changes added to commit (use "git add" and/or "git commit -a")
Manifest [failed]
No such file: lib/Dist/Release/Action/DoSomething.pm
Not in MANIFEST: a
Not in MANIFEST: blog
Not in MANIFEST: lib/Dist/Release/Action/Github.pm
Not in MANIFEST: STDOUT
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.
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.
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.
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.
Rules
- 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.
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.)
help them think they understand.
--Larry Wall
