Not even Christmas and other holidays will stop the Perl 5 Porters. Find below the weekly list of issues, and it's not shorter than usual : lexical scoping questions, portability concerns, refcounting, and other bugs and fixes.
Martien Verbruggen notes that the $DIGIT variables are implicitly localized to the scope of a while() loop, when the regular expression that sets them is in the loop condition. This doesn't appear to be consistent with the documentation, that says that a while() statement never implicitly localises any variables. Moreover, this behavior doesn't occur with if() and foreach(). Nicholas Clark comments that the while() loop condition seems to be scoped within the block. Probably the only thing that's needed is a documentation fix. Bug #19236.
Maybe that's also related to Strange Regexp Scoping Bug #19388, reported by Ton Hospel.
David Nicol asked whether the syntax
\$alias = \$value could be made to work to define aliases, including some form of
my \$alias = \$value for lexically scoped aliases.
Yitzchak Scott-Thoennes proposed to introduce the Perl 6 binding operator
my $alias := $value instead. (Oddly enough this particular syntax isn't currently rejected by Perl 5.)
Nobody proposed a plan to implement this, but looking at Devel::LexAlias (or another alias module) might give some ideas to start with.
Chip Salzenberg provided a patch for bug #19213, reported last week, to canonicalize the names of require()d files on Windows. This way, duplicate entries in %INC are avoided (e.g.
Foo\\Bar.pm). The discussion then derived to case-insensitive filesystems, Unicode filenames, and other cans that presumably contain worms.
Jarkko Hietaniemi proposed a draft patch to add EOL agnosticism to perl, i.e. to allow LF, CR and CRLF line-endings in perl scripts. After some discussion, it was decided that his proposed implementation was not good enough, and that using a source filtering mechanism would be better.
Bug report #18581 led to an interesting discussion. As Hugo summarized it, the problem is with the postincrement statement
$bar = $foo++, where $foo is an object with the
++ operator overloaded, and with a copy constructor that simply returns the original object itself. What happens then is that perl copies $foo, increments it, and returns the copy, which is itself copied (via the copy constructor) to $bar. At some point there is some dangling copy somewhere, leading to a memory leak, or (more precisely) to an object that will be destroyed later than it should.
Ton Hospel reported that affecting a number to the special variable
$\ doesn't work as it should (bug #19330). Rafael Garcia-Suarez, who has to be blamed for this bug, provided a patch.
Blair Zajac reported a case of intermittent segmentation fault when the newest Storable module is used with signals handlers and under the perl profiler. Scary. Bug #19385.
Michael G Schwern released a new alpha version of ExtUtils::MakeMaker, 6.06_02. Work on the Windows, MacPerl and VMS ports is still needed.
Nathan Torkington tried to build perl on FreeBSD 5.0-RC2, and found that some adjustements to the FreeBSD hints file and/or to the Configure script are needed.
Jim Cromie wrote a script to harvest all error and warning messages from the perl sources, including some of the standard modules, and to compare them to what's actually in perldiag.pod. Now he has to sort out the results :)
Mark Mielke and Nicholas Clark suggested to use the __builtin_expect() feature of gcc 3.x to help it to optimize perl for speed.
This summary brought to you by Rafael Garcia-Suarez, back to work. Read it on http://use.perl.org/ and/or via a mailing list, which subscription address is firstname.lastname@example.org. Comments and corrections are, as always, welcome.