blogs.perl.org

In spite of having programming Perl mostly full time for the last 12 years, I still find myself learning new things about how Perl works (like the time I discovered the arcane apostrophe package separator when trying to add a possessive 's' on the end of a variable in an interpolated string).

Yesterday yielded a similar epiphany when I realized how rand, srand and fork were interacting in our e-commerce application at $work. Consider the following one-liner:

perl -le 'for(1..2) { fork or do { print int rand 100; exit } }'

This prints two random numbers between 0 and 99. Simple. Now, consider this slightly different example:

perl -le 'rand; for(1..2) { fork or do { print int rand 100; exit } }'

This prints the same random number between 0 and 99 twice. The reasoning is quite simple but was not obvious to me at first. When rand is first called in a Perl application, srand is implicitly called to seed rand with a different starting number. If this happens prior to a process forking, the same seed is shared by all of the child processes and non-randomness ensues.

Perl has grep/map/sort since probably forever (actually, sort() starts appearing since Perl 2.0). But even now, reduce is still not a builtin in Perl 5 (though available via List::Util), so doing reduce is probably not something that comes as naturally to Perl programmers. Meanwhile Ruby, JavaScript, and even PHP have their reduce operation builtin.

But then, reduce is "not really that useful" (you can just replace it with a simple for loop). So much that Python 3.0 now removes the function from the global namespace and reduces it (pun intended) to a mere member of functools. I guess reduce is really handy only if you are in a heavily functional language that lacks procedural basics.

This can be thought of as a testament to the level of language design skill that Larry has.

The rather funny thing is, in Perl 6, in addition to the reduce() List method there is also the reduce ([]) metaoperator as well.

For a while I've had very little to write because I've had very little time to speak. It makes sense when you think of it. :)

We had a lot of changes at $work recently. I've received a new position (as a team manager) but I'm still retaining my "Perl Ninja" title, and I've also had a birthday celebrated at the $office and was given a makeshift rubberband gun, crafted by Tamir Lousky. :)

Another big change (that is the brainchild of Mr. Lousky) is monitoring according to roles and not category tags, which is (at least according to the title) the subject of this post.

Inspired by some conversations at YAPC NA 2010, I'm abandoning my use.perl.org blog, and starting here. I've never used Movable Type before, so this might take some adjustment.

This blog will be primarily about Perl-ish things in my awareness. I have quite a few other publishing realms, each with their own specialization.

If you want to follow everything I post, I suggest subscribing to my FriendFeed feed.

This is the first blog post I have ever written. Mostly I've not written anything based on fear. Fear that I'm not good enough to post anything out into the aether. 3 years ago I left the programming industry thinking I would never return. In that time I've learned some hard life lessons, the foremost of these lessons is that fear is like a fly trap, it keeps you stuck. So I am making 2010 the year to be fearless. I hope you will all join me and make your first blog post on blogs.perl.org. Look for more posts from this, now community aware, Perl hacker.

Grep is another Perl's great built in function, one of the things I use it most is to check if I can find an element on a list. For example, instead of something like

    my $found = 0;
    foreach (@list) {
        $search eq $_ and $found++;
    }

I prefer to use something like:

    my $found = grep {$search eq $_} @list;

Code is simpler and more elegant, there's no significant performance from using one or another, although grep seems to actually run faster if you want to squeeze all the crumbs:

Like everybody else, I've been reading about Perl6, lurking in #perl6 and just trying to keep up with the progress. But in real life, most of us need to turn out Perl5 code for a living. Of course, we love it (well, I do), but it could be fun to have at least a line or two of Perl6 code under the belt before rakudo *.

So today I tried to jump head first into a problem I wanted solved, connecting to PostgreSQL from Perl6. I'd noticed that there is a Pg.pir in parrot, so I thought it would be possible to use that. It turned out that it is possible, but it required a lot of guessing and even more help from #irc (mainly moritz, who also identified and fixed (r47900) a bug in Parrot in a matter of minutes). omg people are helpful there!

My Perl Android talk was accepted to YAPC::EU 2010 (!!!!) and I want to book the room reservation for my girlfriend and I.

Unfortunately, the hotel (MyHotel - where the conference is taking place) only accepts the credit card details via Email. I've suggested simply calling them and - once I've verified that I'm speaking to the right person - give the details via phone.

However, they insist on getting it via Email. They even suggesting sending two emails, one with half the details, the other with the rest of the details.

Now.. is it just me or is sending it via Email completely insecure? Not to mention that separating them into two emails provides no added security whatsoever.

How did other people handle this? Do you think I should send it via Email, or book another hotel, or.. persist?

The Garden Path

In Perl 5.10, the following code is a syntax error:

{42;{1,2,3;4}}

syntax error at (eval 25) line 1, near ";4"
syntax error at (eval 25) line 1, near "}}

TPP is based on an algorithm called LALR. (To avoid confusion when discussing various programs which parse Perl, I will call the one that comes with the Perl distribution the Tradition Perl Parser, or TPP.) If you look at perly.y, you will find a real achievement in LALR parsing. and therefore in computer language parsing in general. But LALR has its limits and even in the TPP these show up every now and then.

Having just finished an enormous pile of marking, but not having enough time to get on with something more substantial I thought I'd work out (again) how to use LWP::UserAgent and WWW::Mechanize behind an authenticating proxy.

http://user:pass@my.proxy.server:8080

Anyway, here's the way to use LWP::UserAgent behind an authenticating proxy:


