Jerome Quelin

audio::mpd gained ipv6 support

2011-11-24T15:17:00.001+01:00

when i got a bug report asking for ipv6 support in audio::mpd, i didn't know where to start, and put it aside... but since i fixed quite a few test bugs in audio-mpd, i thought i could give a try at supporting ipv6.

and it proved quite easy in fact, with io::socket::ip which is a drop-in replacement for io::socket::inet... and thus, by changing 3 strings in audio-mpd, it is now ipv6 enabled - neat!

so, enable ipv6 on your software with the following one-liner:

$ ack -l 'IO::Socket::INET' | xargs perl -pi -E 's/IO::Socket::INET/IO::Socket::IP/g'

easy, uh? who said ipv6 was difficult? :-)

prisk gains its own map format, allowing translations!

2011-09-16T18:04:00.001+02:00

till now, games::risk was using map files from jrisk. this allowed me to concentrate on the gui and the game experience without having to tackle everything at once.

being a simple format, it was somehow easy to read the maps... but its simplicity has some drawbacks, and for example it's not possible to translate them. therefore, i finally bit the bullet and implemented a format for prisk. basically, information remains the same (such as the mechanism to determine the current country), with one exception: maps are implemented as perl modules. and this allows the use of gettext and other i18n schemes.

this means that maps are now translatable! french translation is of course provided, but help is needed for other languages... (hint, hint)

of course, i wrote an importer to migrate jrisk maps to new prisk format. i also intend to take this opportunity to create some new perl dists with extra maps.

this prisk release shows also a lot of cleanup in the internals, with a partial migration to moose and moosex::poe. using weak_ref for scalar attributes and a tied hash::noref to cache objects allowed to use circular references without having to deal with their problems. finally, prisk is now deferring some module loading to runtime, leading to a faster startup. the changes are plenty, so now is a good time to give it a try! (after v3.112590 has hit your nearest mirror of course)

future releases will continue to see code cleanups and migration to moose. prisk also finally has a configuration system to save user preferences - i "just" need to use this system throughout the code. some dialogs needs also to migrate to prisk's look&feel (thanks tk::role::dialog), and i have some ideas to improve the artificial intelligences & better use poe. not counting other game modes to take into account... oh well, let's say that prisk will keep me busy quite some time! :-)

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

2011-08-29T14:05:00.000+02:00

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

2011-08-27T12:07:00.001+02:00

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.

cpan2pkg: prettier gui, ready for mageia!

2011-06-27T15:01:00.000+02:00

remember cpan2pkg? this is the tool built around cpan2dist to create a native linux package, taking dependencies into account, and integrated with linux distribution repository + buildsystem.

it used to be mandriva only, and curses-based. now that mageia is in full swing mode, i had to port cpan2pkg to support it. and it was a perfect opportunity to clean up the module, and prettify the interface.

here's the result:

on the left, you can see the modules currently being processed, with their status both locally and on the build-system. green means available, and here you can see that moosex::alwayscoerece is being built locally (orange) and is not yet available on mageia (yellow).

note that mageia is fully supported: cpan2pkg will poll the buildsystem status page to follow a module build, and make sure a module is ready before submitting those depending on it.

it is still using poe underneath, but this time with tk. adding support for a platform can be done quite easily - patches welcome!

"magpie fix" also tigthens spec files

2011-06-21T17:22:00.000+02:00

following cpanplus backend cleaning, "magpie fixspec" also gained the ability to clean up spec files with trivial %clean section and %defattr definition.

this means that updating a perl package on mageia (with either "magpie up" or "magpie dwim") will also trim the rpm spec file accordingly. neat!

more tightened spec file produced by mageia cpanplus backend

2011-06-21T16:35:00.000+02:00

cpanplus::dist::mageia 1.111720 has just been released, with 2 changes:

no more %defattr definition
no more default %clean section

indeed, rpm will handle those automatically, as dexter mentioned (cf here and here). this way, we'll have spec files a bit more tightened, which is always better from a maintainer pov.

keep track of your tk widgets easily

2011-04-15T10:20:00.000+02:00

when writing a tk application, it's almost always a good idea to keep track of your widgets: this allows to change their state later on.

most of the time, a simple hash is enough; but it is usually wrapped up in methods to make the hash private to the window object. and of course, those methods are duplicated in all modules, under a form or another...

since duplication is bad, i just released Tk::Role::HasWidgets which is a moose role, and provides with a convenient way to store & retrieve your widgets:

use Moose;
    with 'Tk::Role::HasWidgets';

    # when creating a widget
    $self->_set_w( 'my_button', $button );

    # later on, in one of the methods
    $self->_w( 'my_button' )->configure( ... );

the methods featured in this role begin with "_", that is, they are following perl convention of private methods. this is on purpose: remember that this module is a role, consumed by your class. and you don't want those methods to be available outside of the window class, do you?

a bit of dwimery in magpie

2011-04-12T14:48:00.000+02:00

all the pieces were available, binding them together was just a smop. therefore magpie just got a new subcommand: "magpie dwim" which does exactly what i mean...

in the case of magpie, what i mean is of course:

check which perl packages are not up to date wrt cpan
check them out
tighten spec file
update the package to latest version
commit result
wait for build system if needed
submit result

and all of this is done in parallel, with errors reported at the end.
you too can have some fun:

$ sudo urpmi magpie
$ magpie dwim

maintaining the ~2500 perl module rpm packages in mageia has never been so easy!

magpie: how to list non up-to-date perl modules

2011-03-09T13:17:00.000+01:00

the final stone is now built for magpie: it's possible to list on your mageia system the perl modules that have up to date versions upstream. it allows to see at a glance which perl packages need to be updated. it's based on cpanplus, and only tackles perl modules installed on your system.

the new command is:

$ magpie old
** core packages: 11

Devel::DProf                             20080331.00 20110228.00
Devel::SelfStubber                              1.03        1.05
[...]
if                                              0.05      0.0601

** normal packages: 57

DateTime::TimeZone                              1.28        1.29     perl-DateTime-TimeZone                                 1.280.0
Digest::SHA                                     5.50        5.60     perl-Digest-SHA                                        5.500.0
[...]
parent                                         0.224       0.225     perl-parent                                            0.224.0

** orphan packages: 7

KENTNL                                      0.010173Dist::Zilla…
[...]
inc::latest                                   0.3624        0.38

** strange packages: 3

App::cpanminus                                1.2001      1.4002     cpanminus(1.200.100),perl-App-cpanminus(1.200.100)
HTTP::Response                                  6.00        6.01     perl-libwww-perl(5.837.0),perl-Test-Mock-LWP(0.50.0),perl-HTTP-Message(6.0.0)
Perl::MinimumVersion                            1.27        1.28     perl-Perl-MinimumVersion(1.270.0),perl-Perl-Critic-Pulp(47.0.0)

** ignored modules: 12

Boulder::Unigene(28051999.00), File::MimeInfo::Rox(0.20), Getopt::Lucid(0.19), HTML::Table(2.08), Imager::Font::Type1(1.011), Inline::Python(0.38), Lingua::Features(0.30), Parse::RecDescent::FAQ::Original(6.00), Switch(2.16), Tie::Watch(1.301), WebFetch(0.13), XML::Grove(0.46)

the columns are: module, old version, new version, mageia package name, mageia package version.

as you can see, the modules are sorted in various categories:

core - modules shipped with perl (or perl-base)
dual-lifed (not shown above) - modules that are both shipped with perl (or perl-base) and as a stand-alone package
normal - regular modules with their own package
orphan - modules that do not belong to a mageia package (either inherited from mandriva, or not yet pushed on buildsystem).
strange - modules that belong to more than one magiea package
ignore - those are modules that either cannot be built (with an upstream bug) or that confuse cpanplus when comparing versions

with this information, it's therefore very straightforward to update the packages, launching the following command as needed:

$ eval $( magpie co -s $pkg ) && magpie update

of course, since all the building blocks are now available, that's what the last command to be implemented (magpie dwim) will do!

svk cannot be built anymore - EDIT: svk will build with reduced features

2011-02-28T12:44:00.001+01:00

while rebuilding perl packages for mageia, i found out that svn::mirror cannot be built anymore with subversion 1.6.x. said like this, one may think "wtf, i don't give a damn to svn::mirror". and lots of other cpan modules are bit-rotting, so what's the point? well, the thing is, svn::mirror is a prereq for svk, the decentralized subversion...

granted, svk has been end-of-lifed in 2009, yet it's still widely in use. but as long as svn-mirror won't get fixed, mageia won't include svk support.

EDIT (20110301): in fact, svn::mirror is an optional prereq for svk - mageia will therefore ship with svk, albeit with a reduced feature set

magpie update now waaaaaaay faster!

