good-bye mandriva, hello mageia!

word is spreading fast: mandriva developers & contributors are forking mandriva. the new distribution is named mageia - read the full announce on http://mageia.org. my name being on the announce, no need to say that i fully support this move... :-) more news will be available in the coming days.

supply your own perlcriticrc to dzil test plugin

if you wanted the ability to supply your own perlcriticrc while using dist-zilla-plugin-critictests, then stephen scaffidi is your hero of the day. indeed, he just implemented this - and i had to do the tedious work of typing "dzil release". oh well, i can say that life is difficult. :-)

perl's state in mandriva cooker

some time after mandriva 2010.1 has been released, i'm now pleased to report that perl has been updated to 5.12.1, all cpan modules are up-to-date (including padre 0.68) or bugs have been reported upstream... and parrot 2.6.0 is currently building.

the perl 5.12.0 - 5.12.1 upgrade was really smooth: no patch to rediff, reapply, etc. that's definitely a good thing for perl maintainers to have a stable series with only critical fixes going in. i've already said it, but thanks again to p5p!

announcing file::sharedir::pathclass

following last week's announce of file::homedir::pathclas, i also committed file::sharedir::pathclass on the same principle. therefore, if you always wrap file::sharedir results in path::class objects for greater convenience, just use file::sharedir::pathclass instead, which is doing that automatically for you.

random file-homedir bits

no need to present file::homedir, the module to use to retrieve various information such as where is my home, where is my desktop, where are my documents, etc.

since my needs were not all covered, i contacted alias with some of my ideas. he kindly gave me a commit bit so i can scratch my itches at will...

i therefore implemented xdg support for recent unix desktops, with daxim's help. this means that unix platforms with gnome, kde or any recent desktops won't report $HOME as the one and unique answer to all those questions. this feature is available in released file-homedir 0.91 - towards a cleaning of our homedirs, yay!

still in the work (not yet released), i've also checked in a my_dist_data($dist) function, to standardize the directory where the application will store its internal data, such as database or cache. it is located in:

my_data()/Perl/dist/$dist

