Robin Smidsrød

This is a response to John Napiorkowski's article: Why All the Hate?

Matt S. Trout was talking about the fact that we need to become better with marketing. I second that.

One of the tools of marketeers is the survey.

My suggestion is this: Why don't we publish a survey about perl and get it answered by as many people as possible, even the nay-sayers, reddits and diggers? At least this way the perl community as a whole could better grasp what parts we really need to focus on, based on user feedback? And we'd even include people outside the core community.

I believe that some of the questions should be like this (some alternatives in parenthesis):

• How much do you like perl?
• What are perl's biggest strengths? (we need to make a list here)
• How much do you dislike perl?
• What are perl's biggest weaknesses? (same here)
• How long have you been using perl?
• How are you using perl? (scripter, sysadmin, non-user, cpan dev)
• Are you a member of the perl community? (current, former, never, left)
• What is your age?
• Are you excited about perl6? (yes/no/neutral)
• Do you think the CPAN install process requires improvement? (yes/no/neutral)
• Do you follow perl-related websites? (yes/no/neutral)

It would be wonderful if either EPO, P5P or the Perl Foundation would find the means to issue a survey like this. If it comes from either of these organisations it would probably be taken seriously. This way we could really find out what matters to people, instead of just "guessing" what it is.

I know that something like this was done in the past, and it was what ignited the whole perl6 process. Isn't it about time we do something again?

If you have more suggestions for questions/options to the survey, please state so in the comments. Other comments are also most welcome.

I was stumped why I couldn't run X11 software on my Ubuntu server installation and have it forwarded through my SSH connection to my desktop Windows machine running Xming.

The solution was to install the xauth package from the Ubuntu repositories:


$ sudo aptitude install xauth


Apparently installing an X11 application (gitk) didn't pull in that dependency.

Now I can finally run gitk and visualize those complicated git graphs. Yay!

I was reading Jay Kuri's article about CGI alternatives the other day, and I got thinking. How much memory does these various modules for simple (or advanced) web serving use?

After having looked through Mark Stosberg's article on startup penalties I was even more bewildered. It was hard to track the actual cost of each module, because the perl interpreter footprint was also in there (and that we cannot do anything with).

I wrote a small script called perlbloat.pl to check how each of the mentioned modules come out. It uses the GTop module, which is Gnome's cross-platform way of counting things such as memory.

The results was from this command:

$ for name in $(echo CGI HTTP::Engine FCGI::Engine Catalyst CGI::Application Squatting Continuity Mojo Mojolicious Titanium HTML::Mason CGI::Simple); do perlbloat.pl $name; done


Version numbers are as follows (running on perl 5.10.0 on Ubuntu 8.10):

Catalyst 5.80004
CGI 3.29
CGI::Application 4.21
CGI::Simple 1.110
Continuity 1.0
FCGI::Engine 0.08
HTML::Mason 1.42
HTTP::Engine 0.1.8
Mojo 0.9002
Mojolicious 0.9002
Squatting 0.60
Titanium 1.01

What is interesting to notice here is that CGI::Application actually comes out with a lower footprint than CGI::Simple. Considering CGI::Application has a somewhat bigger API this is surprising.

There is of course no surprise that Catalyst is the most memory hungry module of them all. What seems surprising, though, is that FCGI::Engine eats so much. It would be nice to know why.

If you consider these numbers I would like to know good reasons for using Catalyst in a high-performing environment. To me it seems like the application servers will take a trashing because of the increased memory usage of each process if you compare it to e.g. CGI::Application. Even Titanium which is pretty feature packed comes out at almost three times less memory used.

What is interesting to notice is that if you consider the typical deployment scenario for a Catalyst-based app you get these numbers:

$ perlbloat.pl Moose DBIx::Class Catalyst
Moose added 4.8M
DBIx::Class added 392k
Catalyst added 5.7M
Moose DBIx::Class Catalyst added 10.9M in total


If you consider a similar app based on HTTP::Engine you will have this overhead:

$ perlbloat.pl Moose DBIx::Class HTTP::Engine
Moose added 4.8M
DBIx::Class added 396k
HTTP::Engine added 1.4M
Moose DBIx::Class HTTP::Engine added 6.7M in total


If you turn the loading order around a little bit you get this:

$ perlbloat.pl DBIx::Class Moose HTTP::Engine
DBIx::Class added 528k
Moose added 4.7M
HTTP::Engine added 1.4M
DBIx::Class Moose HTTP::Engine added 6.7M in total


What you can see from this last dump is that Moose and DBIx::Class shares some code (132k), but it is mostly irrelevant when you consider the cost of the rest.

Another package that is getting wildly popular these days is MooseX::Declare (0.22 tested), and as you can see, it has pretty large footprint aswell:

$ perlbloat.pl MooseX::Declare
MooseX::Declare added 10.3M


If you separate Moose and MooseX::Declare you can see that it adds up by itself (it's not only Moose that costs):

$ perlbloat.pl Moose MooseX::Declare
Moose added 4.8M
MooseX::Declare added 5.4M
Moose MooseX::Declare added 10.2M in total


If you have something to say about the numbers I've collected here I would love to hear them. Feel free to post comments.

I was recently attending NPW09 and there I met several prominent members of the Perl community. It was a really exciting event for me. I feel like I learned more in two days then I could've learned from studying documentation for two months. One of the guys I met there was Jonathan Rockway (jrockway).

I asked him how I could make sure that my subs where called in the right way. That is, I don't want a class (static) method to be called as an instance method and vice-versa. In a few minutes he cooked up the example below.


use MooseX::Declare;

class Test {

method my_static_method (ClassName $class: Str $str) {
print "Hello, $str.\n";
}

method my_instance_method (Str $str) {
print "Hello, $str.\n";
}

}

# These work
Test->my_static_method("abc");
Test->new->my_instance_method("abc");

# These fail
#Test->new->my_static_method("abc");
#Test->my_instance_method("abc");


I was amazed to see that it worked so well. Then only thing left now is to figure out how to make sure functions are actually called as functions and not as class/instance methods. If you've got a simple example, please comment.

Side-note: Unfortunately I couldn't test this out at NPW09 on my Strawberry Perl installation on my laptop, because Devel::Declare wouldn't install on it. After a lot of talking (at NPW09) with Florian Ragwitz (rafl) and later with Ash Berlin (ash) at irc we were able to fix the problem. A patch to ExtUtils::Depends that fixes the problem has been submitted, and hopefully it will be available on CPAN soon. If you have any influence to speed things up, please apply some to the maintainers of ExtUtils::Depends. It would be wonderful if Devel::Declare was available to Windows users aswell.

Last week I showed you how to take an adjacency list in a database and turn it into a nicely indented textual output.

Today I will show you how you can take that same (flat) data structure and turn it into an HTML unordered list (UL) using Template Toolkit.

The script is available here: gen_ul_tree.pl.

If you run the code below it will generate the HTML for the data from last week.

$ wget -q -O - http://files.smidsrod.no/gen_ul_tree.pl.txt | perl -


It should look something like this:

• America

  • United States

  • Mexico
  • Brazil

• Asia

  • China

  • Japan
  
  

• Europe

  • Norway

    • Vestfold

      • Sandefjord

      • Tønsberg

      
      
    • Hordaland
    • Nordland
    
    
  • France
  • Spain
  
  

The template code code is fairly well commented, so it shouldn't be necessary to explain here what it does.

Now go out and make some nice treeviews on your web pages. And while you're at it, sprinkle some jQuery on top of it to make it interactive.