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

This Week on perl5-porters - 27 January-2 February 2008

Thread Next
From:
David Landgren
Date:
February 7, 2008 10:07
Subject:
This Week on perl5-porters - 27 January-2 February 2008
Message ID:
47AB48E2.80806@landgren.net
This Week on perl5-porters - 27 January-2 February 2008

   "It's a very naive implementation [...]. Given the scary comments
   Nicholas added in that code, I'd be grateful to see whether one can
   come up with a case where that breaks" -- Rafael Garcia-Suarez,
   warning about warning about undef.

Topics of Interest

Integrating blead changes back to maint

   Some of the changes regarding Safe for 5.10 crept into the 5.8
   maintenance track during change #33111, and Jerry D. Hedden wondered
   if this was a bug or a feature. Nicholas Clark cursed Perforce but
   felt that it could all go into 5.8 in the long run.

     entering a zone of turbulence
     http://xrl.us/bfs2g

   Sure enough, black smoke emerged from the chimney of Steve Hay's lab.

     Smoke [5.8.8] 33111 FAIL(F) MSWin32 WinXP/.Net SP2 (x86/2 cpu)
     http://xrl.us/bfs2i

   Similarly, the integration of consting goodness in change #33119 also
   caused grief on Cygwin. Jerry wondered if the blead changes in #32681
   needed to be integrated as well.

     http://xrl.us/bfs2k

