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

spell check in padre now supports multiple languages... kinda

reshaping the spellcheck plugin for padre to provide a decent interface was my first goal when i took over its maintenance. fulfilling this goal deserved to bounce plugin version to 1.0.0, but that's not the end of my plans...

therefore, i just released version 1.1.0, allowing to change the dictionary language in the preferences dialog of the plugin. you need to have the wanted dictionary installed (note that you can pick only installed dictionaries), otherwise aspell will not work correctly... of course it won't crash anything, you'll just end up with no suggestion and this sort of things.

so, why am i saying that it kinda supports multiple languages? because there is a bug in the styled text control (aka scintilla aka wx::stc) version (1.70) shipped with wxwidgets 2.8.x, which seems to confuse bytes and chars in unicode texts.

this is easily demonstrated by the following snippet:

#!/usr/bin/perl
use strict;
use warnings;
use Wx ':everything';
use Wx::STC;

my $f  = Wx::Frame->new(undef,-1,"test");
my $s  = Wx::BoxSizer->new(wxVERTICAL);
my $t1 = Wx::StyledTextCtrl->new($f);
my $t2 = Wx::StyledTextCtrl->new($f);
$s->Add($t1);
$s->Add($t2);
$f->SetSizer($s);

$t1->SetText("cote");
$t2->SetText("côte");
$t1->SetSelection(0,3);
$t2->SetSelection(0,3);

$f->Show;
sub Wx::App::OnInit {1}
Wx::App->new->MainLoop;

this creates a window with 2 stc, one containing ascii text, the other containing unicode text. then we try to select the first 3 characters in both stc. look how the first stc correctly selects 3 chars, while the second selects only 2 of them:


i hope this is fixed in later versions of scintilla - but even if that's the case, it needs to be integrated into wxwidgets... and current development version of wxwidgets (2.9.x) only has version 1.75 included, which is already 18 monthes old... (if anyone is interested to update stc in wxwidgets, i'm sure they will welcome your help)

so, there it is - the plugin supports non-english dictionaries... but cannot spell check non-ascii texts! that's pretty useless, isn't it? :-(

side note: this plugin version is now locale-aware, and inaugurates the era of translated plugins...

plugins and translation

localizing an application is important if one wants to take over the world with it. this is why we try to localize padre (the perl ide) and translate it in as many languages as possible. (if padre isn't translated in your language, your help would be more than welcome!)

we are using the standard wx localization framework, which is similar to & compatible with gettext. then, using standard xgettext, msgmerge and msgfmt commands, the translators can do their magic and voilà! padre is translated.

this is working quite well.

but now, enter plugins. indeed, to keep padre as lean as possible, non-core features are deported in plugins. and even if padre is still a young project, there are already quite a lot of plugins for padre.

but how to translate plugins?

first (and stupid) solution would be to extract the strings to be translated and add them to padre's messages file. definitely not a good idea, since padre and the plugins do not share the same release planning, and we would end up with strings mismatch between what padre ships and what the plugin uses.

therefore, the plugin must provide its own translation. but that's a bit difficult, since they are not an application of their own: they are running inside padre, an application that already has its translated messages thank you very much.

so we need a way to have more than one strings catalog open at the same time. i had some troubles finding the correct method within wx documentation, but finally came up with:

$locale->AddCatalog($catalog);

$catalog being the catalog containing the new translated strings. and in order not to clash with main catalog (named after the locale, eg "fr-fr" for my current locale), the plugin catalog should be named $plugin-$locale.

but of course, it doesn't work as is. indeed, wx doesn't know where to find this new catalog. so we need to add a new search path to find the locales:

$locale->AddCatalogLookupPathPrefix($directory);

of course, we want padre plugins to be as easy to write as possible, so we don't want plugin authors to have to do this kind of non-sexy things.

therefore, plugin authors just need to define a plugin_locale_directory() method that will tell padre where to look for translated string catalogs. and since the plugins inherit from the base class padre::plugin, they have such a default method which points to the share directory as defined by file::sharedir. therefore, plugin authors don't even need to redefine this method if they're using the install_share instruction of module::install. (i don't like module::install, but that's not the point here)

ok, so plugin authors have one method to add. now they need to extract the strings and translate them (or ask other people to translate them). that's using standard gettext tools, so nothing really gets in the way.

and that's all. because padre handles the loading of new catalogs automatically, as long as they're named $plugin-$locale. that is, if the german translation of Padre::Plugin::SpellCheck is called SpellCheck-de.mo, then padre will find it and make sure that wx translates your plugin.

this is a good thing, because wx is a bitch to program with. that is, you can add a catalog or a catalog path, but you cannot remove them. and you don't want to load all your catalogs at once, to reduce memory load. and padre also takes care of locale switching, unloading previous locales and loading new ones. (unloading as in destroy locale object and create a new one since wx does not know how to remove a loaded locale).

therefore, even for localization, padre plugins are easy to write. why don't you join us and write your own, to have padre behave just how you expect? (using a real programming language that you know and love)

padre gets a new plugin manager

padre, the perl ide, has a plugin system, allowing people to extend it to suit their needs. plugins are written in perl (not in a dumbed down language), and thus one can leverage the whole cpan to extend padre. and since there is a parrot plugin, one can even write plugins in any language supported by the parrot virtual machine. but i digress...

to manage those plugins, and enable / disable them at will, padre is shipping a plugin manager. until now, here's how it looked like:



not really sexy - in fact, it was pretty ugly. and the screenshot has not been taken with all padre plugins available - in this case, the window grows absurdely and expands way beyond the screen edges. not to mention that current plugin manager incarnation is not really useful to know what a plugin really does...

so i worked on it and totally revamped the plugin manager. after much fighting with wxwidgets (and i did not win every time... :-|), here's the result, as available in trunk:



as you can see, the available plugins are now in a list, scaling up quite well with the number of padre plugins that we expect to see in the future. moreover, the plugin status icons show immediately which plugins are currently enabled. finally, there's a space on the right of the window to display the plugin documentation.

what's not visible in above screenshot is that one can sort the plugins on their version and status. and that plugins can now provide their own icon, instead of the default one. now that it has been implemented in the plugin manager, i expect plugins to start using this opportunity quite soon to stand apart...

all in all, i'm quite happy with the new plugin manager. it will be available in next padre release, which should arrive soon. and if you have new wishes or remarks, i invite you to report those bugs / requests to padre's ticket center.

autoformat within padre

one of the things i care about in an editor is the ability to reformat a paragraph. it's really handy if you update your file here and there, and you're left with lines of 15 (or 100) characters.

vim has a nice builtin paragraph-reformatting tool (with gqip), and so does emacs (alt+q iirc). but padre (the perl ide) lacks one...

so i decided to create a plugin that would bring this ability to padre. moreover, it was the opportunity to discover padre's plugin subsystem.

writing the plugin was incredibly easy. especially since i'm standing on the shoulders of giants: i'm reusing the formidable text::autoformat module. in fact, adding the standard build stuff & boilerplate was really what took most of my time... ok, that and fighting a bit with wx stc, which provides everything but the methods i wanted. :-)

all in all, padre::plugin::autoformat is now propagating on cpan. to use it:

1. install it using your favorite method
2. open padre
3. activate the plugin (plugins / plugin manager / autoformat / enable). you only need to do this once, since padre will remember the enabled plugins.
   
4. open a file
5. type ctrl+shift+j to autoformat either current selection (or current paragraph if nothing is selected).
   

enjoy it...