Marpa and OO

Both publicly and privately I hear from folks who tell me that Marpa is an OO superclass waiting to happen. I can see their point. If there ever was a case for code reuse, the Marpa algorithm is one. On the other hand, any non-trivial use of Marpa requires additional semantics, so that the Marpa classes walk, swim and quack very much like abstract type classes.

Furthermore, the additional semantics that Marpa needs comes in pieces -- semantic actions. And even though these pieces often share little code with each other, they interact heavily as part of a specific structure. This means that their semantics are tightly coupled, both to each other and to Marpa. In short, Marpa's semantic actions look a lot like the methods of a subclass.

What's New in Perl

Ricardo Signes will be giving a talk at YAPC::NA 2012 that he describes as:

There are almost twenty thousand lines of documentation describing what has changed since perl 5.8. Those docs are where you can find out that the // operator is awesome, or that the “r” flag on substitution is going to save you typing and bugs, or that you can stop worrying so much about your exception handling. Unfortunately, they also contain a lot of talk about things like GSVS_mg_SLOPPY or engine derecursivisation or what happens now if you try to reset a glob reference during global destruction. With most common Unix distributions now shipping Perl 5.12, and more and more workplaces moving off 5.8, many programmers are faced with reading these documents. Instead, you can come listen to the forty minute summary.

[From the YAPC::NA Blog.]

AnyEvent timers shouldn't use type constraints

While I'm rambling about AnyEvent (which I'll probably do more often), here's a note I'd like to give myself.

I'm using AnyEvent in a big app with objects (objects are, generally, good!) and I have a lazy attribute (lazy attributes are good!) of an AnyEvent timer. This is so the timer doesn't lose scope and will be closed.

At first the constraint was a EV::Timer object. On one machine this failed the type constraint while on another it worked. Some of you already know why. Then I changed it to a generic Object. This failed one as well. Why?

Because AnyEvent is basically like a hub for many event loops (ANY event loop, get it?) and apparently on one machine it used EV (a high-performance kickass event loop written by Marc Lehmann) while on another it hadn't. This meant that one AnyEvent->timer() returned an EV::Timer object while another returned an Array Reference. I removed the type constraint complete. It's now good. :)

Learning AnyEvent

When people hear I learned POE much faster than AnyEvent, they're usually surprised. I don't know why, but POE always made a whole lot of sense to me than AnyEvent. I've used POE in several projects (some pretty big) and it was always easy to work with, always had every component I wanted (except the SSH I wanted, though that exists too now) and the community was totally supportive and helpful. This is not unlike AnyEvent, though. I just haven't used it much.

Recently I started using AnyEvent. Not because I don't like POE anymore but because I wanted to be familiar with both. I have to say I felt quite at home with AnyEvent and started to write more and more elaborate stuff with it. I'm also trying to find more stuff to do with it, though it feels suited for more hardcore people than I. I have no idea where to start if I wanted to write an AnyEvent SSH client based on Net::OpenSSH, for instance.

If you've ever used AnyEvent, I recommend getting familiar with POE. Rocco Caputo and the community have done amazing work on it.

If you've ever used POE, I recommend getting familiar with AnyEvent. Marc Lehmann and the community have done amazing work on it.

Building Scalable, Distributed Job Queues with Redis and Redis::Client

Mike Friedman will be giving a talk at YAPC::NA 2012 that he describes as: 

At SocialFlow, we initially built a simple job queue system using a relational database and a daemon for running workers. While this model is sufficient for a relatively small volume of jobs, an increase in scale resulted in problems with concurrency, failover, and efficiency. This presentation examines the process and design that we used to move our jobs system to the Redis structured data store, and the simultaneous development and design philosophy behind the Redis::Client CPAN module.

The presentation will cover the structure of job queues, an analysis of the pros and cons of relational vs. non-relational data-store models for queues, a brief introduction to the Redis platform, and code examples demonstrating a simplified system.

[From the YAPC::NA Blog.]

sorta Perl 6 grant report

uh yes I have a running grant and want to close it in 2012 even it will take much more effort than just written down in the proposal. I was a bit shy with that to don't get rejected. I don't want to open any new projects til I get this done.

