5.8.8 and 5.9.3 are both terribly near to release. Who will win? Tune in next week!
maint and bleadYitzchak Scott-Thoennes posted a status report concerning the Cygwin port in November, 2005.
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2005-11/msg00284.html
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://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2006-01/msg00222.html
local with threads::sharedAnother 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(\@a);
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://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2006-01/msg00052.html
snprintf() and vsnprintf() in ConfigureAfter 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 ints). 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 snprintfy goodness in on as many platforms as possible.
More C goodness http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2006-01/msg00008.html
B::Concise about optimised constant subsNow 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://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2006-01/msg00016.html
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://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2006-01/msg00022.html
Acme::MetaAndreas J. König noticed that since change #26370 it has become possible to create a file that can be used 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://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2006-01/msg00036.html
Sys::Syslog test problems following patch 26555Yitzchak 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://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2006-01/msg00038.html
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://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2006-01/msg00061.html
Time::LocalDave 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://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2006-01/msg00063.html
NV_ZERO_IS_ALLBITS_ZERO Configure problemJim 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://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2006-01/msg00069.html
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://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2006-01/msg00084.html ... and bad filehandles http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2006-01/msg00091.html
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 #defines 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://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2006-01/msg00128.html
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 committed 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://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2006-01/msg00129.html
blead but a few tests failAbe 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://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2006-01/msg00149.html
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://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2006-01/msg00189.html
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://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2006-01/msg00239.html
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://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2006-01/msg00175.html
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://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2006-01/msg00160.html
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://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2006-01/msg00218.html
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://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2006-01/msg00247.html
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://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2006-01/msg00258.html orphaned reply http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2006-01/msg00297.html
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://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2006-01/msg00263.html
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://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2006-01/msg00245.html
Sys-Syslog-0.12 uploaded by Sébastien Aperghis-Tramoni. This new version resolves the problems with constant noted earlier in this summary.
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2006-01/msg00261.html
1506 open tickets, the lowest I've seen it since summary service was resumed in September. Woohoo!
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2006-01/msg00367.html The list http://rt.perl.org/rt3/NoAuth/perl5/Overview.html
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://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2006-01/msg00260.html
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://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2006-01/msg00020.html
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://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2006-01/msg00046.html
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://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2006-01/msg00171.html
John E. Malmberg fixed a buffer overrun in vms.c and a const problem in utf8.c.
vms.c http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2006-01/msg00054.html utf8.c http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2006-01/msg00055.html
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://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2006-01/msg00058.html
Bug #36837 talks about the way B::Deparse crashes and burns when it encounters a ByteLoadered 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.
B::Deparse doesn't do ByteLoader http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2006-01/msg00067.html
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://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2006-01/msg00110.html
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://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2006-01/msg00279.html
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://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2006-01/msg00206.html
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: 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 or enjoyable, please consider contributing to the Perl Foundation to help support the development of Perl.