This Fortnight on perl5-porters - 6-19 February 2006
Andy Lester continues his quest to const -- Jim Cromie refines his
arena patch -- Module::Build causes a large increase in the use of
Internet bandwidth
This summary uses a new, experimental organisation. The previous
method was more-or-less chronological, with minor threads moved to the
In Brief section. The new method is to First summarise *ad hoc*
threads that spark off some sort of discussion. Then come the patches
sent in by people (the idea being that no patch be left unnoticed, to
offer a checklist for pumpkings), followed by discussions of bugs
posted to RT.
After that come the usual New Releases, Bug Summary and In Brief
sections. Feedback on this new arrangement is welcome.
Topics of Interest
The Great Unicode Slowdown
Back on February 1, Nicholas Clark started to work on the slowdown
that occurred between the 5.8.6 and 5.8.7 releases when dealing with
Unicode.
http://xrl.us/j63g
The problem is one of excessive shuffling of data behind the API, and
Nicholas proposed an additional function to the API to minimise the
amount of copying required. Sadahiro Tomoyuki came up with a better,
more pragmatic solution that Nicholas came to like, and then found a
couple optimisation possibilities that need to be thought about.
He then wrote some code to implement one of the optimisations for
"index", but sadly Phil Pennock replied that it only had a negligible
effect on his code. Tomoyuki explained why this was so, and offered a
couple of work-arounds. Phil penned a long reply, explaining what he
was trying to do, basically, to "unobtrusively write Unicode-aware
scripts for general deployment, with full diagnostic support, which
don't require special setup, do deal with user locales, and will work
on any moderately recent version of Perl without going tits-up".
Nicholas noted that one of the problems was that "-C" (the
semi-repurposed switch for diddling with Unicode) doesn't work on the
shebang line (with a "too late" warning la taint), and wondered how
difficult it would be to remove the restriction, which is mainly a
minor implementation issue. Rafael Garcia-Suarez noted that there
might be problems due to the fact that by the time the shebang line is
process, "stdin", "stdout" and "stderr" are already open (and "-C"
could have an influence on the way they are opened). Nicholas wasn't
convinced, mainly because the tokeniser itself remains very primitive
in its 8-bit/UTF-8 awareness and handling.
Rafael point to bug #34087, where H.Merijn Brand reasoned that the
only sensible course was to ban "-C" on the command line, much to
Abigail's disappointment at the time.
The thread ended with Nicholas. Tomoyuki and Dominic Dunlop discussing
encoding pragmas, "Perl_sv_recode_from_utf8" and the old ISO 646 7-bit
character sets.
I want my cycles back
http://xrl.us/j63h
At the same time, "ags" filed bug #38595. showing how "use encoding
'cp1250'" cause regular expressions to run much more slowly than
without.
Slow Unicode regexps
http://xrl.us/j63i
Cleaner Arenas
Jim Cromie continued to put in a lot of work on the arena code. (An
arena is a section of memory from which blocks of a fixed size are
allocated. Relying on this constraint simplifies the housekeeping
significantly and can improve performance).
Nicholas picked up a thread from last week asking where Jim was
planning to go with the code, noting that a critical C structure
("struct body_details") exposes probably more implementation details
than is wise. Jim punted the issue, citing pending patches to be
delivered. Both Nicholas and Jim agreed that ideally nothing of the
implementation details should leak out through an API (which would
then allow internals to be revamped during stable releases), but that
allowing a certain amount of inspection, such as for modules within
the "Devel::" namespace, is a legitimate wish.
Jim did let on that his Grand Scheme concerning "body_details" was to
allow for a much simpler "sv_upgrade" (the means by which a lowly
scalar "SV" gets converted into a float, a reference or more).
For a while Nicholas and Jim wondered whether the microphone was
switched on, since no-one else had commented, so Yitzchak
Scott-Thoennes said that everyone was awed into silence.
Repairing arenasets
http://xrl.us/j63j
Later on, Jim posted a patch that laid the groundwork for further
work, which he hoisted out in order to facilitate peer review, the
ability to tweak arenas independently, added two new arenas for
datatypes that were previously allocated dynamically as a result of
that, and reorganised how one looks up the size of an arena's type.
Tels commented on the readability of the code, which Jim explained was
a result of the use of macros throughout the code. And it got Jim
thinking about whether some of the magic numbers used in the arena
code should be upped during configuration time for 64 bit systems.
Laying the groundwork
http://xrl.us/j63k
Reclaim an C<HE_SVSLOT>, save some bytes
http://xrl.us/j63m
No smoke here
http://xrl.us/j63n
Jim posted another patch to make arenas adjust their size to fit N
bodies exactly, avoiding wastage for a certain number of data types.
At this point he called for help, as he wasn't sure how to initialise
"PL_arena_sizes[]" nor how to clone it (for threads).
Looking for clues
http://xrl.us/j63o
And after all that effort, Jim generated a consolidated patch to tie
all the loose ends up together and bring everything under one roof.
Yves Orton tested the patch and gave it a clean bill of health on
Win32.
Unfortunately, Nicholas found that it came to grief on t/op/threads.t
and he pondered how to fix it. After a few false starts he figured out
how to proceed, and most of it went in as change #27215. Yay!
What is needed now is for people to take blead for a spin with large
datasets (something the test suite doesn't really do).
The Full Monte
http://xrl.us/j63p
(Not) building XS modules with MS Visual Studio 2005
Yves "demerphq" Orton described the problems he had encountered with
someone trying to build an XS module with MS Visual Studio 2005 and
ActiveState build 815 (their most recent 5.8 distribution).
For some modules, such as his own "Data::Dumper::Streamer" and the
core "Data::Dumper", the source is compiled (albeit with a certain
amount of warnings), a DLL is produced, but "Dynaloader" fails to load
it. For other modules, such as "Scalar::Util", the linker fails with
an error about an "unresolved external symbol "_Perl_seed"".
Steve Hay suggested trying to invoke "nmake" as "nmake CCTYPE=MSVC70"
which might be sufficient to pull things off, otherwise some work will
be required to define a new "CCTYPE" of "MSVC80" in order to bring the
code and compiler into agreement.
Steve also pointed out that since ActiveState currently build their
perl executable with VC6, one really should build XS extensions with
VC6 as well. Using VC7 can be fraught with peril, and now with VS 2005
being equivalent to a VC8, the mismatch in C run-time libraries may be
getting to the point where things just do not (and cannot) work any
more.
Jan Dubois analysed the points Yves raised in turn and explained why
things were failing and what to do about them.
Jan also provided a bit more information about which compiler versions
and their attendant run-time libraries work with perl, and which ones
don't (in brief: don't write XS in C++). Steve noted that he had had
trouble most notably with file descriptors (perl thinking a file was
open, XS thinking it was closed) when compiling XS with VC7 when perl
was compiled with VC6.
Oh no! not another DLL hell!
http://xrl.us/j63q
Unused "Perl_save_*" functions
After running some coverage analysis, Nicholas discovered that a slew
of functions "Perl_save_svref", "Perl_save_long", "Perl_save_I16" and
the like were unused, and wondered whether they had to remain, in
order to support legacy XS code. Depending on the answer they could
either be deleted or moved to mathoms.c (the graveyard for ye olde
retired functions).
Rafael Garcia-Suarez ran a gonzui search and found nothing, but also
reasoned that since they're part of the public API, there's nothing
stopping an XS author from saving arbitrary data on the stack. So he
thought it would be fine to move them over to mathoms. On the other
hand, if they were removed, that would cascade a certain amount of
"enum" cruft as well.
Nick Ing-Simmons mentioned that "Tk" (naturally) uses "save_svref" for
some nefarious (but quite legitimate) purposes, but was quite happy to
see them move to mathoms.c.
Save the mathoms
http://xrl.us/j63r
Making "U" magic available for hashes
Anno Siegel sent in a long message, describing how he wanted to apply
"PERL_MAGIC_uvar" or "U" magic work with hask keys. The aim was to
provide some more support for inside-out objects. This would be a
cleaner approach than using tied hashes. Instead, from the key one
would be able to get to the reference in a more direct manner.
And instead of just waving his arms and saying how good it would be,
Anno supplied a patch against 5.9.3 showing some proof-of-concept code
and asked for feedback.
Yves noticed the parallel between this work and the work he did when
putting the trie optimisation into the regexp engine, but also that
using reference addresses are apparently not recommended in threaded
environments.
Rafael poked at the patch and asked for some example code, to allow
him to weigh up the benefits. Anno delivered a couple, and then went
back to work on refining the concept.
Magic-U-Like
http://xrl.us/j63s
"pp_bit_and", "pp_bit_x?or" and "USE_LEFT"
Nicholas found an interesting discrepancy between a trio of functions
in pp.c. On the one hand "pp_bit_and" does one thing, whereas
"pp_bit_or" and "pp_bit_xor" throw a ternary operator into the works
for what is otherwise very similar code. It's been there a long time,
is touched upon in bug #17809 and Nicholas wanted to know more.
No-one appeared to remember anything about it at all.
Lost in the mists of time
http://xrl.us/j63t
"DESTROY" never dies
Stas Bekman noted that
perl -le 'my($x,$y) = (1,0); my $z=$x/$y; print "done"'
dies with "Illegal division by zero" but on the other hand
package A;
sub new {bless {},'A'};
sub DESTROY { my($x,$y) = (1,0); my $x = $x/$y }
my $X=A->new;
print "done"
produces the output "done". The die has been eaten, and the person
running the program has no idea that anything is amiss.
Unfortunately, Stas was Warnocked on this issue.
http://xrl.us/j63u
Never one to let such a trifling matter bother him, Stas filed a bug
report:
http://xrl.us/j63w
Benchmarking the effect of build options
Linda Walsh wanted to know if there was a package that would let her
benchmark the results of different build options, such as compiler
optimisation levels, enabling threads and the like.
Jim suggested using "Test::Smoke" as a starting point, and make it run
"perlbench" instead of "make test". H.Merijn Brand added some of his
own conclusions he'd made along these lines, and whipped up a small
program to extract the times of the different runs in a smoke test,
and produced some interesting figures as a starting point.
http://xrl.us/j63x
Why "ref(qr/foo/)" is "Regexp"
John P. Linderman looked through all the POD he was able to, but was
unable to find where it was explained that "qr/foo/" is of type
"Regexp" and thought that it should be mentioned.
Yves pointed out that code is free to bless a Regexp into another
package, which means that its "ref()" will then return the name of the
other package. In fact, when this happens, there is no way of
determining that something that set out as a "Regexp" but has since
been blessed as something else, was, at the outset, a "Regexp".
There must be some way of making an obfu out of this behaviour
http://xrl.us/j63y
"Module::Build", "CPAN.pm", "ExtUtils::MakeMaker" and "UINST=1"
Randal L. Schwartz wrote in to say that with recent versions of all of
the above he was not able to install "Zoidberg" and wanted to know
whether it was "Module::Build"'s fault.
A massive thread resulted from this simple question, and happily it
did not devolve into a flame war, at least not too much. There are two
points of view, each with their merits. But since the two viewpoints
are not diametrically opposed, at times the parties seem to be talking
at cross purposes.
Tels saved the day by summarising it nicely, so I shall point you to
his summary:
The thread
http://xrl.us/j63z
The thread, accord to Tels
http://xrl.us/j632
Revisiting the saving of the regexp state
Nicholas Clark had been looking for where code deals with $1 and found
some code in mg.c and wondered if there was code elsewhere that
diddled with these number variables directly.
This week he understood why his proposed optimisation wouldn't fly.
Which got him thinking about another approach. Which he also figured
wouldn't work either.
In related work, a patch that had been stuck in limbo was applied.
Neither Nicholas nor Rafael nor Robin Houston were certain the patch
was perfect, but reasoned that smoke tests should be sufficient to
test it. That, and testing CPAN modules with "blead".
Back in January
http://xrl.us/j633
And fast-forward to now
http://xrl.us/j634
More voodoo
http://xrl.us/j635
Mac OS/Lamp port sources available
Joshua Juran posted the address where people could download the Lamp
port of perl 5.6.1, (I believe this is the result of reviving the old
MacPerl port).
Where to get it
http://xrl.us/j636
System requirements
http://xrl.us/j637
PERL_XSUB_OLDSTYLE
Nicholas Clark wanted to know what old style XSUBs were. They appear
to be so old as to be not used any more. Nick Ing-Simmons was quite
convinced that this was the case. And he should know, having written
"Tk" as one of the first 5.000 extensions, and it used the new calling
conventions... Andy Dougherty agreed, saying that his only
recollection was of Malcolm Beattie's own pre-5.000 "Tk" module used
the original XSUB style, and "PERL_XSUB_OLDSTYLE" was an effort to
continue to keep it working.
Nicholas fired up the chain-saw.
http://xrl.us/j638
Patches of Interest
Patches from Debian for 5.8.8
Brendan O'Dea kindly posted the patches that Debian have been carrying
along on that distribution's Perl package. The points are: a patch for
insecure temporary files, a POD edit, a precedence fix, a patch for
long lines in /etc/groups and a redundant compiler flag on the "sparc"
platform.
Gisle Aas noted that all but one patch were already in "blead", but
punted on the "\x{2010}" POD/"groff" patch, soliciting the opinion of
others. Brendan pointed out that the patch was for verbatim text,
which is usually code, hence it should be left untouched, and that
Russ Allbery had solved the problem in a different way in the current
version of podlators.
Nicholas Clark noted that the long lines bug merely requires a merge
of reentr.pl which has drifted significantly between "maint" and
"blead", which is apparently not for the faint of heart. This script
is used to generate reentr.h and reentr.c which in turn allows the
perl codebase to abstract away the differences in the thread-safe
(re-entrant) versions of various system calls.
Now that "podlators" had been fixed to allow the re-use of parser
objects, Nicholas has less objections about merging it into maint,
which would fix the POD problem, although Yitzchak pointed out that
the code in the "SYNOPSIS" section of old "Pod::Man" doesn't yet work
as advertised. And after a bit of prodding from Russ, Yitzchak coughed
up an exhaustive list of all the niggly compatibility problems that
need to be addressed. But pointed out that some of the issues may have
been conscious design decisions to drop functionality deemed to be
useless (but if so then it should be mentioned explicitly). Russ said
that the goal was to emulate the old interface completely (so I expect
we will see subsequent releases of podlators addressing these issues).
De patches from Debian
http://xrl.us/j639
Fixing broken "valgrind" targets in "make"
Jim Cromie noticed that a number of targets, such as "test.valgrind",
"check.valgrind" and the like did not all work correctly (that is, at
all), and proposed a patch to make them work again. ("valgrind" is a
tool to track down illegal memory accesses, usually caused by errant
pointers). Patch applied by Steve Peters as change #27128.
Grinding into emptiness
http://xrl.us/j64a
What Andy Lester has been doing
Andy Lester delivered a number of patches during his quest to const.
Marking unused arguments (applied as #27129)
http://xrl.us/j64b
Nick Ing-Simmons cautioned that the following patch might break Win32.
Yves said that he'd happily smoke anything from people who needed to
verify Win32 compliance. Nicholas wondered whether Steve Hay's and Abe
Timmerman's smoke tests were sufficient to uncover problems. Jan
explained what recipe was needed in general when doing XS work on
Win32, confirming that Andy's patch did no harm. Jim Cromie sent in a
snippet from his "Test::Smoke" configuration to show how he smokes
these things. Not applied.
Removing unused contexts
http://xrl.us/j64c
And then some more, still no takers
http://xrl.us/j64d
Andy took a fresh stab, this time removing "pTHX"s, redoing the
"s/Nullop/NULL/" change and sundry "const"ing thrown in for good
measure. This was applied as change #27136.
http://xrl.us/j64e
And then some stuff from perly.patch
http://xrl.us/j64f
Now that many "pTHX"s are no longer, some arguments need to be marked
explicitly as unused in order to silence warnings for the Sun Studio
compiler. Rafael realised that this patch would break non-threaded
builds, so Andy went away to cook up a better batch.
A first attempt at linting, not applied
http://xrl.us/j64g
In which perly.c is examined (not applied)
http://xrl.us/j64h
And some POD rewording (change #27174)
http://xrl.us/j64i
More lint removal (change #27177)
http://xrl.us/j64j
The end of the line of the Nullxx macros (change #27238)
http://xrl.us/j64k
Better long path name support for VMS
John E. Malmberg supplied some patches against "blead" to make long
path names work in "readdir" and the like for VMS:
http://xrl.us/j64m
http://xrl.us/j64n
Better "xcopy" support for Win32
Yves Orton supplied a patch to suppress "xcopy" from prompting every
two seconds when rebuilding on Win32. Which I can see would get you
down over the long run. Applied as change #27195, with the proviso
that it makes life more difficult for the Windows 9x platforms.
So: Warning to all Windows Millenium and Windows 95 users: recompiling
perl on your platform will now cause you grief and undue suffering.
(But hey, you knew that already).
http://xrl.us/j64o
"Hash::Util" enhancement
Yves also sent in a large patch to add some functionality to
"Hash::Util". Applied as change #27180.
http://xrl.us/j64p
Patch for perl to compile/work on DragonFlyBSD
Robert Sebastian Gerus sent in a patch to make perl compile correctly
on the DragonFlyBSD platform. H.Merijn Brand applied it as change
#27189.
Whee! Another platform supported
http://xrl.us/j64q
More on DragonFly
http://www.dragonflybsd.org/main/
"stat()" and trailing slashes on Win32
Jan Dubois noticed that "stat" behaves differently on windows when
statting a directory, according to whether the directory to stat has a
trailing slash or not. So he posted a patch to canonicalise the names
to sane values.
This was applied by Rafael, but it sparked off a long thread, where we
learn that Windows allows hard links (although the method to achieve
them is somewhat cumbersome) and there are problems in getting the
timestamps up to date when "the other" link updates the file.
Yves disliked the fact that statting a file required it to be opened
and closed, in order to force the timestamps to be refreshed, as it
incurs a significant performance penalty. Worse, as hard links are so
rare, (since the means to create them are all but invisible to mere
mortals), this high cost is paid every time for what is literally a
*can't happen* event. He wanted to have some mechanism whereby the
open and close timestamp refresh trick could be skipped by default,
but that by flipping a bit the check could be re-enabled if needed.
Jan Dubois came up with the best idea: using sitecustomize.pl, which
was invented to solve exactly this sort of problem.
http://xrl.us/j64s
A test case for "Pod::Plainer"
chromatic sent in a simple test case for "Pod::Plainer", with the
desire to see Schwern poorer. Read the second link to understand what
this is all about.
The patch
http://xrl.us/j64t
Schwern throws down the gauntlet
http://xrl.us/j64u
t/op/stat can fail under Darwin
There's a test in t/op/stat that can fail on Darwin. It tests that
"ctime == mtime", except that it is possible to see 1 second
differences on "HFS+" file systems. Anno Siegel patched the test to
have Darwin skip it, and pointed out that ideally the test to see
whether the test should be skipped should be based on the type of
filesystem the test is being run on, not the type of operating system.
Rafael applied the patch, but pointed out that such testing for the
filesystem would be... difficult.
http://xrl.us/j64v
Patches: B, CGI, ExtUtils::MM_Unix
http://xrl.us/j64w
http://xrl.us/j64x
[PATCH] Make SDBM_File work with -Duse64bitall on Darwin (Mac OS X)
http://xrl.us/j64y
[PATCH] Trouble with $ENV{CDPATH} after change #27236
http://xrl.us/j64z
New and old bugs from RT
Script misses EOF on Solaris (#1734)
Steve Peters visited a venerable (seven year old) bug, and confirmed
its potency on Solaris. The test script reads its own program as input
(but I imagine any file open for read would do), and then forks off a
child, and the child prints out its line and then exits. On a number
of operating systems it works as expected (that is, it halts after
having read the last line of input) but on Solaris (and Unixware) when
it gets to the last line it starts over at the beginning.
http://xrl.us/j642
Alan Burlison pointed to another discussion on the matter
http://xrl.us/j643
where it transpires that a child should call POSIX::_exit instead of
exit. Do that, and the problem goes away.
"use locale" has no effect (#2200)
Six years ago, "gomar" noted that the behaviour with "use locale"
started to have no effect prior to 5.6, but that it worked in
5.005_03. Steve Peters observed that it now worked correctly in 5.8,
so the fix was made somewhere between 5.5.650 and 5.8 (and the Changes
file should reflect it).
Yves Orton wondered whether Steve was seeing the same glyphs in his
mail client that Yves was seeing in his, because what Yves saw of
Steve's tests didn't look the same as the original poster's tests. The
kind of thing that makes one pine for 7-bit ASCII.
http://xrl.us/j644
"PAR", "autouse", and 64-bit Linux (#38441)
Philippe Schaffnit reported the difficulty he was having when
producing stand alone executables with PAR that use "autouse". The
symptom he was encountering was
Can't locate autouse.pm in @INC
Nick Ing-Simmons described a couple of basic checks to carry out,
which Philippe wondered how to do. Nick replied that his usual
technique was to run the program in question under "strace" (or
"struss" depending on your operating system) and then grep the
resulting output, looking for the offending ".pm" file.
http://xrl.us/j645
Coredump when starting "webmin" (#38449)
"kamy" noted that "webmin" dumps core when run by 5.8.7. Steve Peters
replied that the best option was to patch the current version with a
series of patches and upgrade "Sys::Syslog", or perhaps more simply,
upgrade to 5.8.8. Webmin itself should also be upgraded to 1.269.
This resolves the issues surrounding the buffer overflows discovered
in Webmin and Perl last year. And if you have a Webmin installation,
you should do the same.
http://xrl.us/j646
"chdir()" and filehandle parameters (#38457)
Peter Dintelmann discovered that the new functionality for "chdir"
when the argument is a filehandle, as in:
open F, '/tmp' or die $!;
chdir F or warn $!;
doesn't work, although "chdir *F" and "chdir $fh" do. The problem is
that perl considers "F" to be a bareword in this context, which leads
to a "Bareword "F" not allowed" error. Rafael was pretty sure that a
very minor edit to opcode.pl would declare it legal in "blead", but
was worried about backwards compatibility issues if it were allowed in
"maint".
Gisle took a stab at making it work by mirroring how perl deals with
the task of truncating a file handle, but discovered that things were
trickier than they first appeared.
Nicholas considered that the semantic change of "chdir foo" was to
great to be allowed to go into "maint". Nick Ing-Simmons was sure it
would cause trouble.
Taking a crack at it
http://xrl.us/j647
Peter replied via RT, arguing that "stat()" and "truncate()" already
behave this way, and that this would provide more consistency.
Gisle said that the patch was in blead, precisely on the basis of the
argument of consistency. He also pointed out that "chown", "chmod" and
"utime" do not currently accept filehandles, but they are documented
as taking LISTs as arguments. Between changing the functions to allow
globs as argument or pinning down the semantics more precisely with a
documentation patch, Gisle voted for the latter course of action.
Nicholas began to regret having merged the initial
dirhandle/filehandle patches from "blead" that opened up this can or
worms. Gisle was more optimistic, saying that bareword file handles
are legacy and should not be used in new code anyway. (Note to self:
do not let Gisle see my code).
Inconsistent consistencies
http://xrl.us/j648
"chdir()" and closed filehandle parameters (#38457)
Peter also discovered that
open $f, '/tmp' or die $!;
close $f;
chdir $f or warn $!;
produced the warning "something's wrong", and attached a patch to
change the warning to "chdir() on closed filehandle". Rafael liked the
concept, and eventually applied it to "blead" as change #27130.
http://xrl.us/j649
A puff of smoke is seen
http://xrl.us/j65a
On a roll, Peter also thought about the "Cwd" module, which offers a
version of "chdir" that $ENV{PWD} synchronised with directory changes.
As might be guessed, the following doesn't work:
# assuming the script is run from /var/tmp (or elsewhere)
open $f, "/tmp";
chdir $f;
print $ENV{PWD}; # prints /tmp/GLOB(0x233b8)
Apparently no fixes forthcoming at this time.
http://xrl.us/j65b
"@-" contains garbage after a failed match (#38461)
Lukas Mai posted a bug report with an aptly-named wtf.pl that goes
something like
for my $re (qr/fo/, qr/a/) {
'foo' =~ /$re/;
print scalar @-, "\n"; # prints some huge number
print "@-\n"; # eats all available memory
}
Works okay the first time through the loops, comes to grief the second
time. Yves Orton diplomatically suggested that while this was perhaps
not a very desirable outcome, if one does not take the pains to check
whether the match actually succeeds then one shouldn't expect "@-" to
contain anything useful. Lukas replied that he would settle for
"undef" or an empty list, rather than garbage.
Nicholas tried to attack the bug, but whenever he looked at it with a
debugged build the problem went away, which led Andreas to notice the
similarity between this bug and another one (#38363) that he had been
working with the same kinds of symptoms.
After going through a bit of pain, Nicholas spotted what he hoped was
the root of the problem, and committed a one line change (#27133) to
fix it.
http://xrl.us/j65c
A curiously lethal regular expression problem (#38470)
Nigel Sandever posted a short piece of code that uses "pos" and a
moderately large string. It loops for a while (or not at all) and then
dies with a core dump. Nigel and Nicholas identified the problem as
runaway recursion in the regexp engine. For the time being the
work-around is Don't Do That Then.
Here's hoping that Dave Mitchell greps for his name in the summaries
when he gets back on the net.
http://xrl.us/j65d
"Data::Dumper" only warns on unhandled reference types (#38484)
Give "Data::Dumper" a weird reference type it doesn't know how to
handle, and it will spit out a warning, but then goes on to emit some
nonsensical Perl code that may not even compile. Nicholas thought that
"Data::Dumper" should have the good grace to up and "die" if unable to
do anything sensible.
Yves thought it was a bug, since the pure-Perl "Data::Dumper"
implementation correctly dies under the same circumstances. He also
was interested in knowing what to do, since his own module,
"Data::Dumper::Streamer", didn't cope with the construct either.
(Which is *STDOUT{IO} in the bug report).
Nicholas wasn't sure what to do either, noting that even perl itself
has a fit when it tries to dereference such a beast, as in "$x =
${*STDOUT{IO}}".
Yitzchak made a small fix to pp.c to make things die more gracefully.
http://xrl.us/j65e
"use integer; 0x80000000/-1" (#38485)
Inspired by something he heard on "perl6-internals", Nicholas
discovered that
use integer;
0x80000000/-1;
will dump core with a floating point exception, at least on x86
hardware running FreeBSD. He wanted to know whether it was worth
trapping, and dying with a more useful error, akin to dividing by
zero. Steve Peters discovered that a number of different platforms
puked over the code in strange and entertaining ways, but reflected
that it were best they all died the same way, so he committed change
#27155 to do just that.
Yitzchak Scott-Thoennes hated that, since it meant that now systems
would die on the error, despite the fact that before the patch was
added, they would have carried on just fine, and suggested it be
reverted and a different proposed patch be applied instead. Rafael
complied.
http://xrl.us/j65f
More background on the matter, courtesy Wikipedia
http://en.wikipedia.org/wiki/SIGFPE
-x allows -M on the shebang line (#38488)
Nicholas pointed out that the following doesn't work
#!perl -Mstrict
print "foo\n";
but if you run the same script with "perl -x"... it does! And wondered
why this was the case. Yitzchak and Rafael thought that the path of
least resistance was to make "-M" legal on the command line.
http://xrl.us/j65g
New Core Modules
"CPAN.pm"
Andreas Koenig uploaded version 1.64 of "CPAN.pm"
http://xrl.us/j65h
"version.pm"
John Peacock uploaded versions 0.54, 0.55 and 0.56_03 of
"version.pm".
Respectively:
http://xrl.us/j65i
http://xrl.us/j65j
http://xrl.us/j65k
"podlators"
Russ Allbery released "podlators" 2.0.4
http://xrl.us/j65m
In Brief
Andreas Koenig noticed that "POE"'s test suite was issuing the dreaded
"*** glibc detected *** double free or corruption" errors with
"[EMAIL PROTECTED]". Nicholas ascribed the problem to a single missing
tilde, which he fixed with change #27166. Andreas was pleased.
http://xrl.us/j65n
Enrico Sorcinelli wondered why stable is still version 5.8.7,
according to "www.cpan.org" now that 5.8.8 has been released. As it
turns out, it wasn't sloth on the part of the CPAN master librarian
(ook!), but rather a policy decision to wait a certain amount of time,
to see whether the early adopters after the public announcement
uncover any show-stopping bugs, before declaring the release to be
stable.
As it turned out, at the time this summary was written, the 5.8.8
release had been officially declared the stable version.
http://xrl.us/j65o
Nicholas discovered a difference between 5.8.7 and 5.8.8. In the
latter version, the following occurs:
$[ = 2; # warns of "Useless use of a constant in void context"
... but he doubted that it was going to cause problems.
http://xrl.us/j65p
He also realised that a grand total of zero people tested the 5.8.8
release with 5.005 threads. Which may mean they are dead (either the
threads or the people, take your pick).
http://xrl.us/j65q
When prowling around in mg.c, Nicholas came what he thought was an
errant "break" that could never be reached, and asked if anyone could
devise a snippet to reach it. No-one did.
You can't get there from here
http://xrl.us/j65r
A smoke on windows blew up due to "PERL_IMPLICIT_SYS" choking on a
"pTHX" that had been removed. Jan Dubois provided the voice of reason
and got it all lined up again.
http://xrl.us/j65t
Going back to a thread from mid-January asking whether "SOFT_CAST"
could be removed, Nicholas went ahead and got rid of it.
http://xrl.us/j65v
Robert Hicks would like to see a couple of new features in DProf: the
ability to specify a path destination for the ".out" file, and to name
the ".out" file based on the name of the script.
Yes, these would be nice additions. Earn fame and glory by being the
first person to send in a patch to do this.
http://xrl.us/j65w
Merijn Broeren discovered that compiling c++ code via SWIG no longer
works with 5.8.8, spotted something that had changed somewhere between
5.8.4 and 5.8.8, and posted a patch to straighten it all out. Applied
as change #27203 by Rafael.
http://xrl.us/j65x
Perl5 Bug Summary
1543 open tickets as of 2006-02-06.
http://xrl.us/j65y
and 6 more as of 2006-02-13.
http://xrl.us/j65z
All the bugs in the world
http://rt.perl.org/rt3/NoAuth/perl5/Overview.html
About this summary
This summary was written by David Landgren. Compiling this last
fortnight has consumed most of my evenings this week. And yet, try as
I might, I cannot seem to find the way to summarise things more
succinctly. My apologies for the length, and congratulations if you
have managed to read as far as here. Now to start on this week's
summary.
Adriano Ferreira has had to step down for a while, due to constraints
In Real Life. I hope we'll see him in the summariser's seat again in
the future. In the meantime, if writing summaries is your definition
of fun, drop me a note and we'll share the work.
Information concerning bugs referenced in this summary (as #nnnnn) may
be viewed at http://rt.perl.org/rt3/Ticket/Display.html?id=nnnnn
Information concerning patches to maint or blead referenced in this
summary (as #nnnnn) may be viewed at
http://public.activestate.com/cgi-bin/perlbrowse?patch=nnnnn
If you want a bookmarklet approach to viewing bugs and change reports,
there are a couple of bookmarklets that you might find useful on my
page of Perl stuff:
http://www.landgren.net/perl/
Weekly summaries are published on http://use.perl.org/ and posted on a
mailing list, (subscription: [EMAIL PROTECTED]). The
archive is at http://dev.perl.org/perl5/list-summaries/. Corrections
and comments are welcome.
If you found this summary useful or enjoyable, please consider
contributing to the Perl Foundation to help support the development of
Perl.
--
"It's overkill of course, but you can never have too much overkill."
