develooper Front page | perl.perl5.porters | Postings from March 2008

This Week on perl5-porters - 9-15 March 2008

Thread Next
David Landgren
March 22, 2008 10:42
This Week on perl5-porters - 9-15 March 2008
Message ID:
This Week on perl5-porters - 9-15 March 2008

   Take our command, strip off the package, pass the short name and the
   calling package to "_make_fatal()", and then use magic-goto to call
   our subroutine at the end. It's simple, right? Yet I struggle to find
   any time when it's correct. -- Paul Fenwick and his Fatal attraction.

Topics of Interest

Getting blead via git

   Nicholas Clark pondered the layout of files in the build directory. He
   thought that it would be useful to have dual-lifed modules positioned
   under ext/, and in git parlance they would become submodules. This
   would simplify managing the changes between the CPAN version and blead
   or maint. But he was wondered how git would keep track of the same
   file that is in lib/ for maint but in ext/ for blead.

   Sébastien Aperghis-Tramoni wondered if Nicholas was thinking about
   pragma modules (like "strict" and "constant") too.

   Nicholas also wanted to know what support git provided to answer
   questions such as "which changes from this branch have been integrated
   into that branch". Rafael seemed to think it should be possible, but
   no people with strong git-fu responded.

   Elsewhere, there was some idle chatter of converting everything to
   UTF-8, but no resolution.

A lexical Fatal for Perl 5.10

   Now that 5.10 allows people to write lexical pragmas, Paul Fenwick set
   about writing a scoped version of the "Fatal" module (whereby warnings
   become fatal errors).

   He thought that it would be possible to bolt the additional
   functionality onto a dual-lifed "Fatal" module, but the syntax seemed
   clumsy, and a better idea would be to build on "Fatal" to produce an
   all-new "lethal" pragma.

   There was a certain amount of bikeshed discussion to suggest better
   names, such as "deadly", "autodie" and sillier, but "lethal" gathered
   currency as the thread moved along.