following the now traditional data/vendor/application scheme (on legacy unix desktops, the directory will be $HOME/.perl/dist/$dist/var, to be sure that it's a hidden directory). to be consistent with file::sharedir, i guess i'll also implement my_module_data($module), following the same reasoning.

this will likely be released in version 0.92, before working on the last remaining bit on my plate: my_dist_config($dist), returning a directory where an application will be able to store its configuration. it's a bit different of the data directory (even if config is some kind of data): data is supposed to be transient, or can be removed without harming the app - while the config should not be erased. however, it's not really as straightforward as the data directory, since not all platforms support this: on windows, users are not supposed to update config by hand, so it's often stored in the registry... so how to preserve the cross-distribution nature of file-homedir for this very feature? this will require some thinking...

finally, it's with great pleasure that i'm announcing file-homedir-pathclass, which is a convenient wrapper around file-homedir returning path::class objects. alias did not want to introduce it in file-homedir to preserve compatibility, and suggested to release it as a new dist... so i released this new module, allowing to write for example:

perl -MFile::HomeDir::PathClass=-all -E 'say $_ for my_home()->children'

how to retrieve image size in perl

today's topic is quite easy: retrieving image size (in perl, with the help of cpan of course). indeed, when one wants to resize an image, it's often interesting to know its current size.

the easiest way to retrieve those information is of course to use image::size:

easy, wasn't it?

however, as mentioned previously, retrieving those information is often just the prelude before doing some transformation to the image itself. and image::size, while doing it perfectly, does only one thing - it cannot be used for any other image manipulation. so if you intend to use another module after, you can as well use this other module to retrieve this information: that'll be faster (image read only once) and use less memory (only one module loaded). here's how to get those information with image::magick:

it wasn't that difficult, and opens the whole image magick world to your program!

further prisk enhancements

imagine a world map. now show me on the map where china is - easy, uh? where is irkustk? tougher, isn't it? but it remains a region which exists in our world... now imagine we have another map in front of us... a map named godstorm for example... where is thule? or poseidonis?

those questions aren't rethorical, when playing prisk. because, when you exchange 3 cards to get reinforcements, you also get bonuses if you exchange a card representing a country that you own. and if it's easy to check at a glance if you own china when playing classical risk map, it's another challenge to locate thule on godstorm map.

therefore, i'm glad to introduce latest prisk version (3.101510, currently on its way to cpan). in the card window, one can now double-click a card, and this will highlight a country on the big map. this way, you'll know exactly which card to exchange (or what country to invade) in order to maximize your reinforcements. happy invasion!

(remember that i'm always welcoming code contribution or new translations)

new continent window for prisk

some further enhancements to prisk: latest version got a brand new continent window, listing the continents, their bonus, and who owns the countries. it also highlights when a continent is totally owned by a player. it is also updated during the game, when players gain and loose countries.

without further ado, here's a snapshot of the new shiny feature:

also new in version 3.101430, the ability to run prisk directly from the checkout. previously one would need to run "dzil run ./bin/prisk" since file::sharedir requires a fully built + installed distribution before finding its stuff. now, prisk detects if it's running in a local checkout, and will bypass file::sharedir.

the code is on github where you can fork it: patches and translations welcome!

mst lost his ironman status

as said on his blog, mst lost the ironman competition. i wonder how many of the early joiners still retained their ironman status. i still should be in the competition (although really hard at some times), even if there's no way to tell since the ironman app isn't updated since quite some time.

anyway, i get to cast my vote. i don't really care the hair colour, but the talk bit is more interesting. before you guys start submitting ideas such as why php/ruby/python is far better than perl, remember that:

1. mst started the challenge to help perl get known. finishing by forcing him to praise another language seems to be against the rules. not even speaking of this not being very classy...
   
2. the talk will be heavily advertised (at least in the perl community). are you sure you want to offer such a gallery for another language?
   

so i'll cast my vote on a what i will do to advertise perl even more this year talk - hoping this will motivate mst to start another initiative to help promote perl^[0]. i'm open to any other talk subject in the same vein. and i'm ready to trade my colour voting^[1] for you to vote for such a topic. :-)

so here's my vote, mst!
in the meantime, this does not preclude you to continue blogging...

[0] of course, mst can game the talk by showing a single slide with "nothing" on it, but, that, again, would not be very classy. and mst would not settle on such an easy end, would he?
[1] for the pink or orange fans around there

games::risk speaks your language!

well, maybe not yet, but very soon - as soon as you'll contribute the translated strings! :-)

those days, i feel like working on prisk, the risk clone that i wrote in perl. i added full internationalization, and contributed the first foreign language (french, as you may have guessed :-) ).

you can contribute translations for your language by forking the project, and then sending a pull request with your changes. it should be quite fast, since it only features 73 strings to translate. you know what to do... :-)

note that i also fixed a crash that was appearing sometimes during game startup. i'll now try to find some time to work on bigger topics, such as sanitizing the whole codebase, or adding features...

is cpants down?

since some time, i did not manage to reach cpants... i don't seem to be the only one, so does anyone know what's going on?

perl status for mandriva 2010.1 (version freeze)

it's that time of the year: next mandriva version is due beginning of june, which means all updates are on hold - unless they solve a bug or any other problem worth fixing.

on the perl front, mandriva 2010.1 will therefore ship:

• perl 5.10.1 (5.12.x has been postponed to 2011.0)
• padre 0.60
  
• parrot 2.3.0 and rakudo 2010.03
• ... and 1912 dists from cpan!
  

as always, if you miss a perl module, just drop a note (in the comments, or a mail, or on mandriva bugzilla) and i'll package it for you.

roll your own dzil tutorial

rjbs created a roll-your-own dzil tutorial. this brings back memories, maybe there should be monsters in it. otoh, since it mentions module::install, maybe the monster quota is already met. :-)

