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.
http://xrl.us/bh4d5
Elsewhere, there was some idle chatter of converting everything to
UTF-8, but no resolution.
http://xrl.us/bh4d7
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.
http://xrl.us/bh4d9
"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.
http://xrl.us/bh4eb
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.
http://xrl.us/bh4ed
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
environment.
http://xrl.us/bh4ef
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
regen.pl 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
http://xrl.us/bh4eh
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.
http://xrl.us/bh4ej
This in turn led Michael G. Schwern to discover that there was
something wrong with open.pm 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.
http://xrl.us/bh4em
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)
http://xrl.us/bh4eo
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.
http://xrl.us/bh4eq
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.
http://xrl.us/bh4es
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.
http://xrl.us/bh4eu
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
contents.
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
http://xrl.us/bh4ew
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
http://xrl.us/bh4ey
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
built.
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.
http://xrl.us/bh4e2
"Perl_ck_op_sanity"
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.
http://xrl.us/bh4e4
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.
http://xrl.us/bh4e6
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.
http://xrl.us/bh4e8
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
system.
By the end of the week, things were cleaned up enough to give the
green light for the release of 5.8.9.
http://xrl.us/bh4fa
Testing madly
Gerard Goossen set about fixing up the errors with the Perl5-to-Perl5
conversion that the MAD infrastructure provides.
mad/t/p55.t
http://xrl.us/bh4fc
$[
http://xrl.us/bh4fe
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.
http://xrl.us/bh4fg
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.
http://xrl.us/bh4fi
Rever cygwin archname hints
Reini Urban reverted the archname tweaks on the Cygwin platform, the
main reason being to tidy up cpan-testers reports.
http://xrl.us/bh4fk
Lexical Fatal.pm and autodie.pm
Paul Fenwick delivered a first cut at lexically scoped fatalities. The
message thread, however, will be summarised next week.
ENOTIME
http://xrl.us/bh4fn
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.
http://xrl.us/bh4gb
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
effects).
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.
http://xrl.us/bh4gd
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.
http://xrl.us/bh4gf
"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.
http://xrl.us/bh4gh
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.
http://xrl.us/bh4gj
"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
http://xrl.us/bh4gm
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.
http://xrl.us/bh4go
"@-" 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.
http://xrl.us/bh4gq
"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.
http://xrl.us/bh4gs
Perl5 Bug Summary
290 new + 1502 open = 1792 (+10 -8)
http://xrl.us/bh4gu
http://rt.perl.org/rt3/NoAuth/perl5/Overview.html
In Brief
Yitzchak Scott-Thoennes's fix for "Archive::Extract"'s x.lzma test
file was applied.
http://xrl.us/bh4gw
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.
http://xrl.us/bh4gy
The "perlbal" issue of not building for Fedora was sorted out.
http://xrl.us/bh4g2
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
anyway.
http://xrl.us/bh4g4
Elizabeth Mattijsen puzzled over the differences in "builtin()" versus
"builtin( () )" (extra parentheses in the call) and discovered that
she had been bitten by prototypes.
http://xrl.us/bh4g6
Nicholas Clark believes he has nailed the corruptions seen in
ext/threads/t/free.t.
dup shenanigans
http://xrl.us/bh4g8
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 perl.org, and dual-life module bugs reported to
cpan.org 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
domains?
http://xrl.us/bh4ha
Paul Fenwick asked for (and received) a point of order concerning the
cleaning out of RT non-bugs.
http://xrl.us/bh4hc
Last week's summary
http://xrl.us/bh4he
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: [EMAIL PROTECTED]). The
archive is at http://dev.perl.org/perl5/list-summaries/. 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.
