use Perl

Let's start by saying that Exporter is not an ideal module. It was conceived a long time ago, when some things (like programming practices) were different. But if you need a module with exporting capabilities and are not very demanding, Exporter is the module to use. As a bonus, it is there together with your installed perl.

Once we said this, this article is to announce that Exporter is now available at CPAN and now correctly indexed. This means that from within your CPAN shell, you may say:

cpan> install Exporter

and this omnipresent Perl module will be updated to the latest release.

Why is that important?

A lot of CPAN modules break unexpectedly because its authors used the Exporter feature

  use Exporter 'import';

which allows a module to get the Exporter's &import without needing to inherit from Exporter. However, this appeared only in Exporter 5.57 which was released with perl 5.8.3.

That means that every time a module, which did the assumption that this feature were always there with Exporter, was tested against a pre-5.8.3 perl, it choked.

Now these modules can correctly declare they need at least version 5.57 of Exporter and cpan will try to update this very important piece of your standard libraries, to the dismay of many conservative people (including some sysadmins) out there. (Disclaimer: but it will only update if you say so: explicitly or by the configurations you have set up.)

That's evolution coming: time to use new tools even with rusty perls. Maybe, in the next step, people start using newer perls as well. (Hail, 5.10!)

$ make disttest dist veryclean

which I thought should test the distribution-packaged files, create a neat tarball and leave the current directory clean. THE only mistake is that "make disttest" creates the "blib" directories and "make dist" packages it together in the tarball. The pause indexer points your error:

The distribution contains a blib/ directory and is therefore not being indexed. Hint: try 'make dist'.

And I needed to use some weird file names (like Exporter-5.61b.tar.gz) to index correctly the files. I will be smarter some next time.

Sometimes I wonder at how good I am to use code in the wrong way. This time I did it with Test::WWW::Mechanize. I started a test script with:

    use Test::WWW::Mechanize;

    get_ok( $url );

and then I decided to take a look at the HTML I was getting. Using the LWP options seemed natural:

    get_ok( $url, { ':content_file' => 'p.html' } );

But that gave me some binary content rather than the HTML I was waiting for. The problem was that WWW::Mechanize (the father of most of the browser functionality of the testing module) determines that 'gzip' can be used as the content encoding (if Compress::Zlib is available) and transparently decodes the response.

Unfortunately, the LWP options in get_ok are the same as in LWP::UserAgent::get and knows nothing about this helpful trick. So I got the gzipped content and not the HTML page. The content is uncompressed later with other WWW::Mechanize methods.

In turn,

    use File::Slurp qw( write_file );
    write_file( 'p.html', $mech->content );

worked as I needed it.

This week has seen the publishing of the three first micro-articles on Perl 6 operators, following the plan of this grant proposal.

The links are:

• Introduction
• The zip operator
• The ~ operator
• Repeat operators

These articles have been published at Tuesday, Wednesday and Friday. Probably next week we'll settle in a more regular schedule like Monday, Wednesday, and Friday. That means people can read their xkcd strip and have a small dose of Perl 6 in the morning ;-)

I gladly watched the article on the string concatenation operator hit the 12th position in The Hot 25 of O'Reilly blogs by yesterday. This list appears to the right of the main weblog page. I am not so sure of how it ended there, but that's ok, I think.

The project also had, in my opinion, a very good reception from the Perl community. And I found help in all channels I announced it: the #perl6 IRC channel at freenode, the perl6-language@perl.org mailing list, use.perl itself and PerlMonks. Special thanks to autarch who generously offered to do grammar editing improving the English of the texts no need to say I hastily and gladly accepted it. All remaining mistakes in these articles are mine.

It is not all roses however, because I have been strugling with MovableType, the blog software of O'Reilly site, and I am losing by now. Sometimes it raises some pretty database errors after an update (hum, probable entry point for SQL injection attacks), but it gets better after some senseless tweaking. And more to the point, I have proposed to maintain an index of all articles in the introduction, but I encountered the issue that sometimes MT changes the URL after an update. This gets very annoying as all articles refer to the introduction and then need to be updated (while I pray they keep their URLs when I do this). Also it defeats bookmarking as a commenter already complained. If you are well versed in MovableType and have some clues, I am listening.

Juerd kindly granted me an account at feather to work/experiment with pugs. I am also maintaning the article sources there at a SVK repository which should be moved into Perl 6 docs later. I am writing the articles in POD6 and it looks like it is going to be fun. I squashed a tiny bug on the conversion to XHTML and I am playing to get nice looking customizations of the generated HTML. The articles would be available (POD6 and HTML) in the URL:

http://feather.perl6.nl/~ferreira/perl6-operators/

The patch and patched Perl6::Perldoc is also available at http://feather.perl6.nl/~ferreira/patches/ but I filed an RT ticket as well, so it has a chance to be permanently fixed.

http://ferreira.nfshost.com/perl6/stitching6.html

The plan is to write a series of blog entries discussing a Perl 6 operator at a time or a small group of closely related ones.

My working hypotheses are:

