next padre version will (finally) recognize dist-zilla projects

padre 0.55, due tomorrow, will finally recognize dist-zilla projects correctly. among other things, it means that it will set @INC accordingly for syntax checking, keep the directory browser at the project root, etc.

it took a bit of time since the "installer" detection is spread out in different places in padre... this needs refactoring, for those interested.

retrospective 2009

2009's over, but the year was quite a busy one for me on the perl front:

• i finally took the time to investigate moose, and decided to port some of my code to use it.
• i discovered dist::zilla, and definitely plan to use it in all my dists.
• i discovered some other cool new perl modules (thanks guys).
  
• i uploaded some new dists on cpan, including games::pandemic (which i'm quite proud of, even if i need to continue hacking on it).
• i updated & released some of my existing dists.
  
• i contributed to other projects such as padre, dist-zilla, etc. sending patches is a good way to thank the author for their work.
• it's even easier to contribute with github, which i'm using more and more for my projects (and it's no more slow by now, woohoo!). of course, git is the master piece allowing this easy sharing.
  
• on mandriva's front, i resurrected parrot rpm, and finally shipped rakudo.
  
• 2009 was also the year of the great migration to %perl_convert_version
• ... with lots of new perl modules available as rpm (i am managing 450 of them).
  
• ... and finally i took ownership of perl rpm. (thank you perl5 porters btw for 5.10.1 and the push for next stable version!)

so, busy indeed 2009 was... i just hope that 2010 will be as fruitful on the perl front for me, and for the perl ecosystem by large.

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

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

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.

prepender distzilla plugin can add boilerplate copyright

following autarch's advice on yesterday's post, i just uploaded dist-zilla-plugin-prepender 0.2.0 that accepts a copyright option to automatically add a boilerplate copyright at the top of the files.

yet another things that ease an author's life.

i'm still unsure with the strict and warnings options. not because of the test argument, but because of the editing argument. indeed, with padre (the perl ide) doing live syntax check, i want the syntax check to be done with all due stricture...

autoformat and nopaste plugins join padre's nest

after much hesitation, i finally decided to migrate the autoformat and nopaste plugins to padre's svn repository.

not that i prefer svn - after all, i used git for a reason when i started those plugins - but it's handy to benefit of padre's translators for my plugins for free... (btw, if your language is not supported, you're more than welcome to join padre's development team!)

but the nice thing is that gabor told me that if padre gets a good enough git plugin for padre, he will switch padre's repository to git!

good enough here means that even people unfamiliar with git can use it, whatever the platform (yup, windows, i'm staring at you)... and btw, do you remember that there's an on-going contest for best padre plugin?

so what are you waiting for?

padre 0.35 released

on behalf on padre's development team, i'm happy to announce version 0.35 of padre, the perl ide. it is available here, and here's the full list of changes.

some of the highlights are:

• single instance support
• context-sensitive right-click menu for perl documents
• ctrl+left+click on a perl variable / function will jump to its definition
• launching a browser now happens in the background
• new translation: japanese
• various fixes and bug closing

please report any test failure via the padre-dev mailing list or via our bug tracker.

enjoy!

best plugin for padre contest

for those of you that missed it, i remind you that you have one month to come up with the best plugin for padre...

take this chance to discover padre, and see how easy it is to work with/on it! what are you waiting for?

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 does spell check

padre, the perl ide, can now check a text for spelling mistakes. this is done with the padre::plugin::spellcheck plugin. new version 1.0.0 is currently propagating on cpan, and should be available soon.

so, how to use it? the first step (beside installing padre and the plugin) is to enable it. open padre, go to plugins menu, open the plugin manager, then select the spell checking plugin, and click on enable:


(you will notice the nice icon, courtesy of mark james - open-source definitely needs artists besides coders)

of course, this should be done only once. that is, if you already tried this plugin, you don't need to re-enable it. (but if you already tried the plugin, then i can imagine that you're quite familiar with padre, and that you don't need this explanation)

so, the plugin is enabled, and you can now close the plugin manager. open the file that you want to spell check, and just press f7 (which seems to be the standard shortcuts among text processors to launch spell checking). this will check your text, and if there are some mistakes, it will open the following window:



the offending text will be selected. the buttons do what one can expect.

some things to note:

• only english is supported right now. this will change later on.
• the add to dictionary is not yet implemented.
• this plugin is using text::aspell (the perl bindings for aspell) underneath (yes, this means you need to have aspell installed on your machine). in the future, i plan to allow one to change the low-level options of aspell...
• check spelling a program is not a good idea. however,since aspell supports some filtering modes, i'll investigate them.
  

and don't forget that you're welcome to join the padre development team! we could use more contributors...

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

spoiled by padre

a few revisions ago, padre (the perl ide) introduced unicode specificities in wxwidgets.

unfortunately, the perl wx bindings shipped by mandriva are not unicode-aware. in fact, even if the wxwidgets library shipped is unicode capable, the perl bindings were specifically building against the ansi version. the bug has been reported and should be fixed soon.

however, in the meantime, i'm back to using something else than padre... and this sucks! no easy module profiling, no on-the-fly syntaxic checking, etc.

sure, those things could be introduced in my replacement editor (vim). however, they do not feel as natural as those features are in padre.

sure, padre has still a long way to go before matching some features available elsewhere... but it already has features that i can't live without when coding perl. and this is quite incredible when you think how yound padre is...

boy, i wish my padre will be back soon! :-)

padre 0.26 released

on behalf of the padre developpers, i am happy to announce the release of v0.26 of padre, the perl ide!

it took a bit longer than previous releases, because of the complete configuration layer rewrite.

now that the config revamping has landed, and with the previous plugin api cleaning, padre should now be stable for the next months (famous last words, i know). this would be a perfect time to start contributing!

full list of changes can be found here:
http://svn.perlide.org/padre/trunk/Padre/Changes

wait till cpan catches up or install by

pip http://www.perlide.org/download/Padre-0.26.tar.gz

thank you to all padre committers and supporters.

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!