Month: July 2009

Test::Pod 1.40 now checks for illegal L constructs

July 12, 2009 CPAN, Perl 5 6 comments

It will be interesting to see what, if anything, barfs because of the new Test::Pod.
This POD construct is illegal according to perlpodspec, and will not be formatted correctly on [](, either:
> L<perlbuzz|>
Test::Pod catches it now. My wonder is how many people are using it.
Test::Pod also requires Perl 5.8 now, and I’d like to think that pretty much every module on CPAN could use modern Perl versions at this point.

Perlbuzz news roundup for 2009-07-11

July 11, 2009 Community, CPAN, Perl 5, Perl 6 No comments

These links are collected from the
Perlbuzz Twitter feed.
If you have suggestions for news bits, please mail me at

  • Tim Bunce surveys customer relationship management systems in Perl (
  • Sending mail through Gmail with Perl (
  • From the DarkPAN: “The Perl community should move forward without worrying overly much about us that have to drive in the slow lane.” (
  • rgs’s blog post about his resignation as bleadperl pumpking (
  • How we should address the DarkPAN problem (
  • I think chromatic’s points boil down to TAGNI: They Ain’t Gonna Need It, where They is the unknown DarkPAN. I’m inclined to (agree.)
  • Patrick Michaud is looking for Rakudo release managers (
  • perl/vendor/site explained (
  • Top five non-technical mistakes made by programmers (
  • Six modules to help with complexity management (
  • Test::Pod is now on github. Bug fixes welcome! (
  • CPAN Explorer gets props in Visual Complexity (
  • Upgrading Debian packages with newer CPAN releases (

mod_perlite helps Perl gain ground in the PHP arena

July 7, 2009 Perl 5 8 comments

*Michele Beltrame wrote in about the mod_perlite project, which I’d love to see take off. mod_perl has never been easy to install, and ISPs and webhosts are loathe to use it for security reasons. mod_perlite would provide easy access to Perl without the weight of CGI.*
[mod_perlite]( is an interesting Apache module currently under development. I’d say it’s the equivalent of what mod_php is for PHP: a fast, easy to use, and relatively safe way to use Perl scripts for the development of small and medium web applications.
A project like this brings Perl back into play as a good choice in a field currently dominated by PHP. In particular, PHP is great when you need to run a lot of different small applications on the same web server, and you want all of them to run fast enough. CGI is slow compared to mod_php because both the interpreter and the application need to be loaded for every single request. Solutions like [mod_perl]( and [mod_fastcgi]( are the best solution when you have a few big applications, but they’re not a good choice in this scenario, because they keep the application resident: when you’ve got so many small applications (which, in most cases, are invoked infrequently) you end up with enormous memory footprint.
mod_perlite is the winner here: only the interpreter is kept resident (there’s also the idea to keep some modules loaded, which might speed up things further) and applications are loaded at request time. This also helps avoid problems with memory leaks. Using mod_perlite is simple: just configure Apache and all the .pl files will run *without modification* taking full advantage of mod_perlite and therefore reducing execution time to a fraction.
Unfortunately the module is not yet stable, as there’s still work to do. My installation on Gentoo Linux x86_64 went smoothly. mod_perlite works but still suffers some major issues. In fact, at present it’s only usable for very simple applications because of a bug in how query parameters passed by Apache are handled.
To make mod_perlite fully usable, the project web site has a three point TODO list:
* Fix form POST processing (‘read’ does not work reliably)
* Limit Perl running time.
* Find ways to cache code.
The project is looking for help, so if you are interested and know something about mod_perl, writing Apache modules in C, and about overriding system calls in Perl – and if the project seems interesting to you – please shout!
And… if someone argues “we’re 10 years late compared to PHP”, I’d reply “better late than never”. 😉
*Michele Beltrame lives in North-Eastern Italy, where he has been
developing web applications in Perl since 1996. He is an active member
of the Italian Perl community and of the [Italian Perl Workshop](
organizational committee. In his free time he publishes guidebooks on
the mountains surrounding his area.*

Introducing CPANHQ

July 6, 2009 CPAN, Perl 5 1 comment

By Shlomi Fish

Most people who are actively developing using Perl are familiar with
sites for searching CPAN (the Comprehensive Perl Archive Network)
such as
These sites provide a simple search bar where users can search for keywords
or key phrases, and find a list of results. These sites also feature
pages for the various CPAN distributions, the various authors, and the
individual pages of documentation inside the modules.

Recently, Andy Lester started the
CPAN” mailing list
and wrote a
Perlbuzz post titled “Rethinking the interface to CPAN”
, where he gave
the case that the current resources may be inadequate for the process
of selecting a module on CPAN. For a long time, there was an intermittent
discussion and some brain-storming, but very little code (if any) has been
written. This has all changed with

So what is CPANHQ? As documented in
the first
and only wiki page it has so far
(which I wrote a few days ago),
“CPANHQ aims to be a community-driven, meta-data-enhanced alternative to
such sites as
Currently, the functionality is very basic, but we have great ambitions.”

I learned about CPANHQ by overhearing a conversation on Freenode’s #perl
channel. I joined the effort, and made several enhancements to the
Catalyst and
code. The functionality is still very basic.

Some of the plans and ideas we have for CPANHQ, which may be translated into
code in the future are:

  1. The code is and will remain open-source, which makes it easy for people to
    contribute to.

  2. We plan to have most of the current features of and including pages for authors, distributions, and individual
    modules and their documentation.

  3. CPANHQ was already enhanced with some jQuery
    and jQuery UI JavaScript
    goodness, and we plan to add more of it to make the user experience better.

  4. The site aims to be more integrated than the many separate CPAN-related
    sites today:, CPAN Forum, AnnoCPAN, CPAN Ratings, CPANTS,
    CPAN Dependencies, etc. By putting everything under one roof, we can provide
    a better user experience than the many sites with very loose integration.

  5. We plan to enhance the site based on meta-data as provided by both the module
    authors (in the META.yml file and the users of the site.

    For example, we have already added support for the META.yml’s
    which allow authors to tag modules, and we plan to support
    user-tags too.

  6. CPANHQ will be very community-driven. People would be able to open user
    accounts there, which will allow them to contribute content to the site,
    such as tags/labels, comments, wiki pages, chatter, etc.

The CPANHQ wiki page
contains more ideas and insights. Like I said, the current functionality is
incredibly basic, but we hope that with enough help, time and dedication,
we can create an attractive and engaging interface to CPAN, to make
finding a module on CPAN faster, easier and more fun.

In the meantime, you can look at the
we have of the interface so far, or clone the github repositories,
and set up a local web-interface.

Shlomi Fish has been writing using Perl, about Perl and for Perl, since 1996,
when he started working for a web-design shop, and discovered Perl and UNIX,
which he’s been in love with ever since. He initiated and is maintaining
many CPAN modules and
contributed to many other Perl and non-Perl related projects.

Perlbuzz news roundup 2009-07-05

July 5, 2009 Code craft, Community, CPAN, Perl 5, Perl 6 No comments

These links are collected from the
Perlbuzz Twitter feed.
If you have suggestions for news bits, please mail me at