CPAN Love Archives

For CPAN Day: Show Off Your Web Framework!

While I know many of you have CPAN Day projects, some of you might still be searching. There is a very well known benchmark from TechEmpower which compares web frameworks. It gets plenty of press and generates much interest. Unfortunately, the Perl results look like this:


We all know the reputation that Perl has to the outside world, and sadly these results would tend to reinforce it. The person or persons who added these apps seems to have long since forgotten about them. At least the Mojolicious app was a port of one of the others and did not exemplify either the style or power of the framework. The others likely share those traits.

But all is not lost! TechEmpower has recently made it much easier to contribute, and I have fixed the deployment and toolchain problems. I have also updated the Mojolicious app. Would you like to improve the submission of your favorite framework or add your own? Read on!

Type::Tiny rescues Moo

I have just ranted about removing old bad code from the Perl core. Let me lighten the mood by talking about some good, new code.

I have loved Moose for some time now, but like others, I disliked how heavy it was. Then Moo came along and it was great … until I found myself not availing myself of the type system, because it was harder to get to than in Moose. I was skipping validation more and more.

A recent project came up and I really wanted to do it right, so I tried Toby Inkster’s new Type::Tiny and may I say, “hat’s off to you sir!” The combination of Moo and Type::Tiny brings that Moosey feeling back, while still being light and responsive and even fat-pack-able! Great work to all involved in both projects!

Thank you Ack!

People may have noticed my absence from the Perl world lately. I have been writing my Ph.D. thesis (179 pages on Ultrafast Electron Microscopy with my Physics::UEMColumn Perl module featured) and defense.

Ack is a tool for searching code and text. It works much like the unix tool grep, although it is imbued with the power of Perl. To mark the release of Ack 2.0 though I wanted to mention a few one-liners that made my life easier in this stressful time.

My thesis is written in many LaTeX files and one can probably imagine that searching those files was needed regularly. The biggest is for finding non-ascii characters. As I add content from old publications or external programs, lots of non-ascii characters can often come along for the ride. LaTeX is a very old program, well pre-dating unicode, and it has a very different way of adding special characters with its own markup. In fact parts of the compiling toolchain croak with unicode characters. So I found myself using

ack '[^[:ascii:]]'

regularly. Also I had to keep a list of all the abbreviations that I had used in the paper, but of course you forget if you have them all. I used this little bash-ack conglomeration to find all sequences of two or more upper-case characters, which is how I write my abbreviations,

ack -ho '\p{Upper}{2,}' | sort | uniq

I’m sure I used many other little ackings here and there, but these were the two I could remember off-hand. Thanks to Andy and everyone who has contributed to ack!

Now go use it to make your life easier!

Visit the new site:

I love CPANtesters and Travis-CI

I have mentioned before how much I like CPANtesters! Here is another story.

Yesterday I got an email from them listing a number of failures from Galileo, my CMS. I had recently pushed some bugfix releases, but it had some new, and as yet unused code and tests for that code in it. The tests passed on all my Linux systems, so I wasn’t worried about the release. Yet the failures came in. Some on Linux, some on other platforms, but not all the tests were failures and I couldn’t figure out a pattern. CPANtesters put me on to a problem but for this I needed faster results.

I had heard about Travis-CI, a free continuous integration platform based around GitHub. I set up travis testing for Galileo and sure enough it failed there. Though it was frustrating I now had failing tests that I could run at will! After much trial and error, I found that I had an undeclared dependency, but due to the way I was testing, it was throwing a seemingly unrelated error. My problem was that all my systems have the module installed and so I didn’t get the failure on my box, its a common module File::Next (used by Ack) and so many of the CPANtesters had it as well.

CPANtesters alerted me to the problem and Travis-CI let me continuously test on fresh platforms (5.10/12/14/16) until I found the problem. I love open source.

I have released Galileo 0.026 which fixes the problem. There are exciting additions to Galileo in the works, slowed only by my upcoming Ph.D. defense (which obviously takes much of my time). I hope that by this summer Galileo will have several of the most requested features you have told me that you would like.

Happy Perl-ing and remember to thank those projects and developers who make your lives easier, both in person and in public. Thanks guys!

PPI highlighted Mojolicious "quine"

