This Week on perl5-porters - 1-6 June 2008

This Week on perl5-porters - 1-6 June 2008

   *Traditional exception handling is more like equipping each Klingon
   with a dead-man's switch attached to a nuke. Dying by accident in
   someone else's nuke blast would be a death without honor. So the point
   of the Perl 6 exception model is to try to keep as many warriors alive
   as long as possible in order to inflict the maximum possible damage on
   the enemy, which is our highest goal, after all. :)* -- Larry Wall, on
   the issue of dealing gracefully with errors.

Topics of Interest

"IO::Dir" destructor

   Peter Dintelmann looked at Zefram's fix for "IO::Dir" (which was
   clobbering global variables like $!) and realised that the same
   criticism could be levelled at "DirHandle". So he adopted Zefram's
   initial approach to "DirHandle" as well, and Steve Peters made sure it
   got into blead.

     http://xrl.us/b7fqo

Fatal/autodie exception hierarchies for Perl 5

   Paul Fenwick laid out a more detailed description of his exceptions
   hierarchy for Perl 5. chromatic thought that an attempt at
   hierarchies, whether they be singly or multiply rooted, was doomed to
   failure. A much better approach would be to define a set of roles, and
   any given exception would implement one or more roles. Larry Wall
   explained what was going on over in Perl 6 and detailed a most
   interesting shift in the design philosophy of handling exceptions, in
   that errors are treated as data rather than interruptions to control
   flow.

   Mark J. Reed offered a useful Klingon directive (yIQap pagh yIHegh!).
   Joshua ben Jore reminded people of the danger of inspecting $@ and
   wiping it in the process, thus resulting in a error-on-error condition
   known as exception suicide. He went on to show how paranoid you really
   need to be in order to avoid exceptions vanishing through
   carelessness.

     they *are* out to get you
     http://xrl.us/b7fqq

"autodie.pm" design questions

   Paul, no Bruce, Fenwick had a couple of questions to ask the porters.
   The first one was how to apply autodie semantics to "system", which is
   more difficult that one might imagine since it has some really weird
   variant calling conventions. The second question was the possibility
   to grant "autodie" core status at some point (the problem being that
   it currently depends four non-trivial non-core modules).

   Roland Giersig accidentally opened old wounds asking why it couldn't
   be possible to retrofit the new "autodie" semantics onto "Fatal", but
   Aristotle Pagaltzis and Abigail made short order of that issue.

   Of the prerequisite modules needed by "autodie", Roland thought that
   "IPC::System::Simple" sounded like something useful in its own right.

   As to the "system" issue, Abigail thought that it would be nice to
   "autodie" along with the rest, as long as there was an "no autodie
   'system'" escape hatch.

   Paul, err Bruce, no Paul sneaked in a subsequent question, which was
   should a bare "use autodie" enable the Fatality of everything it knew
   how to lay its hands on, or just a conservative (but nevertheless
   broad) subset. In other words, does it mean "use autodie ':all'" or
   "use autodie ':default'"? The latter approach is innately
   conservative, forcing the client code to ask explicitly for any
   semantics for which no solid concensus has emerged.

   Paul dumped his current thoughts into POD here:

     http://github.com/pfenwick/autodie/tree/master/DESIGN.pod

   and admitted it would be better to put it in a wiki, but the tram he
   was in at the time didn't have wireless (loser!).

   Another issue (the bloke just kept sneaking them in) is that old Fatal
   messages sucked the big one, and Paul wanted to make them prettier in
   the new version. Aristotle Pagaltzis argued that their ugliness had
   never hindered widespread adoption of the module in the first place.
   Therefore it was important to retain the bletcherously ugly error
   messages of "Fatal", and introduce soothing, elegant messages in
   "autodie", since that would only increase the velocity of adoption of
   the latter. And you never could eliminate the possibility that
   someone, somewhere, was scraping the exact output of a Fatal error
   message.

     a fatal abstraction
     http://xrl.us/b7fqs