anyway, the tutorial is a nice read for those wanting to learn dist-zilla. there are some glitches here and there (eg, it still mentions AllFiles plugin instead of GatherDir, and other v1 to v2 misses - i'll send patches), but is otherwise wicked cool.

and some of my plugins are even mentioned! :-)

no perl 5.12 in mandriva 2010.1

as announced previously, i did some further testing wrt perl 5.12.0 and mandriva. after having installed it, i've been able to use urpmi and compile various binary perl modules against 5.12.

however, decision has been taken not to push perl 5.12 in spring release. potential for havoc is too important - especially since it's used by many core tools. it'll have to wait after 2010.1 is out... but since all bits & pieces are ready to be pushed, it's now just a matter of time...

perl 5.12.0 in mandriva?

final perl 5.12.0 is now available. i updated our spec file in mandriva, and it builds ok both on my machine and mandriva's buildsystem - so i pushed it to main/testing. however, i did not manage to rebuild packages having a dep on perl, for an obscure reason having to do with testing media, bad karma or not enough chicken blood - i don't know exactly which reason is the good one.

i now need to have more thorough testing, in order to see if urpmi & other tools still works with new perl. i don't know if i'll have time before mandriva 2010.1 freeze date. not counting the fact that we'll have to create a c-wrapper to replace suidperl used in one of the draktools.

so, back to the question: perl 5.12.0 in mandriva? yep, "soon" - but maybe "soon" will mean "after 2010.1". note that if you can help testing, "soon" may revert to a true "soon" meaning...

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.

dzil activity

of course, you are aware that dzil v2 is out, with lots of exciting new features, brought to you by rjbs and the perl foundation.

but it's only one side of the activity floating around dist-zilla... indeed, as dagolden, aevar and others try dzil, they (of course) like it, and start contributing their own plugins.

here's a list of new plugins landed on cpan... first some additional author tests:

• CheckChangesTests - check changelog
  
• CheckExtraTests - runs xt/ tests, but don't copy them to t/
  
• DistManifestTests - check manifest
  
• HasVersionTests - check all your modules have a version
  
• KwaliteeTests - check your kwalitee
  
• MinimumVersionTests - check minimum perl version needed
  
• PodSpellingTests - check pod spelling
  
• PortabilityTests - check if your code is portable
  
• SynopsisTests - check if code in your synopsis compiles
  
• UnusedVarsTests - detects unused vars
  
• ReportVersions - additional test to report version
  

some plugins to complete meta-data:

• Bugtracker - http://rt.cpan.org/Public/Dist/Display.html?Name=xxxx
• HomePage - http://search.cpan.org/dist/xxxx
  

some plugins to customize your build process:

• ModuleBuild::Custom - for mb
• OverridableMakeMaker - for eumm

some plugins to generate additional files:

• FatPacker - creates a script with all dependencies packed
• InstallGuide - creates an INSTALL file
• ReadmeMarkdownFromPod - README.mkdn file

some plugins to compute your next version number:

• BumpVersionFromGit - version taken from last git tag
• VersionFromPrev - classic perl versions, 1.00 to 1.99

and finally some bundles:

• @AVAR - ævar arnfjörð bjarmason's take on it
  
• @MARCEL - marcel grünauer
• @PDONELAN - patrick donelan

you can install all of them in one go via task-dist-zilla.

they are also available in mandriva, and suggested when installing dist-zilla...

how to obsolete a cpan dist?

my autoprereq plugin for dist-zilla is now going core. however, it's currently existing as a dist of its own within cpan... since the module does not change name, what is needed to make sure rjbs can upload dzil v2 when it's ready? is giving co-maint rights on pause enough? will i have to remove previous tarballs?

the same kind of question can be asked for obsoleting a given module. there's (afaik) no way to tell cpan / cpanplus that foo::bar is replacing bar::foo... those problems are tackled for linux distribution packages, could we reuse some of their logic here?

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!

on testing