use LWP::UserAgent;
my $ua = LWP::UserAgent->new;
my ($user, $pass) = qw/user pass/;
$ua->proxy(['http', 'ftp', 'https'], 'http://my.proxy.server:8080/');
my $req = HTTP::Request->new('GET',"http://www.google.com");
$req->proxy_authorization_basic($user, $pass);
my $res = $ua->request($req);
print $res->content;


And here's how to do it with WWW::Mechanize:


use WWW::Mechanize;
my $mech = WWW::Mechanize->new();
my ($user, $pass, $proxy) = qw(user pass http://my.proxy.server:8080 );
$mech->credentials( $user, $pass);
$mech->proxy('http',$proxy);
my $url = 'http://whatsmyip.net/';
my $response = $mech->get($url);
print $mech->content;


->new

i dont like it when people say that. because i like I love people. they deserve some understanding, tenderness and indulgence. and its a decent behaviour to do so anyway.

But on the other hand:

most people on this planet I see as incredibly limited. and in many different ways. whats the most limiting factor are prejudices and be stuck to the own point of view.

In a research project we are using a Perl hash (generated by a tool similar to Dumper, but with some sorting mechanisms that are relevant to the project). Unfortunately some of those dump files take more than 200MB of disk space. But, fortunately, text is easy to compress, and bzip2 does a fair good job compressing these files. But, unfortunately, Perl 'do' function does not handle bzipped files. But, fortunately, we can make our own.

The solution is quite simple. In any case, I decided to share it with you.

First, use the appropriate decompressing module:

use IO::Uncompress::Bunzip2 qw(bunzip2 $Bunzip2Error);

Then, do the job:

As of June 20th, I am now married. It was also my birthday and Father's Day (we just found out she's pregnant!), so I am not only a very lucky man, but I'm going to be totally screwed on presents.

And to make things relevant, I recently asked how to post to blogger.com from Perl. I was also asked to share the solution. Here it is.

2 weeks from now, my last semester exam will be over and as I quit my main $job, there will be *real* holidays this year. At least one month with no plan at all. How cool is this?

I'm considering a rewrite of my module Image::BoxModel which unfortunately never got far and is "a little" messed up in design.
I mainly use it to draw bar charts with ::Chart, and I think I am the only user. At least I don't have notice of anybody using the module. I can feel free to change whatever I want to.

Now, should i do it in Perl 5?
Perl 6?
Use Moose?
I see pros and cons.

As for Moose, I'm uncertain if I want to minimize dependencies or maximize fun.
As for Perl 6, I'm wondering if it is ready and used. On the other hand, I read a little about new features of this language and I must say I'm impressed.

As nobody uses my module anyway, my main target is to learn as much as I can. (This does not include a rewrite in PHP..)

Thanks for your advice!

On Wednesday, Birmingham.pm had their monthly technical meeting. This year we have started a different trend, in that the technical meetings now alternate between technical presentations, and hands-on discussions. While the former is the more traditional talks, slides and projectors, the latter is basically a hacking session. Wednesday night's meeting was a further hacking session, hoping to follow on the success of our April session, which resulted in identifying problems with Test-Database and SQL-Statement.

Yes, I am talking about YAPC::EU::2005. This Yapc was organized in Braga, Portugal, and during this Yapc a proceedings book with some articles was distributed to all participants. It has 235 pages devoted to Perl, and I am sure some of them are still actual.

Yesterday I went digging my archives and mailboxes, searching for the original PDF and, fortunately, I found it. Therefore, you can create your own personal backup copy. Just follow the link above.

I find myself in the habit of saying that I will write a "script" as opposed to an "application" or a "program." I suppose that my habit of saying "script" has roots in procedural language design. Although I still have a habit of saying "script" even if I write an OO application.

Perhaps I unconsciously use the word "script" when I actually mean "simple application" because I want to convey to others that the task will be simple to perform - because I'm leveraging the power of Perl and the CPAN - and will be done quickly.

Perhaps I'm unconsciously thinking that it is risky to say "application" around people who like to over-implement projects (too much planning and hiring of consultants.) On the other hand, it is risky to say "script" around those same people once the development is underway - because they want to be assured that it is being well designed.

Nevertheless, I think that I will try to avoid using the word "script" in most situations.

Dist::Zilla is fantastic, but I seem to have quite a few distributions I wanted to convert and doing the boilerplate for dist.ini from an existing distribution can be a little tedious.

Wouldn't it be great if there was a tool to do this for me?

And so Dist::Zooky was born.

( Embarressingly I had to explain the reference to RJBS, who found this ).

Dist::Zooky generates a dist.ini for a distribution by examining the metadata produced by running Makefile.PL or Build.PL and then converting it to something that
Dist::Zilla will like.

For Build.PL and Module::Install based distributions it does this from the MYMETA.yml file that is produced by running the .PL file. For ExtUtils::MakeMaker based distributions it gathers the meta by parsing the Makefile that is generated. Ick.

Here's an example

Here are some notes I made while hacking on Language::Expr::Compiler::JS. Of course, there are a million differences between the two, but these focus mostly on operators and types. Hope it can be useful.

After hearing the talk of Patrick I decided to offer a Perl 6 training at YAPC::EU. The organizers were kind enough to accept my offer even though it is way after the dead line. So if you'd like to learn Perl 6, on the 7th August I am going to give a training in Pisa, Italy. For details please look at the Perl 6 for programmers page.