• the audience is broader than Perl 6 developers
• they should be educational
• they should be light
• they should not be long
• they should show some nice Perl 6 code
• they should be based on what's specified
• if possible, they should be cool

The goals:

• make people know more about Perl 6
• allow them to do that in an entertaining fashion
• entice the curiosity
• estimulate the need for Perl 6
• spread the word

The choice to approach Perl 6 via operators was an artefact. Every single piece of Perl 6 code would present a bunch of features, hopefully good enough to demonstrate the look and feel of the language. And operators cross over the entire realm of the language (even more than with Perl 5). The pretention would be to compose a picture of the language in small doses like Marvin Minsky did in Society of Mind with every chapter in a single page, striving to get a comprehensible whole from the component pieces. It's kind of prententious, but hubris is a quality around here and I hope not to be alone in this endeavour.

Any help will be much appreciated: suggestions, corrections, grammar and typo fixes, rephrasing, etc. As drafts got ready, I will announce them in Perl channels (#perl6 at freenode, use.perl, PerlMonks, perl6-language mailing list) to have a chance to improve the articles to be published at ONLamp site.

Join me. The drafts of the introduction and the first article are here:

• http://ferreira.nfshost.com/perl6/intro.html
• http://ferreira.nfshost.com/perl6/zip.html

# in-place version
sub strip { s/^\s+//; s/\s+$//; }
# which would be used as
strip($msg);

promptly corrected by Aristotle in, not one, but two flavors:

sub strip { $_[0] =~ s/^\s+//; $_[0] =~ s/\s+$//; }

# or maybe

sub strip { s/^\s+//, s/\s+$// for $_[0] }

When I first thought about it, I believed my sin was failing to find the topic. I mistakenly assumed the sub parameter was already the topic, while one of the variants by Aristotle did not use $_ and the other used a proper mechanism the modifier "for $_[0]" to set it right. To tell the truth, my version works if used just as strip(), acting on whatever is in $_. (More on this on a later blog entry.)

My mistake was like saying

where that something was left hanging like a dangling pointer. The phrase below would be more correct:

My programming error (in Perl language) was like an ordinary error in a phrase in casual conversation (in natural language). And the major culprit was not proof-reading what I wrote.

(Of course, it is also an issue of proficiency. More practice would often imply a smaller defect ratio that could have set me free of that shame. But this proficiency only sets higher the threshold where mistakes are more likely. They will happen anyway the issue is whether they have discovered out there or while in the domestic environment.)

So while writing prose calls for proof-reading, programming calls for documentation and testing to be complete. With documentation, we make clear what is the purpose of the code (even though $_ = "this "; strip() works, it was not what &strip was supposed to do). The tests would establish a certain level of confidence on the operation of the code, at least as long as the usage was captured by the test cases. Extrapolation is always an enterprise with unknown consequences.

I was guilty of being a light commenter, typing faster than my brain takes to write a correct piece of code of 34 touches. But it will never be easy. Fortunately, after Aristotle, some careful documented design and testing, many pieces of code will be as robust as most applications need.

Ok. The entry title was provocative. It only means: Programming is hard. And you already knew that.

Back in the university days, I've read a few texts on language acquisition and almost understood some of the mechanisms used to learn a foreign language. I enjoyed learning about learning. A lot of reading helped me out with English and a lot of practice allowed me writing some comprehensible articles.

Nowadays, I am faced with the inverse phenomenon: language de-acquisition. I never knew it existed. But after years of non-practice, I don't have any conversation skills in English and I just found out that I am getting worse at writing too. Silly me that thought that it was like riding a bike: never to be forgotten.

I diminished a lot on the diversity and volume of reading. Today it takes me too long to write a few paragraphs. And when it is done, it does not make much sense and is riddled with mistakes. It sadly reminds me of a joke we use to tell on a guy that went into USA, could not learn some English and came back home... dumb. Disgusting.

$ perldoc -L it perlintro # perlintro in Italian
$ perldoc -L fr -f pack # read about pack in French
$ perldoc -L eo -q shell # search Esperanto FAQs about 'shell'
$ perldoc -L tlh Acme::DonMartin # the docs of Acme::DonMartin in Klingon

(Obviously, it works if you have installed the corresponding translated PODs.)

These changes were applied to bleadperl and published on CPAN in release 3.14_01. The original work by Italian mongers were followed by a similar distribution of a French translation package (POD2::IT and POD2::FR). These distributions relied on a certain amount of code that Pod::Perldoc called in the manner of a plugin.

After some work on the underlying code, it became evident that the essential of the distribution of the translated PODs was amazingly simple. Place PODs in the corresponding POD2::<lang> namespace. There's not much more about it (and there is some work in progress on the stuff that remains).

With a lift in the original code in POD2::IT and some corresponding changes of Pod::Perldoc, it is possible to distribute and use translated PODs in a very simple way. The necessary steps are:

• install POD2::Base
• install Pod::Perldoc 3.14_03
• just make sure your translated PODs get shipped and installed in POD2::<lang> namespace

and voilà. Silly internationalization at perldoc level working.

I am taking a time, waiting for bugs to show up, feedback, and will submit these changes to bleadperl.