the great renaming: Dist::Zilla::Plugin::CriticTests

oops! kentnl did it again. :-)

this time, dist::zilla::plugin::critictests has been renamed to dist::zilla::plugin::test::perl::critic. once again, change will be trivial for authors [0]. previous module will continue working, for at least one year counting from today.

github repository has also changed and is available here: https://github.com/jquelin/dist-zilla-plugin-test-perl-critic

[0] and this time, i did not fubar-ed the code! :-|

the great renaming: Dist::Zilla::Plugin::CompileTests

in a move to rationalize the plugin namespace of dist::zilla, kentnl started a  great renaming: dzp:compiletests has been renamed to dzp:test::compile

previous module is deprecated, and may be removed later on (but not before one year, that is 2012-08-27). in the meantime, it will continue working (although with a warning).

what does it mean for dzil users? well, nothing much, since old module will continue working as is. however, they should better migrate their dist.ini from:

[CompileTests]

to:

[Test::Compile]

nothing else is needed... for now, since i guess kentnl will continue proposing patches / pullreqs to dzil:*tests plugin authors! ;-)

also, please note that the github repository has been renamed and is now available at a different url. ditto for cpan, since the dist is now named dist-zilla-plugin-test-compile.

github power

i started using github somewhere in 2009 iirc. i was a bit reluctant to use it back at that time, especially because of its speed (or lack of, actually)... and because i already hosted my projects of repo.or.cz.

however, i'm now really glad i started using it. speed is no longer a problem, and it provides really nice features. cia integration, network graphs, comments on commits, watching repos (even if i'm not totally happy with it right now), and of course... pull requests!

i was away this week-end, and found 4 pull requests in my mailbox for my modules when i came back. integrating other's work has never been easier with git and github which allows people to fork at will. that's the new way of writing code: create the basic stub of your module, and wait for others to enhance it! :-) git plugin for dist-zilla now supports pushing to a different branch, supports the new dist-zilla-tester framework and the bundle @git now accepts multi-valued args.

dvcs are a bit harder to grasp at first, but once you understand the concepts, they're really a killer application - especially when coupled with a cooperative platform such as github.

activity in git plugin for dist-zilla

it's been a busy week for dist-zilla-plugin-git...

first, there was some test fixes to work with latest dist-zilla (thanks to ricardo), and also to support git 1.7.

the git plugin then saw support for annotated tags which is now the default - but christopher madsen restored the possibility to use lightweight tags. he then refactored commit message generation, in order to allow a custom commit message. not only that, but he also brought to ability to specify which files are allowed to be dirty, and automatically committed.

then david golden jumped in, and scratched his itches: support for empty lines in changelog and possibility to specify which branch(es!) to push to. all of that with new tests - and some existing test fixes! \o/

git support in dist-zilla is now in a pretty good shape. report bugs if you miss your pet-peeve... or even better: fork the code and send me pull requests once the code is doing what you want!

retrospective 2009

2009's over, but the year was quite a busy one for me on the perl front:

• i finally took the time to investigate moose, and decided to port some of my code to use it.
• i discovered dist::zilla, and definitely plan to use it in all my dists.
• i discovered some other cool new perl modules (thanks guys).
  
