blogs.perl.org

After uploading Test::Class::Most, I kept thinking and thinking about the fact that you automatically get strict and warnings with it. I started to think about my annoyance with test suites in general and am now thinking about doing this with Test::Most. I proposed this to Perl-QA and received three positive responses (two offlist) and no negative. It won't import "features" of 5.10, but instead of this:

use strict;
use warnings;
use Test::Most tests => 34;

You can just write:

use Test::Most tests => 34;

Over the past year or so, I've been working on a project called Cil. It's a distributed issue tracker and if you don't know what that means, let me explain.

Cil is currently a command line tool. It saves it's issues, comments and attachments as plain text files inside your project in an issues/ directory. Some settings are read from .cil and also you may set some personal preferences in ~/.cilrc.

Due to the fact that all data associated with issues (bugs, feature requests, tasks) are saved as text files, it's really easy to check them in to Git and, if required, fix conflicts.

Aha, conflicts, that's gotta be painful. Well, it's not and here's why.

This subject really requires a whole series of posts, but for the moment I'd just like to lay out the basics of what's needed to integrate your Perl development process and Hudson.

First and foremost, you must be using some source control system. Doesn't matter if it's CVS, Subversion, Git, Mercurial, or Bazaar (Hudson supports all these), but you need to have this set up so that Hudson can both consistently check out your software and so that it can notice when to do another build.

Second, you need a test suite. It doesn't have to be perfect, or have 100% test coverage, but you need something that Hudson can run to verify your builds.

I like dispatch tables. Which means I use this kind of thing quite a bit:

$dispatch{$pieces_of_state}->(@args)

if exists $dispatch{$pieces_of_state};

Does that sub-routine call look ugly? I suspect it does. It would look nicer in javascript for sure:

dispatch[pieces_of_state](args)
vs
$dispatch{$pieces_of_state}->(@args)

But how much difference does the syntax really make? I understand the impulse to make perl look more like Haskell but I doubt very much that the extra noise from the sigils makes a lasting difference to the readability/maintainability of the code.

Which is not to say that notation is not important - it is - but it can only get you so far. You still have to understand the concepts behind the notation. I could use source filters and come up this something like:

dispatch :
pieces_of_state
args

Free of sigils and arrows but - well - so what? I still have to mentally reconstruct the text into "table", "condition", and "inputs" clauses.

What is more important in this case is why I'd use a dispatch table in the first place. I can
ruthlessly weed out:

* Irritating if-else clauses
* Obfuscating unless's
* Stupefying switch's.

In short the code becomes more concise. And more beautiful, at least to my eyes.

While you won't notice any changes, there have been biiiig upgrades at CPANdeps. Here's the diff.

I'd heard that MooseX::Method::Signatures incurred a substantial runtime performance hit. I wanted to test if that was true so I tried converting Hailo to use it. The result: Yes, it's slow:

Here's how long it takes (real time) to train Hailo with a new brain, the command is:

time hailo --brain megahal.brn --train /tmp/fortune.trn --no-progress

The results:

• Without MX::MS: 11.37s
• With MX::MS: 52.09s
• With MX::MS + no type checking: 52.84s

Interestingly If I don't do any type checking, I.e. just:

method foo ($one, $two) { ... }

Instead of just:

method foo (Str $one, Str $two) { ... }

MX::MS doesn't become any faster, even though it looks like it also has to check that the argument list is of a certain length and that none of the arguments are undef.

These tests can be reproduced by going to hailo's repository on github and checking out either the master, mx-ms and mx-ms-no-validate branches. Check out version f9786122a08 of master for the most accurate comparison.

I'm really tired of boilerplate. In fact, I hate it so much that I can't stand when I write this:

package Some::Test::Class;
use strict;
use warnings;
use base 'My::Test::Class';
use Test::More;
use Test::Exception;

Of course, you already know about Test::Most and Modern::Perl, so you could reduce it to this:

package Some::Test::Class;
use base 'My::Test::Class';
use Modern::Perl;
use Test::Most;

But that's still boilerplate. So here's what I've just uploaded:

It came to my attention via brian d foy's blog post that the next Nordic Perl Workshop will take place in Iceland - which sounds very interesting. At the same time I decided that I need to take a longish break after working very hard for the last two years. So I will combine my holiday with NPW!

My current plan is bike from Vienna via Prague to Berlin, spend a few days there to visit some friends, take a plane to Rekjavik, attend NPW, and then either cycle a bit more through Iceland or treck a bit (probably combined with public transport). Then take the plane back to Berlin and a train back to Vienna.

The plan still has some issues:

