develooper Front page | perl.perl5.porters | Postings from February 2006

This Fortnight on perl5-porters (6-19 February 2006)

Thread Next
David Landgren
February 24, 2006 13:10
This Fortnight on perl5-porters (6-19 February 2006)
Message ID:
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

   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

   At the same time, "ags" filed bug #38595. showing how "use encoding
   'cp1250'" cause regular expressions to run much more slowly than

     Slow Unicode regexps

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

   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

     Reclaim an C<HE_SVSLOT>, save some bytes

     No smoke here

   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

   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

   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

(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

   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!

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

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

   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.


"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

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

   Never one to let such a trifling matter bother him, Stas filed a bug

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.

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

"Module::Build", "", "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

     The thread, accord to Tels

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

     And fast-forward to now

     More voodoo

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

     System requirements


   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.

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"

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

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

What Andy Lester has been doing

   Andy Lester delivered a number of patches during his quest to const.

     Marking unused arguments (applied as #27129)

   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

     And then some more, still no takers

   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.

     And then some stuff from perly.patch

   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

     In which perly.c is examined (not applied)

     And some POD rewording (change #27174)

     More lint removal (change #27177)

     The end of the line of the Nullxx macros (change #27238)

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:

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

"Hash::Util" enhancement

   Yves also sent in a large patch to add some functionality to
   "Hash::Util". Applied as change #27180.

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

     Whee! Another platform supported

     More on DragonFly

"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, which
   was invented to solve exactly this sort of problem.

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

     Schwern throws down the gauntlet

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.

Patches: B, CGI, ExtUtils::MM_Unix

[PATCH] Make SDBM_File work with -Duse64bitall on Darwin (Mac OS X)

[PATCH] Trouble with $ENV{CDPATH} after change #27236

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.

   Alan Burlison pointed to another discussion on the matter

   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.

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

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.

"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 would declare it legal in "blead", but
   was worried about backwards compatibility issues if it were allowed in

   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

   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

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

     A puff of smoke is seen

   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.

"@-" contains garbage after a failed match (#38461)

   Lukas Mai posted a bug report with an aptly-named 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.

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.

"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 =

   Yitzchak made a small fix to pp.c to make things die more gracefully.

"use integer; 0x80000000/-1" (#38485)

   Inspired by something he heard on "perl6-internals", Nicholas
   discovered that

     use integer;

   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

     More background on the matter, courtesy Wikipedia

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

New Core Modules

       Andreas Koenig uploaded version 1.64 of ""

       John Peacock uploaded versions 0.54, 0.55 and 0.56_03 of


       Russ Allbery released "podlators" 2.0.4

In Brief

   Andreas Koenig noticed that "POE"'s test suite was issuing the dreaded
   "*** glibc detected *** double free or corruption" errors with
   "blead@27059". Nicholas ascribed the problem to a single missing
   tilde, which he fixed with change #27166. Andreas was pleased.

   Enrico Sorcinelli wondered why stable is still version 5.8.7,
   according to "" 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

   As it turned out, at the time this summary was written, the 5.8.8
   release had been officially declared the stable version.

   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.

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

   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

   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.

   Going back to a thread from mid-January asking whether "SOFT_CAST"
   could be removed, Nicholas went ahead and got rid of it.

   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.

   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.

Perl5 Bug Summary

   1543 open tickets as of 2006-02-06.

   and 6 more as of 2006-02-13.

     All the bugs in the world

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

   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

   Information concerning patches to maint or blead referenced in this
   summary (as #nnnnn) may be viewed at

   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:

   Weekly summaries are published on and posted on a
   mailing list, (subscription: The
   archive is at 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
"It's overkill of course, but you can never have too much overkill."

Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About