testing is good for your modules. even the ones you know work as intended. case in point: i wanted to refactor curses::toolkit::object::coordinates to use moose.however, refactoring such a core component of curses::toolkit without a test suite did not sound such a good idea...

therefore i wrote some tests for this module - and i discovered 2 bugs in this class. a small one that made an error message totally useless, and a serious one that affected the semantics of some methods.

so, not counting the fact that refactoring was quite easy once the test suite was in place, i also found some real bugs in the code. those tests were not very funny to write, but at least i know that the roi was very good! :-)

tk::action to simplify access to a gui action

in a typical graphical application, menu entries are often also available in toolbars or other widgets. and sometimes, you want to enable or disable a given action, and this means having to update all those entries and widgets everywhere this action is allowed / forbidden.

this is not fun.

therefore, i wrote tk::action, a module to help managing actions in a tk gui: just create a new object, associate some widgets and bindings with add_widget() / add_binding() and then de/activate the whole action at once with enable() or disable().

simple and efficient, as you can see on this synopsis:

a progressbar for curses-toolkit

curses::toolkit is the promising toolkit for writing curses applications with perl. it follows a gtk-like api, and supports theming. it is using poe for its event loop (although one can craft its own loop), and currently begins a loose moose conversion.

however, the set of widgets is currently a bit restricted: hbox, vbox, buttons, label, entries, windows... so, i wrote yesterday a progressbar widget. it's a bit difficult to understand at a glance where to put code, but i finally nailed a rough first version - it needs to be polished, though. once a listbox widget will be available, the toolkit will be sufficient for a lot of tasks.

lots of stuff remains to be done of course: moose-ification to get rid of its hand-crafted roles, building a real test suite (how the heck are we supposed to test a curses toolkit?), completing the widget set... volunteers welcome.

ironman challenge status?

ironman blogging challenge is now running since quite some time, but it seems that there's no followup. personal status is not updated since october 3rd, so i guess having some stats on the number of bloggers managing to keep up with the pace is not available either...

too bad, since mst managed to gather the perl community to make some noise on the web. maybe an update could promote a second life to perl blogging?

how to profile a perl program?

so, it seems that google isn't aware about perl profiling best practices... this blog post will thus try to link a lot of times to devel-nytprof, which is the solution to use to profile a perl program.

for profiling perl, just use devel::nytprof. it's an easy to use perl profiler:

$ perl -d:NYTProf my_prog.pl
[... let it run, it will be slower than your usual run ...]
$ nytprofhtml

when this is done, just point your brower to the locally created ./nytprof/index.html and enjoy the nice reports.

this is the best profiler for perl available currently. in case you missed the point: the perl profiler devel-nytprof is great, use it for your perl profiling needs.

which module to extract perl prereqs?

in dzil plugin autoprereq, i'm extracting prereqs from the dist modules. i want this extract to be fast, based on the actual code (not makefile.pl or meta.yml, since the goal is to generate them), and as accurate as possible. it should also find base classes, moose roles and other "hidden" dependencies. finally, it should extract the minimum version needed for a given module, including minimum perl version.

my first version was regex-based. i can already see your horrified face - but really it wasn't so bad, since it only needed to find some specific statements such as uses and requires. current version is using ppi, which is better suited for corner cases.

however, long-term makes me think that it would be better to rely on an external module. so, what are the alternatives out there on cpan, and can i use them in autoprereq?

• b::perlreq - parses the file, but reports file (File/Basename.pm) instead of modules, and is generally more suited for rpm
  
• module::extract::use - using ppi to parse a file, but extracts only use & require statements (no inheritance, moose roles, etc). also, it reports no minimum version extraction, only a list of modules.
  
• test::dependencies - using either b::perlreq (see above) or a regex scheme underneath
  
• module::scandeps - runs the file (which is slow), and finds all modules included - and sometimes a bit more (eg: file::homeDir::darwin is found for a module using file::homedir, even on a unix platform). can also run as a static analyser, but calls cpanplus (?!) which is slow.
  
