ferreira's Journal

YAPC Brasil 2008 hatching

ferreira — 2008-09-16T22:36:46+00:00

We just started preparing a YAPC Brasil 2008. It will happen together with CONISLI 2008, at São Paulo (http://www.conisli.org/), October 18-19. Yes, that's very little time until the event, but we'll make the best we can with our distributed efforts. Brazilians are known for being good at improvising. (But we'll work hard to make that work in this limited piece of time.)

We know we will have a stand and a room where the talks will happen. Everything else is in flux yet. We are going to try to put down a preliminary scheduling very soon, and we would appreciate contributors as speakers and people with good ideas and suggestions.

At first sight, it is quite possible that we can gather together many Perl developers that never meet one another in person. That's mainly the people who keep busy the mailing lists Cascavel-pm, Rio-pm, and SaoPaulo-pm.

We are assembling a preliminary list of talks here: http://www.perl.org.br/Main/Yapc2008Preliminares.

I will try to post more information on the event as it is available.

Bye bye, old modules

ferreira — 2008-05-31T22:20:31+00:00

I just scheduled for deletion (via PAUSE) the last CPAN files related to Carp-Indeed and Class-Constructor-Factory distributions. Both were renamed: Carp::Indeed became Carp::Always and was deprecate since a long time ago. Class::Constructor::Factory was meant to be renamed since its inception and became Class::Lego::Constructor. I doubt anyone will miss them.

These files will no longer be found in CPAN, but only at BACKPAN. It got me thinking at how often that sort of cleanup happens. There were some occasions when I only found modules mentioned in the documentation of other code at BACKPAN. In general, these deletions look sensible (incomplete code that were never finished, superseded code, etc.). But many times it is hard to find the reasons they were removed and what was left in its place (if any). So it looks like BACKPAN really become an archeological research field, with all the difficulties to reconstruct the past when someone wants to.

Is your file tidy? Really?

ferreira — 2008-05-01T02:50:08+00:00

With respect to Perl::Tidy, it is quite obvious that a tidy file is one that has gone through perltidy and which does not change if reformatted again.

$ perltidy tidy_file.pl $ diff tidy_file.pl tidy_file.pl.tdy # zero, no difference

But Perl::Tidy is a work in progress which is constantly improving. And improving means changing. Those changes may include the fixes of some behaviors considered non-ideal or even flawed. So tidy files under a Perl::Tidy version may not be tidy under another version. So this concept is a little fragile (or needs a more precise wording).

Even Test::PerlTidy (which intends to capture that tidy-ness concept in the form of an automated test) was caught by this detail, since a new release of Perl::Tidy got out. Edmund von der Burg and me are working on a reasonable approach to this issue. Wait for a new release of Test-PerlTidy soon.

Clashes between functional and OO worlds

ferreira — 2008-05-01T02:37:56+00:00

In refactoring some code, I opted for turning "warn/carp" calls into method calls "$self->carp". This way the objects could act by themselves (using CORE::warn/Carp::carp) or cooperate with others (via a closure).

sub carp { my $self = shift; my $on_warn = $self->on_warn; if ( $on_warn ) { $on_warn->(@_); } else { Carp::carp(@_); } }

It turned out that naming the method the same as a function was a bad idea (at least in the transition to the fully refactored code). The simple application used some simple hierarchies, and when I "fixed" the superclasses as in:

package Parent; sub carp { ... }

I found after some perplexity that in the children, code like that:

package Child; use base qw( Parent ); use Carp qw( carp ); ... $self->carp("message"); ...

emitted strange messages like:

Parent=HASH()message

because $self->carp("message") resolved to Carp::carp( $self, "message" ) as Carp::carp had been exported to Child overriding the method I was expecting to inherit.

That's what we earn because methods are just subs.

Being clever by half may hurt

ferreira — 2008-04-25T12:10:40+00:00

I know Perl may be quite irregular sometimes, and because it is irregular gotchas are easily glossed over and bite.

After some code refactoring, I ended up with a code like that:

for (@$x) { push @array, $_; }

which immediately suggested me an equivalent expression:

push @array, @$x;

Unfortunately, this is not quite equivalent when $x is undef. Under strict, @$x bails with "Can't use an undefined value as an ARRAY reference " while for (@$x) {} works flawlessly as a loop that is never entered. So the real equivalence I was looking for is:

if ( $x ) { push @array, @$x; }

whick is ok (as long as $x contains array refs or undefs).

"perldoc -A @+" is out there

ferreira — 2008-04-23T13:06:31+00:00

Ovid proposed a patch to let perldoc search for Perl predefined variables from perlvar and mentioned it at use.perl here and here.

The development release Pod-Perldoc 3.14_05 brings this goodness to your delight.

Nancy: from Lua to Perl

ferreira — 2008-03-09T20:13:29+00:00

Some days before, Reuben Thomas (a known contributor to Lua community) announced the release of Nancy, "a simple web site builder" at the Lua mailing list.

For the dismay of Lua afficcionados, this release was not written in Lua.

Oh, and it's written in Perl. I thought it might be interesting to say why. The problem was not libraries (I used my pure-Lua stdlib and LuaFileSystem), but deployment on Windows (I use Linux). I had previously built an all-in-one binary for Windows using a cross-compiler. That worked fine but made it hard to debug on Windows as I couldn't just edit-run, and also broke nastily when the cross-compiler was upgraded. So, I switched to LuaBinaries. That enabled me in the end to deploy only pre-built binaries, but at the cost of having to install 2 binary packages, and then do manual fiddling to get .lua files run as commands by the Windows shell.
ActivePerl does all this for me, and I was already using some Perl scripts in the same system, so by rewriting Nancy in Perl I got down to "run the Perl installer" as being the prerequisites for running Nancy.

Nancy begun its life as Lua code (and that's the reason Reuben announced this at Lua mailing list for the last time unless it be written in Lua again in the future).

Perl still has an edge ahead before some of the popular dynamical languages out there, which (I hope) is not going away anytime soon in the future.

Abusing "Memoize"

ferreira — 2008-03-05T20:13:03+00:00

A few days ago, I was writing a code (namely the Path-Classy dist) and stared at the code that produced the file size in raw bytes or "humanized" (28300 or 28K).

sub _format_size { my ($sz, $opt) = @_; my $format = $opt->{format}; if ( $format eq 'h' ) { require Numbers::Bytes::Human; return Number::Bytes::Human->new->format( $sz ); } else { # raw bytes return $sz; } }

Of course, loading Number::Bytes::Human and creating a instance every time $f->size({ format => 'h' }) was invoked seemed overkill. But saving the N::B::H into a class/instance variable seemed overkill too: it has nothing to do with Path::Classy (which are Path::Class ) objects but for that instant relationship to format a file property, size.

Hey, that's a chance to use memoization, splitting the formatter creation into a function and then memoizing it (so that we don't need to create a [reusable] object with the same capabilities over and over), we come to this code.

use Memoize; sub _size_formatter { require Number::Bytes::Human; return Number::Bytes::Human->new; } memoize('_size_formatter'); sub _format_size { my ($sz, $opt) = @_; my $format = $opt->{format}; if ( $format eq 'h' ) { return _size_formatter->format( $sz ); ...

That looked elegant to me. To make it even more tight (and to require yet another CPAN module ;-) ), using Attribute::Memoize seemed right. It avoids the need to repeat the function name in the memoize call and it anticipated the wrapping up of the sub to BEGIN time (a free bonus of Attribute::Handlers in the backstage).

use Attribute::Memoize; sub _size_formatter :Memoize { require Number::Bytes::Human; return Number::Bytes::Human->new; }

That's it! Efficient code, localized behavior, no need for extra variables. Will people understand that for maintenance? I hope so.

Wanna break some dists?

ferreira — 2008-02-14T16:07:10+00:00

An easy recipe to do this is to include a dependency on a module version which only development releases reached that far.

That will provoke installations by the CPAN shell to fail complaining about a bad dependency. These actually will generate NA test reports because of dependencies which could not be satisfied.

I saw such an example the other day. The dist KSx-Analysis-StripAccents declared a dependency on 0.2 version of KinoSearch . The latest stable release of KinoSearch is 0.162 and the current devel release is 0.20_05. That filled CPAN Testers with NA reports on SPROUT's module.

Note that this is not a major fault from author's part. It is just how the toolchain works nowadays. There is no automated way to have a dependency on development versions, which seems a good thing, but which cannot be circumvented (unless it is done manually).

Maybe, that has some resemblances with declaring dependencies on third-party modules which are not in CPAN (like SVN::Core and modules in the list kept by Module::ThirdyParty, and company-specific code).

What's better? -Ilib or -Mblib?

ferreira — 2008-02-13T17:13:46+00:00

When testing/playing with a distribution, one usually runs:

$ perl Makefile.PL; make $ perl -Mblib demo.pl # or (with tests) $ prove -b test.t

Sometime the make (or ./Build) gets annoying and a shortcut is nice:

$ perl -Ilib demo.pl # or $ prove -l test.t

However, there are a bunch of reasons not do that. Among them:

-Ilib won't work for modules with XS parts (it will use installed XS components or fail to load)
the current build settings may establish an environment different from the current lib/ layout (with modules not in the MANIFEST and things like that)

At the end, we conclude that working under -Mblib is safer (and closer to release conditions) than playing with -Ilib.

Another context feature

ferreira — 2008-02-09T17:14:00+00:00

My original title was "Another context trap", but I changed my mind. Read on.

Easy things are supposed to be easy to write in Perl, right? Let's try this one: write an (efficient) identity subroutine one that returns the arguments given to it.

Ok. Now you write down your solution and come back to read the rest of it.

That was my first attempt:

my $id = sub { return @_; }

And it looked like a good idea at first, as the @_ gets all the sub arguments (whether they be zero, one or many). And it seemingly worked.

$id->() returns () $id->(42) returns (42) $id->(42,42) returns (42,42)

Except that I was not totally honest, and these succeed only when the function is called at list context. If that's not the case, we have:

$c = $id->(42); # 1 gets assigned to $c (from scalar @_) ($a) = $id->(42); # good, 42 gets assigned to $c

The quick solution is to take into account the calling context and write down the code as:

$id = sub { wantarray : @_ ? $_[0] }

The fault of this is a Perl feature that most other programming languages don't have: sensitivity to calling context. Those others are happily relieved of this because they are poorer in semantics than Perl in that aspect.

The identity function needs to be defined from a domain into the same domain: A -> A. Then, if we consider the non-void contexts Perl 5 provides: list and scalar, we have not one but two identity functions to consider. Namely,

sub { @_ } # for list context, LIST -> LIST sub ($) { $_[0] } # for scalar context, SCALAR -> SCALAR

Note. The sneaky prototype in the last sub definition entered the scene to guarantee the homomorphism between the domain and image, that was not tested in the previous definition. So to be 100% correct, that should do it:

sub { if ( wantarray ) { @_; } else { die "too many arguments" unless @_==1; $_[0]; } }

The trap in this case is more like a fault of all other programming languages that don't have call context sensitivity. Because if they did, like Perl, they would push you up to think harder about some concepts like identity itself.

What Perl 6 will have to do with this? You bet no one is going to draw back and "relieve" Perl 6 of that extra expressiveness her mother language has. On contrary, Perl 6 will have even more call context sensitivity. But IIRC you will be able to define nice multisubs which dispatch on return type and will avoid unintented uses.

Hm, how they would look like? I am not sure. Maybe

multi sub id(Any $x -> Any: ) { $x }

A Subtlety of 'reverse'

ferreira — 2008-02-07T18:08:47+00:00

A few days ago I was bitten by the dual nature of reverse.

$s = reverse 'xyz'; # 'zyx' @a = reverse qw(a b c); # qw(c b a)

This is even worse because reverse in scalar context may receive a LIST as argument and concatenates the reverse string of each element.
$s = reverse qw(abc mni xyz); # 'zyxinmcba'

There was a code where a method history was meant to return an array and got used in a few places this way:

$history_size = $o->history();

which worked ok, until I found a subclass implementation which had been coded like this:

sub history { shift; return ( reverse @history ); }

and the assumption that it should return the (history) array size when called in scalar context failed miserably. The solution was to document what it was supposed to return in list and scalar contexts and to change the implementation to:

sub history { shift; return my @h = reverse @history; }

That's the kind of thing I remember when someone says: "What's so wrong with Perl 5 that we might need Perl 6?"

That's the kind of subtlety that caught you by surprise occasionally, beginner or not. Idiosyncracies like that put a burden at the programmer which has not a perfect memory (and I am one of such programmers unfortunately, I have to admit) and makes some feel that a Perl guru is needed to detect, solve and explain such bits. This kind of weird behavior leads sometimes to workarounds because there is no time to think about what's wrong with that f... piece of code. And then it distorts into ugly things that contributes to the bad fame of our favourite language.

Such ugly things go like a current joke on Portuguese ortography. A friend tells the other: "Write me a check of 'sessenta' Brazilian Reais" -- "How dow I spell 'sessenta'?" -- "Well, make two checks of thirty." (Background: the word "sessenta" (sixty) may raise doubts to careless people about the right spelling: "sesenta", "seçenta", "sessenta".)

If Perl 6 fails to get rid of such subtleties (and this is one of its design principles), it will have failed to be the improvement of the Perl language it was supposed to be.

SMTP/SASL authentication for CPAN::Reporter

ferreira — 2008-01-25T18:41:07+00:00

I wrote a monkeypatch (dirty, I have to confess) so that I could use CPAN::Reporter with my ISP mail server which requires authentication.

I had to do it by touching Test::Reporter as well. They will be available in CPAN at:

In Test::Reporter, a new accessor net_smtp_args was created which should be filled with a hash ref. If it contains something like:

{ auth => { user => 'me', pass => '***' } }

and Net::SMTP is the current transport, it will attempt to do SASL authentication after opening the connection.

In CPAN::Reporter, the changes allow the code to read from the config file ~/.cpanreporter/config.ini two config values which get passed into Test::Reporter:

# to do SMTP/SASL authentication, add these to ~/.cpanreporter/config.ini smtp_auth_user=me smtp_auth_pass=***

This is not a permanent solution because CPANT::Testers::Transport::* is in the works to replace Test::Reporter which will allow more natural/elegant approaches to that.

WWW::CPAN->query()

ferreira — 2008-01-14T22:51:06+00:00

WWW::CPAN is a work in progress (slow progress, to be honest). At 0.004 release, its API got one more method, query(). The whole API is:

new - good old constructor
fetch_distmeta - grab META.yml (META.json) from CPAN distributions
query - do simple queries and get the result as Perl data

Ain't that promising? Everyone will use it when 0.999 release arrives. (Yes, updates are by +0.001 increments.)

Perl 6 micro-articles just now

ferreira — 2007-12-28T20:53:12+00:00

This week has seen a turmoil of emotions surrounding Perl 6. (Just take a look at the last articles here at use.perl and perlbuzz.) This entry is just to gladly announce that in this very moment (Dec 28 2007 18:30 GMT-0200) three microarticles of the series on Perl 6 operators are in The Hot 25 list of O'Reilly Network Blogs.

It may be due to other causes:

I faithfully provided one article from Monday to Friday for the last two weeks;
This is end-of-year time and reading habits may be different;
I am not quite sure of the criteria that make blog entries appear there in The Hot 25 and maybe it's just noise that took these articles to those positions (#5, #13, #23).

But on the other hand, given that I am not that endowed for writing, I rather believe that

Perl 6 still captures curiosity and attention of people out there;
People do not want to lose the opportunity (to learn, use, criticize, think about, etc.) when Perl 6 is finally released.

So I want to thank everyone that contributed to the current state of Perl 6-related development and to wish much fun in the future work that will bring us this long-awaited Christmas gift.

The need for SUPER

ferreira — 2007-12-28T17:01:31+00:00

Also known as "The trap of SUPER::method"

I never have grokked SUPER and what exactly it could do for me. Until I wrote Class::Constructor::Factory.

Class::Constructor::Factory is a helper module to prevent me to spend time writing constructors after using a module like Class::Accessor (and siblings) that gave me for free handy accessors/mutators for object fields. Those modules also gave me a constructor for free. But I am never happy with constructors without a way to specify defaults when initial field values are not given.

So C::C::F is a step towards a more automated way to get better constructors for free and, in a near future, to write classes with less effort. Actually, using the 0.001 version of the module looks like this:

package Foo; use Class::Constructor::Factory; use base qw( Class::Accessor Class::Constructor::Factory ); __PACKAGE__->mk_constructor0({ foo => 42, bar => 'fourty-two', }); __PACKAGE__->mk_accessors(qw( foo bar ));

The thing is that C::C::F augments the actual constructor provided by the IS-A chain of the new package with handling of defaults. So a closure is built and then installed into &Foo::new to work out the wanted magic.

my $foo = Foo->new(); is( $foo->foo, 42 ); is( $foo->bar, 'fourty-two' );

That is rather straightforward and involved code which looked like this:

package Class::Constructor::Factory; ... sub make_constructor0 { my $self = shift; ... # return a closure return sub { my $self = shift; ... return $self->SUPER::new->( $self, \%f ); # XXX the offender }; }

I must say that this code is deceptively simple and wrong. Because ->SUPER::new tried to invoke the &new of Class::Constructor::Factory superclasses (which does not exist). I understood why by reading the docs of SUPER and perlobj. The relevant quote is:

"It is important to note that SUPER refers to the superclass(es) of the current package and not to the superclass(es) of the object."

So even after the closure was installed into the Foo namespace, ->SUPER::new yet referred to the superclass of the package where the code was compiled, not doing what I wanted.

The solution is to use SUPER and then rewrite the offender code line as:

return $self->super('new')->( $self, \%f );

After this, the &new is searched correctly among the superclasses of the object and everything is just fine.

This entry is just to remind me that ->SUPER::method and dynamic code generation (or equivalently dealing with closures in namespaces other than where they were compiled) is at least misleading. I don't claim to have understood all the issues SUPER may address, but I learned something. Thanks, chromatic! And maybe this trap may be turned off in the future by toogling a feature in a future Perl 5 version.

More Perl 6 micro-articles

ferreira — 2007-12-22T19:37:03+00:00

For the next week, I have some drafts of micro-articles on Perl operators:

I would really appreciate feedback on these texts. Corrections, suggestions, etc.

Five Perl 6 micro-articles

ferreira — 2007-12-17T19:38:20+00:00

So far I published more two articles at OnLAMP:

and got to complete three drafts for the next ones:

I would appreciate that interested people read them and point mistakes and improvements to be done.

P.S. Yeah, sadly I know that some links at OnLAMP are wrong or missing. But I am afraid that MT changes URL again if I try to update the articles. I don't know what is worse.

Micro-articles again

ferreira — 2007-12-11T20:15:16+00:00

After a long pause, I am back to the business of writing the micro-articles on Perl 6 operators.

The article I want to publish tomorrow is about boolean operators and it is here. I welcome corrections and suggestions.

BEGIN { use_ok } keeps biting

ferreira — 2007-12-10T15:59:17+00:00

The fearless Michael Schwern kept his word and brought back the Test-Simple fix for BEGIN { use_ok } bug. (If you don't know what I am saying, read this).

Some CPAN dists remain unfixed and those who upgraded the basic test modules will see an error while testing. Outstanding examples are:

Notice that the fix called for in this distributions is a real test bug. A contrived example is of the form:

use Test::More; if ( $exp_which_tells_test_should_be_skipped ) { plan tests => 1; # this will happen at runtime } else { plan 'skip_all' => 1; # that too } BEGIN { use_ok 'File::Temp' } # at compile-time ok(1);

When Test::Builder had the bug, it swallowed the exception during BEGIN { use_ok } which announced a test before planning. Also, the test count should not include the use_ok to get pass this point. Yes, for some time, we authors have introduced not one, but two bugs in this type of code to make it work. Now it is time to write it down correctly.

use Test::More; BEGIN { if ( $exp_which_tells_test_should_be_skipped ) { plan tests => 2; } else { plan 'skip_all' => 1; } } BEGIN { use_ok 'File::Temp' } # at compile-time ok(1);

Bonus point: The fixed version works ok with the old (buggy) and the new Test-Simple.

Newer Exporter for Older Perls

ferreira — 2007-12-10T11:49:38+00:00

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!)

DON'T make disttest dist

ferreira — 2007-12-10T00:56:40+00:00

One more thing I discovered I should not do: create a tarball in a hurry, right after testing it with a statement like:

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

A Test::WWW::Mechanize trap: getting contents in a file

ferreira — 2007-10-03T22:27:29+00:00

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.

Perl 6 Micro-articles: grant status

ferreira — 2007-09-21T14:51:24+00:00

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:

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.

RubyForge vs CPAN?

ferreira — 2007-09-19T12:42:38+00:00

Daniel Berger has just published this very article: RubyForge vs CPAN. His conclusions (previsible due to the Ruby bias) were basically summarized by one of his commenters: The differences are "not as extreme as one might assume". I did not dive into the article yet, but it looks like it is founded on many hasty estimates/comparisons in many places.

Perl 6 operator: Stitching

ferreira — 2007-09-18T19:27:18+00:00

Now is the time of the string concatenation operator. Very simple. Departing from the Perl 5 tradition. Read and comment if you feel so.

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

Micro-articles on Perl 6 Operators

ferreira — 2007-09-17T17:58:15+00:00

Jesse has announced the acceptance of my microgrant proposal. It is a plain simple idea, whose effects are yet to be seen. Comments and feedback most welcome.

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:

Programming in Perl is hard

ferreira — 2007-09-06T18:46:05+00:00

I failed miserably when trying to write a simple sub &strip to trim leading and trailing spaces, modifying its argument in-place. My attempt was:

# 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

stripping the string is eating the leading and trailing spaces from something

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

stripping the string is eating the leading and trailing spaces from it (the string)

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.

Language De-acquisition

ferreira — 2007-09-06T00:36:47+00:00

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" support gets easier

ferreira — 2007-09-04T15:25:40+00:00

Pod::Perldoc has a recently introduced feature via a new switch -L.

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