2011-02-25T16:02:00.000+01:00

"magpie update", used to update automatically a perl module rpm to its latest version, was a bit slow. the culprit was parse::cpan::packages, taking a whole 10 seconds to parse 02packages.details.txt.gz

fortunately, i found parse::cpan::packages::fast (from slaven++), which does exactly the same job in less than a second...

so, with a 16-line patch (-2/+2), magpie update now is almost instant. cpan is definitely the home of nice gems, and *the* advantage of perl.

new magpie command: update

2011-02-10T14:46:00.000+01:00

i'm happy to report yet another magpie release, version 1.110410

this release brings a new subcommand: update (aka refresh)

it will automatically update a perl module package being checked out to the latest version, update buildrequires (with fixspec), try to build it locally, commit if successful, wait according to build-system hints, then submit it.

it's easy to use:

$ eval $( magpie co -s perl-Foo-Bar )
$ magpie update -v

note: it requires a minicpan installation on your computer...

now, you too can join the fun of updating perl modules packages for mageia! but it's not yet over, automation will go one step further - stay tuned...

new magpie command: fixspec

2011-02-08T16:04:00.000+01:00

i just released magpie 1.110390, which brings a new subcommand: magpie fixspec

as you can guess, this command will try to sanitize a rpm spec file a bit. to use it, you must be in a package checkout, and run it without any argument.

$ eval $( magpie co perl-Foo-Bar )
$ magpie fixspec -v

# to see the list of options
$ magpie help fix

among the things that fixspec does:

it updates %doc depending on the existing files, including meta files
it splits multiple bundled build-/requires to have only one per line
it lines up vertically the summary / etc
it extracts perl buildrequires from meta.json/meta.yml if present
it removes buildroot definition
it removes mdv macros

note that the code is not really clean, it might gain from being in its
own module, with real rpm parsing instead of big regexes. also, it
assumes that we're cleaning a perl module spec file, so you're on your
own if you're using it on other spec file: it might remove the whole
svn, eat your babies, or even convert your rpm database to rpm5. you've
been warned. :-)

new dist::zilla command: pot

2011-02-03T11:26:00.000+01:00

i just released dist::zilla::app::command::pot, providing dist::zilla with a new pot command (not the plant, you hippy!).

this command allows to (re-)generate a messages.pot file holding all strings to be translated from your module. If a messages.pot file is found, it will update it. otherwise, you will be prompted for a file location, with a default matching Locale::TextDomain settings:

$dzil pot
[...]
[DZ] Trying to find a messages.pot file...
[DZ] No messages.pot found - enter your own.
messages.pot to use [lib/LocaleData/Foo-Bar-messages.pot]:
[DZ] Running xgettext...

yup, underneath it just runs xgettext. and currently, it only finds calls to T() - but i'll add an option to provide your own convention such as _(), gettext(), etc.

magpie - MAGeia Perl Integration Easy

2011-02-01T12:17:00.000+01:00

in my mandriva to mageia switch, i promised to myself that i'd collect the various scripts that i'm using on a day to day basis to maintain the myriad of perl rpm packages.

therefore, i've created magpie (MAGeia Perl Integration Easy) and uploaded it to cpan. the tool is not yet complete, but i'm incorporating new commands now and then.

it currently supports 2 commands:

magpie bswait - this command pauses according to the recommendation of mageia build-system. it indeed provides some recommendation on how much time to pause between 2 packages submission to not overload it - (this is known as throttling).
magpie co - this brand new command (in version 1.110320) allows to check-out a given package from mageia repository.

some details about magpie checkout: it is not meant to replace "mgarepo co", it does in fact use mgarepo underneath. so what does this command add?

the possibility to check out in a given directory
$ magpie co -d ~/rpm/cauldron perl
the fact that it will either check out *or* update the local check-out if it already exists:
$ magpie co -d ~/rpm/cauldron perl
# check-out if 1st run, update otherwise
finally, the possibility to dump a shell command to execute to change directory in the fresh check-out:
# add this in your ~/.bashrc
function cco() { eval $(magpie co -d ~/rpm/cauldron -q -s $*); }
# then, one can do a fresh checkout/update + cd by issuing:
$ cco perl

nothing revolutionary, but it saves some keystrokes here and there.

mageia warming up - rebuilding perl packages

2011-01-25T11:44:00.000+01:00

it's been a long time without posting - but real life kicked in.

one of the things that keep me busy those days is the rebuilding of perl packages for mageia. around 2000 have been done, with ~400 still waiting. it's been a good opportunity to clean up the mess: remove old packages, clean spec files, etc.

all in all, mageia will be quite in a good shape regarding perl packages when mirroring will start - which should happen quite soon!

good-bye mandriva, hello mageia!

2010-09-18T18:07:00.002+02:00

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

2010-08-13T19:12:00.001+02:00

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

2010-07-29T10:28:00.000+02:00

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

2010-06-16T13:56:00.000+02:00

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

2010-06-11T12:44:00.000+02:00

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

2010-06-08T10:53:00.005+02:00

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

2010-05-31T17:49:00.003+02:00

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

2010-05-24T16:15:00.003+02:00

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

2010-05-19T09:35:00.003+02:00

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:

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...
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!

2010-05-17T20:01:00.002+02:00

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?

2010-05-13T17:14:00.001+02:00

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)

2010-05-05T19:08:00.004+02:00

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

2010-04-28T18:57:00.004+02:00

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

2010-04-20T15:44:00.004+02:00

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?

2010-04-16T19:16:00.002+02:00

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

2010-04-07T13:52:00.005+02:00

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

2010-03-31T17:01:00.003+02:00

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?

2010-03-23T17:48:00.003+01:00

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

2010-03-15T17:32:00.004+01:00

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

2010-03-09T17:57:00.002+01:00

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

2010-03-03T13:22:00.004+01:00

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

2010-02-24T10:01:00.004+01:00

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?

2010-02-18T16:28:00.003+01:00

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?

2010-02-09T16:31:00.003+01:00

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?

2010-02-03T11:09:00.001+01:00

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

2010-01-27T10:07:00.005+01:00

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

2010-01-20T10:14:00.003+01:00

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

2010-01-13T10:02:00.004+01:00

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

2010-01-07T17:17:00.006+01:00

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

2010-01-04T17:34:00.003+01:00

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.

rt.cpan.org updated - thank you bestpractical

2009-12-31T11:16:00.002+01:00

so it seems that we got a nice present for christmas from bestpractical: rt.cpan.org has been updated to last version 3.8

thank you, and keep up the good work!

helping perl packagers package perl modules (for real this time)

2009-12-29T20:37:00.000+01:00

chromatic posted a long rant (who would have guessed? :-) ) about perl modules shipped by linux distributions. however, he doesn't have all the answers... nor the experience needed for this rant. since i'm a perl author and mandriva packager for perl and lots of perl modules, i think i have more enlightened information about this topic.

first, let me state that using system perl is fine, but i really discourage it for your enterprise application. the perl version will change from time to time, ditto for the perl modules you are relying upon. so if you want to be in control your software foundation for your app (and you should) - compile your perl and your modules yourself.

second thing: i also discourage mixing using perl modules installed by your package system and by running cpan as root. you'll end up with a mix of files in /usr/perl5 that either belong or not to a system package, which sucks. installing packages in a local lib of yours is fine, which is made quite easy with local::lib by now.

if you're comfortable with those rules, then you're welcome to using the system perl and the modules shipped by your distribution. after all, we packagers are going through this work in the hope of being useful to others - that is, you!

but back to chromatic post. if you want to install cpan modules as system packages, there's already a tool that does it for you: it's called cpan2dist, and is part of cpanplus. it works as long as a backend for your distribution exists. there's currently one for debian, mandriva (that i wrote), fedora and gentoo. it's not that difficult to write, and allows you to write:

# cpan2dist --format CPANPLUS::Dist::Mdv --install Foo::Bar

