This Week on perl5-porters (23-29 December 2002)
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.
Implicit localisation of $DIGIT variables
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.
http:[EMAIL PROTECTED]/msg90096.html
Maybe that's also related to Strange Regexp Scoping Bug #19388, reported
by Ton Hospel.
http:[EMAIL PROTECTED]/msg90218.html
Defining lexical aliases
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.
Brent Dax, voice from the Perl 6 lists, 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.
http:[EMAIL PROTECTED]/msg90213.html
%INC on Windows
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" and
"Foo\\Bar.pm"). The discussion then derived to case-insensitive
filesystems, Unicode filenames, and other cans that presumably contain
worms.
http:[EMAIL PROTECTED]/msg90229.html
EOL agnosticism
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.
http:[EMAIL PROTECTED]/msg90253.html
Iterator classes and memory leaks
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.
http:[EMAIL PROTECTED]/msg89230.html
In brief
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.
About this summary
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 [EMAIL PROTECTED] Comments and corrections
are, as always, welcome.
