This Week on perl5-porters - 15-21 September 2008
"This is sort of like one of those useless Windows alert boxes that
pop up to tell you something perfectly normal has happened and you
should do nothing. "A USB device was safely removed!" Yes, thank you,
I just removed it. It's this sort of hand-wringing user interface
design ("but the user might not have expected that USB device to be
removed, they should be told so they can maybe, possibly do
something!") that I'd like Perl to avoid." -- Michael G. Schwern,
wanting numeric upgrades to JFDI.
Topics of Interest
Y2038 branch
Michael G. Schwern's work (in a git branch) on Y2038+ dates continued
apace, with H.Merijn Brand adding some configuration hooks for minimum
and maximum date values, and discussions of how to set up tests to
check for sane values in the year 803619167319 or so, especially if
daylight savings is still in place.
fresh dates
http://xrl.us/oscvv
Blead on OpenSUSE 11.0/64
H.Merijn Brand reported that the only failure on this platform for
5.8.9-to-be was one test in "CGI". On the other hand, "ODBM_File" was
collapsing in a heap on blead, but H.Merijn was puzzled as to why,
since he was using the same configuration settings, and there has been
no changes under ext/ODBM_File between 5.8.x and blead.
Andy Dougherty thought that 5.8.x's "Configure" was missing ODBM_File
altogether, but blead's was a little more aggressive and found a
header that led it to conclude it could try and build the extension,
and this revealed that SUSE's dbm compatibility is not up to par.
not ODBC
http://xrl.us/oscvx
"autodie" behaviour with "flock()"
Paul Fenwick asked what "autodie" should do in the light of blocking
and non-blocking file lock acquisitions, reasoning that calling
flock() in blocking mode means "I need this lock", whereas calling it
in non-blocking mode is a question: "Can I get this lock right now?".
From this, he could come up with sensible behaviour for "autodie".
The main sticking point was the possibility that a "flock" call
returns the "EWOULDBLOCK" error, which is not really an error, or at
least, not something worth dying for.
There was a long discussion about exceptions, errors and opportunistic
code, but the main point to take home is when Zefram pointed out that
if autodie's behaviour for flock is unsuitable, one is always free to
use a "no autodie 'flock'" to switch it off and handle it manually.
blocked on flock
http://xrl.us/oscvz
One may assume that Paul had been pulling his hair out over the issue
and that the documentation wasn't much help. So he improved
documentation for "flock()" in perlfunc.pod and tidied up the code
examples for by using lexical filehandles rather than globs, checking
for errors, and using constants rather than magic numbers.
aiding the cargo cult
http://xrl.us/oscv3
Is the prototype for "CORE::truncate" wrong?
Paul then looked at "truncate" in trying to figure out how to override
it for "autodie". His version could not take a typeglob as a
parameter, as the parser thought it was a bareword, due to
"truncate"'s prototype.
He missed the fact that "truncate" can also work with the name of a
file, not just a file handle, which is why the prototype had to fudge
matters slightly.
This reminded Jan Dubois of a subtlety he encountered with "unlink" a
while ago: "unlink()" will remove the file named by $_, but
"unlink(())" does nothing. The reason for this oddity is to prevent
"unlink(@stuff)" from unlinking whatever $_ points to, should @stuff
happen to be empty.
Jan gave up trying to implement the same semantics in pure Perl,
instead concluding that there are some core functions that are
impossible to duplicate. And perl 5.10's "_" prototype doesn't help
either, given that it imposes scalar context.
Rafaël wondered what would happen (what would break) if he tweaked
opcode.pl to change the prototype to something more suitable for
Paul's need. Paul wondered too.
trunk call
http://xrl.us/oscv5
Practical considerations in changing the integer upgrade path?
Michael G. Schwern asked for people's considered opinions on how
painful it would really be to change the integer upgrade path from
signed -> unsigned -> double -> "Inf" to signed -> long long (or
whatever) -> arbitrary precision.
Specifically, he wondered how one creates a new SV type, what impact
would this have on the code base, and whether it would break XS code.
Yuval Kogman answered all three questions quite clearly. And there
ended the thread.
and python does it right
http://xrl.us/oscv7
Change 30638 introduces regression
Following on from a change for bug #59168 reported by Father
Chrysostomos and an error in the test suite for "XML::LibXML::Simple",
Nicholas Clark backed the regressing change out and added some tests
to identify the problem so that that future attempts don't cause the
same breakage. Dave Mitchell said he had a cold, and was thus unlikely
to look at things for a while.
get well soon
http://xrl.us/oscv9
$* is no longer supported
Rory Kingan was worried about some code that crawled out of the
woodwork complaining about $* no longer implemented in 5.10. Aristotle
Pagaltzis looked at the regular expressions Rory posted and concluded
that it was just cargo cult code that could be safely deleted.
night of the living regexp
http://xrl.us/oscwb
Milestone: metaconfig now under GIT
H.Merijn Brand thanked Sam Vilain and Abhijit Menon-Sen for helping
him get "metaconfig" hosted entirely in git (at
<http://perl5.git.perl.org/?p=metaconfig.git>), and declared its
Perforce branches officially closed.
it's dead, jim
http://xrl.us/oscwd
Syntax incompatibility (5.8.8 vs 5.10)
Edward Peschko wrote about a problem with "Readonly::XS" that was
complaining about a use of "Carp::croak". This can be traced to a
decision taken over three years ago to remove the loading of "Carp"
from "warnings".
Since the author of the module sees no reason to release a new version
of the module just to fix this problem, it is unlikely that it will be
fixed in the near future. Certainly there is no desire to put "Carp"
back into "warnings", and "Perl::Critic::StricterSubs" can be used by
authors to find such problems (where client code loads module X, which
in turn loads module Y, and then the client code calls routines in Y
without having loaded it explicitly).
EWONTFIX
http://xrl.us/oscwf
TODO of the week
Here's a simple task that requires no C knowledge.
Fix tainting bugs
Fix the bugs revealed by running the test suite with the "-t" switch
(via "make test.taintwarn").
(In fact, you don't even have to fix all of them, or most of them.
Just updating perltodo.pod (patches welcome!) with the list of
problematic files would be a start).
Patches of Interest
"icc" wants "-fPIC" on x86_64
Vincent Pit offered a patch to get Intel's "icc" compiling XS modules
correctly. Apparently this went nowhere.
http://xrl.us/oscwh
Pod/Text.pm Can't call method "pod2text" without a package or object
reference
Jari Aalto uncovered a problem in 5.10 with an undefined file
descriptor in "Pod::Text". He supplied a patch for it, which appears
to be stuck in limbo.
http://xrl.us/oscwj
Don't reuse temp files in tests
Jerry D. Hedden found some more tests that had problems with names of
temporary file names being reused, so he changed them to use genuine
temporary file names. Jan Dubois pointed out that this was likely to
be a win for Windows systems that have on-access virus scanning, which
can interfere with files that are rapidly deleted and recreated.
do not use a random method to generate random filenames
http://xrl.us/oscwm
Show using "waitpid" in "IPC::Open[23]" SYNOPSIS
brian d foy noted that the documentation recommends using "waitpid" to
clean up, but the supplied examples don't. So he amended them to
provide baseline best practices for people to use.
do as i say not as i do
http://xrl.us/oscwo
New and old bugs from RT
Volunteer for fixing the "Unicode" bug (#58182)
Back in August, when I was on my summ(?:ary|er) break, Karl Williamson
filed a bug report relating to the inconsistent handling of 8-bit
characters in strings during case mapping when no locale has been
specified.
For instance, "uc("\x{e0}")" returns itself (à, or lowercase a grave)
rather than À (uppercase A grave). And this, regardless of whether
there are any multi-byte characters.
As a consequence, ""\x{e0}" =~ /\x{c0}/i" fails to match. Moritz Lenz
explained that this was a known bug but unfortunately was not fixable
because too much code relies on the current behaviour (which Karl
summarises quite nicely in the original bug report). Moritz showed how
one could make things work, at the expense of a little make-work code
involving "utf8::upgrade".
Juerd Waalboer mentioned that it is fixable and scheduled for
implementation in perl 5.12, and that such backwards compatibility
issues have been noted in "perl510delta".
Dave Mitchell sketched out how one might go about producing an
implementation for this, which would involve breaking out the
semantically overloaded "SVf_UTF8" flag from "SvFLAGS" and hanging it
out in an auxilliary structure, which could be used to store
additional bits of information such as character set, encoding,
locales, UTF-8 caches and more, since there's no space for such
extravagances in a standard SV.
Juerd and Glenn Linderman weren't sure it this would end up being a
win. Glenn in particular thought that locale and encoding metadata
should probably be associated with file handles and the like.
prologue
http://xrl.us/oscwq
Fast-forward to this week, when Karl reported back to the list,
explaining that he'd implemented the change in behaviour in a copy of
5.10 source that seemed to do the trick, and asked the list where to
go from here. In a nutshell, his patch extends ASCII semantics to the
characters in the 128..255 Latin1 characters.
Glenn Linderman explained that Karl should use a pragma to introduce
this new change for code that wants to use it.
Rafaël amended this suggestion by saying that the Unicode situation as
it stands at the moment is such a mess that no pragma would be
required for 5.12: it would just Do The Right Thing and backwards
compatibility be damned. If the change was back-ported to the 5.10
track, then a pragma would be required in order to switch to the new
behaviour.
Andreas König pointed out that Karl should base his patches on blead,
rather than 5.10. Rafaël said that starting a branch from
"git://perl5.git.perl.org/perl.git" would be as good a place as any
from which to start.
Juerd thought that Karl should have no qualms about breaking code with
his changes, since a certain amount of reverse breakage would may
occur, whereby existing buggy code suddenly begins to work
correctly...
famous last words "I just have to fix this bug"
http://xrl.us/oscws
Building Perl 5.10.0 in AIX 5.3 using "-Duseshrplib" option gives
"ERROR: Undefined symbol: boot_DynaLoader" (#58858)
Tippa found a problem that (s)he was able to fix by a minor tweak to
Makefile.SH and so filed a bug report. Jan Dubois repackaged the fix
as a patch to makedef.pl. H.Merijn Brand confirmed the problem and the
fix, and committed it as change #34379.
AIX en provence
http://xrl.us/oscwu
3-arg re-open drops IO layers (#58920)
Frank Meisschaert discovered that if STDOUT is redirected to a UTF-8
file using the 3-argument form of "open", the UTF-8 layer does not get
set. The work-around is to close STDOUT explicitly beforehand.
Michael G. Schwern confirmed that the problem exists from 5.8.8 to
5.10.0 to blead on OS/X .
not a team (p)layer
http://xrl.us/oscww
"grep unpack a/(a)" loops and eats all memory (#58942)
Ambrus Zsbán discovered a nifty way to have perl eat all available
memory. Nicholas Clark reported that the problem had already been
identified and fixed in blead. The correction will be backported to
5.10.1 and 5.8.9, which Nicholas said should be out within a month.
that's not a feature!
http://xrl.us/oscwy
Typo in CGI(3perl) man page (#59132)
Reuben Thomas identified two typos (in bug reports #59128 and #59130)
which were either already fixed in blead, or fixed thanks to his
report. Reuben found another typo in "CGI", for which Renée Bäcker
produced a small patch, although this will have to be pushed upstream
to Lincoln Stein, "CGI"'s maintainer.
meanwhile back at the CSHL
http://xrl.us/oscw2
He also found a typo in "File::stat" (filed in bug #59134).
the proof is in the reading
http://xrl.us/oscw4
Perl5 Bug Summary
Heading north. 268 new + 1032 open = 1300 (+6 -2)
http://xrl.us/oscw6
http://rt.perl.org/rt3/NoAuth/perl5/Overview.html
New Core Modules
constant 1.16
Sébastien Aperghis-Tramoni uploaded what is essentially a
documentation fix. Applied to blead by H.Merijn Brand.
http://xrl.us/oscw8
podlators 2.1.4
Russ Allbery fixed up the test suite to skip Unicode tests below
5.8, since "Pod::Simple" doesn't support UTF-8 encoding with those
versions, and rearranged things to deal with Red Hat "ispell"
idiosyncracies.
http://xrl.us/oscxa
This followed 2.1.3, which was Russ's first attempt at addressing
error handling (emitting to STDERR instead of creating a POD
ERRORS section), along with the errors that H.Merijn brought up
recently, where an otherwise flawless smoke run was choking on
UTF-8 locales.
http://xrl.us/oscxc
In Brief
Gábor Szabó chose "Debug::Client" as the name for his client for the
built-in debugger.
now available on CPAN
http://xrl.us/oscxe
Alexandr Ciornii set up dual life for "Text::ParseWords". The previous
module on CPAN is 9.5 years old.
now available on CPAN
http://xrl.us/oscxg
Paul Marquess was worried about the complexities and potential for
breakage if he created a composite distribution that contains all his
"Compress::Zlib" / "IO::Compress::Gzip" / "IO::Compress::Bzip2"
goodness. Fortunately the solution is simple and robust.
now available on CPAN
http://xrl.us/oscxk
Michael G. Schwern reported on "Method::Signatures" and the "[EMAIL
PROTECTED]"
prototype, and how nice it all was.
now available on CPAN
http://xrl.us/oscxn
Last week's summary
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?
