blogs.perl.org

Over the past year I had posted queries to our local perlmongers group za-pm and received substantial help from the inmates.

Looking at things Perl I noted that on the perl.org site that we did not have a flag planted on the map. Querying this I found that the group leader (I never knew there was such a thing) had gone awol and that his emails were bouncing.

Reporting this with glee to the list & asking the leader to please stand up and be identified got me voted into the hot seat before you could write a perl one-liner.

Having disposed of other encumbrous duties I recently got access to the web site and added a small note, the first in seven years! Happy that I had fulfilled my promise to reactivate the site to pm_group I sent a small 'done it' note expecting a pat on the back.

Database access for Rakudo Perl 6 has improved markedly in the past month. Here are the main points:

The MiniDBI project formerly known as FakeDBI is destined for inclusion in Rakudo * and is now 'usable' and 'useful'. Commit permission to the repo is freely available via hugme in #perl6. Porting simple database client software from Perl 5 to Perl 6 requires only minimal editing.

So, why MiniDBI and not just DBI? Because Perl 6 will have a DBI v2, based on JDBC, read more about that below. The Perl 5 DBI (v1) is very widely used, but enhancing it is far less important than maintaining its stability. Mini means a short term port of a v1 subset, leaving the DBI name free for v2 to use in future.

The mysql DBD has been working for several weeks now, most enjoyably inside http://pivo.jnthn.net (source). Su-Shee++ contributed various fetch* methods and tests in the new database independent test suite.

A new distribution is now on its way to your nearest CPAN mirror. Devel-Platform-Info provides the code framework to return metadata regarding the currently running operating system. The intention is to eventually use this metadata within CPAN Testers reports. However, the first step is to provide the means to extract the information from the operating system and return it in a consistent form (a hash) to the calling code, regardless of the operating system. There have been a few attempts on CPAN to provide 1 or 2 items of this metadata, or to verify whether the OS is as requested, but nothing that provides a simple data structure, with all the necessary components provided.

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}}

If you try it, what you'll see is something like this:

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.

Sometimes you're lucky and a proxy url of the form

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

will work nicely. No such luck for the proxy I usually use.

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;


I'm not really sure how you'd go about accessing a basic auth protected page with the WWW::Mechanize method mind you. It'd also be nice if (in both cases) whether to use a proxy, and the username and password could be handled during the call to

->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.