on testing

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

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

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

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.

right trimming for dzil autoprereq plugin

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

app::cpan2pkg now on cpan!

app::cpan2pkg 0.3.0 is currently spreading its way on cpan. since it's the first public release, give it some time to propagate.

you should be able to download it soon, and then play with it:

cpan2pkg Foo::Bar Acme::Baz

here's a list of what it's doing:

• check if module is already installed locally
  
• check if module is provided by your distribution
• install from your distribution if possible
• find the module prereqs and starts over for each of them
  

note that only mandriva is supported currently. i intend to support more distribution later on (read: after v1.0.0), but don't hesitate to join the fun if you want to add support for your distro right now!

next steps are synchronizing prereqs, running cpan2dist for the module, importing resulting package into upstream...

since it's a bit rough on the edges (curses::ui is not the best toolkit ever - i'm waiting for your new toolkit dams! hint, hint), i also plan to have a better gui someday...

once again, don't hesitate to ping me if you want to contribute. the git repository is online: clone it, everyone can also push on the mob branch, or i can even give you commit rights on it.