• i uploaded some new dists on cpan, including games::pandemic (which i'm quite proud of, even if i need to continue hacking on it).
• i updated & released some of my existing dists.
  
• i contributed to other projects such as padre, dist-zilla, etc. sending patches is a good way to thank the author for their work.
• it's even easier to contribute with github, which i'm using more and more for my projects (and it's no more slow by now, woohoo!). of course, git is the master piece allowing this easy sharing.
  
• on mandriva's front, i resurrected parrot rpm, and finally shipped rakudo.
  
• 2009 was also the year of the great migration to %perl_convert_version
• ... with lots of new perl modules available as rpm (i am managing 450 of them).
  
• ... and finally i took ownership of perl rpm. (thank you perl5 porters btw for 5.10.1 and the push for next stable version!)

so, busy indeed 2009 was... i just hope that 2010 will be as fruitful on the perl front for me, and for the perl ecosystem by large.

announcing git plugin for dist-zilla

pushing lazyness even further, i released a git plugin for dist-zilla. in fact, there are 4 plugins within the distribution. they are kicking in during dzil release, since i've hacked dzil to provide beforerelease and afterrelease roles.

dzp:git:check - this plugin checks that git is in a clean state before releasing. the following checks are performed before releasing:

• there should be no files in the index (staged copy)
• there should be no untracked files in the working copy
• the working copy should be clean. the changelog and dist.ini can be modified locally, though.

if those conditions are not met, the plugin will die, and the release will thus be aborted. this lets you fix the problems before continuing.

dzp:git:commit - once the release is done, this plugin will commit in git if needed changelog and dist.ini (which is a valid target if you happen to set the version manually in it). the commit message will be taken from the changelog for this release.

dzp:git:tag - once the release is done, this plugin will record this fact in git by creating a tag named v$VERSION.

dzp:git:push - once the release is done, this plugin will push current git branch to remote end, with the associated tags.

if you want to use all those neat plugins, you may want to use the git plugin bundle by writing in your dist.ini:

[@Git]

there, one more thing that dzil is doing for me... no more time lost doing those tedious steps - if you're lazy, you should really try it! as usual, comments and feature requests are welcome.

autoformat and nopaste plugins join padre's nest

after much hesitation, i finally decided to migrate the autoformat and nopaste plugins to padre's svn repository.

not that i prefer svn - after all, i used git for a reason when i started those plugins - but it's handy to benefit of padre's translators for my plugins for free... (btw, if your language is not supported, you're more than welcome to join padre's development team!)

but the nice thing is that gabor told me that if padre gets a good enough git plugin for padre, he will switch padre's repository to git!

good enough here means that even people unfamiliar with git can use it, whatever the platform (yup, windows, i'm staring at you)... and btw, do you remember that there's an on-going contest for best padre plugin?

so what are you waiting for?

polyglot: introducing our test environment

reminder: this article is part of a serie.

before we start, we need to set up a working environment. this environment should provide us with two things:

• a version control mechanism
• a test environment with some non-regression tests

the version control is needed to be sure that we get some points where we can go back in time. since we're going to mess our program quite hard, we'll be happy to check out a version that was working at a given time, and start messing in another direction.

the easiest way to go is of course to go with git. the following simple steps will create a git repository, and start tracking our polyglot program:

$ git init
$ vi fibonacci.txt
[fill in the perl program mentioned in the introduction]
$ git add fibonacci.txt
$ git ci -m 'first language: perl'

note: for easier reference, i will publish the changes to an online git repository. of course, i will only push the parts needed for a given blog entry, so don't expect to see all commits supporting all languages! :-)

that being done, we'll now create a test suite to make sure that our modifications won't break the languages that were previously working.

perl is well-known for its test automation. it has a strong history in regression testing: perl itself comes with over 200.000 internal tests, and the various distributions available on cpan almost all come each with a comprehensive test suite. i'll therefore use the standard test modules to come up with the polyglot test suite.

the simplest way to build our test suite is to use prove. each covered language will have a test file, emitting some tap. prove will harness those test files and report their status. each test will do, in order:

1. create a clean directory where the test will take place
2. copy the program in this directory. since some languages are picky on the extension, the destination will have a file extension matching the language.
3. run the appropriate command, capturing stdout / stderr
4. compare the output with what was expected
5. remove the test directory

since we're lazy, this will be in a module that will export a single function fibo_check() doing everything mentioned above. the complete module, located in a lib directory, will look like:

                                                                                           
package FiboTest;                                                              

use File::Copy;
use File::Path qw{ mkpath rmtree };
use FindBin    qw{ $Bin };
use Test::More tests => 1;

use parent qw{ Exporter };
our @EXPORT = qw{ fibo_check };

# fibo_check( $lang, $ext, $cmd )
sub fibo_check {
    my ($lang, $ext, $cmd) = @_;

    # clean room for the test
    my $dir = "$Bin/tmp/$lang";
    rmtree($dir);
    mkpath($dir);

    # get expected result
    my $want = do { local $/; <DATA> };

    # run the test
    copy( "$Bin/../fibonacci.txt", "$dir/fibonacci.$ext");
    my $command = sprintf "cd $dir; $cmd 2>&1", "fibonacci.$ext";
    my $have = qx{ $command };

    is( $have, $want, "language $langtest");

    # clean after ourselve
    rmtree($dir) unless $ENV{POLYGLOT_DEBUG};
}

1;
__DATA__
1
1
2
3
5
8
13
21
34
55

this fibo_check() function really implements the steps described above. the only things worth noting are:

• the fact that we're storing the expected output in the data section of the module
• the last line, that will _not_ remove the test environment if the environment variable POLYGLOT_DEBUG is set.

with this helper module, each test (one language per file) in the t/ directory
is really dumbed-down, and will look like the following:

use strict;
use warnings;
use FiboTest;
fibo_check('perl', 'pl', "perl %s");

running the test suite is as simple as:

$ prove -l t
t/perl....ok
All tests successful.
Files=1, Tests=1,  0 wallclock secs ( 0.02 usr  0.00 sys +  0.03 cusr  0.00 csys =  0.05 CPU)
Result: PASS

running a single language test will be achieved with:

$ prove -l t/perl.t
t/perl....ok
All tests successful.
Files=1, Tests=1,  0 wallclock secs ( 0.02 usr  0.01 sys +  0.03 cusr  0.00 csys =  0.06 CPU)
Result: PASS

of course, let's not forget to commit this in git:

$ git add lib
$ git ci -m 'test helper module'
$ git add t
$ git ci -m 'test file for perl'

and for even better checkpoint, let's add a git tag, named after the implemented language:

$ git tag perl

our working environment is now ready, and we can now go wild - knowing that we have a safety belt and a control mechanism. let the fun begin!

how to shave 10% speed?

contributing to other projects is good (not counting the fact that it's fun):

• you help open-source as a whole
  
• you gain some knowledge on the projects you help
• ... and you discover some new stuff, techniques, tricks

so recently i've been helping the padre team, where i discovered the module class::xsaccessor. reading the pod, it seemed quite good, but the question was: is it really that interesting?

so, i decided to try that on language::befunge, which currently uses a mix of class::accessor::fast and hand-crafted accessors (man, some part of the code is untouched since 2002!). who recalls of using the following in his/her code:

BEGIN {
my @attrs = qw{ attr1 attr2 attr3 };
foreach my $attr ( @attrs ) {
    my $code = qq[ sub get_$attr { return \$_[0]->{$attr} } ];
    $code .= qq[ sub set_$attr { \$_[0]->{$attr} = \$_[1] } ];
    eval $code;
}
}

anyway, i created a new git branch in langage::befunge's repository, and ported all my classes to use class::xsaccessor. and then i've run both the module's test suite and mycology:

• current language::befunge: tests = 5.28s, mycology = 20.48s
• using class::xsaccessor: tests = 5.12s, mycology = 18.18s
  

(everything ran once to warm cache, and then averaging three passes. all output directed to /dev/null in order not to pollute cpu measures with io)

that is, around 5% saved (a bit less) for the tests, but 10% (a bit more) for mycology. knowing that the tests are not representative of real befunge workload, this means a 10% speedup in befunge programs... neat!

needless to say that i merged this temp branch (ain't git cool?) to master, and language::befunge 4.09 is on its way to cpan!

conclusion: use class::xsaccessor, it fulfils its promises... and contribute to other projects, at least you'll find some ideas for your own projects!