Mojo Perl web framework logo

Here’s my take on Mojo 0.8.7, a new web framework for Perl.

The primary author of Mojo, Sebastian Riedel was once as a primary contributor to Catalyst. There are clearly some similarities, and it’s easy for me to see Mojo as an evolution of Catalyst.

One major difference with Catalyst sparked my interest in Mojo. Catalyst now depends on Moose among other things, with a very long overall dependency change. How long? I downloaded Catalyst 5.8 along with all of it’s non-core Perl module dependencies. The result was over 250 modules, not counting the Catalyst modules themselves, or anything in the Test::* name space. Bleh.

What to see for yourself? Get my “self-contained” patch out of the local::lib tracker and run the following. It will install Catalyst and all it non-core dependencies into a “Catalyst” folder. Be aware, this could take half an hour or more… (The TinyURL points to a Catalyst 5.8 tarball)

1
2
perl -MCPAN -Mlocal::lib=--self-contained,Catalyst  \ 
-e 'install "http://tinyurl.com/5hbzoo"' 

Leaning on dependencies can be a great thing. It works well when you are able to outsource part of your needs to an external module that is already well written, documentation and tested. I’m sure there’s some of that happening in the Catalyst dependency chain. But there’s also a good deal of duplication, as different authors solve things different ways. For example: Exporter.pm, Sub::Exporter and Moose::Exporter all serve the same function, and are dependencies somewhere along the way. Class::Accessor::Fast competes with MooseX::Emulate::Class::Accessor::Fast. And this is where a long dependency chain can start to look and feel like bloat, and it can be difficult to overcome if the owners of the dependencies don’t share the projects preferences about how to export subroutines or build accessors.

It could perhaps be said though that Mojo suffers from re-using too little. Mojo::Base is yet-another accessor-generation solution, like Class::Accessor.

The potential I see in Mojo is the summed up in the following:

  • No dependency chain, for less complexity and easy deployment
  • Built-in support for several backends, for portability
  • A rewrite of HTTP request and response objects, as a sanely designed evolution of what CGI.pm has been used for
  • No ties to a specific framework design beneath the server/response-request object layer, for flexibility and potential code sharing between frameworks based on it.

It is this last item that has allowed me to ignore the bundled Mojolicious framework for this review– It’s not required for use with Mojo and could use it’s own review.

Overall, I feel positive about the Mojo project, although I have no current plans to quit developing with Titanium-style projects myself. In theory, they could be used together. Mojo could provide the backend-server support and query object, and CGI::Application could run inside the Mojo handler() in much the same way CGI::Application apps can run in a mod_perl handler. Now, CGI::Application can already run under various servers and with different query objects, so whether or not you’d actually want to use CGI::Application with Mojo is left up to the reader.

I don’t recommend using Mojo yet– it needs more documentation and tests for my taste. It’s Mojo’s clean, scalable and extensible design that make it a project worth following. I’ll be keeping my eye on Mojo.

This post is being discussed on reddit.com

Darcs logo To review darcs 2, I reviewed hundreds of bugs entries in the darcs bug tracker, checking to see whether the bugs were fixed are still present. Through this process I became as intimate as the developers with what had been improved in darcs and what remained to address.

What I found was that darcs 2 closed over half the bugs in the bug tracker, literally hundreds of bugs. This was possible because it addressed not just specific bugs, but whole categories of bugs were closed by major architecture and design improvements.


Major bug fixes

  • Darcs 1 was unfortunately famous for "hanging" at times as it calculated the resolution of complex patch conflict cases. This was a tough issue to solve, but is largely solved with darcs 2.
  • Darcs 2 no longer considers identical patches or patch "hunks" a conflict.
  • Darcs 2 has important safety improvements. With new repo formats available to use, darcs 2 is more resistent to repository corruption caused by third parties, like a stray recursive find-and-replace function that gets into the repo directory. It will also create backup files in cases where it did not before.
  • Darcs 2 replaces the concept of "partial" repositories with "lazy" ones. There has always been a desire to allow "lightweight" checkouts that don't include the complete repo history. The darcs 1 solution to this was "partial" repositories that only checked out history up to a point. This approach worked to some extent, but didn't play with well with darcs commands that expected the whole history to be present. The new "lazy" concept offers similar benefits, and will pull down older remote patches on demand if some command needs them. Lazy repositories are a great comprise between features and performance.
  • Darcs 2 fixes some broken darcs 1 repositories. In some cases a darcs 1 repo could get a bad state so some commands didn't work. Often these repos could be converted into the darcs 2 format, and would be "fixed" when used with darcs 2.

While darcs 1 was and is a useful tool, darcs 2 fixes some significant bugs that restricted some kinds of uses in the past.

New Features

