blogs.perl.org

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.

One of the things that people were emphasizing at YAPC::NA::2010 was the importance of marketing and framing Perl. Another thing we learned is that the CPAN is the "language" for our Perl "virtual machine."

If you were telling a novice Perl developer about the CPAN, which web site would you send them to?

Perform a Google search for "cpan" and notice that www.cpan.org is returned as the first result. Don't get me wrong, www.cpan.org is a great resource for developers. However, I don't think that it gives a very good first impression. perl.org/cpan.html seems to be an improvement, in my opinion.

What should the face of the CPAN be like?

No one wants to step on any toes. Is www.cpan.org "well volunteered" or "patches welcome" friendly?

Or would we be better off referring and linking to the other faces of the CPAN?

Damn, damn, damn, my last post was eight days ago. Not sure if this interval qualifies for Iron Man. Any way, I'll continue trying to keep this blog active.

Then, today I would like to talk a little about one of the two talks I submitted to YAPC::EU::2010, the one that got accepted (for now), about rewriting documents.

Perl regular expressions are powerful. I think we can't call them regular anymore, since Perl 5.6. But, hey, that's the name everybody uses, so let's keep using it.

Now, sometimes we do not want to perform just a substitution, but a sequence of transformations. And, in some cases, these transformations are inter-dependent. When you are in this situation, a rewriting system is very useful.

It's a brilliant idea: bank on JSON's popularity and more widespread implementations, add some of the important YAML features not present in JSON on top of it. The result is JSYNC, along with its preliminary CPAN module. (I'd probably picked a different name and choose something like "\" for prefix instead of ".", but hey, it's not my project :-)

A few months ago I was really desperate with the YAML situation in Perl. We have the largest number of YAML implementations, but none of them are good enough compared to Ruby's libsyck. I even contemplated converting all my YAML documents to JSON, but of course that plan was cancelled because JSON doesn't even support references nor objects.

Here's to hoping JSYNC will rocket to popularity soon enough. Ingy++.