5.8.x "usemymalloc" failures

   In a discussion in a bug report (see #50352 below), it will be
   revealed that Perl's own "malloc" is usually faster than the "malloc"
   delivered with the C library. Jerry D. Hedden removed the
   "-Uusemymalloc" from his Cygwin build, thereby switching from the
   system "malloc" to Perl's, thereby gaining a boost in speed for free.

   He reported success for 5.10 and blead, but a few tests failed in 5.8.
   In fact, the error appears to be there as far as he was able to go
   back in history.

     there was a reason for this
     http://xrl.us/bfs2n

MM_Win32.t failures (caused by "PathTools" upgrade)

   Steve Hay noticed that the major rewrite to Win32's "catdir",
   "catfile" and "canonpath" caused major failures in
   "ExtUtils::MakeMaker" handling on Windows. The more Steve looked, the
   more he found the new behaviour confusing.

   Michael G. Schwern believed that part of the problem was the use of
   "catdir", when in fact "catpath" was what was called for (regarding
   the handling of "C:" as a volume specification).

   Ken Williams chalked it up as another case of ""File::Spec" is just
   hard to use correctly".

     but Path::Class makes it fun!
     http://xrl.us/bfs2p
     http://xrl.us/bfs2r

"next" resetting match variables - bug or feature?

   Nicholas Clark was puzzled by ext/B/t/deparse.t issuing a warning on
   5.10 but not on 5.11, and narrowed it down to what remained in a match
   variable at the beginning of a loop. There was a difference, depending
   on whether the loop had reached the end of its scope, or had been
   short-circuited via a "next".

     coming up next
     http://xrl.us/bfs2t

Make Perl Y2038 safe

   After the initial silence following Michael G. Schwern's plea to make
   Perl survive 2038, the thread kicked off in earnest this past week.

   Some people believed that it was just a question of having a 64-bit
   machine and 64-bit "time_t" datatype. To a certain extent, this is
   already the case for many platforms other than Unix, be they IBM
   mainframes, VMS minis or even Windows micros. In this case, 32-bit
   "time_t" quantities are shims over datatypes of greater precision,
   provided only for compatibility with Unix.

   The real problem is that of programs that store 4-byte "time_t"
   quantities in binary files. The other problem is with "localtime"
   which is currently specified for 32 bit quantities, which means that
   if the system can handle the year 2050 as an epoch, it might be unable
   to format it a readable manner. And one nice thing that "localtime"
   does, more or less for free, is to figure out which time zone you're
   in.

   Craig Berry suggested that the first step would be to plan some tests
   to check the results of date arithmetic that push past 2038, mark them
   as TODO, and then go about fixing them. It would seem evident that
   some %Config variables would be useful to help people determine what
   is implemented natively and what needs to be worked around.

   Mark Mielke pointed out that the "DateTime" modules are perfectly
   2038-safe, but you still run into problems if you try to map a
   DateTime value outside the 1970-2038 range onto an 32-bit epoch value.
   Unfortunately, for some people, it's just too slow.

   Aaron Crane gave a fascinating historical overview of time handling in
   Unix.

     TAI64 for attosecond precision, anyone?
     http://xrl.us/bfs2v

op/sprintf.t and op/write.t failures with mingw-runtime-3.14

   Rob "Sisyphus" observed incorrect "sprintf" behaviour with the latest
   MinGW runtime and wondered if anyone else had encountered the problem.
   He was hesitant to label it a MinGW bug, since simple C programs using
   "sprintf" worked as expected.

   Yitzchak Scott-Thoennes said that he'd heard that the MinGW developers
   had tweaked the behaviour of "vnsprintf", and that put Rob on the
   right track.

     bug, many eyes, shallow
     http://xrl.us/bfs2x

Patches of Interest

Fix "uc"/"lc" warnings in CGI.pm

   Now that "lc(undef)" issues a warning as it return an empty string,
   one of the first (no doubt of many) consequences was that "CGI"'s test
   suite issued a couple of warnings. Lincoln Stein folded the fix into
   his copy of "CGI".

     old horse, new tricks
     http://xrl.us/bfs2z

   At that point, Nicholas Clark noticed that there were some gratuitous
   differences between the core version and that on CPAN, and hoped that
   the porters and Lincoln could reconcile the differences. No word back
   from Lincoln as we went to press.

     get back together again
     http://xrl.us/bfs23

Unwanted warnings from "PerlIO::scalar"

   Ben Morrow produced a cut-down code sample that showed a spurious
   warning when opening a scalar as an output stream. He proposed a
   patch, but Hugo van der Sanden thought it would cause an overdose of
   magic.

     http://xrl.us/bfs25

Fix  regression in File/DosGlob.pm

   Alex Davies encountered a globbing problem in "File::DosGlob" and was
   amazed to discover that things had been like that since the year 2000.
   Steve Hay accepted the patch.

     http://xrl.us/bfs27

Don't forbid brace groups with g++ 4.2.2

   Robin Barker noticed that the restriction against using brace groups,
   that appeared in 2006 for versions of g++ available at the time, no
   longer seemed to be required for the current g++ 4.2. This in turn
   allowed other warnings that g++ issued over the *REFCNT_inc macros to
   go away. Rafael accepted the patch.

     http://xrl.us/bfs29

New and old bugs from RT

IRIX hints (#33849)

   Andy Dougherty came back with a new attempt to teach "Configure" how
   to the the right thing on the IRIX platform.

     over to you, Mr. Cantrell
     http://xrl.us/bfs3b

Safe and "use encoding 'utf8'" (#48419)

   Back in December, Ville Luolajan-Mikkola reported that trying to use
   "Safe" and "encoding :utf8" results in a fight, and the program loses.

   Rafael Garcia-Suarez suggested importing the needed methods into the
   Safe compartment might be a suitable work-around, but he was doubtful
   that Safe could be fixed safely.

     putting the accent on safety
     http://xrl.us/bfs3d

Newbie redirect error (#50266)

   James Nemanich stumbled across the RT queue and filed a bug about
   perl, not realising that in fact the bug was in his own code. People
   pointed him to Perlmonks, "Perl::Critic", pragmas "strict" and
   "warnings", the Learn Perl mailing list (empty message to
   "subscribe-learn@perl.org" if you want to help) and Alexandr Ciornii
   went as far as rewriting the original code in modern day, idiomatic
   Perl.

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

"CGITempFile" causes "Insecure dependency in sprintf" in perl 5.10.0 
(#50322)

   Steve Hay used "CGI" and uncovered a bug due to the fact that in 5.10,
   "printf" format strings are now considered tainted. In the case of
   "CGI", the routine in question reads the contents of an environment
   variable when composing the canonical name of the temporary file.

   Steffen Müller suggested a couple of fixes to resolve the issue, the
   first one being the least intrusive, the second one being more to his
   likely.

   Tim Jenness wondered why "CGI" didn't use "File::Spec->tmpdir"
   instead, since this particular wheel has already been invented over
   there.

     taint fun
     http://xrl.us/bfs3h

   Lincoln Stein stopped by to say that he was going to use Steffen's fix
   in an upcoming 3.33 release.

     still accepting patches
     http://xrl.us/bfs3j

Perl 5.10 "Storable" extremely slow for large trees of data (#50352)

   Clinton Pierce had a data structure that when dumped with
   "Data::Dumper", produced about 8Mb of output. The same structure takes
   less than a second to be dumped with "Storable", as long as perl 5.6
   is used. If perl 5.10 is employed instead, the time taken balloons out
   to 5 to 8 seconds.

   Naturally he wanted to know whether this was a bug. Nicholas Clark
   suggested he take the 2.18 version available on CPAN (which is bundled
   with 5.10) to see if there was any difference on 5.6 (thereby
   isolating the problem to the module or the core. Unfortunately Clinton
   was on a Windows box without a compiler. Fortunately, Steve Hay was
   around and he was able to compile 2.18 on 5.6, and confirmed the
   slowdown on both 5.8 and 5.10 (while 5.6 remained fast).

   After some more research, Steve reported that the choice of "malloc"
   (Perl's or the C library) made a very significant difference to the
   time taken. In both cases, Perl's own "malloc" was a couple of orders
   of magnitude faster. He noted that Activestate built their Perl
   distribution on Windows with the system "malloc" since it was a
   necessary precondition for their "fork" emulation.

   Curiously enough, Clinton's 5.6 installation was already using the
   system "malloc". No-one was able to pin down the precise reason for
   the slowdown, although it was likely that 5.8 and 5.10's full UTF-8
   implementation may be a culprit.

     fancy a strawberry?
     http://xrl.us/bfs3m

perlop.pod - misnomer in % operator documentation (#50364)

   Martin Becker suggested a more mathematically precise definition of
   the modulus operator, and provided a patch to prove it.

     unapplied
     http://xrl.us/bfs3o

unexpected "exit" in "open3()" on win32 (#50374)

   Alex Davies reported a curious set of circumstances that would cause
   "IPC::Open3" exit when you least expected it.

     this is a feature?
     http://xrl.us/bfs3q

"GIMME_V" broken with 5.10.0/GCC and XS (#50386)

   Robert May reported some strife with "GIMME_V" always returning
   "G_VOID" regardless of context with an Activestate perl and XS
   compiled with gcc. On the other hand, the same code compiled with VC++
   6 behaved as expected.

   Jan Dubois explained that this was due to a difference in how gcc and
   VC++ laid out their bitfields. It turns out that VC++ is rather
   profligate in its use of memory to store a number of bitfields, and
   Jan promised to deliver a patch that would allow VC to be more
   parsimonious in its memory consumption.

   Armed with this information, Robert was able to twiddle a switch on
   gcc to order it to lay out bitfields in an identical manner to VC++,
   which solved his immediate problem.

   Unfortunately, a blanket compiler switch override would then cause a
   gcc for a Strawberry Perl to compile his XS module incorrectly, and
   thus Rob needed to know how one could figure out what compiler was
   used to build the perl within a Makefile.PL. Jan suggested probing for
   values in the "Config" hash, as well as all you ever wanted to know
   but were too afraid to ask about distinguishing an Activestate build
   of perl from a perl built directly from source.

     http://xrl.us/bfs3s

   Jan followed up with a patch to lock down the underlying sizes used in
   constructing bitfields.

     http://xrl.us/bfs3u

"Filter::Util::Call" problem with $_ (#50430)

   Ambrus Zsban reported an oddity with an identity source filter (that
   is, one that doesn't transform anything). If he removed an innocuous
   assignment to $_, everything stopped working.

     deep filter voodoo
     http://xrl.us/bfs3w

Perl5 Bug Summary

   321 new + 1491 open = 1812 (15 created, 1 closed)

     http://xrl.us/bfs3y
     http://rt.perl.org/rt3/NoAuth/perl5/Overview.html

New Core Modules

   B-Generate 1.12_03
       Jim Cromie uploaded a development version of "B::Generate" that
       behaves correctly with 5.10 and 5.11 (although it segfaults on
       5.8). He was hoping to be made co-maintainer of the module, and
       had a couple of questions for the porters, although no-one
       ventured their opinion.

         http://xrl.us/bfs32

       He also had some special "B" portability macros fall out as a
       consequence of the above.

         http://xrl.us/bfs34

This is the BBC

   Devel-Cover-0.63
       "OP_SETSTATE" is no longer. Paul Johnson said he'd get around to
       fixing it.

         http://xrl.us/bfs36

   Devel-StackTrace-1.15
       Non-existent documentation leaves the implementation open to
       interpretation. Nicholas locked the implementation down and
       Devel::StackTrace had bet the wrong way. Dave Rolsky released 1.16
       to CPAN.

         http://xrl.us/bfs38

   Net-DNS-0.62
       The test file t/04-packet-unique-push.t failed in a build, but ran
       successfully within the debugger.

         the worst sort of failure
         http://xrl.us/bfs4a

In Brief

   John E. Malmberg commented that showing the pid when running under
   "-Dv" would be more useful if it were rendered as hex under VMS, since
   all the other VMS utilities do so. Craig A. Berry wondered if that
   just didn't make things more confusing compared to how Perl works on
   all the other platforms

     http://xrl.us/bfs4c

   Robin Barker's patch to silence compiler warnings about clobbering
   volatile C stack variables was deemed suitable by Rafael
   Garcia-Suarez.

     http://xrl.us/bfs4e

   Steven Schubiger's consting of util.c made it in.

     http://xrl.us/bfs4g

   He also added some consting tweaks to toke.c and universal.c, which
   Rafael applied.

     Andy would approve
     http://xrl.us/bfs4i

   He also managed to pull off a remarkable "const char *const str" in
   taint.c.

     http://xrl.us/bfs4k

   Moritz Lenz reported an issue that cropped up on Perlmonks, where a
   simple regexp ran 1.5 orders of magnitude more slowly on 5.10. Andreas
   König identified the problem as being change #27903, in which Dave
   Mitchell removed some recursion trickery. Neither Dave nor Yves Orton
   were around to comment on the issue.

     http://xrl.us/bfs4n

   Yitzchak found a code example in "POSIX" that had drifted out of focus
   and suggested how to make it work again. Applied.

     $b be banished
     http://xrl.us/bfs4p

   Steve Hay tidied up some compiler warnings on Win32, but Nicholas
   Clark came up with a better technique.

   Moritz may also have uncovered a problem building blead with a
   parallel make, although the jury is still out.

     http://xrl.us/bfs4r
     http://xrl.us/bfs4t

     change #33109 trumps change #33106
     http://xrl.us/bfs4v

   Scott T. Hildreth reported a segfault with "Term::ReadLine::Gnu".
   Rafael was inclined to think the problem was a signal handler issue
   and wondered if "libreadline" was to blame.

     http://xrl.us/bfs4x

   brian d foy was trying to clarify smart match behaviour in "when",
   when the "when" contained a "&&". He was troubled by differences in
   what the documentation said and what the implementation did.

     learning perl, TNG
     http://xrl.us/bfs4z

   Jerry D. Hedden todoified yet another "threads::shared" bug concerning
   a shared object that is attached to a shared scalar.

     http://xrl.us/bfs43

   The bug in "ExtUtils::CBuilder" not honouring "extra_compiler_flags",
   that leads to the "GIMME_V" problem was filed by Robert May as a
   ticket on the "ExtUtils::CBuilder" queue.

     http://xrl.us/bfs45
     http://rt.cpan.org//Ticket/Display.html?id=32806

   Daniel Frederick Crisman spotted a typo in a test name from last
   week's additions from Abigail regarding the test of "for reverse ...".

     http://xrl.us/bfs47

   Daniel also identified a possible POD markup error in the Japanese POD
   question last week.

     ceci n'est pas une pipe
     http://xrl.us/bfs63

   Robert May thought that the POD in encoding.pm talked about side
   effects far too much, so he dragged out the chain-saw and removed two
   duplicate sections.

     may cause drowsiness
     http://xrl.us/bfs49

   Reini Urban made some progress with his perl compiler project this
   week.

     just in time
     http://xrl.us/bfs5b

   Robin Barker noticed some sub-optimal POD formatting in "File::Find"
   with C<{ bydepth =E<gt> 1 }> and proposed an alternative.

     try writing that in POD
     http://xrl.us/bfs5d

   Nicholas Clark took a lateral thinking approach to solving the
   parallel make bug for "SDBM_File" by provoking the same error but in
   the "POSIX" module.

     but not all the time
     http://xrl.us/bfs5f

   Philippe Bruhat ran into a spot of bother trying to build 5.8.8 with a
   particularly recent version of the gcc compiler. Andy Dougherty and
   Andreas König gave him a couple of work-arounds, and Nicholas promised
   to make sure 5.8.9 (coming Real Soon Now) should have the fix.

     going by the book
     http://xrl.us/bfs5h

   Watching the smoke signals, failure reports came in from Steve Hay for
   Win32, as far as change #33169. No reports from other platforms.

About this summary

     last week's
     http://xrl.us/bfs5j

   Yitzchak Scott-Thoennes clarified the panic on copying a freed scalar:
   I thought the magic of @ARGV was part of the problem, Yitzchak said
   that any array at all will suffer the same erroneous behaviour.

     http://xrl.us/bfs5m

   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 to help support the development of Perl.



Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About