This Fortnight on perl5-porters - 13-27 April 2008

This Fortnight on perl5-porters - 13-27 April 2008

   "Perl simply isn't broken enough. Most things work too well, hence
   no-one finds that they need to fix their itch, so in turn, they don't
   get sucked into core development generally. Maybe we need to start
   adding bugs, somewhat like a protection racket."

       "Your program works very nicely. It would be a shame if something
       went wrong with it, wouldn't it? ..."

   -- Nicholas Clark, on possible future revenue schemes.

Topics of Interest

Perl @ 33536

   Nicholas Clark followed up on the 5.8.9-tobe thread, regarding binary
   compatibility, pointing out that the entire 5.8 line had never needed
   to rearrange struct layouts, so clearly it's not much of a limitation.

   He thought that forcing a layout reshuffle between each minor release
   sounded like quite a bit of work; Jan Dubois noted that all one needed
   to do was to roll the first member around to the end, which is easy,
   and has the added bonus of guaranteeing that the offset of every
   single member changes.

     challenge their assumptions
     http://xrl.us/bj2sx

Banishing "free to wrong pool", and making Win32 faster?

   Nicholas then related the details of a discussion he had with Dave
   Mitchell concerning the viability of a copy-on-write scheme. The main
   stumbling block is the need for threaded perls to track which
   interpreter allocated a given block of memory, since only the true
   owner should free it.

   This would mean that every single SV needs an extra pointer to link
   back to the parent interpreter, on top of the extra counter needed to
   keep track of the current copy count.

   So Nicholas went exploring to find out if there was another way to
   determine to which parent a block belonged. After studying things for
   a while he came to the conclusion that between util.c and malloc.c,
   the necessary infrastructure already exists to acquire large blocks of
   memory from the system and then allocate it on an as-needed basis as
   program executes.

   And then he was struck by the fact that this could be useful right
   now, without waiting for a copy-on-write scheme to be written, since
   the above could be used to both speed up Win32's slow "malloc"
   performance and speed up (or at least simplify) thread destruction.

   Another brilliant piece of detective work by Nicholas that, alas,
   attracted no comments.

     http://xrl.us/bj2sz

Taint (PL_tainting, SvTAINTED_on, SvTAINTED_off, SvTAINT)

   Nicholas also took the time to examine Paul Fenwick's reasons for
   dismay with the way tainting can be turned on part way through a
   program and offered a number of answers to Paul's questions.

   By using Sam Vilain's git repository back to the dawn of time, he was
   able to show that the current behaviour was introduced during 5.000
   alpha 4.

     http://xrl.us/bj2s3

Sustaining Perl 5 maintenance

   Nicholas also related a conversation from Real Life (see, the man does
   have a Life) where Leon Brocard asked whether there were enough people
   working on Perl 5, and Nicholas's flat answer was... no.

   The inescapable fact is that working on a codebase that is over twenty
   years old is not fun, it's work. Even taking care of patches people
   send in and shepherding them to completion is work. A back of the
   envelope calculation gives 8 person-work-days, per week, just to stand
   still.

   The grant scheme is not working. Expert Perl users know how to skate
   around the weird parts of the language (or give them a wide berth).
   Companies don't see the need to finance Perl development.

   At the very least, a bug-wrangler who could keep track of bugs, tie
   related bugs together, filter out not-a-bugs, write TODO tests, write
   tests to improve coverage... well, it's a full-time job. And not fun.
   At least not always. Hardly ever.

   Dave Mitchell pointed out that a seemingly innocuous bug report about
   a "premature free" error turns out, after a long debugging session, to
   be another case of a design decision embedded in the code base many
   years ago, at which point there's very little to be done about it.
   This sort of bug cannot be dealt with by a junior coder, lest they
   quickly lose their mind, or at least become quickly discouraged.

   Sven Dowideit gave thanks for the Git repository, which made life much
   easier compared to the previous Perforce export via rsync approach. In
   which case one of the goals for switching over to git has already been
   met.

     life support
     http://xrl.us/bj2s5

Updated Perl Git, with the Git Nits Picked

   Sam Vilain, on the subject of the Perl Git, announced that he had
   cleared up all the problems outstanding with the first release of the
   repository and said that the current repository would likely be the
   definitive one.

   Rafael Garcia-Suarez announced that his company, booking.com, had
   offered the bandwidth and hosting for the repository, and it would
   live under the perl.org domain. He said that the move to git will take
   place once 5.8.9 is out the door and so in the meantime Sam will have
   to continue to import the Perforce changes.

     git.perl.org
     http://xrl.us/bj2s7

