blogs.perl.org

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

This year the YAPC Surveys have had a few updates. Every attendee now gets an email beforehand containing their personal keycode, so they can prepare the bookmarks before they get to the conference. The announcements are now part of the administration on the site, so I don't have to run everything manually, and can send repeat announcements to users who confirm late, even during the conference.

This year, for the first time, and thanks to a suggestion from Curtis Jewell, the Lightning Talks are all now available for feedback by attendees.

The survey will be open for 4 weeks, and now I have the tools in place, I'm hoping to have the results out before YAPC::Europe. Likewise, I aim to get the talk evaluations to speakers by then too.

Now that the CPAN Testers work is now in monitor mode, I can now pay more attention to packaging up the survey code and releasing it all. I've had interest from various people to use it, and it will be good to get some further use out of the code than just YAPCs. Mind you if any Workshops that use Act would like me to integrate the surveys with your event, please let me know and I'll set up and instance for you.

In a recent interview I did with SourceForge, I got to plug all the really great development that's been going on in the second age of Perl.

I think it's nice when we as Perl devs are able to spread the word out to audiences outside the Perl community. Hence the reason I share this link. I'd like to see more of this from other Perl devs.

Truth == Simplicity?

In other posts, I talked about improvements to Jay Earley's parsing algorithm -- some from Joop Leo, some from Aycock and Horspool, some of mine . Here I'd like to talk about Jay Earley's original algorithm. A common belief of great scientists is that, if an idea is basic and true, it is in essence also simple, and therefore it must have a simple explanation.

Finding the simple explanation might be far from simple. But a simple explanation there ought to be. I like to look for those simple explanations. Writing my mathematical novel, The God Proof, confirmed me in this habit. Whenever I am studying something, and it seems important and true, I look for the simple explanation.

Dotted Rules

The idea behind Earley's algorithm is that you can parse by building a table of rules and where you are in those rules. "Where" means two things: location in the rule relative to the rule's symbols, and location relative to the parse's input stream.

In a Perl script typically a shebang line is something like:

#!/usr/bin/perl

this works great if you want to use a wide, system based, Perl for your scripts. But what if you have several different installations of Perl and want to run the same script using different Perl versions without having to change the shebang line. Well, one possible and straightforward solution is to change it to something like:

#!/usr/bin/env perl

and then push the version you want to use to your $PATH environment variable. This can even be easily done based on the user. For example, you can have a user named 'perl_5.10' and for that user have:

PATH=/usr/local/perl_5.10/bin:$PATH

now, this user runs scripts (with the env version of the shebang line) using Perl 5.10.

I've done a little more with Perl and web design, but I've encountered a problem that has left me a bit perplexed. There's something PHP does that I'm sure Perl CAN do, but I'm just not sure how. That said, I'm not a huge fan of PHP, and to be quite honest the only function I've utilized has been include(), which is what I need to replicate. As you know, being able to standardize a page layout (header, body, footer) with separate pages makes things much easier to update. Instead of correcting/adding a navigation link to twenty pages, you only make one change! However, using PHP within a Perl script (without the aid of the PHP or PHP::Include modules - my host doesn't have 'em installed) doesn't work as the browser doesn't get the chance to parse/execute the PHP.