the perl 5.12.0 - 5.12.1 upgrade was really smooth: no patch to rediff, reapply, etc. that's definitely a good thing for perl maintainers to have a stable series with only critical fixes going in. i've already said it, but thanks again to p5p!
since my needs were not all covered, i contacted alias with some of my ideas. he kindly gave me a commit bit so i can scratch my itches at will...
i therefore implemented xdg support for recent unix desktops, with daxim's help. this means that unix platforms with gnome, kde or any recent desktops won't report $HOME as the one and unique answer to all those questions. this feature is available in released file-homedir 0.91 - towards a cleaning of our homedirs, yay!
still in the work (not yet released), i've also checked in a my_dist_data($dist) function, to standardize the directory where the application will store its internal data, such as database or cache. it is located in:
my_data()/Perl/dist/$distfollowing the now traditional data/vendor/application scheme (on legacy unix desktops, the directory will be $HOME/.perl/dist/$dist/var, to be sure that it's a hidden directory). to be consistent with file::sharedir, i guess i'll also implement my_module_data($module), following the same reasoning.
this will likely be released in version 0.92, before working on the last remaining bit on my plate: my_dist_config($dist), returning a directory where an application will be able to store its configuration. it's a bit different of the data directory (even if config is some kind of data): data is supposed to be transient, or can be removed without harming the app - while the config should not be erased. however, it's not really as straightforward as the data directory, since not all platforms support this: on windows, users are not supposed to update config by hand, so it's often stored in the registry... so how to preserve the cross-distribution nature of file-homedir for this very feature? this will require some thinking...
finally, it's with great pleasure that i'm announcing file-homedir-pathclass, which is a convenient wrapper around file-homedir returning path::class objects. alias did not want to introduce it in file-homedir to preserve compatibility, and suggested to release it as a new dist... so i released this new module, allowing to write for example:
perl -MFile::HomeDir::PathClass=-all -E 'say $_ for my_home()->children'
the easiest way to retrieve those information is of course to use image::size:
easy, wasn't it?
however, as mentioned previously, retrieving those information is often just the prelude before doing some transformation to the image itself. and image::size, while doing it perfectly, does only one thing - it cannot be used for any other image manipulation. so if you intend to use another module after, you can as well use this other module to retrieve this information: that'll be faster (image read only once) and use less memory (only one module loaded). here's how to get those information with image::magick:
it wasn't that difficult, and opens the whole image magick world to your program!
those questions aren't rethorical, when playing prisk. because, when you exchange 3 cards to get reinforcements, you also get bonuses if you exchange a card representing a country that you own. and if it's easy to check at a glance if you own china when playing classical risk map, it's another challenge to locate thule on godstorm map.
therefore, i'm glad to introduce latest prisk version (3.101510, currently on its way to cpan). in the card window, one can now double-click a card, and this will highlight a country on the big map. this way, you'll know exactly which card to exchange (or what country to invade) in order to maximize your reinforcements. happy invasion!
(remember that i'm always welcoming code contribution or new translations)
without further ado, here's a snapshot of the new shiny feature:
also new in version 3.101430, the ability to run prisk directly from the checkout. previously one would need to run "dzil run ./bin/prisk" since file::sharedir requires a fully built + installed distribution before finding its stuff. now, prisk detects if it's running in a local checkout, and will bypass file::sharedir.
the code is on github where you can fork it: patches and translations welcome!
anyway, i get to cast my vote. i don't really care the hair colour, but the talk bit is more interesting. before you guys start submitting ideas such as why php/ruby/python is far better than perl, remember that:
- mst started the challenge to help perl get known. finishing by forcing him to praise another language seems to be against the rules. not even speaking of this not being very classy...
- the talk will be heavily advertised (at least in the perl community). are you sure you want to offer such a gallery for another language?
so here's my vote, mst!
in the meantime, this does not preclude you to continue blogging...
 of course, mst can game the talk by showing a single slide with "nothing" on it, but, that, again, would not be very classy. and mst would not settle on such an easy end, would he?
 for the pink or orange fans around there
those days, i feel like working on prisk, the risk clone that i wrote in perl. i added full internationalization, and contributed the first foreign language (french, as you may have guessed :-) ).
you can contribute translations for your language by forking the project, and then sending a pull request with your changes. it should be quite fast, since it only features 73 strings to translate. you know what to do... :-)
note that i also fixed a crash that was appearing sometimes during game startup. i'll now try to find some time to work on bigger topics, such as sanitizing the whole codebase, or adding features...
on the perl front, mandriva 2010.1 will therefore ship:
- perl 5.10.1 (5.12.x has been postponed to 2011.0)
- padre 0.60
- parrot 2.3.0 and rakudo 2010.03
- ... and 1912 dists from cpan!
anyway, the tutorial is a nice read for those wanting to learn dist-zilla. there are some glitches here and there (eg, it still mentions AllFiles plugin instead of GatherDir, and other v1 to v2 misses - i'll send patches), but is otherwise wicked cool.
and some of my plugins are even mentioned! :-)
however, decision has been taken not to push perl 5.12 in spring release. potential for havoc is too important - especially since it's used by many core tools. it'll have to wait after 2010.1 is out... but since all bits & pieces are ready to be pushed, it's now just a matter of time...
i now need to have more thorough testing, in order to see if urpmi & other tools still works with new perl. i don't know if i'll have time before mandriva 2010.1 freeze date. not counting the fact that we'll have to create a c-wrapper to replace suidperl used in one of the draktools.
so, back to the question: perl 5.12.0 in mandriva? yep, "soon" - but maybe "soon" will mean "after 2010.1". note that if you can help testing, "soon" may revert to a true "soon" meaning...
however, i'm now really glad i started using it. speed is no longer a problem, and it provides really nice features. cia integration, network graphs, comments on commits, watching repos (even if i'm not totally happy with it right now), and of course... pull requests!
i was away this week-end, and found 4 pull requests in my mailbox for my modules when i came back. integrating other's work has never been easier with git and github which allows people to fork at will. that's the new way of writing code: create the basic stub of your module, and wait for others to enhance it! :-) git plugin for dist-zilla now supports pushing to a different branch, supports the new dist-zilla-tester framework and the bundle @git now accepts multi-valued args.
dvcs are a bit harder to grasp at first, but once you understand the concepts, they're really a killer application - especially when coupled with a cooperative platform such as github.
but it's only one side of the activity floating around dist-zilla... indeed, as dagolden, aevar and others try dzil, they (of course) like it, and start contributing their own plugins.
here's a list of new plugins landed on cpan... first some additional author tests:
- CheckChangesTests - check changelog
- CheckExtraTests - runs xt/ tests, but don't copy them to t/
- DistManifestTests - check manifest
- HasVersionTests - check all your modules have a version
- KwaliteeTests - check your kwalitee
- MinimumVersionTests - check minimum perl version needed
- PodSpellingTests - check pod spelling
- PortabilityTests - check if your code is portable
- SynopsisTests - check if code in your synopsis compiles
- UnusedVarsTests - detects unused vars
- ReportVersions - additional test to report version
some plugins to complete meta-data:
- Bugtracker - http://rt.cpan.org/Public/Dist/Display.html?Name=xxxx
- HomePage - http://search.cpan.org/dist/xxxx
some plugins to generate additional files:
- FatPacker - creates a script with all dependencies packed
- InstallGuide - creates an INSTALL file
- ReadmeMarkdownFromPod - README.mkdn file
some plugins to compute your next version number:
- BumpVersionFromGit - version taken from last git tag
- VersionFromPrev - classic perl versions, 1.00 to 1.99
and finally some bundles:
you can install all of them in one go via task-dist-zilla.
they are also available in mandriva, and suggested when installing dist-zilla...
the same kind of question can be asked for obsoleting a given module. there's (afaik) no way to tell cpan / cpanplus that foo::bar is replacing bar::foo... those problems are tackled for linux distribution packages, could we reuse some of their logic here?
first, there was some test fixes to work with latest dist-zilla (thanks to ricardo), and also to support git 1.7.
the git plugin then saw support for annotated tags which is now the default - but christopher madsen restored the possibility to use lightweight tags. he then refactored commit message generation, in order to allow a custom commit message. not only that, but he also brought to ability to specify which files are allowed to be dirty, and automatically committed.
then david golden jumped in, and scratched his itches: support for empty lines in changelog and possibility to specify which branch(es!) to push to. all of that with new tests - and some existing test fixes! \o/
git support in dist-zilla is now in a pretty good shape. report bugs if you miss your pet-peeve... or even better: fork the code and send me pull requests once the code is doing what you want!
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! :-)
in a typical graphical application, menu entries are often also available in toolbars or other widgets. and sometimes, you want to enable or disable a given action, and this means having to update all those entries and widgets everywhere this action is allowed / forbidden.
this is not fun.
therefore, i wrote tk::action, a module to help managing actions in a tk gui: just create a new object, associate some widgets and bindings with
add_binding() and then de/activate the whole action at once with
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.
too bad, since mst managed to gather the perl community to make some noise on the web. maybe an update could promote a second life to perl blogging?
for profiling perl, just use devel::nytprof. it's an easy to use perl profiler:
when this is done, just point your brower to the locally created ./nytprof/index.html and enjoy the nice reports.$ perl -d:NYTProf my_prog.pl
[... let it run, it will be slower than your usual run ...]
this is the best profiler for perl available currently. in case you missed the point: the perl profiler devel-nytprof is great, use it for your perl profiling needs.
my first version was regex-based. i can already see your horrified face - but really it wasn't so bad, since it only needed to find some specific statements such as uses and requires. current version is using ppi, which is better suited for corner cases.
however, long-term makes me think that it would be better to rely on an external module. so, what are the alternatives out there on cpan, and can i use them in autoprereq?
- b::perlreq - parses the file, but reports file (File/Basename.pm) instead of modules, and is generally more suited for rpm
- module::extract::use - using ppi to parse a file, but extracts only use & require statements (no inheritance, moose roles, etc). also, it reports no minimum version extraction, only a list of modules.
- test::dependencies - using either b::perlreq (see above) or a regex scheme underneath
- module::scandeps - runs the file (which is slow), and finds all modules included - and sometimes a bit more (eg: file::homeDir::darwin is found for a module using file::homedir, even on a unix platform). can also run as a static analyser, but calls cpanplus (?!) which is slow.
- module::info - regex based
- module::cpants::generator::prereq - parses makefile.pl, where i want sthg that parses actual code
- module::cpants::kwalitee::prereq - parse meta.yml, makefile.pl or build.pl
i'm now waiting for a new release of this module with my enhancements, meaning that i can get rid of this part of the code in dzil autoprereq. which was, if you recall, the original goal! :-)
this module is basically a sqlite database replicated automatically by orlite::mirror. using it is very simple - for example, couting the cpan dists shipped by mandriva is achieved by the following snippet:
(fyi, the result is 1899 as of writing, +1 since i just imported the module itself)
at module use time, it will automatically download (and cache for a week) the sqlite database. and one can then use the module as an ordb for this db... the module does not however produces the stats for you - so alias & gabor, now is your turn to work! :-) i'm waiting for your top-100 most wanted mandriva or whatever crazy stats you'll want to produce.
the database itself is generated by module::packaged::generator. this module uses different drivers depending on the current linux distribution (but nothing prevents *bsd to also have a driver) it runs on. only mandriva is supported currently, but ryan will work on a debian driver. all other contributions are most welcome - the code is on github: fork it and send me pull requests!
it took a bit of time since the "installer" detection is spread out in different places in padre... this needs refactoring, for those interested.
on the it-s-the-details-that-count front, dzil clean will now remove *~ files lingering in your local copy.
dzil command now accepts a -I argument that adds a directory to perl @INC (same as perl's -I option). which means dzil plugin author can now do:
and release their distribution using the latest version of their plugin...$ dzil -Ilib release
a new run subcommand has been added, which is doing more or less the following:
which means you can now do:$ dzil build
$ rsync -avp My-Project-version/ .build/
$ cd .build
$ perl Makefile.PL # or perl Build.PL
$ make # or ./Build
$ export PERL5LIB=$PWD/blib/lib:$PWD/blib/arch
$ launch command defined by rest of your args
the first one is specially useful if you're using file::sharedir and don't want to add extra hooks detecting whether it runs in a dev checkout or not.$ dzil run ./bin/myscript
$ dzil run prove -l t/unit.t
$ dzil run bash
speaking of sharedir, i crafted a quick'n'dirty implementation that made modulebuild plugin automatically install an existing share directory (which is possible since module::build 0.36). rjbs then re-factored it to use the installdirs plugin. nperez then finalized the work for the makemaker plugin. so if you have a share directory, it will now be automatically recognized as such by dzil and installed accordingly.
rjbs just released a new version of dist-zilla with those enhancements (and other stuff).
it still takes time to install all those modules, but at least you can do it in one go with cpan or cpanplus: no need to install them one by one manually.
of course, if you're on mandriva, running:
will install the package perl-Dist-Zilla and all its deps while also suggesting to install all the dzil plugins...urpmi perl-Dist-Zilla
- 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!)