"PERL5OPT -M" processed after command line -M?

   David Golden was surprised to discover that the effect of a "-M"
   switch in the "PERL5OPT" environment variable takes place after a "-M"
   switch on the command line. And I imagine that few people would have
   expected the contrary.

   Rafaël Garcia-Suarez argued that it was intentional, since
   traditionally, the command-line overrides the environment and when one
   thinks about the precedence of module loading it sort of makes sense.
   On the other hand "-T" gets noticed straight away. David agreed that
   while that was useful behaviour, the inconsistency bothered him. What
   was lacking was the documentation that would explain which switches
   overrode which context.

     http://xrl.us/b7fqu

More results from llvm-gcc

   Yuval Kogman reported on some research he had conducted with llvm-gcc
   (the Low Level Virtual Machine project) by using it to compile the
   5.10 perl codebase. He saw an improvement of around 15% (which is a
   serious improvement) but had trouble trying to get XS modules to work
   (which is a serious disadvantage). On the other hand, it may open the
   door to putting Perl apps on Apple's iPhone, which earns serious cred
   points in the mindshare department.

   Steve Peters wanted to see how current Intel C++ and Sun Studio fare,
   since they usually leave gcc in the dust.

     the return of the compiler wars
     http://xrl.us/b7fqw

Ruminations on "Devel::Cover"

   In a side remark on the Summer of code mentor applications starting
   (and ending) next week thread, Paul Johnson, on the subject of modules
   that maintain a rather incestuous relationship with the core, said
   that for better or worse, "Devel::Cover" was destined to remain a
   module that remained outside of core.

   He admitted that while it would be nice to have someone step in and
   fix up its breakage following significant changes to the core, he was
   sufficiently lucid to realise that the resources available to develop
   the core are thin, and that in releasing such a module, he was
   responsible for expending the appropriate effort to keep it working.
   Joshua ben Jore admitted that his love-hate relationship with the core
   veered strongly to the hate side.

     all raise your glasses to Paul
     http://xrl.us/b7fqy

"??{ }" closure semantics

   Yuval Kogman also ran into some trouble in some hairy patterns using
   "??{ }" constructs, and assumed it was a bug. Rafaël confirmed the
   issue, saying that it was indeed a bug, Dave Mitchell knew about it,
   and wanted to fix it. David Nicol asked if it was more difficult that
   just incrementing the refcount on lexicals encountered within
   "??{...}" constructs and maintaining a list of same to decrement when
   the regexp goes out of scope, and Dave said yes.

     it is *more* difficult than that
     http://xrl.us/b7fq2

Smoking from GIT

   H.Merijn Brand idly wondered how we were supposed to smoke from a git
   repository, since a nice monotonic sequence, a feature that endears us
   to Perforce, is replaced by a SHA-1 digest that only an idiot savant
   could love. Rafael sidestepped the issue by saying that the 'HEAD' tag
   gets you what you need.

     git describe
     http://xrl.us/b7fq4

'once' warnings from xs modules in perl 5.10.0

   Chia-liang Kao noticed that 5.10.0 spews out "used only once: possible
   typo" where before silence used to reign. He wondered if it was
   possible for the core to suppress the warning if it emanated from an
   XS boot block.

   Nicholas Clark thought that something needed to be done to address the
   problem, so Chia-liang will file a bug next week.

     direct from the time machine
     http://xrl.us/b7fq6

TODO of the week

Common test code for timed bail out

   Write portable self destruct code for tests to stop them burning CPU
   in infinite loops. This needs to avoid using alarm, as some of the
   tests are testing alarm/sleep or timers.

   (This TODO is perhaps too terse. Interested parties are invited to ask
   the porters for an idea of what really needs to be done. Even TODOing
   the TODO would be helpful at this point).

Patches of Interest

"Archive::Tar" was building corrupt archives on VMS

   John E. Malmberg finally figured out exactly what the problem was with
   "Archive::Tar" on VMS. So he fixed it.

     now to get it applied
     http://xrl.us/b7fq8

Fix for lib.pm Config detection

   Steffen Müller was embarrassed by a very silly mistake in his work on
   lib.pm. He corrected it, and Rafaël applied the correction.

     http://xrl.us/b7fra