• Is it totally insane to cycle through Iceland in May (if any Icelandic person could comment on this, I'd appreciate that..).
• Maybe cycling from Vienna to Berlin takes to long or is boring. Then I could take the train to Berlin, and cycle from there to Copenhagen, fly to Iceland, and go back to Berlin.

Anyway, I'm really looking forward to this!

Hinrik and I have been creating a replacement for the well-known MegaHAL conversation simulator in Perl. The result is already on the CPAN as Hailo and the source code is available on Github.

MegaHAL has numerous problems that we sought to solve:

I've been working on a personal project lately and I decided that, amongst other things, I was going to use PostgreSQL. Some of you may recall that I had an interesting testing strategy for MySQL. The basic idea is that I don't want to teardown and rebuild the database for every test. Truncating a table is generally much faster than dropping and recreating it. However, if I leave the database up, how do I guarantee it's always in a pristine state? One way is to use transactions and always roll them back at the end of a test. That means, amongst other things, that I can't easily test "commit". You can make it work with nested transactions (if your database supports them), but "rollback" can cause issues.

There's also the problem that by breaking "commit", you're altering the behavior of your code somewhat. Plus, if you have more than one process, unless you can share the database handle, separate processes can't see what's happening in another's transaction.

San_Francisco.pm (SF.pm) started off 2009 with a bang! Fred Moyer took on the daunting role of President, and Joe Brenner stepped up to the unforgiving role of Speakers Co-Chair. Both leaders relieved X-President Quinn Weaver, who sheperded SF.pm for 6 years leading up to 2009.

A Meetup web portal was created at http://www.meetup.com/San-Francisco-Perl-Mongers/ which served to facilitate organizing meetings. Six Apart generously donated a conference space for monthly meetings on the 4th Tuesday of the month (as has been a tradition for the last 10 years). Matt Lanier, the founder of SF.pm, liasoned with Six Apart to obtain this arrangement. We started off the year with a 35 person meeting on how not to use memcached - http://www.meetup.com/San-Francisco-Perl-Mongers/calendar/9432356/

The Perl QA Hackathon 2010 will take place in the lovely MetaLab, a grass-root non-profit hack-space in the middle of Vienna (more on Wikipedia). There will be lots of space, workplaces, sofas, wireless and wired network and a big fridge full of drinks.

Vienna.pm has also proud to announce that we will sponsor the hackathon with 10.500 Euro. We will reserve a small part for catering during the event, but most of the money will go into paying for transport and hotel of invited guests.

If you want to hack on a QA / Toolchain project, please add yourself to the Attendees page of the wiki.

Thomas Klausner,
on behalf of Vienna.pm and the Perl QA Hackathon 2010 team

I'm currently working at Blekko, Inc.; we're still in stealth mode, so I can't really say anything about what we're doing, except that it's really cool, and it's all in Perl.

Working for a startup is wildly different from anything that I've done before; there's an incredible amount of freedom, coupled with an equal amount of responsibility. I love working here.

I'm currently doing a lot of work on our build process, streamlining it and automating it. I'm running things under Hudson with a lot of support stuff to get Perl integrated into Hudson's very Java-y workflow. I'm holding back on details for the moment until I've submitted my proposal to OSCON, but once I've done that I'll talk more about what I've been doing.

I'm on a new team at the BBC. On the previous team, PIPs, we gathered BBC programme data for television and radio. The rest of the BBC could use PIPs to pull schedules, get information about Doctor Who (note, that's "Doctor", not "Dr."!) or understand how a radio programme is broken down into segments which might be rebroadcast on a different programme. The work was complex, but fun. If our system went down, large parts of the BBC wouldn't be able to update their programme data.

Why is blogs.perl.org so slow?

I will use this space to blog about Perl, which might not sound peculiar, but wait!

Unlike most here, I don't make my living by programming in Perl, but rather by working on several unconnected Microsoft frameworks that have a .NET in their brand name. I do use Perl for my pet projects and tools I work on my space time. In this sense I'm a hobbyist Perl programmer.

I think this gives me a unique look on the world of Perl, one of an outsider looking inside. Now, this is quite an oversimplification of the matter, as I should make clear. I frequent the different Perl online presences, such as PerlMonks, use.Perl, blogs.perl.org and planetperl. But I do all that as an enthusiast rather than as a professional.

In the first B::C debugging article we stepped into the B::C compiler with Od.
In the second B::C debugging article we stepped the c code with gdb.
We saw that the compiler is missing a method_named sub (aka a package->method call), the most typical problem with the compiler.
In the third B::C debugging article we saw the easy workaround, using -u to force using the package subs from the package given in the -u option.

Now let's finally fix this bug which was introduced with the addition of the opcode method_named forever.
Looking at the source of pp_method_named() we see that the package name is a PV at
[PL_stack_base+TOPMARK+1], and the method name is at the stack.
Looking at the illguts stack page, inspecting the optree generator in op.c and debugging into pp_method_named we confirm that the missing package PV is the SVOP->sv of the previous op. The name of the CONST.

(Pardonnez mon mauvais français). Ma belle-mère (presque) visite Londres cette semaine. Elle aimerait que Leïla (ma fiancée) habiter en France et me demanda s'il serait difficile pour moi de trouver un emploi en France. J'avais l'impression que Perl n'est pas très populaire en France et je lui ai expliqué que, sans parler couramment le français, il serait difficile pour moi d'obtenir un emploi en France dans un autre langage que Perl. Pour Perl, il semble qu'il ya très peu d'emplois à Perl en France. Est-ce vrai?

Nous n'avons aucune intention de quitter le Royaume-Uni, mais je suis curieux de connaître l'état de Perl en France.

My future mother-in-law is visiting this week. She wants Leila to move back to France and asked me if it would be difficult for me to find a job in France. I was under the impression that Perl is not very popular in France and found myself trying to explain that without speaking French fluently, it would be difficult for me to get a job in France in a programming language other than Perl. As for Perl, it's seems that there are very few Perl jobs in France. Is this true?

We are not planning on leaving the UK, but I am curious about the state of Perl in France.