cpan2pkg now available in text mode!

cpan2pkg is the tool used to automatically package a module from cpan to mageia as a rpm, along with all its dependencies. it's built on shoulders of giants (cpan2dist, mgarepo, poe, etc)

it used to feature a tk window with one tab per module being investigated - but this was troublesome for people wanting to have a cli. so i just released a new version of cpan2pkg which brings a --text flag (or -T for the lazy ones) which works on the tty. of course, we loose the ability to interact with the application, but that's still convenient sometimes. and of course, the tk version is still available!

prisk gains its own map format, allowing translations!

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! :-)

cpan2pkg: prettier gui, ready for mageia!

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!

keep track of your tk widgets easily

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?

tk::action to simplify access to a gui action

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

this is not fun.

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

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

sweetening tk

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

the state of perl in mandriva 2010

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 :-)

external event loops no more part of poe

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

prettyfying tk apps

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

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

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

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