"File::Copy" & permission bits

   Following Craig A. Berry's belated follow-up on the change in
   "File::Copy"'s behaviour, Charles Bailey, made an even more belated
   follow-up, and it was full of good stuff. Charles explained the
   original rationale behind "copy" and "syscopy" and how things have
   drifted over the years since the original implementation was drafted.

   He also agreed that the new changes were likely to cause trouble on
   non POSIXish platforms. Abigail expressed surprise that the patch was
   even accepted in the first place, given the provisos surrounding it
   (that it was non-backwards compatible and that it was unclear what it
   would do on non-POSIX platforms).

   While no clear concensus emerged as to what should be done, most
   people that commented suggesting that backwards compatibility was
   paramount, and in any event the code needs a thorough overhaul.

     up on the blocks
     http://xrl.us/b7frc

"stat()" and "-X" for tied handles

   Robert Norris, who goes for tied file handles in a big way, delved
   into the guts in order to allow "stat" and "-X" (where X is f, d, b,
   ...) to do something sane. Rafaël Garcia-Suarez looked upon it
   favourably, but waited to see if other people had any opinions, as he
   doesn't really do tied handles at all.

     http://xrl.us/b7fre

Incorrectly failing test in lib/Pod/t/text.t

   A correction for a bug in "Pod::Simple" meant that a work-around in
   the test suite was no longer required. This made it into both blead
   and the podlators kit.

     http://xrl.us/b7frg

"perldoc -q ..." searches index entries ("X<>")

   Renée Bäcker noticed a slew of "X<>" going to waste in the perl FAQs,
   and therefore tweaked "perldoc -q" to look at them when asked to
   perform a search.

     http://xrl.us/b7fri

New and old bugs from RT