• module::info - regex based
  
• module::cpants::generator::prereq - parses makefile.pl, where i want sthg that parses actual code
  
• module::cpants::kwalitee::prereq - parse meta.yml, makefile.pl or build.pl

so, no module was doing exactly what i wanted... since i am using ppi and that module::extract::use does the same, i contacted brian d foy to see whether he would be interested in additional extractions (moose roles, base classes, etc.) for this module. he was, so those enhancements are now pushed on my github clone.

i'm now waiting for a new release of this module with my enhancements, meaning that i can get rid of this part of the code in dzil autoprereq. which was, if you recall, the original goal! :-)

stats about cpan modules shipped by mandriva

adam and gabor asked me about some information on what cpan modules are shipped as rpm packages by mandriva... i finally found some time to work on it and produced ordb::cpan::mandriva.

this module is basically a sqlite database replicated automatically by orlite::mirror. using it is very simple - for example, couting the cpan dists shipped by mandriva is achieved by the following snippet:

(fyi, the result is 1899 as of writing, +1 since i just imported the module itself)

at module use time, it will automatically download (and cache for a week) the sqlite database. and one can then use the module as an ordb for this db... the module does not however produces the stats for you - so alias & gabor, now is your turn to work! :-) i'm waiting for your top-100 most wanted mandriva or whatever crazy stats you'll want to produce.

the database itself is generated by module::packaged::generator. this module uses different drivers depending on the current linux distribution (but nothing prevents *bsd to also have a driver) it runs on. only mandriva is supported currently, but ryan will work on a debian driver. all other contributions are most welcome - the code is on github: fork it and send me pull requests!

next padre version will (finally) recognize dist-zilla projects

padre 0.55, due tomorrow, will finally recognize dist-zilla projects correctly. among other things, it means that it will set @INC accordingly for syntax checking, keep the directory browser at the project root, etc.

it took a bit of time since the "installer" detection is spread out in different places in padre... this needs refactoring, for those interested.

some dzil goodness coming

i scratched some itches in dist-zilla, and hopefully the result will be useful to you too... some are rather trivial, while some are more feature-ful.

on the it-s-the-details-that-count front, dzil clean will now remove *~ files lingering in your local copy.

dzil command now accepts a -I argument that adds a directory to perl @INC (same as perl's -I option). which means dzil plugin author can now do:

$ dzil -Ilib release

and release their distribution using the latest version of their plugin...

a new run subcommand has been added, which is doing more or less the following:

$ dzil build
$ rsync -avp My-Project-version/ .build/
$ cd .build
$ perl Makefile.PL     # or perl Build.PL
$ make                 # or ./Build     
$ export PERL5LIB=$PWD/blib/lib:$PWD/blib/arch
$ launch command defined by rest of your args

which means you can now do:

$ dzil run ./bin/myscript
$ dzil run prove -l t/unit.t
$ dzil run bash

the first one is specially useful if you're using file::sharedir and don't want to add extra hooks detecting whether it runs in a dev checkout or not.

speaking of sharedir, i crafted a quick'n'dirty implementation that made modulebuild plugin automatically install an existing share directory (which is possible since module::build 0.36). rjbs then re-factored it to use the installdirs plugin. nperez then finalized the work for the makemaker plugin. so if you have a share directory, it will now be automatically recognized as such by dzil and installed accordingly.

rjbs just released a new version of dist-zilla with those enhancements (and other stuff).

cpan task for dist-zilla

dist-zilla has a lot of prereqs. and even when you have installed it, you may need to install other plugins manually. therefore, i just uploaded task::dist::zilla that pulls in all dzil plugins and plugin bundles.

it still takes time to install all those modules, but at least you can do it in one go with cpan or cpanplus: no need to install them one by one manually.

of course, if you're on mandriva, running:

urpmi perl-Dist-Zilla

will install the package perl-Dist-Zilla and all its deps while also suggesting to install all the dzil plugins...

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.