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: 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, please consider contributing to the Perl Foundation or attending a YAPC to help support the development of Perl.