-e tests not reliable under Win32 (#30622)

   Steve Peters noted that Cygwin is now reliable, although the problem
   persists with Windows.

     http://xrl.us/b7frk

"CGI::Util", expire_calc (#33047)

   Tom Hospel wondered why his bug had been resolved, since he thought
   the initial problems were still present. Bram demonstrated why he
   thought otherwise, and invited Tom to point out where his reasoning
   was incorrect.

   In any event, the bug should probably be addressed via Lincoln Stein,
   the module's author.

     and we will synch
     http://xrl.us/b7frn

"\n" after $ in regex (#35877)

   Bram thought that a nice warning for this problem would be a warning
   that said "Possible unintended interpolation of $\ in regular
   expression', assuming it's actually possible. Yitzchak Scott-Thoennes
   observed that there is an elegant work-around to silence the warning,
   by way of "${/}".

     assuming that's also possible
     http://xrl.us/b7frp

"File::Temp" and unsafe shell characters (#50146)

   Ed Avis failed to see why anyone still used of "system" when
   "IPC::Run" was so much nicer.

     'coz it ain't core?
     http://xrl.us/b7frr

"pod2man" needs to translate some ASCII characters (#50950)

   Steve Peters committed Mike Ward's patch that addressed the rendering
   of backticks. There was also the issue of a =head2 with two C<> blocks
   (#53974)

     podlators are go
     http://xrl.us/b7frt
     http://xrl.us/b7frv

perl-5.10.0 glibc detected *** free(): invalid pointer (#51238)

   Warren Dodge reported a problem in "ClearCase::CtCmd" puking on a
   "free()". Steve Peters asked if he was able to coax a full stack trace
   out of his perl binary, but Warren wasn't sure how to do that and
   asked for guidance.

     help me-e-e-e-e
     http://xrl.us/b7ftv

ext/POSIX/t/sysconf.t makes too many assumptions (#51276)

   Steve Peters noted that thanks to change #33401 there's one less
   assumption in the code.

     Posixly robust
     http://xrl.us/b7frx

perl5.8.8 crashed when I build ikiwiki on gentoo linux (#53200)

   Steve Peters verified that this problem is solved in 5.10. The next
   thing to do will be to see what a 5.8.8 debugging build thinks of it.

     SMOD
     http://xrl.us/b7frz

Regexp modifier to disable interpolation like m'' (#54702)

   Bram thought that the /n modifier for a non-interpolating regular
   expression was a bad choice since it has a purpose in .NET patterns.
   Ed Avis thought that /d would do just as well; the letter is not
   important, the functionality is. Abigail could see the point in having
   a generalised quoting mechanism for non-interpolating patterns, à la
   "q()" and "qq()", so long as it didn't break any existing code. Ed
   pointed out that "m/./d" was currently a syntax error.

     doomed episodic demigoddesses
     http://xrl.us/b7fr3

perlio.c has a problem (both 5.8 and 5.10) (#54828)

   Rafael applied Goro Fiju's patch, who then realised that the second
   part of it was redundant since the first part of the patch ensured a
   level of consistency that obviated the need for a subsequent sanity
   check.

     http://xrl.us/b7fr5

Attempt to free unreferenced scalar fiddling with the symbol table (#54934)

   After some further discussion with Niko Tyni concerning the eventual
   security implications leaving this bug unchecked could have, Rafaël
   applied the patch.

     http://xrl.us/b7fr7

Hash subscript documentation (#55158)

   Ian Goodacre supplied a goodly-sized chunk of documentation to explain
   hash subscripts more clearly. The patch was left on the table, perhaps
   because Ian did not supply another patch that removed the equivalent
   budget of words plus from elsewhere in the documentation.

     documentation karma
     http://xrl.us/b7fr9

Fix cygwin mount test (#55160)

   Reini Urban suggested a fix and Rafaël applied it.

     http://xrl.us/b7fsb

"File::Spec" Cygwin/Win32 case_tolerant improvement (#55162)

   Reini Urban attempted to improve "File::Spec" to make it behave better
   on Windows and produced several iterations of a patch that still
   wasn't accepted by midweek.

     http://xrl.us/b7fsd

Autoflush output after :encoding pushed (#55172)

   Kevin Ryde discovered that using an encoding on a file handle will
   interfere with any subsequent attempts to change the flushing
   behaviour (as in $|).

     http://xrl.us/b7fsf

UTF-8 regex case insensitive character classes mishandle non-utf8 
strings (#55250)

   John Gardiner Myers found some more arguable behaviour in the handling
   of pattern matching in UTF-8 strings. Rafaël agreed with John, and
   stated that some of the misbehaviour will definitely need to be
   smacked down. Bram wrote some TODO tests.

     http://xrl.us/b7fsh

cc_runtime syntax error (#55302)

   Reini Urban discovered a long-standing bug in "B::CC", which has been
   there more or less since its inception. Steve Peters applied the
   patch.

     and you are the first person to notice... oh wait
     http://xrl.us/b7fsj

No warnings when reading from a file only opened for appending. (#55420)

   Paul Fenwick was surprised to learn that using the diamond operator on
   an file handle in void context will warn if the file was opened for
   output, but not if it was opened for append. So he took a look at
   pp_hot.c to cook up a patch, and did so, but thought it was too easy.
   Especially since more exotic file opening directives like "+>>" should
   not warn.

   Rafaël thought that fixing that would require a new "IoTYPE".

     http://xrl.us/b7fsm

Perl5 Bug Summary

   With Renée and Steve P getting their hands dirty along with Bram, the
   total bug count continues its downward trend. Hooray.

     274 new + 1286 open = 1560 (+15 -60)
     http://xrl.us/b7fso
     http://rt.perl.org/rt3/NoAuth/perl5/Overview.html

New Core Modules

   podlators 2.1.0
       The official announcement from Russ Allbery.

         http://xrl.us/b7fsq

       Steve Peters reported that "Pod::Simple" was slightly broken for a
       while since it initiated an undeclared dependency on
       "HTML::Parser" in order to scoop out "decode_entites". But
       everything was straightened out in the end.

         a simple matter of programming
         http://xrl.us/b7fss

       On the other hand, when Nicholas Clark integrated the upgrade into
       5.8.9 he discovered that a new test was failing in UTF-8 locales.

         http://xrl.us/b7fsu

   Sys-Syslog 0.25
       Sébastien Aperghis-Tramoni realised that 0.25 had not made it into
       core, which was a pity, since it contained fixes to all sorts of
       issues.

         http://xrl.us/b7fsw

       Nicholas went out for a smoke, and discovered lots of errors on
       blead. Sébastien was able to reduce the problem to a tiny test
       case involving "constant". After some more detective work, he
       confirmed that there was a discrepancy between
       "ExtUtils::Constant" in blead and on CPAN. And further that the
       discrepancy was an issue of proxy subroutines.

       This in turn led to the discovery that there wasn't any
       documentation for "ExtUtils::Constant::ProxySubs", which, at the
       very least, makes it difficult for anyone to realise that it could
       be of any use.

       Working together, Sébastien and Nicholas ironed out all the bugs
       that were deemed necessary to fix.

         some 5.6.0 breakage observed
         http://xrl.us/b7fsy

In Brief

   Paul Fenwick reported on his "autodie.pm" updates.

     now with 5 minute video tutorial!
     http://xrl.us/b7fs2

   Dave Mitchell observed that change #32881, to make "Data::Dumper"
   handle blessed regexes properly caused 5.10-maint to dump core.

     http://xrl.us/b7fs4

   Bram spent most of the week helping Jochen Luig come to grips with
   some perl 5.10.0 installation issues on CentOS 5 but success eluded
   them.

     http://xrl.us/b7fs6

   John E. Malmberg proposed some correct CGI/t/upload*.t fixes for VMS,
   but learnt that Craig A. Berry had already beaten him to it.

     http://xrl.us/b7fs8

   Re: Change 33987: Upgrade to podlators-2.1.0 http://xrl.us/b7fsu Some
   of the porters helped out with some datapoints to help Torsten
   Foertsch understand some "Linux::Smaps" kernel/perlio dependencies.

     try this at home
     http://xrl.us/b7fta

   Rafaël Garcia-Suarez took Renée Bäcker's patch to make "perldoc -q
   slurp" do something useful.

     no more bug #8806
     http://xrl.us/b7ftc

   Steve Peters idly wondered if there was a VAX Ultrix box alive
   somewhere. If so, it would help solve bug #17146.

     stalled until further notice
     http://xrl.us/b7fte

   Renée Bäcker found a series of tickets in RT that could be closed. But
   when I went to look, Rafaël had already beaten me to it.

     i feel inferior today
     http://xrl.us/b7ftg

   Renée also noticed, regarding bug #19388, that the behaviour changed
   in Perl 5.10.

     but is it any better?
     http://xrl.us/b7fti

   Shlomi Fish announced that he was revamping the Perl FAQs. Rafaël
   directed him to the "perlfaq-workers" mailing list.

     http://xrl.us/b7ftk

Last week's summary

     This Week on perl5-porters - 25-31 May 2008
     http://xrl.us/b7ftn

About this summary

   This summary was written by David Landgren.

   Weekly summaries are published on http://use.perl.org/ and posted on a
   mailing list, (subscription: perl5-summary-subscribe@perl.org). The
   archive is at http://dev.perl.org/perl5/list-summaries/. Corrections
   and comments are welcome.

   If you found this summary useful, please consider contributing to the
   Perl Foundation or attending a YAPC to help support the development of
   Perl.

-- 
stubborn tiny lights vs. clustering darkness forever ok?

• This Week on perl5-porters - 1-6 June 2008 by David Landgren
• RE: This Week on perl5-porters - 1-6 June 2008 by Jan Dubois
• Re: This Week on perl5-porters - 1-6 June 2008 by Barrie Slaymaker
• RE: IPC::Run [was: This Week on perl5-porters - 1-6 June 2008] by Jan Dubois
• Re: IPC::Run [was: This Week on perl5-porters - 1-6 June 2008] by Craig A. Berry
• Re: IPC::Run [was: This Week on perl5-porters - 1-6 June 2008] by Nicholas Clark
• Re: IPC::Run [was: This Week on perl5-porters - 1-6 June 2008] by John E. Malmberg
• Re: IPC::Run [was: This Week on perl5-porters - 1-6 June 2008] by Nicholas Clark
• Re: IPC::Run [was: This Week on perl5-porters - 1-6 June 2008] by John E. Malmberg
• Re: IPC::Run [was: This Week on perl5-porters - 1-6 June 2008] by Barrie Slaymaker
• Re: IPC::Run [was: This Week on perl5-porters - 1-6 June 2008] by Nicholas Clark
• Re: IPC::Run [was: This Week on perl5-porters - 1-6 June 2008] by Nicholas Clark
• Re: This Week on perl5-porters - 1-6 June 2008 by Ed Avis
• Generic system() replacements (was Re: This Week on perl5-porters- 1-6 June 2008) by Paul Fenwick
• Re: Generic system() replacements (was Re: This Week on perl5-porters - 1-6 June 2008) by David Golden
• Re: Generic system() replacements by Paul Fenwick
• RE: Generic system() replacements by Jan Dubois
• Win32 exit values (was: Generic system() replacements) by Paul Fenwick
• RE: Win32 exit values (was: Generic system() replacements) by Jan Dubois
• Re: Win32 exit values (was: Generic system() replacements) by Craig A. Berry
• Re: Win32 exit values by John E. Malmberg
• Re: Generic system() replacements by Paul Fenwick
• Re: Generic system() replacements by Dr.Ruud
• Re: Generic system() replacements by Aristotle Pagaltzis
• Re: Generic system() replacements by Paul Fenwick
• Re: Generic system() replacements by Aristotle Pagaltzis
• Why $@ makes me cry (was Re: Generic system() replacements) by Paul Fenwick
• Re: Why $@ makes me cry (was Re: Generic system() replacements) by David Nicol
• Re: Why $@ makes me cry (was Re: Generic system() replacements) by Paul Fenwick
• Re: Why $@ makes me cry (was Re: Generic system() replacements) by Bram
• Re: Why $@ makes me cry (was Re: Generic system() replacements) by Juerd Waalboer
• Re: Why $@ makes me cry (was Re: Generic system() replacements) by Abigail
• Re: Why $@ makes me cry (was Re: Generic system() replacements) by Mark Mielke
• Re: Why $@ makes me cry (was Re: Generic system() replacements) by Aristotle Pagaltzis
• Re: Why $@ makes me cry (was Re: Generic system() replacements) by Mark Mielke
• Re: Why $@ makes me cry (was Re: Generic system() replacements) by Mark Mielke
• Re: Why $@ makes me cry (was Re: Generic system() replacements) by David Nicol
• Re: Why $@ makes me cry by Dr.Ruud
• RE: Why $@ makes me cry (was Re: Generic system() replacements) by Jan Dubois
• Re: Why $@ makes me cry (was Re: Generic system() replacements) by Graham Barr
• Re: Why $@ makes me cry (was Re: Generic system() replacements) by Mark Mielke
• Re: Why $@ makes me cry by merlyn
• Re: Why $@ makes me cry (was Re: Generic system() replacements) by David Nicol
• Re: Why $@ makes me cry (was Re: Generic system() replacements) by Abigail
• Re: Why $@ makes me cry (was Re: Generic system() replacements) by Ben Morrow
• Re: Why $@ makes me cry (was Re: Generic system() replacements) by David Nicol
• Re: Why $@ makes me cry (was Re: Generic system() replacements) by Aristotle Pagaltzis
• Re: Why $@ makes me cry (was Re: Generic system() replacements) by Aristotle Pagaltzis
• Re: Why $@ makes me cry by merlyn
• Re: Why $@ makes me cry by Aristotle Pagaltzis
• Re: Why $@ makes me cry by Paul Fenwick
• Re: Why $@ makes me cry by Aristotle Pagaltzis
• Re: Why $@ makes me cry by Paul Fenwick
• What if $@ was block-local? (was: Re: Why $@ makes me cry) by merlyn
• Re: What if $@ was block-local? (was: Re: Why $@ makes me cry) by David Nicol
• Re: What if $@ was block-local? (was: Re: Why $@ makes me cry) by Abigail
• Re: Why $@ makes me cry by Dave Mitchell
• Re: Why $@ makes me cry by Ben Morrow
• Re: Why $@ makes me cry by Dr.Ruud