Here is the popular digest of the Perl 5 porters mailing list for the second week of February. Featuring new proposals, new command-line switches, new ideas, and fixes for all sorts of bugs.
Fergal Daly asked why length($a) isn't a lvalue.
This would allow to
trim a string by changing directly its length. But there is a problem :
defining the proper behavior when the length of $a has to grow. Should $a
be kept unchanged, or should it be blank- (or null-) padded ? For this
reason, Hugo decided that length() isn't going to return a lvalue yet.
Abigail reports (bug #20827) that a large number (1597009560 ** 2) is sometimes print by perl as an integer, and sometimes in the scientific notation. When this square operation has been constant folded, the number is stored by perl as an integer, but when it occurs at run time, perl uses a floating point value, hence the difference in output.
François Pons proposed a patch to allow to load gzipped modules, via the PerlIO-gzip layer. Slaven Rezic pointed out that this functionality was probably not worth being put in the core, because it can be implemented via the coderef-in-@INC feature.
Jarkko Hietaniemi implemented the -C command-line switch he proposed
some weeks ago. This switch (with additional option letters) can be used
to control perl's Unicode behavior : for example, to turn on/off the
utf-8-ness of the standard input or output, or of input files supplied on
@ARGV. This new flag will be available in perl 5.8.1 as well.
To address a namespace
pollution issue raised by John Lenz, Jarkko
implemented a new C preprocessor symbol, PERL_NO_SHORT_NAMES, which
prevents the #definition of the short form of any of the Perl_*
symbols.
Our pumpking, Hugo van der Sanden, who was quite busy those last weeks, caught up with the developments. Most notably, the patch that Salvador Fandiño sent in November to add assertion support to Perl is now in.
Rafael Garcia-Suarez implemented a new function in Scalar::Util, that allows to change the prototype of a function.
Jos Boumans proposed (with a patch) to advertise Test::More and Module::Build in the perlmodstyle man page.
Fergal Daly imagined a new, more concise way to invoke Exporter, and sent a patch to implement his idea.
Bug #20920 pertains to the new safe signal implementation in perl 5.8.0 : apparently, when a signal handler is running, the corresponding signals are not blocked, whereas they should be. This can lead to segfaults. Slaven Rezic provided a fix.
Bug #20912, fixed by Enache Adrian, is about a split() on a utf-8 string
that causes the unusual error message Split loop to be thrown.
Mark Mielke produced a strange case of core dump, involving ties and auto-references.
Jarkko reminds us that someone has to make sure that the fields
pragma still works, now that pseudo-hashes have been removed. (The plan
being to use read-only hashes.) That could be a bite-sized task for
someone. (And while we're at it, there are still traces of the old 5005
threads to be cleaned up.)
This summary brought to you once more by Rafael Garcia-Suarez. Summaries are available on http://use.perl.org/ and/or via a mailing list, which subscription address is perl5-summary-subscribe@perl.org . Comments and corrections are welcome.
Re:nit
rafael on 2003-02-19T14:34:15
So I've mistaken -CA and something like "-Ci for files open via magic <>" ? Besides the fact that I deserve public flogging for this error, this is perhaps a sign that the description of -C in the bleading perlrun isn't accurate enough.Re:nit
jhi on 2003-02-19T16:16:30
Hmmm. Currently perlrun -CA documentation says "the @ARGV elements are supposed to be in UTF-8", maybe "the @ARGV elements are supposed to be strings encoded in UTF-8"?
As far as the magic open goes, -Ci would cause those magic opens to have the ":utf8" layer implicitly in them, but if you want also the STDIN to be the same, you must have also 'I' (that's capital "eye", not lowercase "ell".) in there. So -CIi.
Rafael Garcia-Suarez implemented a new function in Scalar::Util, that allows to change the prototype of a function.
Is there any reason why it went into Scalar::Util? That's not the place I would look for such functionality. Wouldn't Sub::Util be more appropriate?
Re:From my armchair...
rafael on 2003-02-19T16:57:59
The options were:
- modify the prototype() builtin function to be a lvalue or something. Obviously not backportable to older perls.
- implement this function in a new module. This would be a new core module, as Mark-Jason Dominus needs this functionality for Memoize.
- put it in an existing core module.
Moreover, Scalar::Util is apparently for all kinds of stuff that mess around with the internals in ways that are not built-in in the language. So I made a patch for it, and Graham Barr liked the idea and applied my patch.
Seems like there are two different ways one might want to hook into @INC. The first is to provide an alternate location (see my Import Subversion example). This works fine by allowing coderefs in the @INC array.
But, it does seem to me that the other way one would want to hook into the import mechanism is to allow Perl do do its normal iteration over the @INC array, but to modify what it sees and/or how it deals with what it sees in those directories. For example, it normally looks for "$_/Some/Module/Path.pm" and is happy if it finds it. A module that lets the normal scanning process see "$_/Some/Module/Path.pmz" as a match (and associates an unzip filter with it for reading) seems like a distinct but good idea to me. There might even be some weirdness that allows one to see a "*.pm" directory with version-numbered files in it as a set of available versions for a module (compare with Brian Ingerson's use only module). This way, Perl would be happy to grab "$_/The/Finest.pm" as the module if it were a file, but if it were a directory, it would grab "$_/The/Finest.pm/undef.pm" (if there is no version) or "$_/The/Finest.pm/1.0.pm" (for version 1.0).
Again, this seems like it is a better fit for a what-to-do-when-visiting hook rather than a different-thingee-to-visit hook (which is what the current @INC coderef hook allows).
Re:@INC hooks: there should be two kinds (IMO)
simonm on 2003-02-20T16:16:02
As I understand it, you can accomplish this second goal using the same mechanism as for the first: there's nothing stopping your @INC sub from doing its own simple iteration over the other entries in @INC looking for its own kind of match.