this will automatically download foo::bar, check its dependencies (and build & install them if needed recursively), build the module as a mandriva package and install it. what else exactly do you want/need? (as a cpanplus backend writer, i do have some things that i'd like cpan2dist to have, but none as a regular user). and if you're a packager and want to integrate cpan2dist with your linux distribution build system, cpan2pkg can help you (even if it's currently stalled due to sthg missing in cpanplus).

however, if you want to help perl packagers package your modules for a distribution, here's a list of thing that you should not do. this is a list of real, practical things to do as a module author - not some generic hand-waving towards the perl community out there. this comes from my experience as packager for mandriva of more than 400 modules, and makes me curse the module author everytime i'm encountering one of those problems...

test your dist before shipping. really, i'm not kidding. lots of dists just fail their tests. and not just on linux, on all the platforms. so if you make an update that "just can't fail" (yeah, right) to your dist just before shipping, please run your test suite nevertheless. just in case, you know, it might fail.

if you're shipping pod tests that are skipped depending on the presence of test::pod and test::pod::coverage, make sure you have those modules installed, so you are running those tests, too. even better: skip those tests unless RELEASE_TESTING or AUTHOR_TESTING is set. after all, it's nice for you to know you still have some documentation work to do, but i don't care as a packager... and, you know, it's now the standard & recommended way of shipping those tests.

those 2 items lead me to another easy thing for module authors to do to help us: check the cpantester status of your dist. investigate all the fails that you have. if you see a fail that is your fault, fix it and upload a new version. it helps us because this prevents us from having to report a bug against your dist. i generally wait 3 or 4 days before reporting a bug on a dist that has some failure reports, hoping (what a fool) that the author will notice by herself that sthg is going wrong.

speaking of bug reports, if we take the time to open a report for your dist (very often with a patch attached)... please read it. and act. or at least answer us. either apply the patch, or explain why you don't want to apply it like that... and ship a new version of your dist, with the fix included.

but of course, before reporting a bug, we should find the bug tracker. so, by using rt.cpan.org, you really help us to have a single unified point of contact. i know that rt is kind of slow, not very intuitive, has some problems and could be cleaned out a bit... but it is here, bestpractical is providing & administering it for us for free, and has this nice feature of having a queue for every perl dist on cpan. if you don't want to use it, there are some more polite ways of saying it... and giving the url of your tracker helps, too. oh, and if i took the pain to play by your rules and report a bug to your non-standard bug tracker, i would greatly appreciate that you act on my ticket. or at least, you know, just acknowledge the fact that you received the report.

if you want to really piss off a packager, a simple but effective way is to change your versioning scheme every now and then, by (ab-)using your knowledge of perl way of understanding versions. in the same major version, of course. going from version 1.470 to 1.50 is not funny. if you want to change your versioning scheme, you can change the major number to. after all, i'm pretty sure that you're not paying any extra money per major number used in your dist. this is what caused us to mangle the version of perl modules shipped in mandriva.

speaking of regular changes, it's irritating to have to follow you through your use of makefile.pl to build.pl to makefile.pl to build.pl to... well, you understand what i mean. even to use this shiny replacement that is module::build, or this oh-so-marvelous module::install, oh no finally module::build way of working fits me better in retrospective... it's ok for you to change from time to time, but changing at every version of your dist - just make up your mind dammit!

speaking of it, i hate module::install. and especially its feature that prompts and tries to handle the deps itself coz-it's-so-cool-it-can-do-it-for-real. sorry, but that's not your job in the tool chain. just report that you miss some deps. i know that there's a flag to make this feature go away while launching makefile.pl. but i don't want to bother and would rather expect that the whole stuff has sane defaults...

oh, and in case you're wondering - every prompting in the configure phase (makefile.pl or build.pl) sucks and should be banned.

having clear and up-to-date dependencies would be fine, too. i know it's not always easy to have them correctly, but you can change your tools and adopt one that extract your prereqs for you.

try to avoid dependency on modules that are known to fail. even if it works in your setup, trust cpantesters if they tell you that it fails 95% of its reports: it might not be a good idea to depend on it.

trying to support old perl versions and old releases of modules is fine, but update your modules and see if your code work. some functions may become deprecated, or you were relying on a buggy behaviour, or whatever. we update the perl packages as we see new versions, not only your modules. so a linux dist will usually have latest & greatest version of all the modules - you'd better be sure that your code work with them, hmm?

finally, if you're developping under macosx, make sure that you don't ship resource files, or textmate temp files. having ._Foo.pm in the dist is not fun: automatic compile tests will fail, unless that's your manicheck or signature check. and even if everything in perl dist is fine, things may bork in the repackaging of the system package due to a file not listed. so, be extra careful when shipping your dist - or change platform and burn your shiny toy that calls itself a computer (careful & clever readers may have guessed from previous sentence that i don't like macosx - but that's not a reason to ditch this post and not to follow the advices i'm reporting).

there, i think that's a pretty good start. i've encountered each and every item of this list at least once (i stopped counting exactly how much a long time ago). don't take it personally if you made some of those mistakes - i have done almost all of them by myself as module author (except of course using module::install and using a mac, but you could have guessed for at least the last part). what's important is to realize that those behaviours are annoying for packagers, and that changing those habits is quite easy to do (except for the burning your mac part, because i agree that it's not very environmental-friendly - see, i'm not that stubborn! ;-) ).

if you're following all those advices, packagers of your modules will love you. (or at least, not hate you - which is still a win :-) ). i know i will...

scrapping web pages with embedded javascript in perl

2009-12-23T13:49:00.004+01:00

recently i had to download various pdf files from a vendor website, which list them according to different criterias. since i'm lazy, i wanted to write a script that would download all those files for me.

that would be quite easy, but the list was generated by some ajax when i was changing the criterias... so, what to do to pally this problem?

there are some solutions out there for the perl programmer.

although www::mechanize's author stated that he does not want to bother with integrating javascript support, someone wrote a javascript plugin for mechanize. it's still experimental by now, though.

the same author, leveraging his knowledge, also wrote www::scripter that's supposed to achieve the same result.

but before going in those complex beasts, it may be worth trying to understand what the javascript is doing, and if the hidden url that gives the wanted list of files is easy to guess. to do that, you can go the hard way and read the javascript... or the easy way and wiretap the network!

enters http::proxy which is a configurable proxy written in perl by book. among the various examples, it comes with a logger.pl script that displays all the urls accessed by your browser (with cookies). run it as is, configure your browser to use a proxy on localhost port 3128, and check the output of logger.pl while tinkering with your ajaxy application.

chances are that you'll see a url such as http://www.examplecom/path/to/script/list/?crit1=foo&crit2=bar&limit=10

well, that was the case for me, and i could just download the list according to my criterias, parse it with the excellent html::tree and download each of the files separately... \o/

so the title of this blog post is wrong: no javascript webscrapping (although i gave some hints on how to do it), but cheap trick to achieve the same result! :-)

parrot 1.9.0 available in mandriva

2009-12-16T10:40:00.003+01:00

since parrot 1.9.0 is officially out, it landed quite quickly in mandriva cooker. next rakudo version will soon follow.

rakudo available in mandriva

2009-12-09T11:39:00.003+01:00

after some chat with parrot-porters, i finally undertood that what's get installed in /usr/src/parrot (and that i was trimming during installation) is not parrot full source, but intermediate forms of pmc, needed if high-level languages want to subclass them. they are thus now shipped in parrot-src package - and this is enough for rakudo to be compiled.

therefore, rakudo 2009-11 is now (finally) available in mandriva...

mojomojo now available in mandriva

2009-12-05T11:22:00.003+01:00

after struggling quite some time with its dependencies, and then some other prereqs not mentioned deep in the dependency chain, i'm happy to report that mojomojo, the catalyst powered wiki, is now available in mandriva.

migration to moose - step 3

2009-12-02T11:21:00.004+01:00

continuing ^[0] to port mpd modules to moose - this time it's poe::component::client::mpd turn. in order to do that, i had to fix the tests (using the shiny new test::corpus::audio::mpd) in order to be sure not to introduce regressions.

migration was quite easy, but a bit long. especially since i used a lazy_builder attribute for the connection, leading to commands sent before actual connection took place - and thus the tests failed with a cryptic message from poe::component::client::tcp ^[1]

the excellent moosex::poe was used too, but not in the connection, since it reuses various components having a more classic way of defining their events.

and now that the base code is moose-ified, i think i'll be able to gain more clarity while leveraging some moose levers.

[0] see this previous post and this one
[1] saying that {server} doesn't have a put method... as opposed as what's documented. but that's because at that time it has not (yet) morphed into a poe::wheel::readwrite. even if i'm at fault for not waiting the connected event, couldn't it provide a better error message?

announcing git plugin for dist-zilla

2009-11-25T17:18:00.002+01:00

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.

sweetening tk

2009-11-18T08:46:00.001+01:00

after discovering how to sweeten moose with moosex::has::sugar, i thought the concept could be extended for other modules.

as a tk enthusiast, this was a logical target. especially since i was already kind of doing this with some internal modules exporting variables. so i decided to just extract this piece of code, update it and wrap it in a new module, tk::sugar.

so, where previously you were doing:
you can now write:

which is way better imo.

of course, the module supports lots of other often-used helper subs - check the doc for more information. and if you need some more, either request them or clone the repository and send pull requests! in the meantime, enjoy it...

sweetening moose

2009-11-14T09:12:00.006+01:00

even if moose is nice and allows to prune a lot of code, it can still be seen as cryptic. take the following example, and imagine that you have a lot more attributes to declare:

the first thing that can be done is using moose builtin types instead of their name, with moosex::types::moose. this allows to remove the quotes around the types:

but that's still a bit mouthful. enters moosex::has::sugar, for a nicer code:

your code is now more readable - yet some other modules that i'll now use in my dists...

cpan activity

2009-11-09T18:05:00.002+01:00

with mandriva linux 2010.0 out, it's time to have a look at cpan activity once again.

version freeze happened on october 1^st for mandriva, at which point it wasn't possible to upload new version - unless to fix a bug preventing usage. since we know that cpan modules don't have such bugs^[0], it means that almost no perl package was updated till cooker^[1] reopening (which happened on november 6^th).

so, how many dists needed an update after ~40 days? around 150. yes, 150. on 1685 distributions shipped by mandriva. and some of those were updated more than once...

that's ~10%. a bit less than what was reported in april for mandriva 2009.1, but:

this time it's for whole mandriva, not only the packages i'm responsible for
freeze was a bit longer for 2009.1

yet another proof of perl community's health.

[0] :-)
[1] cooker is mandriva's development version

the state of perl in mandriva 2010

2009-11-03T16:51:00.008+01:00

mandriva linux 2010 is out... this is thus a good time to have a look at the state of perl in this release.

adelie (mdv 2010 codename) ships perl 5.10.1 with threads^[0], which allowed me to drop half the patches carried within mandriva^[1]. and since perl 5 porters hope to make perl 5 releases more often, it means that (hopefully) i'll be able to trim down those patches even more!

on the modules front, mandriva is shipping plenty of them. padre 0.47 (and lots of plugins), moose, poe framework (and lots of components), devel modules, dbi drivers, gui (tk, wx, gtk) and various lib bindings, you name it... using book's pearl of wisdom, this gives us^[2]:

12117 installed modules
including 11016 from cpan (15.65% of cpan)
that is 1685 distributions (8.88% of cpan)

that's not half of cpan, but a good deal nevertheless. chances are that you will find the module you need - and if you don't, drop me a mail or open a request and i'll package it for you.

but the biggest change that you will see in mandriva 2010 regarding perl (well, maybe you won't even notice it), is the new standardized version scheme forced upon all perl modules. for example, dist-zilla version 1.092680 is shipped for mandriva 2010 in rpm perl-Dist-Zilla-1.92.680. yes, i know, it means that the mandriva version might differ from upstream version. yes, i am aware that this sucks. yes, i am also aware that there's no real way to get upstream version back from mandriva rpm version. and no, i don't plan to roll back this change - unless you have another miracle solution that deals with rpm not understanding cpan modules changing their versioning scheme without bumping their major (grrr!).

however, note that previous mandriva version (and fedora too) already mangled some modules version, but not all of them - which is even worse imo. since i agree with david that version numbers should be boring, all modules now have their version mangled. no ifs, no buts, we're mangling it. and it makes life easier for us packagers...

of course, the modules' code is not affected by this change. it's only the packaging that changed a bit. to check which version is installed, just check the $VERSION of this package. that's always been, and remains, the only safe way to be sure. eg:

$ perl -E 'for (@ARGV){eval "require $_"; say "$_\t",$_->VERSION if !$@}' Dist::Zilla
Dist::Zilla     1.092680

on the parrot front, we're shipping 1.6.0 (1.7.0 was too late to be included). and rakudo is still not present, since it cannot use an installed parrot.

all in all, that's a quite a good release on the perl front. if you add all the work that went in all other areas, mandriva 2010 will be quite a solid release. i invite you to test it out - who knows, you might even like it so much that you'll switch to it permanently! :-)

[0] no need to complain, rgs - i know your feelings about it.
[1] yup, i took the ownership of the perl package - silly me...
[2] why, yes, i install all perl modules available as rpm on my box :-)

right trimming for dzil autoprereq plugin

2009-10-28T09:17:00.000+01:00

autoprereq plugin for dzil used to trim all modules under the dist namespace from the list of prereqs. eg, for dist-zilla dist, it would trim all dist::zilla::* modules.

although good for a first try, it had two problems:

modules outside of your dist can be trimmed. eg, audio::mpd is requiring some audio::mpd::common modules which are outside of audio-mpd dist.
if your dist is shipping 2 namespaces, only the modules inside the first namespace are trimmed, and you can end up with a dist with circular deps.

