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!

a progressbar for curses-toolkit

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

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

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

migration to moose - step 3

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?

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

moosex::poe ftw!

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.

migrating to moose? hell yeah!

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

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

beginning of moose support in padre

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.

poe::component::client::mpd 0.9.1 released

following other mpd-related modules announcements, poe::component::client::mpd 0.9.1 is, too, on its way to cpan.

changes:

• updates to match mpd 0.14 behaviour

the new idle command is not yet implemented, but will be in a subsequent release (api to be thought of).