Monday, 25 May 2009

Catalyst/Mojo Plugins for Padre now in 8 languages!

Catalyst is an amazing web framework, but requires a little learning effort before you get to do all the cool stuff. Mojo still needs some work (specially documentation-wise) but it's catching up as a solid simple-yet-powerful alternative for web development, specially if you're Perl begginer. As you may know, both of them have Padre plugins to further easen your developing process. To make it even easier, the new versions of Padre::Plugin::Mojolicious (0.02) and Padre::Plugin::Catalyst (0.03) now have localization support, so menu and messages can be displayed in your native tongue! Problem is, I don't know what your native tongue is ;)

Right now, they're already translated in these languages (besides original english, of course):
Is your native tongue not listed? Then please add support for it! You can find both plugins on Padre's svn repository. Let me know if you need any help creating a .po file from messages.pot. Also, since both Cat and Mojo plugins share almost the same messages, if you translate one of them, the other should be a quick and easy copy/paste process. Heck, I can even do it for you if you're too lazy ;)

Many thanks to all translators! Also, many thanks to jq, who did an excellent job adding translation support for plugins on Padre, and to szabgab++ for the impressive effort on enabling translation for all plugins under Padre's svn repo. Now we could really use your help translating not only these, but all of Padre's plugins!

Friday, 15 May 2009

Test::More memory issues

You gotta love testing. And, writing Perl code/tests, you gotta love Test::More. It has a great API, it's cool, it's fast, it's stable, it's leaking memory... "Say what?!"

Yeah. I mean, it's not leaking leaking, just eating more memory at every test you run, be it is(), ok(), or whatever. See for yourself:
use Test::More qw(no_plan);
while (1) {
If you run this, you'll see memory consumption for the process going up at a very fast pace (use top or any other viewer), this is what it looks like on my system after 40K tests (a couple of seconds using the code above):

After a quick stop by #perl-qa, rjbs++ said it was a feature, not a bug. Apparently, Test::Builder (the backend for Test::More, Test::Simple and their siblings/derivatives) stores each test result, so by the time you're at 50_000 results, you'll have 50_000 hashes in memory, even if they are all just PASS tests.

This does explain the ever-increasing memory issue, but it's still a no go for me. Although 95% of Test::Builder users will never see this as a problem, I'm doing a lot of combinatorics tests, so a single .t of mine has to go through well over 500K tests, hitting a memory wall real hard.

Now, if you stumbled in that same problem, don't panic: there are at least two possible workarounds for it.
  1. Split you combinatorics tests into smaller test files, picking the variable with the most possible...erm... variations... and turn it into a different constant for each test file. If you picked a good one, the number of tests on each file will be exponetially decreased and the collected test data won't be such a memory burden.

  2. If you have huge/nested loops in your tests, you can take a reverse approach and instead of using "ok or not ok" functions, use "normal" (code) compares, triggering fail() if something bad happens. This way the testing framework will only store the history of failed tests, eating as little memory as possible.
Just a couple of hours before my "potential bug" report, Schwern++ replied confirming it was "working as designed", and was kind enough to patch those workaround tips in the "CAVEATS and NOTES" part of the documentation for Test::Builder (as it affects everything, not just Test::More). I really should thank Apocalypse++ for talking me into writing it :)

Of course, I still hope to see this problem go away in future releases, and (fortunately for me) so does Schwern. According to him, this was one of the design issues which brought Test::AtRuntime to a halt. As a result, his upcoming Test::Builder2 will have the ability to turn off history and the history sub-system will be a separate object. There also might be a happy medium where history contains just a count of each type of result - just as I hoped - which will allow most of Test::More's features based on knowing the results to continue to work while not eating up too much memory in a long-running test file.

Yay for testing, and for the Perl QA community!

Saturday, 9 May 2009

Testing Differences in Templates

I've been doing some template refactoring now, and since I want to make sure the new templates render exactly the same as the old ones, I used Schwern++'s Test::More to compare their outputs for all combinations of input variables I had. Things were great for the first small-and-obvious changes, but at some point both outputs looked the same to me, and yet were still failing the test, meaning something was off. But what?

A quick CPAN search pointed me to Barrie Slaymaker++'s Test::Differences (now maintained by Ovid++). After that, all I had to do was replace my is() call with eq_or_diff() and voilá:

#   Failed test 'templates should produce the exact same output'
# at t/refactoring.t line 128.
# +---+------+---+----------+
# | Ln| Got | Ln| Expected |
# +---+------+---+----------+
# | 3 | | 3 | |
# | 4 | | 4 | |
# | 5 | | 5 | |
# * 6 |\t\n * 6 |\n |
# | 7 | | 7 | |
# | 8 | | 8 | |
# | 9 | | 9 | |
# +---+------+---+----------+
Ha! Much easier, much direct. After a simple extra tab removal, all tests were successful and I could move on. Yay!

Friday, 1 May 2009

Padre + Mojolicious

You most likely already know about Padre, the Perl IDE (if you follow this blog you do!). It's quickly becoming a great environment for beginners to learn Perl, and is already proving itself useful to some seasoned developers as well.

Recently, I talked about my Catalyst Plugin for Padre. It's also turning into a hit (yay!) and will hopefully help a lot of people doing web development in Padre. But Catalyst, amazing as it is, can impose a somewhat high learning curve for beginners, specially those not very familiar with (the also great) Template Toolkit and DBIx::Class.

This is where Mojolicious enters the scene.

Mojolicious is a next generation MVC web framework focused on minimalism and simplicity. It comes with the Mojo backend, a "framework for web frameworks". Through constant development and the tireless efforts of sri++, vti++, charsbar++ and several others, Mojolicious offers state of the art technology to deliver an environment where it is simple enough for beginners to get started, and powerful enough to just keep you going all the way.

Mojolicious is not a replacement for Catalyst, or vice-versa. They are just different approaches to the same problem and, although separately, both teams work very closely with each other (in fact, sri was -the- founder of the Catalyst project, and marcus++ is a channel op at #mojo on You should simply pick the one that best suits your experience and needs. And now you can do it inside Padre, too!

Padre::Plugin::Mojolicious incorporates helpers for Mojolicious inside Padre. Its behaviour is pretty much like the Catalyst plugin, letting you create new Mojolicious web applications, start and stop the webserver, and review some of the documentation.

Enjoy! And let me know if you have any suggestions to further improve it :-)