This Week on perl5-porters - 8-14 September 2008
"A string in Perl is a sequence of arbitrarily large integers. If they
are all < 256, then you can store them all in bytes, so you can use a
sequence of bytes. If some of them of them are > 255, then you need a
representation that allows storing such values, and a byte string is
not enough. In that case, Perl stores a sequence of variable-width
values encoded according to the rules of UTF-8." -- Aristotle
Pagaltzis, making it seem so simple.
Topics of Interest
The great "perl589delta" race!
Paul Fencwick has put together a mailing list, RSS feeds, a repository
and more for people wishing to help write the document describing the
changes in perl 5.8.9. Most importantly, he wrote a micro HOWTO to
show people how they could get involved (and no, you don't need to
read p5p, nor this summary in order to help).
no more excuses
http://xrl.us/oru6d
In a related note, Andy Dougherty expunged the INSTALL file of
references to 5.10.
http://xrl.us/oru6f
Wrong debugger interaction with 'n' single stepping and a panic
Heiko Eißfeldt didn't like the way the perl debugger doesn't know how
to leap over entire "map" or "grep" blocks in a single leap when using
the 'n' command. In fact it was enough to make Heiko to make the
debugger Do The Right Thing, and proposed a patch for review. Joshua
ben Jore offered some good advice for making things more robust,
especially when taking error handling into account.
source perlmonks thread
http://www.perlmonks.org/?node_id=709679
richard foley offers encouragement
http://xrl.us/oru6h
"unless(...)" terser than "if(!...)"
In response to Graham Barr's counter-example using overloading that
showed then "if(!$foo)" is not equivalent to "unless($foo)", Nicholas
Clark commented that this was sufficient reason not to integrate the
change into a minor release, as there may be code out there that
relies on an overloaded variable being true and false at the same
time.
On the other hand, the concept is so demented that he had no qualms in
breaking it for a major release.
another obfu bites the dust, hep hep
http://xrl.us/oru6j
Steve Hay bemoaned the fact that the unless/!if optimisation blew away
his "Win32API::File" smokes. Vincent Pit realised that he had failed
to make allowance for chained nots, as in "1 if !$x or !$y or !$z",
since that exceeded the size of the opcode stream that the peephole
optimizer was able to consider. And, bad luck, such a code path was
tweaked in test.pl itself. (Hint: we need some absurd chains of
conditional tests somewhere in the test suite).
Nevertheless, according to the theory that being able to describe the
bug means you're able to fix it, Vincent proposed a second patch that
nullifies the ops rather than trying to surgically remove them.
no ops bad, null ops good
http://xrl.us/oru6m
Storable-2.15 on FC9
J. Adams was suffering in the attempt to build an ancient version of
Storable (2.15) on a brand new 5.10 perl. Nicholas Clark asked if this
was really necessary, since the current 2.18 is so much nicer. J.
replied that yes, it was vital, since other machines in the network
with older versions of Storable were digesting the output and would
fail if they encountered Storable files from the future.
Nicholas sketched out what brain transplant surgery would be required
in order to get things to work. We may assume that J. succeeded in
getting things to work.
http://xrl.us/oru6o
"Test::Harness" prove.t failures
Steve Hay discovered that all his smoke tests were failing simply
because he had set the "HARNESS_TIMER" environment variable to 1.
Nicholas Clark stole some code from Andy Lester's upstream
"Test::Harness" repository that he hoped would address the problem.
http://xrl.us/oru6q
blead with "-Dusemymalloc" fails on t/comp/hints.t
Vincent Pit noticed that blead is now failing in the above test file
but had no idea since when. A little detective work led him to
conclude that it was a question of underlying C "struct"s that were
running into a problem of overlapping copies. While neither Rafaël
Garcia-Suarez nor Nicholas were able to reproduce the error, Vincent's
patch seemed sane enough to apply.
http://xrl.us/oru6s
Capture the wtf8 flag
(Best. Subject. Line. Ever.)
Ricardo Signes joined a long list of illustrious Perl hackers in
experiencing the pain of UTF-8, and suggesting a set of guidelines for
dealing with it. Aristotle Pagaltzis laid it out in crystal clear
terms (see the top of this article). Glenn Linderman tweaked
Aristotle's looser prose and both of them recommended Juerd Waalboer's
"BLOB" CPAN module that helps in times like these.
More advice from Glen Lindemann:
* Using the utf8 flag to make decisions about how to process
character data is inappropriate.
* Using the utf8 flag to determine if it is character data or not is
inappropriate.
So don't do that.
http://xrl.us/oru6u
2038 fix
Michael G. Schwern is dragging Perl kicking and screaming into the mid
21st century, so that date arithmetic in the years 2039 and beyond
won't collapse in a screaming heap on Unix systems. People with more C
expertise than Michael are invited to join in the fun on the Google
Code project that hosts the code that deals with this.
your children will be grateful
http://xrl.us/oru6w
Michael had so much fun with 2038 and git branching that he went ahead
and produced a git branch for grafting 2038+ date arithmetic onto
blead.
http://xrl.us/oru6y
In the process of dealing with time values larger than 32 bits,
Michael wondered about scalar upgrades that go from signed to unsigned
"int" and thence to "double", and whether it would be worth slotting a
64-bit long long in there somewhere.
Joshua Hoblitt suggested the Utopian int to long long to
"Math::BigInt". Tels, as author and maintainer of "Math::BigInt"
pointed out that he had collected various ideas and techniques over
the years to rewrite it in C, but said that this would take hundreds
of hours and he didn't see how the effort could be financed, short of
winning the lottery.
http://xrl.us/oru62
$VERSION in "Opcode"
Nicholas Clark wondered how one should deal with different versions of
"Opcode" living on CPAN (insofar as it is published with each released
version of Perl) whilst avoiding "I must upgrade your perl" arms race
when someone attempts to upgrade it.
Rafaël thought it was pretty much a non-issue, given that Opcode is so
intimately tied to the particular perl release (unlike "Safe" which is
dual-life-clean), it cannot reasonably be upgraded. In light of this,
its version number is nearly meaningless. Nicholas wondered if a
"1.06_01" scheme could work.
Zefram recalled problems with "Module::Build" in the light of such
version numbers, but John Peacock thought that "Module::Build" no long
had any issues relating to development release numbering schemes.
http://xrl.us/oru64
"Test::Smoke" improvements for Windows
Jan Dubois, answering Steve Hay's question as to why his smokes spewed
so many warnings, said that the main problem is that the smoke in
question is on a 64-bit platform, even though there's precious little
in the output to distinguish it from a 32-bit build.
The warnings arise from the fact that Perl's internals are not 64-bit
clean at all. Variables are defined as I32 (32 bits in length) and get
assigned "size_t" values (which are indeed 64 bits in length on 64-bit
platforms), plus many other assorted programming sins.
Other 64-bit platforms are more or less immune to such problems as
everything is 64 bits. Windows is singular in its approach, with
"int"s and "long"s being 32 bits when "IV"s and pointers are 64 bits.
Jan had tried to clean this up once, but wound up converting just
about every single "I32" into an "IV".
Andy Dougherty felt his pain, having undertaken the same task himself
in days gone past. After having battled to resolve the contradictions
between perl's own internals use of an "int", and what the C library
wants to see in terms of "int", each time Andy found something much
easier to do, like rewriting Perl's Unicode handling on EBCDIC.
http://xrl.us/oru66
Change 33727 (op.c) breaks constant folding in "elsif"
Alexey Tourbin uncovered a flaw in the plan to fix the longstanding
"wrong line number reported for "elsif"" bug. Nicholas understood why
it was going wrong, but professed lack of knowledge to figure out how
the optree and peephole optimiser work.
Vincent Pit proposed a fairly ambitious patch to blead that fixed this
issue which Rafaël applied to blead. At the same time, Rafaël also
thought that the original patch was too dangerous to go into the 5.8
track at least in its current state and it being so close to the 5.8.9
release. Nicholas concurred, and backed the change out.
http://xrl.us/oru68
O(1) ISA isa not as great as hoped
Nicholas Clark related the story of Tim Bunce profiling "PPI" with
"Devel::NYTProf", and discovering that "PPI" spends 15% of its time
living in "UNIVERSAL::isa".
So he replaced an @ISA linear scan with a hash lookup. And then he
wondered why he observed only a 1% speed improvement. Michael G.
Schwern thought that the problem was probably not so much @ISA
traversals something going on in "isa_lookup", which contains a lot of
code.
http://xrl.us/oru7a
"pod2man" and POD errors (cpan #39007)
Russ Allbery asked what the porters thought of changing "pod2man"'s
error handling to emit errors to stderr, rather than building a POD
ERRORS section in the document. He listed the pros and cons of each
approach.
Alan D. Salewski voted for stderr, Zefram suggested an option to
"die()" on error.
podchecker anyone?
http://xrl.us/oru7c
TODO of the week
Here we go, this is easy. Fame, fortune, it's all yours.
merge checkpods and podchecker
pod/checkpods.PL (and "make check" in the pod/ subdirectory)
implements a very basic check for pod files, but the errors it
discovers aren't found by podchecker. Add this check to podchecker,
get rid of checkpods and have "make check" use podchecker.
Patches of Interest
Fix up minor formatting inconsistency in "perltodo"
When looking for the TODO of the week a couple of weeks ago, several
proof-readers pointed out the POD formatting errors in the TODO
section. As it was a direct steal from perltodo.pod, I sent in a patch
to fix it up. But of course Nicholas Clark did a much better job of
it.
fwp -- fun with pod
http://xrl.us/oru7g
Fix mismatched "#if"/"#endif" in Win64 configuration.
Jan Dubois suspected that change #33350 was responsible for deleting
an "#ifdef" from a Windows header file. So he put it back, and Rafaël
applied the change.
http://xrl.us/oru7i
$ENV{TEST_JOBS} vs $ENV{HARNESS_OPTIONS}
Bram dug down to the bottom of a problem with the new test harness
running tests in parallel and having some tests fail because they are
not yet parallel-safe.
He thought that the problem was that "Tap::Harness" was not running
certain tests serially because of interactions between two environment
variables that govern the harness. So he wrote a patch to get the test
suite testing without error, which seemed good enough for Rafaël to
apply.
http://xrl.us/oru7k
Cross-compilation - step 1 of N+1
Vadim Konovalov delivered a first patch, to Makefile.SH, in hopefully
what will be a series, to get cross compilation working. The result of
the patch is a new Makefile target which can then be used to kick off
the compilation. Rafaël seemed pleased.
http://xrl.us/oru7n
Fix parallel testing temp filenames
Jerry D. Hedden identified lib/charnames.t, lib/strict.t and
lib/subs.t as badly behaved citizens in the brave new world of
parallel testing, so he adjusted them to use the officially sanctioned
temporary file name generation technique.
the prognosis is grim
http://xrl.us/oru7p
conform or die
http://xrl.us/oru7r
New and old bugs from RT
CGI "multipart_init()" incorrectly quotes other headers (#33118)
Steve Peters filed a bug in 2004 concerning a problem that the
Bugzilla project had uncovered with the venerable CGI.pm.
Renée Bäcker wrote a patch to address the problem, but it broke the
test suite. In the time it took him rework the patch, Lincoln Stein
had already fixed it in his upstream repository.
While this was happening Nicholas Clark piped up to get the
attribution of another Windows patch from Steve Hay sorted out in the
credits. Craig A. Berry also confirmed that the VMS patches that
Lincoln had integrated blindly did in fact result in a clean test run
for VMS.
3.42 is gold
https://bugzilla.mozilla.org/show_bug.cgi?id=275108
http://xrl.us/oru7t
Subclassing "CGI::Pretty" dies in ->new (#41572)
Nicholas Clark noted with satisfaction that as of CGI version 3.42,
the blead and CPAN versions are byte-for-byte identical. The only
scheduled change planned in blead is simply the architectural issues
involved in placing the CGI build directory under ext/, which should
not affect the source.
http://xrl.us/oru7v
print doesn't overwrite $! (#43097)
Christoph Bussenius wrote a patch to fix this problem, which simply
clears the error flag on the file descriptor each time it's called.
Gisle Aas pointed out the flaw in the plan. Christoph took another
stab at solving the problem, but realised that with a global $!,
there's not much chance at developing a robust solution. What's needed
is a $! for each file handle.
http://xrl.us/oru7x
debugger: "o warn=0 die=0" ignored (#57016)
Tye McQueen reported that, following a refactoring of the debugger
that assigned the functionality of "O" to "o", the above debugger
command no longer did anything useful. He restored the previous
behaviour (or some sort of useful behaviour) in a patch, which Rafaël
Garcia-Suarez applied.
http://xrl.us/oru7z
"Unicode::UCD::casefold()" does not work as documented (#58430)
In response to Karl Williamson's description of the possible options
available to him to solve the problem of Unicode case folding, David
Landgren offered a couple of suggestions.
http://xrl.us/oru73
unicore/mktables expects wrong syntax from CaseFolding.txt (#58656)
As Karl kept looking at the Unicode problems, he discovered that the
"mktables" program, which generates the Unicode tables that the core
will use afterwards, is looking for things in a file that Karl points
out do not exist. He wasn't sure whether the code is just utterly
wrong, or whether the Unicode Consortium changed the contents of the
file at some point. Either way, something needs to be done about it.
http://xrl.us/oru75
POD for "encoding" pragma has triplicated section (#58774)
Darren Duncan suggests that of the three "Side effects" section in the
documentation, only one is needed.
do not operate heavy machinery
http://xrl.us/oru77
make test problem, perl 5.10.0 on AIX 6.1 (#58802)
G. Harders reported a problem building NDBM on AIX. Unfortunately, all
the sympathetic AIX hackers were busy doing other things.
http://xrl.us/oru79
Not OK: perl 5.11.0 +DEVEL +patchaperlup: on i686-linux-64int
2.6.22-1-k7 (UNINSTALLED) (#58848)
The problem is that "Test::Harness" is looking for, and failing to
find "Time::HiRes".
http://xrl.us/oru8b
Perl5 Bug Summary
264 new + 1032 open = 1296 (+8 -5)
http://xrl.us/oru8d
http://rt.perl.org/rt3/NoAuth/perl5/Overview.html
In Brief
Kawaljeet Kaur reported encountering a couple of errors building
"Time::HiRes" with perl 5.8.8 on a justifiably ancient Solaris 2.6
host. Steve Peters was more impressed by the fact that such an old
operating system was able to build a recent Perl with no more errors
than that.
teaching an old dog new tricks
http://xrl.us/oru8f
Richard Srisamang mulled over a "Storable" problem, whereby a data
structure is read in, the structure acquires additional elements and
then is written out... and the new file is smaller than the original
file. Nicholas Clark suggested viewing the results in a human-readable
format, such as XML (sniggering not allowed) or "Data::Dumper".
sounds like a feature
http://xrl.us/oru8h
Tom "spot" Callaway is desperately seeking Rob Brown (BBB on CPAN).
It's a question of licensing code on CPAN with respect to Fedora.
licensing issues, yummy yummy!
http://xrl.us/oru8j
Gábor Szabó is clearly mad, since he's building a GUI front-end to run
debugger sessions over a network link.
and looking for a name
http://xrl.us/oru8m
Last week's summary
This Week on perl5-porters - 25-31 August 2008
Where it is given thanks for the work of Bram and Renée Bäcker in
reducing the bug count by several hundred over the summer.
http://xrl.us/oru8o
This Week on perl5-porters - 1-7 September 2008
No comments.
http://xrl.us/oru8q
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 contributing to the
Perl Foundation or attending a YAPC to help support the development of
Perl.
--
stubborn tiny lights vs. clustering darkness forever ok?
