I blog every two years.

Perl hash autovivification is hateful

Perl Iron Man rules specifically said we could blog about what we hate; the nasty habit that Perl has to autovivificate hashes when you don't expect it to, is one of them.

autovivification in itself is a good thing and is useful in many places [1], but at times, it's just plain aweful:

Here is a first nasty effect in a common idiom:

yann@dev:~$ re.pl                                                                 
$ my %hash =  ( x => 1);
$ exists $hash{x}                                                                   
1
$ exists $hash{meta}
$ exists $hash{meta}{z}
$ exists $hash{meta}
1

And now here is a second common idiom that can be fatal:

$ my $hash = {}
$HASH1 = {};
$ for (keys %{ $hash->{meta} }) {                                                   
> print "$_\n";                                                                     
> }                                                                                 
$ $hash
$HASH1 = { meta => {} };

Each time, the 'meta' hash has been autovivicated when deferenced, the problem is that it's quite easy to oversee that fact and somewhere else do in the code:

unless (exists $hash->{meta}) {
    do_something_really_important($hash); # will install $hash->{meta}
}
## code that relies on $hash->{meta} to have meaningful informations

Where you can, completely avoid to evaluate conditions based on the presence of a hash in your hash, because this can lead to silent and painful bugs. Calling method calls on objects where it's possible is one option, or use another indicator that do_something_really_important() needs to be called...

To finish with a bit of love after all this hate: re.pl is awesome and you can get it here (checkout MultiLine PPI plugin too):

http://search.cpan.org/perldoc?Devel::REPL

[1] http://www.sysarch.com/Perl/autoviv.txt

SPAM: maladresse ou malveillance?

Je me suis inscrit il y a plusieurs années sur le site LAMBDA, pour voir, et je n'ai jamais consenti a ce que mon adresse email soit partagée. Et ce matin, je reçois un SPAM d'un site qui n'a rien a voir si ce n'est qu'il est hébergé par le même contact technique.

Que ce soit de la négligence ou un acte purement criminel de la part de Mr. FC, le gérant de ce site: c'est tout simplement lamentable.

update:

En plus des commentaires ci-dessous avec FC et Renaud Varoqueaux., des mails ont ete echanges, et j'attends d'y voir un peu plus clair.

update 2:

J'ai censure ce post, ne voulant pas porter trop de prejudices a quelqu'un qui n'avait pas d'intentions malveillantes (mais qui a porté prejudice a de nombreux internautes). FC a fauté professionellement et est responsable de cette erreur, en admettant qu'il s'agisse bien d'une erreur, meme si ce n'est qu'un prestataire qui l'a commise.

Perl script to help stuffing diff into Review Board

update: I found another way

At Six Apart we occasionally use Review Board to submit patches for review. For a while I've been using Git with git-svn to work on our proprietary projects. So my workflow looks like:

$ git checkout -b feature-X
... work ...
$ git commit # multiple times
... work ...

# go back to my branch where I track subversion's trunk
$ git checkout svntrunk

# get changes from upstream
$ git svn rebase

$ git checkout feature-X
$ git rebase svntrunk

So then I need to send the patch for review, but a simple git diff svntrunk doesn't work with review board. I guess there is a better way (I even found git mentioned in Review Board's UI) but I couldn't find it. So I started with a simple shell script to take git diff output and change it to be accepted by review board, but in the last version Perl came to the rescue to make it a bit better and easier to read (So this entry counts for Perl Iron Man).

Here it is:

This removes a/ and b/ prefixes that Review Board rejects, add the subversion revision number and remove /dev/null that git uses to mark new files.

this thread gave me the inspiration: http://www.nabble.com/Using-git-svn-with-review-board--td16119879.html

Perl Iron Man

my Feed reader come up with this post:

Blog once per week [about Perl].

Every week.

Every single week.

Ten lines is fine. It's going to take all we failures some effort to get into this, so there's no going to be restriction on post length. There's going to be no barrier for how badly written it is. None of us are good enough, and that isn't a problem. What matters is we try. What matters is that we make some fucking noise. Show off cool new toys you've found, or cool new toys you're writing, or even trying to write. Show off neat tricks you came up with. Talk about your failures, too, because then maybe the next guy who makes the same stupid mistake will find it on google and think "I'm so glad that guy didn't mind sharing his idiocy because he's saved me wasting half a day because I'm an idiot too." Tell the world that perl5 is alive. If you're a perl6 true believer tell the world how it's soon going to be christmas. Talk about the stuff that you love, the stuff that you hate, the stuff that excites you, the stuff that drives you insane. But MAKE SOME FUCKING NOISE because if enough of us do, the law of averages says there's going to be some of it that's well worth reading.

So, I've set up an alarm in my calendar and I'll try to do just that... Blogging and Perl: I had to do it... won't be pretty most likely, but not posting is even worse.

What about you?

I like moose

The past weeks I've been a bit more interested in Moose and I liked the concepts so far. At the surface It's still the same old Perl but with less typing and incentives to reuse best practices, but when you dig a bit further the MOP is really kicking ass.

In order to get accustomed with it I've started to port Data::ObjectDriver to it (you can find it in my github repo). I just have the new 02-moose.t test passing. Another reason to look into that (Yet Another ORM) is that there are some parts in DOD that I really like and that aren't in Fey::ORM or Reaction AFAICT.

The whole process gave me ideas about something else, so I have dropped this branch and I have spent some of my free time on this new idea. I'll post here if this gets interesting.

Git-svn hack to import original committers from an svk import of svn

I don't recall exactly what was the context but on one of your repo at Six Apart we had the beginning of the project imported into the public repostitory using an external tool (svk I think), I made a patch to git-svn (quick and dirty) to look into the subversion log message and correctly attach the commit to the original author.

The original commit messages have this format:

        # r123@host (orig r1234):  author | 2006-05-17 17:07:42 -0700