www.osscensus.org

   Andy Armstrong mindlessly propagated a link to a web site that
   purports to perform a census on the adoption of open-source software,
   and was keen to find out how Perl fared.

   Apparently one has to download a 44Mb Ruby application as part of the
   process.

     that's the easy part
     http://xrl.us/bj2s9

t/test.pl taint issue with VMS

   John E. Malmberg returned to the issue of $ENV{PATH} being tainted on
   VMS and there being no way to untaint it in order to allow test.pl to
   execute "runperl". Part of the problem is that $ENV{PATH} need not
   even exist on VMS, and things will work just fine without it.

   He recalled that the issue worked if PATH was defined beforehand but
   couldn't track down the original discussion on the matter.

     finding your way
     http://xrl.us/bj2tb

Wrong line numbers in "elsif()"

   This one's been around for a *looong* time and now, finally, it may be
   time to retire advice #11943 from Klortho.

   Nicholas Clark took another look at it and decided that it would make
   a lovely opener for the Vienna Summer of TODOs project. Then when he
   took a closer look, he thought of a trivial solution that just might
   work after all.

   He wrote up the new TODO, and within 12 hours, Rafael Garcia-Suarez
   had written and applied a patch to implement Nicholas's idea.
   Unfortunately it skewed another line numbering result. So he committed
   a better change (#33710). Nicholas wondered whether Rafael was going
   to fix each TODO he attempted to propose as worthy of a bounty.

   Bram wondered if this was related to bug #47632, and asked whether the
   fix could be extended to resolve a variation on the theme (of
   reporting incorrect line numbers).

   Tim Bunce was very pleased, because an unexpected benefit that came
   out of this was that all line-based execution profilers picked up the
   improvement for free.

   Paul Johnson saw that "Devel::Cover" was flummoxed by the change, but
   he noted happily that the test suite was reporting the error in an
   appropriate way which should simplify the fix. He also saw that
   "B::Deparse" got a little confused as well and offered a patch to fix
   that up.

     "Ah yes, and you are the first person to have
     noticed this bug since 1987. Sure."
     http://xrl.us/bj2td

   The above work thus allowed Rafael Garcia-Suarez to announce that the
   bug "if ... elsif" gives wrong line number for warning about undefined
   value (#37302) was hereby fixed.

     so backport it
     http://xrl.us/bj2tf

valgrind

   H.Merijn Brand took valgrind for a spin on his Text::CSV_XS module to
   see what happened. In the process he discovered that it works better
   if you have a perl built with "-DDEBUGGING", but a module written by
   Rafael ("Perl::Destruct::Level") partially obviates the need.

   Marvin Humphrey explained what good valgrind figures should look like
   and made some suggestions to reduce the numbers H.Merijn was seeing.
   Vincent Pit asked whether his brand new "Test::Valgrind" would be of
   any use, and this caught Marvin's attention.

     the daily grind
     http://xrl.us/bj2th

"ExtUtils::CBuilder" with MinGW on Win32

   Steve Hay asked about the status of "ExtUtils::CBuilder" (or more
   specifically, the differences between the CPAN version, the
   development version in its Subversion repository and blead). When all
   was said and done, version 0.23 made it out to CPAN and this contains
   the MinGW fixes that will clean up Steve's smokes.

   On the other hand, the blead version still contains some VMS-specific
   fixes that need to be merged back into the development version of the
   module to get everyone in synch.

     whither 0.24?
     http://xrl.us/bj2tj

Object ~~ overloading and not

   Ricardo Signes reminded the porters about the perils of

     $anything ~~ $obj_without_overload

   and wrote a test case to try and nail it down. But something went
   wrong and he had a core dump on his hands. Rafael took over and
   cleaned everything up so that we know have a nicely-behaved TODO test.

     http://xrl.us/bj2tm

   In other news, he also wrote a testcase as a followup to the "Array ~~
   Any" discussion, but this appears to have been overlooked.

     http://xrl.us/bj2to

Support mallocs of struct T containing struct S[N]

   In his continuing explorations of slab allocations, Jim Cromie offered
   a patch to allow structs with arbitrarily-sized arrays of structs to
   be allocated easily.

   This was a follow-up to his Warnocked patch at the beginning of the
   month dealing with exposing the ptr-table subsystem, on the grounds
   that it offered a speed boost to XS authors. It turned out that
   freeing ptr-tables was very slow, and so switching to a slab allocator
   would simplify the freeing, since one could just throw the slab away.
   But for that to work, one needed to be able to calculate the overall
   required size needed for variable length allocations.

   Those who were sufficiently well versed in the finer details of the C
   standard pointed out that not many current compiler implementations
   had implemented this part of the standard, which appears to have
   compromised the acceptance of the patch.

     unwarranted chumminess with the C implementation
     http://xrl.us/bj2tq

Why is Ruby on Rails so darn slow?

   A long digression about the relative merits of speed and usefulness of
   Perl, Ruby and Java, inspired by a web article written by Tim Bray.

     not much porting going on
     http://xrl.us/bj2ts

Perl 5.10 and the concept of stable

   Alberto Simões learnt that Slackware 12.1 was about to be released,
   and it is set to go with 5.8.8 rather than 5.10.0.

   When he enquired as to why this was, he was told that according to the
   documentation on cpan.org, 5.10.0 is considered a testing release, and
   thus not suitable for general deployment (as in being bundled with a
   Linux distribution).

   Matt S. Trout warned that anyone into Catalyst will run into problems
   with attributes on an unpatched 5.10.0. Reini Urban had several
   patches for Cygwin that had to make it back in.

   The fact that "given"/"when" and smartmatch have problems was brought
   up again, and a call was made for someone to go through the archives
   and track down the exact issues (which occurred during my summary
   sabbatical, sorry).

   If a concise explanation can be made and a concensus can be reached as
   to what the desired behaviour is, Dave Mitchell, Matt S. Trout and
   Ricardo Signes offered to put in the work to get it done.

     smartmatching the concept of stable
     http://xrl.us/bj2tu

   Matt S. Trout reiterated the call for information.

     http://xrl.us/bj2tw

Any takers for "Math::Complex"/"Math::Trig" and "Time::HiRes"?

   Jarkko Hietaniemi put the maintenance of these dual-life modules on
   offer, citing lack of time to be able to devote the required tuits to
   shepherd them along. Zefram offered to take them over, since they were
   already of interest to him.

     time for some maths
     http://xrl.us/bj2ty

Bug or not? constants warn only once

   Nicholas was surprised that the following code only produces one
   warning:

     perl -lwe 'sub pie {print 0 + "pie"}; pie; pie;'

   An even simpler variation on theme also didn't produce subsequent
   warnings and one could argue that it should. The problem is that the
   expression gets marked as valid numerically (or more precisely, "IOK"
   gets set) after the first time through (and issuing a warning) whereas
   the second time around the numeric context is used directly, thereby
   skipping the chance for the warning to fire.

   Jan Dubois therefore observed that this was the equivalent of saying
   that "IOK" should be not be set if the conversion generated a warning.

   Abigail ventured the opinion that one warning was enough, and that if
   the problem the warning was signalling was so important as to merit
   repeated warnings about the same problem, then the warning should have
   been an error in the first place.

   In the end, Nicholas suggested a series of tests to codify the
   behaviour and asked people to see if any loose ends needed to be tied
   up.

     have your say
     http://xrl.us/bj2t2

One less "File::Copy" bug

   Nicholas fixed up the very silly bug that allowed one to copy a file
   using a buffer of 0 bytes, which is only useful if you want 0 bytes in
   the copied file.

   The conversation then veered into a discussion about the fact that
   "File::Copy" doesn't respect file permissions and attributes, and
   other generally unhelpful problems the module has.

     it's ok to ask the OS to do it
     http://xrl.us/bj2t4

New perl packages fix denial of service (Debian)

   Spiros Denaxas wanted to know if the porters were aware of a Debian
   security issue concerning buffer overflows in regular expressions
   containing Unicode characters.

   Tony Cook replied that there was an open ticket (#48156) on the issue
   in the bug database.

     http://xrl.us/bj2t6

On the almost impossibility to write correct XS modules

   Marc Lehmann wrote an impassioned plea to see what could be done about
   helping XS modules work correctly with Unicode strings.

   The first problem is that the raw interface to a string ("char *") is
   useless, since there is no side channel to tell the XS code what
   encoding is in use.

   In reaction to this, some XS authors have invented their own XS
   typemaps to get around the problem, however this can result in objects
   being stringified.

   The only way out that Marc could see was to take a mortal copy of the
   input argument. Rafael thought that it might be possible to invent a
   more efficient mechanism, if only syntactically.

   Marc stressed that the problem with the current situation is that when
   people encounter the problem on their own, they wind up learning about
   the utf-8 flag and begin to play around with that, and this leads to
   only more tears. Hence, if Perl wants to get really serious about
   Unicode, it needs to be addressed in a sane manner for XS.

     http://xrl.us/bj2t8

INSTALLDIRS and dual-life modules

   Paul Marquess inquired about the right way to deal with CPAN updates
   overwriting core versions of modules correctly. By default, the CPAN
   shell will carefully install the new version in an @INC directory
   listed after the core version (also known as shadowing). The trick is
   to specify an override in the "Makefile.PL" (or "Build.PL") of the
   CPAN module.

   Rafael wondered if there was a problem with the core installing files
   in architecture-dependent directories when in fact they should be
   installed in architecture-independent directories, and whether it was
   because of some blanket assumption about the modules living under ext/
   in the codebase.

     http://xrl.us/bj2ua

Closing tickets in RT

   Bram trawled through RT and found close on a dozen tickets that he
   thought could be closed. So Steve Peters closed them. For another
   ticket concerning AIX, H.Merijn Brand suggested a hint that checks
   that the maths library is available.

     http://xrl.us/bj2uc

Linking with "DynaLoader" and "ExtUtils::Embed::ldopts" since 5.10

   Reini Urban reported that linking against DynaLoader had become quite
   difficult since the release of 5.10, due to changes in the way various
   linker symbols were exposed where. Rafael pointed to the exact change
   to help Reini understand what was going on.

   Nicholas Clark thought that a test or two wouldn't go astray.

     http://xrl.us/bj2ue

Smoking bleed @33752 blew up my system

   Johan Vromans had the misfortune to smoke change #33752, which was
   perfectly bracketed by change #33751, which introduced a bug into the
   forked debugger code that was then reverted by change #33753.

   Unfortunately the bug caused the smoker log file to fill up the
   remaining disk space with an endless loop of debugger output.

     you have been warned
     http://xrl.us/bj2ug

TODO of the week

   Hey! We got a bite! James Bence wrote a patch to make a reproducible
   perlmodlib.PL. Note to budding TODO doers: please use unified diffs
   for sending patches ("diff -u", or the more melodious "diff -dub").

     smoke that
     http://xrl.us/bj2ui

   Next up, I think the following two TODOs are dids.

   Improving "threads::shared"
       Investigate whether "threads::shared" could share aggregates
       properly with only Perl level changes to "shared.pm".

   "POSIX" memory footprint
       Ilya observed that "use POSIX" eats memory like there's no
       tomorrow, and at various times worked to cut it down. There is
       probably still fat to cut out - for example POSIX passes Exporter
       some very memory hungry data structures.

   I believe that the first issue, if anything can be done about it, is
   receiving the appropriate amount of care from Jerry D. Hedden. And the
   second issue has been resolved with Nicholas Clark's new
   implementation for constant subs.

   Here, then, is a TODO that requires a little C knowledge:

Weed out needless "PERL_UNUSED_ARG"

   The C code uses the macro "PERL_UNUSED_ARG" to stop compilers warning
   about unused arguments. Often the arguments can't be removed, as there
   is an external constraint that determines the prototype of the
   function, so this approach is valid. However, there are some cases
   where "PERL_UNUSED_ARG" could be removed. Specifically

   *   The prototypes of (nearly all) static functions can be changed

   *   Unused arguments generated by short cut macros are wasteful - the
       short cut macro used can be changed.

Patches of Interest

perlfunc.pod: "atan2(0,0)" returns 0, not "undef"

   The porters continued to study the holy scriptures (that is, the C
   standard) this past fortnight to figure just what was the best thing
   for "atan2(0,0)" to return. Rafael Garcia-Suarez boldly went where no
   pumpking had gone before, and declared with change #33676 that it
   should return "undef". And almost immediately began to have second
   thoughts.

   Andy Dougherty opened another can of worms and asked if we should also
   be checking for things like ±0. But it seems that, buried in the
   Configure infrastructure, we already do.

     an error shall not occur
     http://xrl.us/bj2uk

Allow "->[]" and "->{}" instead of "@{}" and "%{}"

   Ben Morrow delivered an amazing hack to the parser to allow "$x->[]"
   (currently a syntax error) to be semantically equivalent to @$x, and
   this comes in handy when $x is a complex hash-array-hash-hash-array
   dereference.

   Rafael Garcia-Suarez commended Ben on the patch, and asked for a)
   tests and b) whether "qq{$x->p[]}" worked, since the latter involves
   working with the scarier parts of the lexer.

   One problem that arose with builtins and there prototypes is that the
   lexer really, really, *really* wants arrays to begin with a "@" sigil.
   Nevertheless Ben came back with another iteration of the patch that
   solved that problem, by pushing the is-it-an-array decision from the
   lexer into the various ops. As a bonus this slims the "PL_parser"
   struct, and shaves off an op here and there.

   Other people admitted to being a bit disturbed by the patch, citing
   that it added some inconsistencies to the language that were a little
   too weird to explain away with mere hand-waving.

   Jonathan Rockway pointed out that this doesn't help the matter of
   protecting array dereferences from blowing up by guarding it with an
   empty list as in

     @{ $might->{be}{undef} || [] }

   This moved Nicholas Clark to say that autovivification would be less
   inconsistent if @$x, where $x is undef, returned an empty list. This
   garnered a certain amount of agreement, but Graham Barr pointed out
   that code that dereferences "undef" expecting something good to happen
   is probably buggy.

   Aristotle Pagaltzis thought that "autobox::Core" already provides a
   satisfactory solution to retrofitting a saner syntax onto Perl 5, and
   for anything beyond becomes the realm of Perl 6.

   People asked again why it was that "autobox" wasn't in core, and
   Nicholas Clark did such a wonderful job of summarising the debate that
   it deserves its own entry right here:

     http://xrl.us/bj2un

   Matt S. Trout wrapped up the thread to say that new, exotic syntax
   bending must first of all prove itself as a distinct CPAN module, and
   only afterwards should it move into core. And if it can't be done
   without patching the core itself, then the core needs to expose more
   hooks so that such syntax extensions can be made. Which is sort of the
   argument for putting autobox in the core, but like David Nicol says,
   the name is strange, or at least esoteric, and possibly it leads us to
   the Dark Side Of Laziness.

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

Linking to Better Alternatives from core modules

   Shlomi Fish suggested adding SEE ALSO references from core modules to
   other modules available on CPAN that solve the issue in better ways.

   A number of people took issue with the subjective slant of "better"
   and thought that "alternative" would be, well, better.

   One of the suggested modules, in relation to "File::Spec" was
   "Path::Class", but Sébastien Aperghis-Tramoni mentioned that he had
   modified a number of programs at work in this very way, but had to
   roll back the changes due to unexpected interactions between
   "Path::Class" and other non-Path::Class-aware modules on CPAN.

     http://xrl.us/bj2ur

perlbugging non-core modules

   Alexandr Ciornii continued to enhance "perlbug" to warn the user if
   they tried to report a bug in a non-core module. Perhaps part of the
   reason that no-one commented was that he leveraged CPAN.pm to do the
   heavy lifting, which makes for one more thing to go wrong.

     and Module::Corelist?
     http://xrl.us/bj2ut

Fix several problems in "a2p"

   Gregg Weber delivered a patch to fix no less than seven problems in
   "a2p", the awk-to-Perl convertor, as well as the smarts to deal with
   two modern awk language extensions. Tels thought that the patch had
   been inverted, but other than that the patch attracted no comments.

     http://xrl.us/bj2uv

"gcc -foptimize-sibling-calls" cause trouble for perl's signal handler

   Gisle Aas reported that the above switch will cause gcc 3.3 to emit
   incorrect code. This can be patched by adding an explicit return
   statement at the end of the C function that causes the problem.

   Another alternative would be to arrange the build process to not apply
   the -foptimize-sibling-calls switch when compiling mg.c.

     http://xrl.us/bj2ux

New and old bugs from RT

Clearing magic (was: "length($@)>0" for empty $@ if utf8 is in use) (#51370)

   Animator took a stab at resolving this bug report that details how
   magic associated with $@ persists long after the need has gone, and
   proposed a series of approaches all deficient in one way or another
   until finally hitting what looked like the right one.

   Rafael thought the result looked correct, but thought that some more
   testing would be needed, and also wondered if there was a more concise
   way of achieving the same result (rather than 8 lines of code).

   Bram wondered what could be tested, and how to do it. chromatic
   couldn't think of anything better than scraping the output of
   "Devel::Peek".

     ye gods, Devel::Peek::XML?
     http://xrl.us/bj2uz

"Scalar::Util::looks_like_number" *versus* Optimzation in regexp (#51568)

   Nicholas Clark situated the error within "Scalar::Util" and prodded
   Graham Barr to integrate the change (or something that meets with his
   favour) upstream, then it could be merged back into the core
   afterwards.

     c'est utile
     http://xrl.us/bj2u3

Warn/abort on attempted perl exit (#52000)

   Animator suggested overriding the core "exit" built-in function with
   an appropriately verbose equivalent. John Gardiner Myers was doubtful
   as to whether that would help in his situation, since things were
   exiting due to memory allocation failures.

     last exit to prompt
     http://xrl.us/bj2u5

Segfault on ISA push after symbol table delete (#52074)

   Rafael fixed up the segfault by ensuring that the deleted stash stays
   dead, but wondered what the appropriate behaviour should be when asked
   to act upon a stash that is no more.

   No clear concensus (between Nicholas, Rafael and Graham Barr) arose,
   perhaps because in the end this is just another case where the experts
   just say "yeah well things are a little weird around this part, so
   don't venture out too far", and move on to other matters.

     doesn't crash == good enough
     http://xrl.us/bj2u7

Perl 5.10 regression bug in match and substitution evaluation in list 
context (#52658)

   Rafael backed out the optimisation that Yamashino Hio had written
   (that sped up "s///e" substitutions by freeing intermediate
   temporaries).

     choose correctness
     http://xrl.us/bj2u9

Incorrect variable name in perlintro (#52860)

   Matt Kraai spotted an error in the documentation where the dubious $a
   and $b had been replaced by ordinary $x and $y variables, except not
   entirely.

     http://xrl.us/bj2vb

Invalid "cop_free" of nullified cop (#52920)

   While testing "B::C", Reini Urban discovered that nulled opcodes were
   being freed. He proposed a straight forward patch that addressed the
   symptoms, but wondered if another more subtle patch might be a better
   approach. Then he realised it was "B::C" itself generating spurious
   data that could never be produced by the core, thus there was no cause
   for alarm.

     good cop, bad cop
     http://xrl.us/bj2vd

   In other discussions, Rafael added some code to the core to keep an
   eye out for these sorts of shenanigans.

     never can be too sure
     http://xrl.us/bj2vf

map leaks memory (#53038)

   Robin Redeker reported that "while (1) {map 1, 1}" leaks memory. Bram
   wondered if this was bug #48004 in another guise. Shlomi Fish
   confirmed a leak under valgrind. Nicholas Clark used a machine with
   real hardware watchpoints to pin-point exactly where the leak was
   occurring, but was then not quite sure if it was more an issue of
   particularly delayed house-keeping, rather than a leak *per se*.

     http://xrl.us/bj2vh

UTF-8 converted to Latin1 for output with format incorrect output (#53054)

   Michael Koehn submitted a detailed report where UTF-8 being converted
   to Latin1 in a Perl format went wrong. His workaround was to use an
   explicit "encode" on the data.

   Alexandr Ciornii confirmed the problem exists with 5.10 on Windows.

     http://xrl.us/bj2vj

Modifying $_ inside "given" (#53186)

   Ed Avis was bitten by the fact that "given" takes a copy of its value
   that is in turn passed to $_ for use in "when" statements. Paul
   Fenwick pointed out that if one used "for" instead of "given" then one
   could indeed obtain the desired aliasing behaviour.

     forgiven
     http://xrl.us/bj2vm

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

   A bug report that attracted no comments.

     double free or corruption
     http://xrl.us/bj2vo

Stop t/op/fork.t relying on "rand" (#53238)

   David Dick noticed that some failures for testing "fork" involved the
   parent and child processes generating a random number. Since the
   generator wasn't explicitly seeded, it turns out that every once in a
   while both processes would generate the same number and the test would
   consequently fail.

   David wrote a patch to ensure that the numbers are always different,
   and Rafael applied it.

     that must have been hard to reproduce
     http://xrl.us/bj2vq

perl-5.10.0-33733 assertion with JSON::XS-2.2 (#53244)

   David Favor reported a failure in "JSON::XS" on the maintenance track
   of 5.10. Nicholas Clark suggested a patch to fix "JSON::XS". Marc
   Lehmann was surprised as it seemed to him that "SvCUR" could no longer
   be used as previously, and thought that many other modules could be
   prone to the same sort of failure.

   Jan Dubois was surprised as it seemed to him that people shouldn't be
   using "SvCUR" unless "SvPOK" was known to be true. Marc still thought
   it was a regression.

     http://xrl.us/bj2vs

Trying to build perl5.8.3 under Maemo environment (#53328)

   Devendra Purbiya reported a problem with a "getcwd" call failing
   miserably. Sébastien Aperghis-Tramoni suggested that the first thing
   to try would be to use a more modern release, such as 5.8.8 or 5.10.0,
   which may fix the problem due to fixes made since 5.8.3 was released
   (over four years ago).

     http://xrl.us/bj2vu

Error on Configure PERL 5.8.6 on HP platform " pthread:  not found." 
(#53330)

   Alexandra Bacher also reported having problems building a slightly
   more modern perl from source on the HP platform. H.Merijn Brand
   enquired as to whether there was a reason she didn't want to a
   precompiled bundle.

     http://xrl.us/bj2vw

Parse problem in Switch.pm (#53414)

   Another bug report from the module that would not die.

     rrrrr, chainsaw, rrrrrrrrr
     http://xrl.us/bj2vy

Perl5 Bug Summary

   In the second week we saw a welcome decline of 4 tickets, although
   sadly not enough to make up for the difference of 9 new tickets the
   previous week.

     296 + 1524 = 1820 (+11 -2)
     http://xrl.us/bj2v2

     293 + 1523 = 1816 (+6 -10)
     http://xrl.us/bj2v4
     http://rt.perl.org/rt3/NoAuth/perl5/Overview.html

This is the BBC

   Devel::Cover
       Now fixed in 0.64

         http://xrl.us/bj2v6

New Core Modules

   Compress::Zlib, IO::Compress::*
       Paul Marquess synched blead with the latest compression modules
       available on CPAN.

         2.009
         http://xrl.us/bj2v8

   Math::BigInt
       Tels released v1.89, closing out 4 tickets in the process.

         http://xrl.us/bj2wa

   Win32
       Jan Dubois uploaded 0.36 to CPAN, and Steve Hay synched it with
       blead. Not much more than a few tweaks to make it behave nicely
       when compiled in 64-bit land.

         http://xrl.us/bj2wc

In Brief

   Reini Urban found the time to figure out Tels's sins with
   "Devel::Size" and bleadperl, and wrote a patch to fix it up.

     all part of the service
     http://xrl.us/bj2we

   Brian Greenfield announced that he had taken up smoking.

     http://xrl.us/bj2wg

   Reini Urban updated the Perl 5 wiki with a summary of hints for
   distributors wishing to distribute Perl with their operating system.

     comments welcome
     http://xrl.us/bj2wi

   Dave Mitchell wanted to know if it there was anything preventing the
   inclusion of "Test::Harness" 3.x in maint-5.10.x. Andy Armstrong
   thought it would be fine.

     and there was colour!
     http://xrl.us/bj2wk

   Aschwin van der Woude cross-posted a question from an spctools mailing
   list regarding a tpp_gui.pl forking problem. Tels wondered if the
   problem was due to /dev/null missing inside a "chroot" jail.

     http://xrl.us/bj2wn

   Adriano Ferreira synched blead with the ongoing developments of
   "Pod::Perldoc".

     http://xrl.us/bj2wp

   Robin Barker had another go at "[[:print:]]" *versus* "\p{Print}" that
   Rafael liked sufficiently to accept. (Bug #49302).

     documents and tests
     http://xrl.us/bj2wr

   Paul Fenwick wanted to know if he could use "%^H" in Perl 5.8.x,
   especially the upcoming 5.8.9. Nicholas Clark said no, and that it was
   unlikely that the 5.8 track would ever be able to.

     time to let go
     http://xrl.us/bj2wt

   Rafael applied a patch for perl5db.pl to get the forked debugger to
   work on Linux/Cygwin and reverted it after noticing it caused a
   failure in perl5db.t.

     back to the drawing board
     http://xrl.us/bj2wv

   Bram documented "perlrun -x".

     see bug #46369
     http://xrl.us/bj2wx

Last week's summary

     6-12 April 2008
     http://xrl.us/bj2wz

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.

• This Fortnight on perl5-porters - 13-27 April 2008 by David Landgren