the first one is easy to solve with a fixed [Prereq] section in your dist.ini (this is what i've done for audio-mpd). and the second is not really common, so i thought that i could leave dzpa as is...

but dams now uses dzil for the excellent curses-toolkit - which ships curses::toolkit::* and poe::component::curses::* modules. so he complained (rightly) and i had to fix autoprereq plugin.

so, dzpa will only trim modules that are part of the dist, instead of blindly removing the modules under the dist namespace. and this only change fixes at once the 2 problems outlined above. where dzpa used to trim too much and not enough, it now trims just what it has to...

migration to moose - step 2

2009-10-25T12:11:00.004+01:00

another module converted to moose (and dist-zilla): audio::mpd. migrating the attributes is quite easy, but this time the constructor migration was a bit trickier to do. fortunately, moose lazy building proved handy.

since the module is quite stable by now, i bumped version to 1.x (1.yyyddn even).

one more module with a simplified code-base... next migration will be pococm, and should prove more difficult, but for even more reward (thanks to moosex::poe).

test::corpus::* namespace

2009-10-21T12:45:00.003+02:00

both audio::mpd and poe::component::client::mpd share the same files for their regression test suite. this includes some boring ogg files - weighing around 150 kb. although not that much, those files are duplicated between those 2 modules.

moreover, it means that everytime i upload a fix for one of those modules, i'm taking some more space on cpan for those exact same files - they never ever change...

something had to be done. i therefore wanted to split this raw test data, and put it in a module of its own. the other 2 modules would then get rid of the test data, and require the new one during the tests.

the question was of course how to name this module. i asked module-authors for advices, and david nicol proposed the test::corpus::* namespace.

since the idea is quite sound, i then released test::corpus::audio::mpd with the data (with some fixes to bring it up to mpd 0.15.x). audio::mpd has already been migrated to use this. i still need to do it for pococm, though.

anyway, this post is merely about the announce of the test::corpus:: namespace, to hold your test data instead of putting them in your dists. let us know what you think of it.

dist-zilla: compile tests can skip some modules

2009-10-14T17:13:00.003+02:00

the compilation test plugin for dist-zilla now accepts a parameter to skip some modules. this can be handy to prevent testing some known-to-fail modules - yes, this can happen if your module does stuff assuming a given environment not currently in place (eg: test modules...).

just use the following in your dist.ini file:

[CompileTests]
skip = Test$

the skip parameter is interpreted as a regex, matched against the module name (not the file name of the module). in this example, all modules with a name ending with Test will not be tested for compilation.

migration to moose - step 1

2009-10-11T11:10:00.003+02:00

as promised, i just migrated audio::mpd::common to use moose. and since i was at it, i also took the opportunity to migrate to dist::zilla!

conclusion: it takes some time to migrate (around half a day?) - and this is a very small dist! maybe i should have not mixed moose and dzil migration... but the resulting code is also easier to read, and better documented now, so it's not a one to one migration.

anyway, i'll continue migrating the mpd related modules to moose, dist-zilla as i find the tuits.

mandriva 2010 coming - which perl modules do you miss?

2009-10-05T16:59:00.004+02:00

mandriva's next version (2010.0) is now in version freeze, for a release date in early november. this means that current packages are not allowed to be upgraded to latest version, unless there's a compelling reason to do so (security update, crash or big regression).

there is still, however, the possibility to ship new packages. so if you miss some perl modules in mandriva and you really want them available as rpm packages in 2010.0 version, now is the time to speak up! just add your request as comment to this post, and i'll do my best to fulfill it.

about exporter bug

2009-09-29T19:34:00.002+02:00

finally exporter with multiple inheritance bug is explained: class::accessor::fast version 0.34 now does some import magic, and in that case export's import sub is not called. so it's neither perl, nor exporter related.

but still, using multiple inheritance cannot be avoided sometimes...

multiple inheritance - why still using it

2009-09-29T15:52:00.004+02:00

ovid reacted to the bug i opened against exporter and multiple inheritance, stating that we cpan authors shouldn't use multiple inheritance, since roles exist.

with all due respect to ovid, this is over-simplifying. cpan holds 15000+ distributions, of which maybe 5% is proposing a role-based api (and i think i'm generous). which means that a lot of the modules available needs you to inherit from them^[0]. so what to do when you want to use those modules? yup, multiple inheritance. i know it's bad - but i don't have the choice, mmk?^[1]

i can already predict ovid's answer: my bug was related to inheriting from both exporter and class::accessor::fast^[2], so i should switch to moose to replace the class::accessor bit. right, i plan to do it later on (patches welcome, too).

but in the meantime, i have a module that worked perfectly under 5.10.0, and that breaks under 5.10.1 (i am still not sure if it's perl or exporter or base/parent related). no need to talk of greypan and compatibility accross major perl releases: i'm talking of backward compatibility of minor perl version for regular cpan module with code available here. and even if it's using sub-standard technology - i am entitled to not expect this kind of breakage.

[0] which is not exactly surprizing, since roles are quite new in perl's oo landscape: 2.5 years according to moose's changelog. if you count some time to let the new feature stabilize, get some needed speed boost and gain acceptance, i don't expect to see a lot of non-role based api soon.

[1] i'm not advocating to use multiple inheritance at all costs. ovid is right: if you can, compose classes with roles. really, he is right on this topic. however, the key words here are if you can.

[2] see how both synopsis request you to inherit from them?

working around exporter bug in perl 5.10.1

2009-09-28T17:39:00.002+02:00

exporter seems to have a bug with perl 5.10.1. in case of multiple inheritance, it must be the first parent, otherwise no export magic is done.

the bug is experienced both with base and parent, so i really think it's exporter related - or maybe 5.10.1, since it was not present with 5.10.0.

i reported the bug to p5p - in the meantime, just switch exporter to be the first parent in multiple inheritance...

external event loops no more part of poe

2009-09-23T17:46:00.003+02:00

for those (such as me) that did not spotted it, external event loops for poe are now released as their own distribution. this means they aren't part of the poe distribution anymore, and you should add them to your prereqs...

of course, there's no way that dzil's autoprereq plugin could extract poe::loop::tk from code such as:

so, i had to use the regular prereq plugin to list it as a manual dependency. since dzil is using moose roles, it means more than one plugin can provide the prereqs, so i can continue using autoprereq beside this exception - woohoo!

in conclusion, games::pandemic 1.092660 is on its way, fixing a problem reported by a cpantester (thank you guys - you rock!)

first external pandemic translation

2009-09-21T17:12:00.003+02:00

i'm really happy to release a new pandemic version, namely 1.092640 (that is first release of 264th day of year 2009 for those that skipped previous entry).

beside the introduction of the medic player (which in itself is interesting), it's with great pleasure that i committed a japanese translation that tomita naoki provided me with. thank you tomita for this first external contribution!

so, if you want to contribute, an easy way to start is by providing a translation for your language! of course, any other contribution is also welcome. :-)

moosex::poe ftw!

2009-09-14T16:19:00.003+02:00

in the serie "why using moose and moosex" - today i present moosex::poe.

say you want to create a poe session. traditional way is to create a module handling spawn method that would be called as:

the module itself would be something like this:

now that's moutful. and it has an easy-to-miss error - found it? right, it's should be event3, not evnet3. you can curse poe quite some time trying to understand why your nice handler never gets called for event3.

here's the version using moosex::poe:

of course, it's still possible to mis-spell event3. however, you only have to spell it once, whereas you wrote it 3 times before - which is 2 times too much!

and i'm not talking about the easy accessors that could be added by moose - but i'm concentrating on moosex::poe here.

granted, there's one downside: subs are now anonymous, which can make it a bit harder to debug. but that's a small price to pay, imo.

so, moosex definitely makes your code more readable - i'm definitely not looking back, and i advise you to have a look too.

full pandemic stikes, woohoo \o/

2009-09-07T18:01:00.003+02:00

erm, not this pandemic, but the pandemic game written in perl...

so yes, i'm happy to report that milestone 1.0¹ has been reached. indeed, here's what warrants the bump:

infection rate grows as epidemics strike
special event: airlift implemented
special event: forecast implemented
special event: government grant implemented
special event: one quiet night implemented
special event: resilient population implemented
epidemics now shown in past cards

yup, this means the game is fully playable. i'm not saying fully implemented, since there are still stuff missing such as the medic or dispatcher roles, the possibility to choose the difficulty, number of players, etc. and of course lots of polishing is needed to get rid of all those peksy details that get in the way.

however, all in all, i'm quite happy (and proud) of the release. version 1.0 is definitely not the ultimate one, it only means that you can play with it with comfidence.

of course, i'm always eager to have (constructive) feedback² on it. and if you want to contribute, well, the source is available on github.

[1] in fact, it's 1.000000 (i know it's ugly) since i'm switching to rjbs' versioning scheme: 1.yydddn³. it'll make versioning boring (even if not beautiful).
[2] fan & love mail is ok too :-)
[3] yes, i'm taking every bad habit rjbs has to offer, as long as it helps my laziness. of course, games-pandemic is using the excellent dist-zilla since the beginning.

migrating to moose? hell yeah!

2009-09-01T16:49:00.003+02:00

dave is asking whether we (cpan authors) would consider migrating to moose.

between moose which brings a lot of nice features, moosex extensions such as attributehelpers (which i'm being said is going core) or moosex::poe (poe integration ftw!), there is so much that moose can bring to developers!

less fuss, less coding, more fun...

of course, moose is a bit slow during startup (but not afterwards). but even if i respect adam's will not to slow down padre too much during startup, i'd be in favor of using it nevertheless for padre. after all, we can expect some speed gains if moose's adoption continues to rise.

so, at least for me, the answer to dave's question is a definitive yes! i am considering switching to moose, and i'll end up doing that when i'll have the tuits to migrate my modules.

note: i should also add that since i'm at it, i'll also switch my modules to dist::zilla, which does a fantastic job to promote lazyness :-) but that's another topic...

pandemic nearing v1

2009-08-28T09:47:00.002+02:00

so games::pandemic 0.8.0 has just been uploaded on cpan. this release saw lots of improvements:

diseases can be eradicated
performing infection outbreaks
detecting game over condition when too many outbreaks
allowing player to choose which disease to treat in multi-infected cities
return/escape bindings for dialogs
tooltips for various game information
fix unfair epidemic repartition
fix never-ending too many cards / deal more cards when dropping a card but still being beyond max number of cards
better dialog for past cards / infections

the game is thus playable, with only 2 things missing to have a full game: augmenting number of infection when epidemic strikes, and special event cards. when those will be done, i'll issue 1.x

of course, this does not mean that game is complete and won't be improved after. for example, the startup dialog to choose the game and player roles, ui improvements, etc. will be post 1.x material.

but in the meantime, enjoy 0.8.0, which is already quite interesting to play.

perl 5.10.1 has hit cooker

2009-08-24T20:40:00.004+02:00

perl 5.10.1 is out, so i just built it for mandriva cooker - after fighting the build system which seems to be broken very often those days. :-(

it's currently propagating on mirrors, and should hit your machines soon... lots of other packages will need to be rebuilt, so you may want to run urpmi with the --keep flag.

in other news, parrot 1.5.0 is also available on cooker since yesterday.

new pandemic release

2009-08-22T14:46:00.003+02:00

games::pandemic 0.7.0 is now on cpan, with a lot of improvements and a crash fix:

wiping all cubes from a city if a cure has been found for the disease
reacting to winning conditions
reacting to game over condition when no more disease cubes
possibility to see cards already played / discarded
possibility to see past infections

i'm taking my time, but all in all there is progress... :-)

more dzil goodness

2009-08-17T09:25:00.002+02:00

i'm happy to announce yet another plugin for dist-zilla: critictests.

in your dist.ini, just add:

[CriticTests]

and dist-zilla will automatically create for you an xt/author/critic.t file that will criticize your code during author tests.

of course, since your code will be munged by dist-zilla, code that passes critics in your repo may fail after being rewritten... case in point: stricture use, since dist-zilla-plugin-pkgversion will insert a version just after the package statement - and thus before any use statements. in order to make your code compliant again, just move the use strict / warnings before the package. indeed, use is lexically scoped, and thus the scope of the use statement will be the whole file.

your code will now look like:

use strict;
use warnings;
package Foo::Bar;

and of course, perlcritic this time will now be happy.

perl 5.10.1-rc1 available on mandriva

2009-08-09T10:41:00.003+02:00

perl 5.10.1-rc1 has been released 3 days ago, so i packaged it for mandriva. the good thing is that a lot of patches that we were adding to our perl are now merged upstream.

the new perl (perl-5.10.1-0.rc1.2mdv at the time of writing) rpms are available in mandriva testing media. you can install them with:

# urpmi perl perl-base --media "Main Testing"

please report any problem to either mandriva cooker mailing list, or to perl 5 porters if that's a perl related bug.

epidemics strike in games::pandemic!

2009-08-08T15:44:00.002+02:00

games::pandemic 0.6.0 is now on cpan, with a lot of improvements:

introducing epidemic events - fear! :-)
closing current game is now supported
player cards now displayed in a window of their own
detecting game over condition when no more cards
sorting cards by type then by disease then by city name
introducing a new "action" menu, with shortcuts for actions
actions now independant of buttons / menu for easier reuse