"Fatal::AUTOLOAD" - Feature or Bug?

   In the middle of adding lethal support to Perl, Paul stumbled upon a
   thing of wond'rous beauty. It turns out that you can inherit from
   "Fatal" in a package, and through the magic of "AUTOLOAD", invoke
   Fatal behaviour by prepending an ampersand to a builtin (à la "&open
   my $in, '<', '/no/such/file'") or not, by omitting it.

   Of course, this functionality is not documented anywhere: neither the
   POD, nor code, nor test suite make any allusion to it. As such, Rafael
   Garcia-Suarez and a chorus of porters called for the chain-saw to have
   the beast put out of its misery.

Fedora 9 and 5.10.0

   Tom Callaway was happy to announce that, thanks in large part to the
   efforts of Andy Armstrong, Nicholas Clark and Rafael Garcia-Suarez,
   the upcoming Fedora 9 release will contain perl 5.10.0. This should be
   available in late April.

Safely supporting POSIX "SA_SIGINFO"

   POSIX offers various ways to define C routines that may be used as
   signal handlers, one of which gives the routine access to additional
   information. This in turn offers the handler more context with which
   to figure out what is going on. Some years back, Jarkko Hietaniemi
   wrote some code to expose this richer interface to a signal handler
   written in Perl.

   Nicholas Clark ran across Jarkko's work this week, and realised that
   it no longer worked in the age of safe signals, because the lag
   between the signal's arrival and its delivery to Perl results in the
   extra information being lost. He thought that there was a way to make
   things work, as one of the allowed system calls in a signal handler is
   "write", and with this he could squirrel the information away
   somewhere until it is safe to fetch it.

   His scheme was to install a shim at the signal arrival to write the
   information to a conveniently pre-opened pipe, and then after the
   current opcode has been run, see if there are any piped signals
   waiting. If there are, then the information is pulled out of the pipe,
   unpacked (since it is all intra-host communication, we'd be free to
   write out raw structs), prettied up, and then the safe signal handler
   is called.

   Tim Bunce admired the deviousness, but wondered if using pipes was
   overkill, and asked whether a slab of memory could be set aside for
   this use instead. Nicholas pointed out that there is nothing from
   preventing a process from receiving multiple signals simultaneously
   (they are asynchronous after all), so when all is said and done one
   would probably wind up with something that resembled the pipe
   infrastructure anyway, only buggy.

   Current flaws in the idea include the fact that on a couple of
   platforms the siginfo structure is larger than 512 bytes, the largest
   atomic write permitted to a pipe. Craig Berry reminded people that for
   multiple deliveries of the same signal during the execution of an
   opcode are thrown away. Nicholas wondered if that was a bug that
   needed fixing. Craig pointed back to previous thoughts he had had on
   the subject perl's signal implementation.

   Nicholas also mentioned the hoops one would have to jump through in
   order to deliver the signal to the right thread in a multi-threaded

Refine "make regen" to be more selective

   Jim Cromie was annoyed by the fact that running a "make regen" will
   cause everything to be recompiled (because it generates a slew of
   files that tickle major Makefile target rules). So Jim added smarts to to have each file built in a holding pen, and only update the
   target file when it differs from previous run.

   At first there was considerable debate about using checksums and hash
   digests to check whether the files differed. Ben Morrow pointed out
   that as both the old and new files were present, and read in their
   entirety one could do away with extra trickery and just perform a
   simple byte-for-byte comparison.

     shades of mv-if-diff

A question of inheritance, encoding and aliases

   It started out with H.Merijn Brand tracking down the cause of utf8.t
   (from "Test::Simple") failure on HP-UX.

   This in turn led Michael G. Schwern to discover that there was
   something wrong with and "Encode". Rafael Garcia-Suarez
   realised that the cause of the problem was due to some sort of
   assumption of a routine name being present in the "Encode" namespace,
   something that the new method dispatch of 5.10 may have broken.

   Michael G.Schwern extracted the problem and filed it as a bug. Rafael
   fixed that up with change #33486. H. Merijn Brand produced a similarly
   entertaining error message by using "Encode" and "encoding" without an
   encoding name. Michael thought the results were very pretty, but a
   better error message wouldn't go astray.

     Encode::Alias + open go boom (#51608)

   After the dust settled, Dan Kogai, the Encode maintainer, release
   Encode 2.24. H.Merijn was, however, still having difficulties with the
   utf8.t with open failing to know what to do about "roman8" encoding
   which appears to be an HP specialty. Michael G. Schwern tried, and
   failed, to understand what "Encode::Alias" was doing, and/or whether
   it was doing it incorrectly.

   Unfortunately, at about the same time, David Cantrell discovered that
   his own 5.10 smoke tests were spewing black, and so Rafael and
   H.Merijn suggested he try upgrading to Encode 2.24. Alas, that did not
   solve the problem.

   Fortunately, Jarkko Hietaniemi came to the rescue with his "646"
   patch, and this had David up and running again. Alas, Jarkko did not
   think that this would help with H.Merijn's roman8 problem.

Taint ("PL_tainting", "SvTAINTED_on", "SvTAINTED_off", "SvTAINT")

   Bram has a large application that wasn't designed to be taint-clean.
   Nevertheless, in the middle of the code, he wanted to enable taint
   mode briefly in order to bring taint checks to bear on unsafe feeds
   coming into the system.

   So he used "Taint::Util" and "Taint::Runtime" for his nefarious
   purposes, yet was surprised when reality didn't quite meet his
   expectations, in that a scalar, created before taint mode was enabled,
   reading from "STDIN" will *not* be considered to have tainted

   Paul Fenwick was horrified by the idea of enabling taint mode at an
   arbitrary point during the execution of a program (perhaps missing the
   point that Bram's application wasn't taint-clean in the first place,
   in which case some taint is better than none). He thought that the
   problem of scalars not honouring taint mode if created before tainting
   was enables was probably a performance consideration.

     say it taint so

5.8.9 for VMS

   Craig Berry issued a status report for the current 5.8 snapshot on
   VMS. There are four main problems (three in ExtUtils, one to do with
   threads). Solutions exist for two problems in ExtUtils, the third may
   be a question of housecleaning. The threads issue is related to bug
   #45053. As this is failing with 5.8.8, Craig suggested that it could
   be left documented that way so as not to hold up 5.8.9.

     99.63% okay

Tests failed on PPC64

   Sérgio Durigan Júnior reported a couple of failures in the test suite
   when building 5.10 on the PPC64 platform. Dominic Dunlop realised that
   the messages were semi-harmless, being indicative of tests making
   assumptions on the availability of modules that had not yet been

   Since none of the porters run PPC64 machines, it seems likely that
   some new hints will be needed for the configuration process to allow
   building straight out of the box.


   Jim Cromie regretted the lack of a "Perl_ck_*" routine to check all
   constructed ops, and thought we needed one. The routine would check
   that the C struct of the op had sane values.

Test failures for perl 5.10 on Solaris 10

   Ken Williams took 5.10 for a spin on Solaris and discovered a number
   of failures. He traced this down to the fact that the source was built
   using Sun's "make", but that some tests wind up running with a
   different make, and they fail.

Patches of Interest

More sv.c consting

   Steve Schubiger continued with his consting crusade, creating a series
   of patches that Rafael applied. At the end of the week, patch number
   13 was as yet unapplied.

Fix "ExtUtils::Install" under Cygwin

   This problem continued to occupy Steve Hay, Nicholas Clark and Jan
   Dubois this week. The underlying issue is whether a read-only
   directory may not be added to, or may not be deleted. Compounding the
   problem was the fact that different compilers return contradictory
   information concerning the information returned from the operating

   By the end of the week, things were cleaned up enough to give the
   green light for the release of 5.8.9.

Testing madly

   Gerard Goossen set about fixing up the errors with the Perl5-to-Perl5
   conversion that the MAD infrastructure provides.



   Gerard also wanted to rip out a chunk of code that was no longer
   needed for guessing if a bareword was a subroutine name. Rafael
   wondered if this was wise, and Gerard explained that changes elsewhere
   in the MAD codebase had rendered the code unnecessary.

Misleading example in perlsyn.pod (given/when/default)

   Paul Fenwick looked at "given" and "when", and was misled by the
   documentation. He proposed removing the ambiguity with a slight edit,
   and Rafael applied it.

Rever cygwin archname hints

   Reini Urban reverted the archname tweaks on the Cygwin platform, the
   main reason being to tidy up cpan-testers reports.

Lexical and

   Paul Fenwick delivered a first cut at lexically scoped fatalities. The
   message thread, however, will be summarised next week.


New and old bugs from RT
=head2 Remove revision bread crumbs from short description (#48453)

   The perlfaq has, for the longest time, carried the blight of revision
   tags in the titles, causing an unsightly mess in "perltoc". Rafael
   explained that that the Perl FAQ was maintained in a separate SVN
   repository, and suggested that it would make sense in the long run to
   bring it back in the fold under git control.

Incorrect calculations (#50072)

   Vladislav Malyshkin filed a bug back in January, and at the time
   Abigail explained that the bug was more in Vladislav's code rather
   than Perl (the heart of which was the problem of operators having side

   Abigail and Michael G. Schwern replied that debating the merits of
   operators and side effects in Perl 5 was a bit of a lost cause at this
   stage of the game.

Problem and "solution" for building 5.10.0 with win32+mingw+dmake (#51562)

   Kjetil Skotheim reported a problem (and a fix) when building perl on
   Win32 with MinGW. Jan Dubois wasn't sure how Kjetil encountered the
   error in the first place, suspecting that some other issue was coming
   into play.

"Scalar::Util::looks_like_number" vs. Optimisation in regex? (#51568)

   Steffen Ullrich thought he had found a bug in "looks_like_number", but
   he was passing $3 as a parameter. Eric Brine explained that this was a
   dangerous practice, as something was probably interfering with it on
   the way down. It would be wise to interpolate it into a string, and
   pass that instead.

   When that is done, the problem goes away.

segmentation fault with array ties (#51636)

   "blino" encountered a problem while developing "Gtk2::SimpleList" and
   reduced it to a bug involving ties within ties. Most remarkable was
   the fact that (s)he was able to pin-point the problem as being change
   #31770, which involved optimising "push @ISA" and propose a tentative
   patch to correct the problem.

   Rafael thought the patch looked safe enough, but wondered if it would
   not be papering over a deeper bug in handling magic. Vincent Pit was
   able to put forward a very good explanation as to what was really
   happening, and produced a better patch and a regression test. Nicholas
   wondered if Vincent should have used heavier machinery for saving and
   restoring magic; Vincent wasn't sure either way.

"waitpid()" example in perlfunc(1) is bogus (#51642)

   "vedge" suggested that the "waitpid" snippet in the documentation
   could produce an infinite loop, and proposed an alternative. Abigail
   thought that the alternative could also wind up as an infinite loop.

     back to the drawing board

op/alarm.t hangs on 5.11.0 (Windows Vista only) (#51674)

   Sisyphus reported problems with "alarm" on Vista. Robert May owned up
   as being the probable culprit with some recent changes he had made.
   With a small edit, he was able to recover the correct behaviour.

"@-" array is incorrect with non matching grouping (#51688)

   The bug itself was not a bug, but (and perhaps because of that) Paul
   Fenwick asked for a point of order concerning the handling of tickets
   on the perlbug RT queue.

"utf8::valid" rejects characters in \x14_FFFF - \x1F_FFFF (#51710)

   Chris Hall discovered a discrepancy between "utf::valid" and
   "Encode::encode('utf8', ...)", with "utf::valid" rejecting characters
   incorrectly. No takers.

Perl5 Bug Summary

     290 new + 1502 open = 1792 (+10 -8)

In Brief

   Yitzchak Scott-Thoennes's fix for "Archive::Extract"'s x.lzma test
   file was applied.

   Andy Dougherty delivered what he thought was his most trivial patch
   ever, a one line suppression in MANIFEST. Nicholas Clark thought Andy
   could do much better, since Nicholas has made changes that involve
   only a single character.

   The "perlbal" issue of not building for Fedora was sorted out.

   Daisuke Maki found a leak in "Text::CSV_XS->getline" , which isn't
   part of core, but since (s)he supplied a reasonable patch, H.Merijn
   Brand, "Text::CSV_XS"'s maintainer, took the time to fix the problem

   Elizabeth Mattijsen puzzled over the differences in "builtin()" versus
   "builtin( () )" (extra parentheses in the call) and discovered that
   she had been bitten by prototypes.

   Nicholas Clark believes he has nailed the corruptions seen in

     dup shenanigans

   In the process of tidying up a bug report for "CGI", Nicholas Clark
   wondered if the current dual life module bug/patch work-flow was
   optimal. The distinctly sub-optimal part is having perl bugs reported
   to an RT queue at, and dual-life module bugs reported to RT queues. This alone makes it difficult to bounce tickets
   from one queue to another.

   Which begs the question, why are we even using RT in two separate

   Paul Fenwick asked for (and received) a point of order concerning the
   cleaning out of RT non-bugs.

Last week's summary

About this summary

   This summary was written by David Landgren.

   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, please consider attending a YAPC
   conference or contributing to the Perl Foundation to help support the
   development of Perl.

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