On February 28th I will be presenting an “Introduction to Mojolicious” to the meeting. If you are in the area I hope you will stop by; it won’t just be an introduction despite the name. If you are interested, here is the Meetup link.

I haven’t decided, but I might try to “self-host” the talk, writing it as a Mojolcious app! To do that I had to resurrect one of my earliest CPAN releases Mojolicious::Plugin::PPI. This module does just what the name should imply, providing syntax highlighting via PPI and PPI::HTML in a handy Mojolicious plugin.

Whether or not I decide to use this for my talk, it still is handy to have around. Here is a cute example, a simple “quine” which you can run:

#!/usr/bin/env perl

use Mojolicious::Lite;

plugin 'PPI' => { toggle_button => 1 };
get '/' => sub {
  my $self = shift;
  $self->stash( file => __FILE__ );



@@ quine.html.ep
% title 'A Mojolicious "Quine"';
<!DOCTYPE html>
    <title><%= title %></title>
    %= javascript 'ppi.js'
    %= stylesheet 'ppi.css'
    <h2><%= title %></h2>
    %= ppi $file

A quine is a program that prints its source code as its output. In truth, this “quine” is really a cheater, a true quine doesn’t read itself. Still, the above example renders the source code nicely highlighted by PPI (and with some added goodies like toggleable line numbers).

Just for fun, some other Perl (cheater) quines are:

@ARGV = $0; print for <>


seek DATA,0,0; print for <DATA>

But those outputs aren’t syntax highlighted. For a real one see the comments.

A Question of Location

The great detective was staring at the door, as he had done for the past two weeks. He needed a case to occupy that mind. Thankfully today the door opened and Holmes had a case.

A man stepped in and introduced himself as Mr. Mokko.

“Watson, here is a man having troubles with Perl.”

“Holmes, how can you know that?”

“We can tell from the lines on his face, the stiff wrists and the pads of his fingers that he a much maligned sysadmin; from the Hawaiian shirt and the hat that he’s into the Perl scene. The scowl and the fact that he’s here on our doorstep tells me that he’s having troubles.”

Holmes looked back to the man and said, “Come now, you must tell me the tale.”

RFC Module::Build::CleanInstall

Edit: Module::Build::CleanInstall has been released!

Following the recent work (chronicled here) by Yanick Champoux and this StackOverflow question, I got it into my mind to try to write a Module::Build subclass which first removes all the files previously installed by a module before installing the new version. In those posts, this is motivated by File::ShareDir concerns, but this problem is more general than that.

If your new version of a module does not come with some file that a previous version did, installing the new version will not remove that file. Most of the time this is ok, but every now and again you need to know that those files don’t exist. That’s usually when you see warnings in the POD saying, “be sure to remove all previous installations …” or “only install on a fresh copy of Perl”. The author knows that a problem is possible, but the user has to fix it. Sounds bad.

What if you could just switch your build tool from Module::Build (or EU::MM) to Module::Build::CleanInstall and let that take care of it for you?

Normally once I mock up an example, I release it to CPAN and see how it goes, but this time, I thought I might solicit comments first, since perhaps there are real world considerations I haven’t thought of. Please let me know any thoughts on this idea and the proposed implementation in the comments below.

On CPAN Namespaces: Urban Namespace Planning

I’m having a bit of a conundrum over where to put my next GSL-based module. First some background.

I’m already the author of a GSL-based module (see my first rant), the horribly named Math::GSLx::ODEIV2. This name reflects the same odd namespacing conundrum that I find myself in again, as well as the sub-library name odeiv2.c/h.

Duke Leto has already essentially taken the whole Math::GSL namespace by brute-force SWIG-ing the entire library. Much of this work is not fully implemented, but still parked. Further, since the namespace is already fairly crowded, its next to impossible to tell which parts are his and which would be anyone else’s. So lets call that out of the running. Note that I’m not complaining about his efforts, but it makes choosing a name harder.

I released my first module which uses GSL under the namespace Math::GSLx, but this is also less than desirable since it seems to be related to Math::GSL which it isn’t (at least not in the way that MooseX is related to Moose). Its also hard to type and hard to search for.

This leave me thinking about starting a new toplevel, which I do not undertake lightly. My two concepts are the simple GSL and the more namey PerlGSL. I say namey since toplevels with names like Mojolicious are not contentious since they represent more of a concept than an implementation detail (like Net::).

To be distinct from Math::GSL I would encourage users of PerlGSL to

  1. Make their interfaces Perlish rather than the utilitarian output the SWIG may produce
  2. Give their module a name that is descriptive without squatting on the sub-library name or other implemenations

In this way if two different authors want to provide an interface to GSL’s Monte Carlo multidimensional integrator, one might be PerlGSL::Integration::MultiDim (since there are a number of 1D integrators to be considered) and another might be PerlGSL::Integration::NDim.

Once I settle on a toplevel, I expect that I will “release” a namespace decriptor module (not unlike Alien) describing this for future users. It might also eventually pull in the GSL library via Alien::GSL once my Alien::Base work permits. From there I would release PerlGSL::Integration::MultiDim and rechristen Math::GSLx::ODEIV2 as PerlGSL::DiffEq (assuming the toplevel PerlGSL).

Anyway, I’m interested in your comments, so please let me know!

One Unit of Stepping Up

In the mold of Buddy Burden’s great post Stepping Up, I wanted to share a recent pleasant result of contacting a wayward author.

One or two of you may have seen my MooseX::Types::NumUnit which brings “dimensional” (read: units) types to Moose objects. I had been using two different unit engines Math::Units::PhysicalValue and Physics::Unit. This was essentially because I hadn’t been able to figure out how to get the functionality of both out of just one, though I was rather sure it should be possible. Recently though, I spent some of my diversion time on the problem and settled on using only Physics::Unit. This is new version was pushed to CPAN a few days ago.

Now that I have settled on one underlying module, it came time to address some of my druthers with that module. Notably it lacks the shortcut for millimeters: mm. I was able to hard code that shortcut into my module so my users wouldn’t see that wart, but one that I couldn’t fix was nm meaning nautical miles rather than the much more common (at least in my field, physics; sorry navigators) nanometers. There was no way to override the preset.

I have taken on a lot lately and didn’t really want to take another CPAN module, but it seemed like that was going to be the case seeing that Physics::Unit hadn’t seen a release since 2003. Worse than that, seeing as units haven’t changed much since then, the author Chris Maloney (KLORTHO), hadn’t published any other modules, so 2003 was his last activity. I opened GMail with a heavy heart, “its time to try to find a wayward author, just to take over another module, just to make a few minor changes”. The first email bounced. I tried again, googling for his name. But here is where the story changed.

To my delight, his reply started “Wow, this is a blast from the past! I’m very happy to get this email, and especially that you find the module useful. I have always had it on my to-do list to go back and update my CPAN entry with a few things, including my email address.”

He and I have been working on the changes I envisioned, he is using it as a reason to learn git and GitHub. It has me very excited, not just for a new release of an old module, not just for the improvement of my higher-level module, but for the human experience of CPAN. I know there have been some public kerfuffles lately; I hope that doesn’t put off too many people. CPAN and the Perl community have so many nice people, even those that have strayed for nearly a decade.

Reach out to the author of that module on your mind and ask a question, offer to help, its time to Step Up. It might be more pleasant than you expect.

A milestone for Alien::Base

I have been working on a set of base classes intended to make creating a new Alien:: distribution for some library as easy as making a simple Module::Build based distro. So far the code isn’t on CPAN yet, follow its progress on GitHub.

I haven’t been feeling so well today, so I have been sitting around watching movies (which I own on DVD) on TV. Of course I can’t sit still that long without doing anything so Alien::Base saw a burst of activity today.

Along with testing I am also keeping an Alien::Base-based Alien::GSL (which provides the Gnu Scientific Library) in the examples folder. The big news today is that this example distro can now query the GNU FTP server, pick the newest version of the library. It then downloads, extracts and builds the library in a temporary folder. Finally it “installs” the library in a File::ShareDir directory in the Alien::GSL root/share directory. Even this isn’t as cool as how it does this:

It does it entirely from the Build.PL configuration!

It is my hope that most small/self-contained libraries can be wrapped in this simple way. In this way I hope to increase the number of Alien:: modules available on CPAN.

Of course its still needs much more functionality, lots more tests, and all the documentation. All of that is coming however, so keep watching!

About Joel Berger

user-pic As I delve into the deeper Perl magic I like to share what I can.