of course, there are still a lot of things to do, but it's shaping up nicely...

shipping compile tests with dist-zilla

2009-08-07T09:14:00.000+02:00

perl community places some emphasis on testing. which is great, since it enhances the overall quality of perl ecosystem.

the first, easiest test that one should provide is basic: making sure the modules compile. we have 2 options here:

either create a test and add some use_ok('Foo::Bar'). but we then need to update it whenever we add more modules to our distribution - without forgetting to update test count.
or, to get rid of this burden, ship a test that automatically finds the module and tries to compile them.

but shipping the exact same generic test is boring, and could be automated. which is now the case for dist::zilla with the new module dist::zilla::plugin::compiletests. just add the following in your dist.ini file:

[CompileTests]

and you will get a brand new t/00-compile.t that will test your modules and your scripts one by one. this my take some time if your dist ships a lot of modules having lots of prereqs, especially if they are a bit slow to compile such as Moose. but this will potentially find more compile errors in your modules.

more moose support in dzp:autoprereq

2009-08-06T14:54:00.003+02:00

dist::zilla::plugin::autoprereq just gained more moose support: it can now extract the base module declared with:

extends 'Foo::Bar';

it's not perfect since it only extracts the first base class, but i think it will cover 90+% of the cases out there.

bash completion for dzil command

2009-08-04T18:28:00.002+02:00

lazyness strikes once again: i've created a (rough) bash completion file for dzil command that rjbs just merged. it will be available in next dist::zilla release.

converting & rebuilding mandriva perl modules rpm

2009-08-01T10:26:00.004+02:00

as time went by, the %perl_convert_version^[0] macro in rpm has proven useful to convert perl version number to something that rpm will (should) always be able to parse. i also patched mandriva's perl.prov and perl.req (that automatically extracts requires & provides for perl in rpm packages) to use %perl_convert_version also.

the last step happened this week, when guillomovitch has converted youri checks to also compare newer cpan version with %perl_convert_version. therefore i'm currently migrating the not-yet converted mandriva perl rpm package to use %perl_convert_version also^[1]...

expect some problems during installation till all modules are converted. this should be solved soon.

[0] so that eg 1.54 is understood as 1.540.0, and thus greater than 1.470 - as on cpan.
[1] when the build system works! :-)

autoprereq plugin for dist-zilla gets smarter

2009-07-24T14:26:00.004+02:00

i just released dist::zilla::plugin::autoprereq 0.2.0 which now extracts prereqs from moose roles declared with the with keyword ^[0]. also new in this release is the support for skip list, allowing to trim unwanted prereqs.

[0] why, yes, i got some failures for games::pandemic 0.5.0 due to a missing prereq... defined in a role, you guessed it. :-)

parrot 1.4.0 landed on mandriva

2009-07-22T19:14:00.002+02:00

latest stable parrot version (1.4.0) is now available on mandriva - enjoy.

pandemic turns implemented

2009-07-18T08:25:00.000+02:00

so games::pandemic 0.5.0 is now released^[0].

the basic game play is now done: besides the player actions, the cards are now dealt and infections propagated. card limit is also implemented, so player can discard them if needed. add to that a bit of ui polishing, and we now have a solid basis on which to build upon...

next releases will see (in no special order):

the special cards (including the epidemics)
end of game conditions (both game-over and win cases)
more ui polishing (i think the players cards will have their own toplevel)
easier game play (drag-n-drop on the canvas)
missing player features (dispatcher, medic)
missing rule implementation (disease eradication, ...)
start game dialog
etc.

yup, that's still a lot to do, so expect other 0.x versions! ;-)

[0] and without any more warnings, since i spotted a bug in moosex::semiaffordanceaccessor which has been swiftly fixed!

prettyfying tk apps

2009-07-10T14:45:00.008+02:00

one of the main griefs people have against tk is the fact that it looks ugly. however, it's possible to tremendously enhance tk with only one line. indeed, tk by default uses a 2 pixels wide border, which does look fugly.

here's a snapshot of config::model (used as an example):

now, try to insert the following line in your code:

$mw->optionAdd('*BorderWidth' => 1);

here's the result, still using config-model as guinea pig:

look at how the buttons are crisper... now that's better, uh? :-)

thanks to ala qumsieh who first reported this tip on perltk.org - but the site seems to be down nowadays.

note: i'm told that tk 8.5 can be themed and looks native. but i'm still using perl/tk which is build against tk 8.4

perl helps save world pandemic

2009-07-02T19:03:00.005+02:00

ok, maybe the title was a bit too much dramatic - especially in those days. :-)

i like playing board games, and my wife and i discovered recently pandemic, from z-man games. it is a tremendous cooperative game, where players allies to eradicate 4 diseases. but the infections spread out, and if you aren't fast enough, you end up with a global pandemic - and loose...

it is really addictive, so i decided to write a perl module games::pandemic implementing a clone of this board game, with all its rules. it was also a good occasion to learn moose, dist::zilla and other modern perl stuff. at least, this goal is already fulfilled! :-)

i'm also using poe and tk (i know, i know). i just published the first public release, version 0.4.0. it already implements all the player actions, and here's a snapshot of a game:

of course it isn't finished, but i'm pretty happy of the result (even if the gui might change in the future). i aim for a v1.0.0 playable alone, and then allow networked game...

the code is available on github if you want to help - even "only" translating strings is welcome!

so, expect to hear more about pandemic on this blog. and while waiting for this perl version to be complete, i recommend you to buy a pandemic board game: you won't regret it...

even more lazyness with dist::zilla::plugin::autoprereq

2009-06-29T18:45:00.003+02:00

who never forgot to list a prereq in their makefile.pl / build.pl / whatever? it happens to me on a regular basis.

now that i started using dist::zilla, prereqs are not listed in a build script, but in dist zilla configuration file. but the problem is the same: prereqs are listed manually. and doing stuff manually sucks.

i had to do something. so i used dist-zilla's plugin infrastructure and just uploaded dist::zilla::plugin::autoprereq. just add:

[AutoPrereq]

in your dist.ini, and it will automatically find your prereqs for dist::zilla to use.

the parsing is somehow very rough: it will just find the lines beginning by use or require. for more advanced / hackish stuff, dist::zilla::plugin::prereq is still available. i still think that it should cover 80+% of the cases. i considered using module::info, but it evals the modules to find the prereqs and the result is damn slow... and speed was more important imo.

note that i plan to add the possibility to add modules manually, in order to add missing modules (or maybe we can use both prereq and autoprereq?), and a skip option to trim modules that should not be added to the list of prereqs.

also, i may change the algorithm used to find prereqs: maybe ppi will be fast enough? we'll see.

but in the meantime, just enjoy not writing anymore those prereqs by hand! :-)

beginning of moose support in padre

2009-06-25T18:54:00.006+02:00

so i started using moose like all the cool kids today. it turns out to be quite nice to use. declaring an attribute is as easy as:

has foo => ( is=>'ro', ... );

and since i'm also using poe, i was glad to find the illicit love child of moose and poe - aka moosex::poe. declaring an event without any fuss:

event frobnize => sub { say $_[0]->foo };

but when your module grows to have lots of attributes and poe events, it's difficult to go directly to a given definition in the file.

readers of this blog know that i'm using padre (the perl ide), but neither the sub nor the outline views can help. indeed, if you look the code snippets above, there is no traditional sub definition... syntaxic sugar is nice, but it means the tools need to be aware of them.

this was clearly an itch to scratch... i had a look at padre's outline code, and after some help from alias, here's the result:

the patch is surprisingly small: around 20 lines for attribute detection, and the same for event detection... that's the beauty of having cpan modules at hand - the great ppi in this case.

