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.

cpan modules & native linux packages

cpan is great - one finds a lot of modules for really everything. the problem comes from installing those modules.

indeed, your system comes with a perl and some cpan modules packaged for your distribution. and mixing them with modules installed directly by cpan(1) or cpanp(1) is the best way to wreck havoc on your system.

enters cpanplus backends, allowing one to easily create native linux packages for you distribution using:

cpan2dist Foo::Bar

pretty straighforward, assuming there's a backend available for your distribution...

so i created cpanplus::dist::mdv, and life was good: i created rpms when i wanted some new modules. it has even become the official way to create rpm packages from cpan modules for mandriva.

unfortunately, it's still not enough, even if jos agreed to integrate a --install flag in cpan2dist to install prereqs after building them.

indeed, you don't want to build a prereq when this one might be already available from your distribution. moreover, once a package is installed, you'd like to submit the new package to your distribution, for other users to benefit from them (assuming you're a contributor for your distribution).

lazyness helping, i always let it go. but lazyness strikes back: always repeating the same steps to check if a prereq is provided by mandriva, building them or installing them, and then submitting them is not that a good way to spend my time.

so one week ago, i've decided to create an app::cpan2pkg module (not yet on cpan), a curses application build around cpan2dist and taking care of every itch mentioned earlier.

it is really a glue application, meant to reuse existing command lines, but taking the decisions automatically and chaining the steps.

note that it's called app::cpan2pkg, and not app::cpan2mdv. i intend to write it so that one can adapt it to other distributions workflows. of course, currently i'm focusing on mandriva, the distribution i'm using. but if others want to plug in, they're more than welcome!

it is currently in version 0.1.0 (except to see it soon on cpan), and is able to extract the module prereqs. i'll let you know about the progress...

how to shave 10% speed?

contributing to other projects is good (not counting the fact that it's fun):

• you help open-source as a whole
  
• you gain some knowledge on the projects you help
• ... and you discover some new stuff, techniques, tricks

so recently i've been helping the padre team, where i discovered the module class::xsaccessor. reading the pod, it seemed quite good, but the question was: is it really that interesting?

so, i decided to try that on language::befunge, which currently uses a mix of class::accessor::fast and hand-crafted accessors (man, some part of the code is untouched since 2002!). who recalls of using the following in his/her code:

BEGIN {
my @attrs = qw{ attr1 attr2 attr3 };
foreach my $attr ( @attrs ) {
    my $code = qq[ sub get_$attr { return \$_[0]->{$attr} } ];
    $code .= qq[ sub set_$attr { \$_[0]->{$attr} = \$_[1] } ];
    eval $code;
}
}

anyway, i created a new git branch in langage::befunge's repository, and ported all my classes to use class::xsaccessor. and then i've run both the module's test suite and mycology:

• current language::befunge: tests = 5.28s, mycology = 20.48s
• using class::xsaccessor: tests = 5.12s, mycology = 18.18s
  

(everything ran once to warm cache, and then averaging three passes. all output directed to /dev/null in order not to pollute cpu measures with io)

that is, around 5% saved (a bit less) for the tests, but 10% (a bit more) for mycology. knowing that the tests are not representative of real befunge workload, this means a 10% speedup in befunge programs... neat!

needless to say that i merged this temp branch (ain't git cool?) to master, and language::befunge 4.09 is on its way to cpan!

conclusion: use class::xsaccessor, it fulfils its promises... and contribute to other projects, at least you'll find some ideas for your own projects!

hats off to translators!

i'm the kind of guy who prefer (most of the time) using the english locale for the applications i'm using.

however, being part of padre's development team, i'm updating the french locale (we try to remove everything that can be a barrier for people new to padre).

and this made me realize how time-consuming and difficult it is to correctly translate an application. indeed, you don't understand the hard work needed for a task unless you are to do this task yourself...

so, my hat off to the many translators that are working on open-source projects: even if your contribution has a lower profile than code, your task is nevertheless important!


ps: and if you think that you could:

• make a better translation job than me
• contribute a translation for your language
• or even add features

to padre... join us!

befunge on parrot fix for "sgml spaces" error in mycology

my bad - mycology was right, i was wrong. when spotting an error in my befunge interpreters, i should trust matti and look in my code. :-)

the sgml spaces mycology error mentioned previously came from the instruction ` which is greater than, not greater than or equal.

so i fixed it, and befunge on parrot now passes completely the befunge 93 mycology tests.

befunge on parrot interpreter now working (again)

it all started with a discussion on #parrot:

Dec 28 19:17:27 <kj> don't think zcode is still being maintained
Dec 28 19:19:16 <rurban> Looks like so, yes.
Dec 28 19:19:27 <rurban> befunge being the worst.

(funny thing is that i wasn't even here at that time, cognominal reported it to me later on)

as befunge on parrot author, it hurted my pride. i could stand that befunge wasn't the best parrot language implemented, but being the worst... i had to do something!

so, after some time to compile parrot (didn't did that for 3 years, it's now way easier!), getting up to speed to groak parrot error messages, i started porting befunge on recent parrot.

i took the opportunity to move from pasm to pir, using neat addons such as subs (even with parameters and return values!), named vars, random pmc (instead of pseudo random stuff using mod and chicken sacrifying) and other welcome stuff that were not available in 2002 when i first implemented befunge on parrot.

the result is a working befunge-93 implementation on top of parrot, and befunge now passes its tests:

$ make test
../../parrot -o befunge.pbc befunge.pir
cd .. && /usr/bin/perl5.10.0 t/harness --languages=befunge
befunge/t/basic....ok
All tests successful.
Files=1, Tests=1, 1 wallclock secs ( 0.06 cusr + 0.01 csys = 0.07 CPU)

i also checked this implementation with mycology, and it seems to work:

• plain mycology: reports a failure on sgml-mode, but that's a bug in mycology
  
• mycouser: success, before jumping to befunge-98 library semantics, where it fails (of course)
  
• mycorand: success
  

so, all in all, befunge on parrot is once again alive and kicking!

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

audio::mpd::common 0.1.4 released

still due to recent mpd 0.14 availability, audio::mpd::common 0.1.4 is on its way to cpan.

changes:

• missing tag last_modified in amci:playlist (new in mpd 0.14)

audio::mpd 0.19.5 released

audio::mpd 0.19.5 is on its way to cpan.

changes:

• updates to match mpd 0.14 behaviour (released for x-mas)
• doc update

the new idle command is not (and will not be) implemented in audio::mpd, since it requires non blocking sockets and i don't want to deal with them in this module. it will be implemented in poe::component::client::mpd, though.