Recently I updated Index A, which is still the most usable part, because its a quick overview of all builtins and operators. There were tons of details I did: setting new links, cleaning up things I didn't understood myself exactly, making better examples, more "see also" for similar commands. There were even some Perl 6 commands new to me, which I added and we are currently approaching the entry number 650. But the most important bit was: I understand the strange socialtext wiki syntax a bit better, so I could insert a lots of anchors inside of lines. So not only similar terms are now interlinked. Even better, many (and soon every) commands can be linked from outside which is good for automatically generated links if you need some quick explanation to a perl 6 term which is linked to an even more detailed explanation and to tables where it is summarized with similar things.

Thats the link-syntax for the builtin "if":

What to avoid in BEGIN blocks

I came along this crazy code.

But first some short explanation. The perl compiler B::C saves the state of any program at CHECK time, and runs it later. That means every action in BEGIN blocks is frozen and then thawed on a potential another machine in later time. Not all action can be frozen/thawed as we know from the common modules Data::Dumper or Storable

The compiler is better than those. It can restore regular expressions which Storable cannot. It can save the state of some IO object, which Data::Dumper can not. It can save the whole dependency tree of code. Data::Dumper or Storable can only save data, not code along with it.

But some actions are really a bad a idea to be restored at run-time.

1st sample:

my $f;open($f,">&STDOUT");print $f "ok"

This is trivial. The fileno 2 is dup'ed to $f. All at run-time. Nevertheless you will not be able to freeze/thaw $f. The compiler can.

Why does your site not link to!

Recently an article was published that claimed Perl usage in websites had dropped below 1%. For a Perl developer this seems ridiculous on the face of it. As it turned out, it was ridiculous, since the error margin was 17.6%. Meaning that for 17.6% of the sites they surveyed they could not even detect that they were using Perl. And they only survey the top 1 million, out of the 175 million active sites Netcraft reported. So the validity of these numbers is highly suspect.

So, all is fine? Catastrophe averted? Heh, not really.

Here's the issue: To a Perl developer this might seem ridiculous. Most of us are aware of how many websites use it under the hood. But to the average person it seems perfectly reasonable. The suffixes ".php" and ".asp" are ubiquitous and lets everyone know what the website is running on. Ruby and Python operations are proud of using their languages and flaunt it. To an average person it might even seem like there are more Ruby and Python websites.

Yet Perl is practically invisible. It drives a lot of sites, businesses and livelihoods worldwide, neither of which make any indication of the tools they're using. Let's take a look at a random sampling:

Site Alexa Rank 37 245 1,710 2,171 2,195 3,149 7,776 25,266 145,896 161,366 172,291 295,127

These are sites that run on Perl, but to look at them you'd never even know it. Perl has advanced route dispatching mechanisms and its great modularity makes it possible to write an entire website as a single application. In fact, for most modern Perl web frameworks it has become customary to run web applications as self-hosting services to which a web server connects via a network port. Perl has made it very easy to design one's url structure exclusively around the data one serves, which has made it entirely impossible to tell for most Perl-driven sites that they actually are Perl.

Now, all of these sites have reasons to be proud of the tools they use. Some of them indeed are very proud, for example has donated 150.000 USD last year to Perl development and others on the list have donated smaller amounts as well or are supporting Perl conferences and spend a lot of money to have a presence on Perl conferences. Those on the list who are hiring, are also hiring Perl developers, some of them quite prominently. Even others on the list are websites created for the express purpose of serving the Perl community.

Yet none of them even mention Perl on their frontpage or even link to I know Perl doesn't have nice and easy promotion buttons like Python or PHP do. But a simple text link does the job just as well. Just a simple "Built with Perl" in the footer or a sidebar would show that you care about Perl, would make it easier for job seekers to notice that you're looking for Perl devs and would raise the visibility of Perl and make it a more appealing choice for students looking to learn a dynamic language.

I do not believe this is done out of any maliciousness and that it's rather just a simple oversight, something that was never considered. As such i've sent a small email to each of those sites, asking them to consider this issue and to please add a link to or to weigh in on why they would not do it. Maybe they are issues that the Perl community can fix.

Similarly, if you own a site yourself that runs on Perl and does not link to

Why does your site not link to!

About is a common blogging platform for the Perl community. Written in Perl and offering the modern features you’ve come to expect in blog platforms, the site is run by Dave Cross and Aaron Crane, with a design donated by Six Apart, Ltd.