(note: the feature is in trunk currently. you'll have to wait 0.38 release)

so, try padre. tell us which feature it lacks. or how can we make it the modern perl editor, the one that would be recommended alongside moose and others.

where are builtin tk icons? (aka tk::toolbar fun)

2009-06-22T19:53:00.004+02:00

for everything gui related, my favorite toolkit is tk. it's quite powerful, easy to learn and to use, and feels quite perlish ^[0]. in a word, it doesn't get in the way.

yeah, of course, current version is not the most up to date ^[1][2] - but it gets the job done, with the help of some nice tk additional modules available on cpan.

one of those modules is tk::toolbar, from ala qumsieh. and it comes with a set of bundled icons that are loaded. they may not be the prettiest icons out there, but they are available and allow you to do something like ^[3]:

$mw->Label( -image => 'fileopen16' )->pack;

instead of having to create & load the images yourself.

knowing this, when i needed to add an icon in my new project (yes, yes, i need to present it here), i loaded tk::toolbar in my code, and re-used one of the bundled images.

well, that was my goal anyway - the image never appeared... i tried to tweak my code in every direction, but did not manage to make this icon appear.

having rebuild perl-tk package yesterday to fix a bug in mandriva's package, i thought it might be related... so i tried to run a perl/tk gui provided in one of my other modules using tk::toolbar's icons, but the icons were correctly displayed. so long for this idea...

after having fought 5 minutes, i finally managed to understand what was going on: in this new project, i currently do not have created the toolbar. and since the icons are loaded in the classinit() method, called during the creation of the first widget of this particular class, the icons were not loaded...

so i created a toolbar ^[4], and miracle! the icon i wanted magically appeared.

tricky one...

[0] contrary to wxwidgets for example - at least imnsho
[1] i'm using plain tk 804.028 and not one of those tk ersatz tcl::tk ^[5] or tkx ^[6]
[2] slaven told me he would like to update it when he'll have some tuits...
[3] tk allows you to name the images you load, to do for example:

$mw->Photo( "foo", -file=>"path/to/some/image.jpg" );
[... later on ...]
$mw->Label( -image => "foo" )->pack;

[4] i'll populate the toolbar later on
[5] which is far from complete, and does not seem to be maintained anymore
[6] which doesn't compile easily out of the box, and feels really clumsy after tk goodness. oh well, i guess beauty is in the eye of the beholder...

prepender distzilla plugin can add boilerplate copyright

2009-06-21T11:36:00.004+02:00

following autarch's advice on yesterday's post, i just uploaded dist-zilla-plugin-prepender 0.2.0 that accepts a copyright option to automatically add a boilerplate copyright at the top of the files.

yet another things that ease an author's life.

i'm still unsure with the strict and warnings options. not because of the test argument, but because of the editing argument. indeed, with padre (the perl ide) doing live syntax check, i want the syntax check to be done with all due stricture...

new distzilla plugin: prepender

2009-06-20T11:56:00.005+02:00

when i first heard of dist::zilla, its concepts definitely appealed to me. it took me quite some time (never the good time, plus i needed to create the rpms for mandriva), but i finally managed to try it...

and although i still need to get used to it, i'm already really happy with it. on the new project that i recently started (more on that later on), i'm letting dist::zilla deal with all those pesky copyright, version, pod, etc. stuff.

however, i'm used to add some boilerplate at the top of my files, as the fsf recommends. and i found nothing in dist::zilla to do that... so i just wrote a new plugin for it: dist::zilla::plugin::prepender.

just add the following in your dist.ini file:

[Prepender]
line = #
line = # This file is part of Foo::Bar
line = #
line = # Foo::Bar is copyright...

but it can also be used to enforce some common pragma: since it will be inserted at the top of the file, the pragma will be applied to its lexical scope - the whole file itself in this case:

[Prepender]
line = use strict;
line = use warnings;

since those usages are quite common, i might as well in a future version propose them as options:

[Prepender]
copyright = 1
strict    = 1
warnings  = 1

but i'm not really sure... wdyt?

which parrot version to package?

2009-06-18T10:55:00.003+02:00

after some lengthy discussions finding the final versioning scheme for parrot, allison finally decided that parrot will use the following version numbers:

1.0 (March, deprecation point)
1.1 (April)
1.2 (May)
1.3 (June)
1.4 (July, deprecation point)
1.5 (August)
1.6 (September)
1.7 (October)
1.8 (November)
1.9 (December)
2.0 (January, deprecation point)
2.1 (February)
2.2 (March)
2.3 (April)
2.4 (May)
2.5 (June)
2.6 (July, deprecation point)
2.7 (August)
2.8 (September)
2.9 (October)
2.10 (November)
2.11 (December)
3.0 (January, deprecation point)

the stable versions will be the deprecation points - that is, 1.0.0, 1.4.0, 2.0.0, 2.6.0 and 3.0.0. this means that those versions may have some bugfix releases during their support lifetime (1 year), but only for very limited stuff (security or other critical problems). everything is described in parrot's support policy.

as parrot packager for mandriva, this is good to know. however, i don't really know what to do: should i package the stable versions? or should i update the package for each new devel version?

since parrot is quite in flux those times, version 1.0.0 (which is 3 monthes old) is really useless... if you add that almost nothing production-ready relies on it currently, i have decided to update the package on a monthly basis. which means that rpm for parrot 1.3.0 is available on cooker right now.

but let's think forward a bit... when rakudo will be able to use an existing parrot, when perl 6 will be in production, i won't continue like that: i'll just stick (of course) with the production releases... but when will this point happen? when will i switch from devel to stable versions? this remains to be seen...

redefining exported subs in perl

2009-06-11T10:03:00.007+02:00

i've explained in a previous post that i changed the way i was logging debug statements within language::befunge. i mentioned that i applied some tricks and promised to explain them - so here are the explanations.

the goal is to minimize time spent for debug statements. previously, i was doing:

$interpreter->debug(@stuff);

and debug was a method defined as:

sub debug {
    my ($self, @stuff) = @_;
    return unless $self->debug_mode;
    warn @stuff;
}

so, to log a debug message, i was doing:

a method call on $interpreter
a second method call to check an attribute
finally the actual logging (skipped if we're not in debug mode)

this is bad, especially since method calls cannot be resolved at compile time by perl, and thus are actually resolved during run-time. but what's worse is that this always happens, even if we're not in debug mode (which is around 99% of the time).

so, one obvious way to improve was to move from a method to a plain sub. this would remove the run-time cost of resolving the method. the debug mode can be stored as a package scalar instead of an attribute.

but we can do even better. knowing that:

perl optimizes out calls to empty subs
we are not in debug mode most of the time

we can define the debug sub as an empty sub!

here's our code at that point:

package Language::Befunge::Debug;

use 5.010;
use strict;
use warnings;

use base qw{ Exporter };
our @EXPORT = qw{ debug };

sub debug {}

of course, we need to provide a way to activate debugging. a naive approach would be to redefine our debug() sub in our debug package:

sub enable {
  *debug = sub { warn @_; };
}

alas, this won't work. well, it will work for calls such as:


Language::Befunge::Debug::debug(@stuff);

but calls using exported debug() will still log nothing. indeed, it's important to understand that exporter installs a copy of exported sub in the package. therefore, changing the definition of the original does not change the exported copies.

so, to redefine exported subs, one is forced to walk the symbol table of all packages and redefine subs on the fly. here's what i ended up doing:


my %redef;
sub enable {
    %redef = ( debug => sub { warn @_; } );
  _redef();
}

sub disable {
    %redef = ( debug => sub {} );
  _redef();
}

my %orig; # original subs
sub _redef {
    my $parent = shift;
    if ( not defined $parent ) {
      $parent = '::';
      foreach my $sub ( keys %redef ) {
          $orig{ $sub } = \&$sub;
      }
    }
    no strict   'refs';
    no warnings 'redefine';
    foreach my $ns ( grep /^\w+::/, keys %{$parent} ) {
      $ns = $parent . $ns;
      _redef($ns) unless $ns eq '::main::';
      foreach my $sub (keys %redef) {
          next                                     # before replacing, check that...
            unless exists ${$ns}{$sub}             # ... named sub exist...
            && \&{ ${$ns}{$sub} } == $orig{$sub};  # ... and refer to the one we want to replace
          *{$ns . $sub} = $redef{$sub};
      }
    }
}

there, it will redefine my sub in all packages, even the ones that hold an exported copy.

now, do you think this would warrant a sub::redefine module on cpan? after all, i found nothing on cpan that would achieve that. otoh, i'm not sure it's that common to do this kind of things... so tell if you're interested, and i'll turn that in a cpan module for your own use.

cpan2dist oddity

2009-06-06T20:32:00.003+02:00

cpanplus is great - really, i mean it. i don't like its internals, and having to adapt to it for cpanplus::dist::mdv is not my fondest memory. however, it gets the job done, and that's what counts in the end.

but cpanplus has some oddities in the user-space also. cpan2dist, which is a tool allowing you to create a native package for your platform, sometimes makes me cry.

it insists on building prereqs for the module you want. that's fine, except for one thing: it will also build packages for modules that are not up to date... and this is where the fun starts.

you can think that --nobuildprereqs would prevent this, but nope, it's the default and really means: "don't rebuild prereqs if we're at latest version, but rebuild anyway if we're not at latest version". the --buildprereqs indeed means "i really really want to loose my time, please rebuild a package for all the prereqs even if i already have them installed and working". like this option is of any use... erm.

so in app::cpan2pkg, in order not to build the prereqs, i ended up using --ignore flags (flags as in plural form, since using a negative look-ahead regex such as /(?<!$name)$/ do not work). it took me quite some time to come up with this solution, since --ban was not working at that time.

so life was good, i've used cpan2pkg quite some time to create rpms for mandriva, and updated it till v1.0.0. however, since some time, i can see strange things in the packages submitted on upstream buildsystem: the build prereqs were not set. and i had to update the spec file manually, adding all those missing prereqs. i got tired of that, and investigated what happened.

after some experiments, it appears that cpan2dist seems to have somehow changed the way it handles its --ignore flags. ignored modules now are removed from the prereqs completely, and thus the cpanplus::dist backend do not even see them any more. and thus, buildrequires end up empty. of course, --nobuildprereqs still retained its old silly behaviour...

fortunately, it seems that --ban now works correctly (at least on 2 tests that i made). so i've just updated cpan2pkg, and version 1.1.0 should be available soon on cpan, this time really adding the needed buildrequires.

till the next cpan2dist change, of course... :-|

note: i don't want to sound too harsh to jos in this post... i totally understand that cpanplus is still 0.x software - moreover, this is a bug fix in my mind, since --ban was not working.

some befunge love

2009-06-05T17:17:00.005+02:00

i took some time to review my befunge modules. trying to speed up things is always fun, so thanks to devel::nytprof, i saw that i was spending quite some time on my debug statements.

it should be noted that those statements were method calls on the main language::befunge::interpreter object. and the method then was outputing things depending on the value of a debug attribute of the interpreter. the interpreter was not used outside of this.

knowing that method calls are expensive (since perl doesn't know until run-time where to find the method), i therefore created a language::befunge::debug module that exports a debug() sub. 2 other subs are provided (but not exported) to turn on/off the debug. (there's a trick here, that i will explain in another post).

net result? around 20% speedup (a bit more in fact). not bad for one hour spent on the subject. :-)

other than that, language::befunge tests got sanitized (using test::more, test::output and test::exception everywhere instead of crafting stuff by hand). part of this code was not touched since 2002...

finally, language::befunge got some new extensions, still passing all mycology tests. you can now enjoy the following in jqbef98:

CPLI - complex numbers extension
DIRF - directory operations
FILE - file i/o operations
FIXP - fixed point operations
STRN - string operations
SUBR - subroutines extension
TIME - date/time operations

some of them were pretty difficult to get right, if you forget some befunge basis (note to self: the storage offset is here for a reason, dammit!).

which leaded me to update language::befunge::debugger to load mycology correctly, with a new option to run without delay till the next breakpoint. using it, things were easier to get right. still not perfect, but already more than usable...

so, enjoy language::befunge 4.11 and language::befunge::debugger 0.3.6, now available on cpan!

image resizing in perl

2009-05-29T15:28:00.004+02:00

perl is really versatile, and can do a lot of things. moreover, you can do it in a lot of different ways. the difficult part being sometimes to choose the way you want to do it...

so i need to resize an image within perl. this is for games::risk, a perl implementation of the famous board game (btw, try it and tell me if you like it!). i want the background image to fit the window size on resize events. of course, i want it to be fast - but i also want something maintainable.

looking on cpan, i found 3 modules: gd, image::magick and image::imlib2. using gd to resize a picture is a nightmare, therefore i ditched it for image::resize which is a convenient wrapper around gd.

here are the needed incantations to resize:

with imlib2

my $old = Image::Imlib2->load($src);
my $new = $old->create_scaled_image($w, $h);

with image::magick - note that the operation is done inplace, so one needs to clone the image first to compare the same things.

my $old = Image::Magick->new;
$old->Read($src);
my $new = $old->Clone;
$new->Scale(width=>$w, height=>$h);

with image::resize

my $old = Image::Resize->new($src);
my $new = $old->resize($w, $h);

so i benchmarked them and found that on average, image::imlib2 is a few times faster than image::magick, which is itself around the same speed or a bit faster than image::resize.

however, image::imlib2 has a drawback: the only way to get back the new image is to save it to a file, where one can get the new image as a scalar directly:

image::resize with $img->jpeg
image::magick with $img->ImageToBlob

therefore, one must also take this into account in the benchmarking! so here's the latest version of the bench:


#!/usr/bin/perl

use 5.010;
use strict;
use warnings;

use Benchmark qw{ :all };
use Image::Size;                                                                                                                                             

use Image::Resize;
use Image::Imlib2;
use Image::Magick;

my $src = "src.jpg";
my $dst = "dst.jpg";

my ($w, $h) = imgsize($src);
my @sizes = (
 [10,10], [100,100], [1000,1000],
 [640,400], [840,600], [1024,768],
 [$w,$h], [$w/2,$h/2], [$w/4,$h/4],
 [$h,$w], [$h/2,$w/2], [$h/4,$w/4],
);

my $imlib2 = Image::Imlib2->load($src);
my $resize = Image::Resize->new($src);
my $magick = Image::Magick->new; $magick->Read($src);

foreach my $s ( @sizes ) {
 my ($width, $height) = @$s;
 say "-> ${width}x${height}";
 local $/;

 cmpthese( -3, {
     imlib2 => sub {
         my $img = $imlib2->create_scaled_image($width, $height);
         $img->save($dst);
         open my $fh, '<', $dst;
         return <$fh>;
     },
     magick => sub {
         my $img = $magick->Clone;
         $img->Scale(width=>$width,height=>$height);
         return $img->ImageToBlob;
     },
     resize => sub {
         my $img = $resize->resize($width,$height);
         return $img->jpeg; # $img->png
     },
 } );
 say '';
}

and i was quite astonished to see that image::imlib2 is still 2 or 3 times faster that image::magick or image::resize!

so, imlib2 may not the best api around, but sure it's fast...

rationalizing perl module versions

2009-05-22T13:18:00.003+02:00

versioning sucks. nobody agrees on what version numbers should look like. everybody has some good reasons not to like a given scheme. and i would say that everybody is right - at least from their point of view.

if you throw in the way that perl deals with version (used by cpan and cpanplus), you add more fuzzyness to the whole thing. eg, 1.40 is supposed to be more recent than 1.300 (yes, 1.40 is understood as 1.400). and i won't even talk of digits 3 to 6, or developer releases...

add to that developers who change their versioning scheme every now and then, or the ones who knows the way perl works and use 2 or 3 digits after the dot (yes module::starter, i'm staring at you - but you're not the only one)...

yup, versioning is a nightmare for packagers. this sucks.

so, after some time bugging mandriva admins, we finally have a shiny rpm macro %perl_convert_version that normalizes perl versions to a x.y.z scheme. here is its content for whoever is interested:

perl -Mversion -le '$v=version->new(%{1})->normal; $v=~s/^v//; print $v'

and we're going to use it on all perl modules packaged by mandriva. yes, this means that the rpm version will potentially be different than the upstream version on cpan. but that's the price to pay to have rpm and other non-perl aware tools to work correctly.

for the migration to be as smooth as possible, the following needs to be done:

push the rpm macro on mandriva build system. done.
fix cpanplus::dist::mdv to use it.
update youri's update check to recognize it.
update mdvsys to recognize it during mdvsys update.
fix our perl packages spec files.

in order to move on, i'm therefore happy to announce that cpanplus::dist::mdv 1.1.0 has been released, which (among other changes), now uses the rpm macro %perl_convert_version. that's one ticked off the list. :-)