To summarize the feature improvements: darcs 2 provides a more polished user experience. Here are highlights of the new features:

  • Better progress reporting. In places where the user may need to wait more than a second or two for a response (Say, pulling over HTTP or SSH), darcs 2 is able to give live progress updates. There's often an option to turn up the detail level with '--debug' and '--verbose' flags.
  • Performance improvements. Darcs 2 has an option to use a new "global cache" system which speeds up some kinds of operations. Performance when operating over SSH is improved as well. There does remain room for improvement here. Very large projects may not be satisfied with the performance, and "darcs whatsnew --look-for-adds" remains noticeably slow when compared to competing tools.
  • Better error messages. Users who run into exceptional cases are more likely to discover error messages that make it clear what to next, without consulting a reference or mailing list.
  • Better integration with external tools. Darcs has improved the "post commit hook", allowing better automation for tools would operate on every patch that is pushed to a central repo. The darcs project made direct use of this feature, allowing it to close a bug tracking ticket simply by including the right phrasing in the name of a patch.
  • Better handling of binary files. With darcs 2, you can make all the files in particular directory as being binary, rather than just using pattern matching on the file names.

Under the hood

There a few important details to know about what's under the hood of darcs 2.

First, backwards compatibility is in there. There is a strong set of automated tests that insure that darcs 2 works as well as possible with repos in darcs 1 format. You can upgrade to darcs 2 now even if some of the repos you need to access will remain in the darcs 1 format.

Quality Assurance tools have been been improved. While end users won't notice directly, they benefit from the improved quality assurance practices of the darcs project. The large automated test suite is now better organized and more portable. Further, a new "Buildbot" system automates builds of darcs on various platforms, allowing the team to catch portability issues faster.

Deep math? still in there. darcs has always excelled at cherry picking patches from a branch due the patch algebra originally implemented by physicist David Roundy. this unique foundation of the source control system remains and was updated for the new release to support the features described above.

In the community

Between Darcs 1 and Darcs 2, the community continued to release and update related tools that work with Darcs. Some darcs projects worth highlighting include:

Adopting Darcs 2

Darcs 2 is an easy upgrade decision for darcs 1 users. Darcs 2 deserves serious consideration for anyone evaluating source code control tools. Be careful reading comparisions of darcs to other options. Most published at the moment still measure against darcs 1, and some cite the now-fixed weaknesses of darcs 1 as reasons not to adopt it. The darcs project is now up front about it's significant limitation: It isn't recommended for very large projects.

The reality is that while some of the weaknesses of Darcs 1.0 were dealbreakers for some users, Darcs 2 is a solid, mature, usable release that deserves a second look.

Darcs 2 binaries for Ubuntu Linux are available on Iain Lane's PPA page. Binaries for many other platforms are available.

Thanks for reading! This post is discussed on reddit.

Today I made progress on making a self-contained distribution of the Titanium web framework.

The goal is to have a single archive file you can unpack and have a complete web framework to work with-- no more CPAN dependencies to install! You can play with it on your desktop or laptop with the built-in web server, and upload a directory to your web server when you read to go live.

After I patched the great local::lib module, I can now use this simple command to create a "Titanium" directory, into which Titanium and all of it's non-core dependencies will be installed.


perl -MCPAN -Mlocal::lib=--self-contained,Titanium -e 'install Titanium'

The next step is to hopefully eliminate required dependencies on XS code. The following modules need to be address:

  • Compress::Raw::Zlib
  • HTML::Parser
  • Params::Validate

Params::Validate should be easy to handle, since it has a Pure Perl alternative. I haven't decided now to deal with the other two yet.

I can post an archive of what I have so far if it's of interest. The XS modules above are compiled for 'i486-linux-gnu-thread-multi'.

Perhaps my favorite parts of Perl 6 are subroutine signatures and getting rid of "my $self = shift;".

These features available now in Perl 5, without source filters, using Method::Signatures.

Sure, it's labeled as "ALPHA" involves some dark magic to make it work, but it's there to play with. And if it can be hacked up as a module, surely it would be feasible to add to Perl 5.12....

With the increasing popularity of laptops, getting the most out of small screen sizes has become a priority for computer users.

Ubuntu Linux helps with this by providing a consistent keyboard shortcut for a "Full Screen" mode. Pressing "F11" in many standard Ubuntu applications allows you to to toggle the application in and out of a full screen mode. Today I tested that the following key applications support this:

  • Firefox
  • Gimp Image Editor
  • Eye of Gnome Image Viewer
  • Evince Document Viewer
  • Totem Movie Player
  • Rhythmbox Music Player
  • Terminal

Now that I realize the shortcut exists and is widely supported I use it regularly to get the most out of my 14" laptop screen. I did find one key application had a full screen model and used a different shortcut. Open Office mysteriously uses "Ctrl-Shift-J". I have filed a bug to suggest that Ubuntu make this consistent as well.