This Week on perl5-porters - 2-8 January 2006
5.8.8 and 5.9.3 are both terribly near to release. Who will win? Tune
in next week!
Cygwin status on "maint" and "blead"
Yitzchak Scott-Thoennes posted a status report concerning the Cygwin
port in November, 2005.
http://xrl.us/jihi
Yitzchak managed to scrape a few tuits together to bring the issue
back on the radar and offered a patch against "blead" to move forward.
Rafael Garcia-Suarez doubted the portability of the "grep -e ... -e
..." (the program, not the builtin) construct and wondered whether an
alternation would be more portable. H.Merijn Brand thought that
multiple "-e" switches was more widely available. Andy Dougherty
mentioned that there weren't any viable "grep" and multiple "-e"
solutions on Solaris, and that "sed" was a better option.
Yitzchak rewrote the patch using "egrep" and one "-e".
Cygwin gets better
http://xrl.us/jihj
Problem using "local" with "threads::shared"
Another bug (#37671) from November, that had its tyres kicked in
December was cleaned up this week. Dave Mitchell broke the problem
into two distinct issues.
The first is an issue of "local $foo = $foo", when $foo is a a
thread-shared scalar, or also a tied scalar or otherwise having magic.
A one-liner to demonstrate the problem:
$! = 1; print "[$!]\n"; local $! = $!; print "[$!]\n"
(The second print is empty, instead of being the same as the first).
Dave couldn't think of an easy fix for this.
The second issue is the coredump on "blead". Dave committed a change
(#26569) to resolve that. And then he realised that there was a third
issue, that of leaking scalars. In the simplest form:
foo([EMAIL PROTECTED]);
sub foo {threads->new(...)}
... leaks. This caused Nicholas Clark to voice his suspicion that weak
references are getting cloned when they should not be, but was having
difficulty coming up with a test case to prove or disprove the
hypothesis. The following day, Dave came back with some code to
demonstrate the problem. Nicholas outlined an algorithm to fix the
problem. To be continued next week...
Leaks and threads and stuff
http://xrl.us/jihk
Scanning for "snprintf()" and "vsnprintf()" in "Configure"
After H.Merijn patched "Configure" to silence warnings during the
detection of "stdio" char signedness on Tru64 (patch courtesy of
Jarkko Hietaniemi), Jarkko then wondered whether it would be possible
to probe for the existence of "snprintf()" and "vsnprintf()", as these
functions provide a safer API for people doing XS work.
Steve Peters delivered a first version, based on the assumption that
since these functions are reasonably "new", one should be able to rely
on the POSIX specification (that they return "int"s). Russ Allbery has
apparently already been there and done that, and offered a few tips on
the subject. A number of changes were committed by H.Merijn and Steve
to get all this "snprintf"y goodness in on as many platforms as
possible.
More C goodness
http://xrl.us/jihm
Teaching "B::Concise" about optimised constant subs
Now that perl (space) optimises constant subroutines, Jim Cromie
thought it was time that "B::Concise" knew how to display them. He had
some problems with some constants in POSIX.pm that display as "FOO
exists in stash, but has no START" and wondered if his work-around was
correct.
Considerable discussion followed, tweaking the code to improve its
robustness, and veered into numerological considerations, with Jim
Cromie offering a beer to whoever scores patch #27182.
Concision
http://xrl.us/jihn
Much ado about PVGV and PVLV
PVGV are variables with attached magic. You can make them like so:
my $mg = *STDIN;
PVLV are lvalue variables. You make them this way:
my $text = 'bergomask fairing';
my $lv = \(substr $text, 2, 4);
Nicholas was worried whether it could be possible to contrive a set of
circumstances whereby, given the above...
$mg = $lv;
...would fail. The issue at hand is that for a long time, a PVGV
variable was the biggest thing you'll find in perl's guts. And
"Perl_sv_upgrade" knows how to upgrade from anything, except a PVGV,
because it was always the biggest.
But now a PVLV is larger, and Nicholas was wondering whether it was
possible to expose a PVLV without magic, which would then cause
"Perl_sv_upgrade" serious indigestion.
Yitzchak noted that the code already rules out the possibility of this
occurring, but did find a problem with the following:
sub TIEARRAY {bless{}}
sub FETCH { *FETCH }
sub FETCHSIZE { 3 }
tie @a, "main";
sub { $x = $_[0]; use Devel::Peek; Dump $x}->($a[2])
$x winds up as a "PVNV" instead of a "PVGV". But I'm not sure of the
ramifications, and in any case, the thread stopped there.
Defensive coding
http://xrl.us/jiho
Patch 26370 breaks "Acme::Meta"
Andreas J. König noticed that since change #26370 it has become
possible to create a file that can be "use"d but that perl cannot
compile. One example was "Acme::Meta", which ordinarily wouldn't be
particularly worrisome, but Andreas has a test in "Devel::Symdump"
that is based on "Acme::Meta", so he had a problem.
Rafael had a look, and narrowed the problem down to:
bleadperl -Mstrict -le 'BEGIN{print defined $foo::{bar}}'
and then committed change #26574 to make things work again.
Have a look at my stash
http://xrl.us/jihp
"Sys::Syslog" test problems following patch 26555
Yitzchak spotted an intriguing error with "Sys::Syslog", due to the
fact a test file being skipped when tested. When the code was
corrected to make the tests proceed, an error cropped up with some XS
code that generates constants.
Nicholas said that he regarded the exact details of contstants as mere
implementation details, so one should not be too surprised when the
implementation details change. Rafael wanted to know who much code Out
There uses this technique, and Nicholas described his helplessness at
trying to ask gonzui to search for constant when what he really wanted
was to look for "calls to a function named constant".
Pay no attention to the subroutine behind the curtain
http://xrl.us/jihq
Everyone's working too hard
Nicholas looked at the number of patches committed to the codebase
over the last eight years. After a lull in 2004, the changes have
rolled in with a vengeance this year, which explained why Nicholas was
having to spend so much time porting changes from "blead" back into
"maint".
Abigail pointed out that there have been more changes, less arguments
but no new releases, There have been more than 6000 changes to the
codebase since 5.8.0 was released three and a half years ago.
Shouldn't we be ready for 5.10? The conversation continued on briefly
about the roadmap to Perl 6, with Ponie and 5.12 both getting a
mention.
http://xrl.us/jihr
Cleaning "Time::Local"
Dave Rolsky, wearing his "Time::Local" maintainer's hat, asked the
porters whether anyone had objections to him running perltidy on the
source, and parenthesising particularly hairy math expressions. For
his own sanity as much as anything else. Rafael wasn't against the
idea, and Johnathon Stowe pointed out that he ran "Term::Cap" through
perltidy when he sent in his last patch and that no-one seemed to
mind.
http://xrl.us/jihs
"NV_ZERO_IS_ALLBITS_ZERO" "Configure" problem
Jim Cromie wrote about the way he could provoke consistent smoke
failures, and of his investigation as to what was happening. He
narrowed it down to a snippet of code in "Configure"... but had no
idea what to make of the inconsistent results he was getting.
H.Merijn wanted to know the *precise* version of "gcc" that Jim was
using. Nicholas tracked it down to some code of his, and supplied a
fix.
http://xrl.us/jiht
Bogus dirhandles raise no warnings
Mark Jason Dominus filed bug #36889 against 5.8.0. The following code
produces no output:
perl -wle '$x=7; print readdir $x'
Steve Peters replied that in blead, the above code now produces the
error
Bad symbol for filehandle
Yitzchak thought that saying "unopened dirhandle" would be preferable.
Steve pointed out that "Perl_gv_IOadd" generates the warning, and the
exact text is unchanged since 5.003, which made him a little hesitant
about making the change.
Mark had also filed bug #36888, which was a slightly different
problem: when mistreating "readdir", perl complains about a
*filehandle* instead of a *dirhandle*. Steve Peters explained how the
directory manipulation routines are supposed to follow a POSIX
standard, but across all the platforms that Perl is supported, POSIX
adherence is spotty. Nonetheless, he added some code to make perl
produce a correct error message.
Bad symbols...
http://xrl.us/jihu
... and bad filehandles
http://xrl.us/jihv
MinGW and lib/CORE/Win32.h
Sisyphus/Rob wrote in with a problem concerning MinGW and a simple C
program that does little more than include perl.h, but the compilation
dies with problems about "intptr_t" and "uintptr_t" typedef
redefinitions. He was able to trace the problem down to the use of
"-ID:/MinGW/include" to indicate that said directory is searched for
include files. He proposed a fix that involved a couple of defensive
"#define"s in win32.h.
Steve Hay had a look and noticed that in (the current) version 3.3
MinGW had changed their io.h to pull in stdint.h, and this causes the
duplicate definition errors. A work-around would be to downgrade to
3.2 temporarily.
Steve then committed an amended patch to incorporate the initial
patch, safely bracketed in a "__MINGW32__" "#ifdef" section.
And finally after a bit more detective work, Rob found the explanation
for the bizarre circumstances of the error. It turns out that you can
silently redeclare a type so long as it is in a system header, but if
it isn't, then an error is raised. The "-I" switch was causing gcc to
get confused and assume that the files were not in fact system
headers.
http://xrl.us/jihw
macro "newSVpvn"/"sv_catpvn_flags" errors
Jim Cromie found that when doing "make" after a "make regen" on a
recent version of "blead", the compilation would issue a huge number
of errors:
macro "newSVpvn" requires 2 arguments, but only 1 given
... but only when threads were configured. Rafael spotted the problem
and connitted a patch to deal with the first level of macro expansion,
so that instead of:
#define newSVpvs(str) newSVpvn(STR_WITH_LEN(str))
it now says
#define newSVpvs(str) Perl_newSVpvn(aTHX_ STR_WITH_LEN(str))
Both "a_THX_" and "STR_WITH_LEN" are macros, although the former is
empty when building a non-threaded perl. And gcc cannot deal with the
expansion of both macros at the same time. This made Gisle Aas sad,
because he felt that it made "STR_WITH_LEN" less usefulness, because
you can never use it directly as a argument to a function call, lest
than function itself become one day encapsulated in a macro.
http://xrl.us/jihx
VMS still compiles "blead" but a few tests fail
Abe Timmerman was impressed that in spite of all the recent additions
to blead, VMS still manages to compile it at change 26652. There are
still a number of test failures, mainly to do with IO. John E.
Malmberg went through the list, giving his current status/awareness on
the issues.
Paul Marquess chipped in with a tightened test for "Compress::Zlib" in
the hope of silencing a warning (the existence of a file that should
not be there possibly being led astray by VMS's capacity to store
multiple versions of the same file).
A discussion followed as to whether "Compress::Zlib" should be updated
for 5.8.8 or 5.9.3 or both. Paul wasn't too sure, as he's done a lot
of work on Compress::Zlib recently and felt it might need a bit of
time to settle. (What Paul has done is to abstract the zlib code out
from the core, in order to add other compression formats, such as
bzip2 and lzop).
#26652
http://xrl.us/jihy
Unforunately, by the time change #26660 hit the wire, things were
looking less rosy, with a C compiler spitting out errors. And then
Nicholas patched things up.
#26660
http://xrl.us/jihz
5.9.3 approaches
Rafael wants to release 5.9.3 soon and called asked people to hold off
committing big changes and start paying attention to smokes, testing
CPAN modules and ancillary Perl tools (like "perldoc", "dprofpp" and
the like.
H,Merijn noted that "DBM::Deep" was recently broken on blead. Andreas
said this was due to a bug in the module: the author had tripped over
pseudo-hashes by accident. Dave Mitchell said that he wanted to land a
fairly big change to "threads::shared" and including it in 5.9.3 would
give it some needed testing.
Abigail asked what the plans were from here to 5.10. Rafael replied
that if a good lightweight IPC solution is found, it could be soon.
Paul Marquess understood that one of the constraints of 5.10 was that
there must be a Ponie capable of running it, but Nicholas had
understood the opposite: a 5.10 ponie must match a 5.10 native perl.
(Ponie is still looking for a pumpking/queen by the way).
Yitzchak mentioned that the new-fangled constant subroutines merit an
Incompatible Change entry, given that symbol tables now house new,
previously-unknown beasties.
Steve Hay found a problem in an XS module due to "STRINGIFY" in
patchlevel.h, and the dependency chain between it and perl.h. He
wondered how many other XS modules are in the same boat, but Gonzui
was down. Gisle suggested changing the ouput of "perl -v" slightly,
which would remove the need to use "STRINGIFY" at all in patchlevel.h.
Ensued a somewhat arcane discussion about how best to represent the
exact build level of a Perl release, whether maintenance, development
or snapshot. Gisle came up with probably the best approach:
new-style perl -v
http://xrl.us/jih2
Steve Hay found another problem in one of his modules, in a bit of C
code that calls "NEWSV" asking for a length of 8, and gets back an
"SV" who's length is 12, rather than 8+1 (space for a trailing "\0".
Gisle thought it slightly dangerous: one shouldn't be worried if perl
allocates a bit more memory than strictly necessary, especially if it
reduces the need for expensive reallocations later on. Steve fixed his
code.
A call to testing
http://xrl.us/jih3
Jim Cromie called for a review of perl593delta, to make sure that all
the recent goodness added to "blead" is accounted for when 5.9.3 is
released. Nicholas Clark came up with an account of all the stuff he
has been working on, as well as other work by people like Dave,
Jarkko, Rafael, Andy Lester and John E. Malmberg.
Then there was Yves Orton's regexp trie optimisation, and new versions
of core modules, and configure probes for enabling more features from
compilers.
perl593delta review
http://xrl.us/jih4
Configure won't handle versions 5.10.0 or 5.8.10
Andy Dougherty noticed that the code in Configure performs simple
scalar comparisons with version numbers using "lt". This is great when
all versions, sub-versions and revisions are single digits, (after
all, '5.8.7' lt '5.9.3'), but it is disasterous when the sub-version
or revision goes to 10, and that could happen in a reasonably short
time frame.
This will have to be fixed up at some point in the future.
http://xrl.us/jih5
Better "ithreads" shared variables.
Dave Mitchell landed a mega-patch (in terms of improvement) that makes
ithreads shared variables smaller and faster, by doing away with the
"shared_sv" struct. "User-level locks and condition variables are
slightly slower, while everything else is quite a lot faster", to
quote the man himself. I think it stunned everyone into silence.
http://xrl.us/jih6
Comparing the speed of stat operations
R.K./Reikko filed bug #38179, reporting that "-X _" is 20% slower than
"-X" and that "Fcntl"'s "S_ISDIR" is 9 times slower than a "-d", which
benchmarks to show it. Nicholas Clark provided a detailed analysis,
pointing out a couple of faulty assumptions and committed a change
(#26701) to improve "Fcntl"'s lacklustre performance.
http://xrl.us/jih7
orphaned reply
http://xrl.us/jih8
Comparing the speed of constant subs
Jim Cromie made his own investigations on the performance of the new
Nicholas Clark constant subs, and while they use much less space,
sadly, they don't appear to go faster. No feedback as yet.
http://xrl.us/jih9
New Core Modules
"CPAN-1.81" released by Andreas. Support for "Module::Build", use of
SHA-256 digests and bugfixes are the key points. By the end of the
week, with the arrival of bug fixes, we were up to 1.83.
"version-0.52" from John Peacock
http://xrl.us/jiia
"Sys-Syslog-0.12" uploaded by Sébastien Aperghis-Tramoni. This new
version resolves the problems with "constant" noted earlier in this
summary.
http://xrl.us/jiib
Perl5 Bug Summary
1506 open tickets, the lowest I've seen it since summary service was
resumed in September. Woohoo!
http://xrl.us/jiic
The list
http://rt.perl.org/rt3/NoAuth/perl5/Overview.html
In Brief
speedy shared "our" variables! The bug #37946, posted by Jerry D.
Hedden a while back:
noted in the In Brief section
http://dev.perl.org/perl5/list-summaries/2005/20051212.html
was fixed by Dave Mitchell. As an added bonus, code of the following
nature:
our @a : shared;
for (1..10_000_000) {
$a[$_ % 10_000]++;
}
is now 7% faster. Along with the other thread fixes committed by Dave
this week, the overall improvement is a share more than 20%.
Shared variables sped up
http://xrl.us/jiid
Nicholas thought about "perl_clone()" and "-Dusemultiplicity" for a
bit, and realised that since the problem mainly affects Windows and
that he doesn't have access to Windows development machines there
wasn't much he could do about it. He made a few suggestions, such as:
a better implementation of this area of the code.
Windows dilemma
http://xrl.us/jiif
The "eval", "DESTROY" method and $@ bug (#38034) was considered to be
working as documented. The problem is that there was no documentation.
Mike Guy added the appropriate information (the trick is to localise
$@ when using "eval").
eval destroys $@
http://xrl.us/jiig
Removing NULL from Sys::Syslog. Sébastien Aperghis-Tramoni gave a
status report on this issue and all other tickets (4) open on RT at
this time.
Syslog status
http://xrl.us/jiih
John E. Malmberg fixed a buffer overrun in vms.c and a "const" problem
in utf8.c.
vms.c
http://xrl.us/jiii
utf8.c
http://xrl.us/jiij
Robert Spier noted that 64bit perl uses a huge amount of virtual space
(for example, 59Mb rather than 6Mb in bug #38132. Dave Mitchell
suspected that it was due to massive objects being linked into the
program, pointing to locales as a likely culprit. And he was right.
Life in the 64bit lane
http://xrl.us/jiik
Bug #36837 talks about the way "B::Deparse" crashes and burns when it
encounters a "ByteLoader"ed program. Stephen McCamant took the time to
explain why it was so, and offers a short patch to make it deal more
gracefully with the situation.
C<B::Deparse> doesn't do C<ByteLoader>
http://xrl.us/jiim
Jim Cromie sent a patch to tweak the behaviour of "-V:foo" to make it
play a bit more nicely with shell tricks. Rafael warned of backwards
compatibility issues and wondered what a brand-new method would look
like, and why. The discussion sort of stopped there.
Tweaking C<-V:> command line switch
http://xrl.us/jiin
Joshua ben Jore wondered whether Robin's recent work on "%^H" means
that user pragmas can be written, and sketched out an idea with
"lint". Rafael explained that the change only means that "%^H" is now
availale during string evals. Before, it used to disappear at the end
of the initial compilation phase. But even now, "%^H" is still empty
after compile time in regular code. I think the answer is no, then.
User pragmas via %^H ?
http://xrl.us/jiio
Gisle thought that some code to process "-s" on the shebang line was
redundant, and wondered whether it should be axed. Rafael agreed,
suspecting a mis-applied patch.
http://xrl.us/jiip
About this summary
This summary was written by David Landgren.
Information concerning bugs referenced in this summary (as #nnnnn) may
be viewed at http://rt.perl.org/rt3/Ticket/Display.html?id=nnnnn
Information concerning patches to maint or blead referenced in this
summary (as #nnnnn) may be viewed at
http://public.activestate.com/cgi-bin/perlbrowse?patch=nnnnn
If you want a bookmarklet approach to viewing bugs and change reports,
there are a couple of bookmarklets that you might find useful on my
page of Perl stuff:
http://www.landgren.net/perl/
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 or enjoyable, please consider
contributing to the Perl Foundation to help support the development of
Perl.
--
"It's overkill of course, but you can never have too much overkill."