cpan2pkg reaches maturity

2009-05-17T12:23:00.003+02:00

i finally took some time to work on app::cpan2pkg - and i'm happy to report that it now chains upstream builds, which means that all basic features are in.

therefore, i just released app::cpan2pkg 1.0.0 on cpan. detailed changelog:

updating prereqs + moving on when module installed from upstream
splitted module in poe session + worker
moved info from app:cpan2pkg to module attributes
don't submit on upstream build-system if missing prereqs on it
cpan2pkg documentation written

yes, cpan2pkg can build, install, import and automatically build packages from cpan for linux, while following dependencies. does it work? sure, i already used it successfully.

note however that there are some caveats...

the first one of course is that it only supports mandriva currently. this is not a fatality, i expect other distributions (and why not other platforms such as *bsd or solaris) to be handled later on if they want. after all, i'm using cpan2dist underneath to generate the packages, and there exist some backends besides cpanplus::dist::mdv. if you're interested, here's the git repository - and i'm ready to give push rights. heck, if you insist i might even agree to move to github which seems to have all the hype those days.

the second one is that the interface is rather ugly and has a lot of rough edges. i'm waiting for dams to continue his work on curses::toolkit, so i can drop curses::ui::poe. i might also provide a tk or wx version at some point. in the meantime, you have to know the application a bit to understand what's going on. i intend to polish it later on.

finally, the code can be cleaned - but you don't care as a user.

so, that's it. cpan2pkg is live... enjoy!