"Perl simply isn't broken enough. Most things work too well, hence no-one finds that they need to fix their itch, so in turn, they don't get sucked into core development generally. Maybe we need to start adding bugs, somewhat like a protection racket."
"Your program works very nicely. It would be a shame if something went wrong with it, wouldn't it? ..."
-- Nicholas Clark, on possible future revenue schemes.
Nicholas Clark followed up on the 5.8.9-tobe thread, regarding binary compatibility, pointing out that the entire 5.8 line had never needed to rearrange struct layouts, so clearly it's not much of a limitation.
He thought that forcing a layout reshuffle between each minor release sounded like quite a bit of work; Jan Dubois noted that all one needed to do was to roll the first member around to the end, which is easy, and has the added bonus of guaranteeing that the offset of every single member changes.
challenge their assumptions http://xrl.us/bj2sx
Nicholas then related the details of a discussion he had with Dave Mitchell concerning the viability of a copy-on-write scheme. The main stumbling block is the need for threaded perls to track which interpreter allocated a given block of memory, since only the true owner should free it.
This would mean that every single SV needs an extra pointer to link back to the parent interpreter, on top of the extra counter needed to keep track of the current copy count.
So Nicholas went exploring to find out if there was another way to determine to which parent a block belonged. After studying things for a while he came to the conclusion that between util.c and malloc.c, the necessary infrastructure already exists to acquire large blocks of memory from the system and then allocate it on an as-needed basis as program executes.
And then he was struck by the fact that this could be useful
right now, without waiting for a copy-on-write scheme to
be written, since the above could be used to both speed up
Win32's slow malloc performance and speed up (or at
least simplify) thread destruction.
Another brilliant piece of detective work by Nicholas that, alas, attracted no comments.
http://xrl.us/bj2sz
Nicholas also took the time to examine Paul Fenwick's reasons for dismay with the way tainting can be turned on part way through a program and offered a number of answers to Paul's questions.
By using Sam Vilain's git repository back to the dawn of time, he was able to show that the current behaviour was introduced during 5.000 alpha 4.
http://xrl.us/bj2s3
Nicholas also related a conversation from Real Life (see, the man does have a Life) where Leon Brocard asked whether there were enough people working on Perl 5, and Nicholas's flat answer was... no.
The inescapable fact is that working on a codebase that is over twenty years old is not fun, it's work. Even taking care of patches people send in and shepherding them to completion is work. A back of the envelope calculation gives 8 person-work-days, per week, just to stand still.
The grant scheme is not working. Expert Perl users know how to skate around the weird parts of the language (or give them a wide berth). Companies don't see the need to finance Perl development.
At the very least, a bug-wrangler who could keep track of bugs, tie related bugs together, filter out not-a-bugs, write TODO tests, write tests to improve coverage... well, it's a full-time job. And not fun. At least not always. Hardly ever.
Dave Mitchell pointed out that a seemingly innocuous bug report about a "premature free" error turns out, after a long debugging session, to be another case of a design decision embedded in the code base many years ago, at which point there's very little to be done about it. This sort of bug cannot be dealt with by a junior coder, lest they quickly lose their mind, or at least become quickly discouraged.
Sven Dowideit gave thanks for the Git repository, which made life much easier compared to the previous Perforce export via rsync approach. In which case one of the goals for switching over to git has already been met.
life support http://xrl.us/bj2s5
Sam Vilain, on the subject of the Perl Git, announced that he had cleared up all the problems outstanding with the first release of the repository and said that the current repository would likely be the definitive one.
Rafael Garcia-Suarez announced that his company, booking.com, had offered the bandwidth and hosting for the repository, and it would live under the perl.org domain. He said that the move to git will take place once 5.8.9 is out the door and so in the meantime Sam will have to continue to import the Perforce changes.
git.perl.org http://xrl.us/bj2s7
Andy Armstrong mindlessly propagated a link to a web site that purports to perform a census on the adoption of open-source software, and was keen to find out how Perl fared.
Apparently one has to download a 44Mb Ruby application as part of the process.
that's the easy part http://xrl.us/bj2s9
John E. Malmberg returned to the issue of $ENV{PATH} being tainted
on VMS and there being no way to untaint it in order to allow
test.pl to execute runperl. Part of the problem is that
$ENV{PATH} need not even exist on VMS, and things will work just
fine without it.
He recalled that the issue worked if PATH was defined beforehand but couldn't track down the original discussion on the matter.
finding your way http://xrl.us/bj2tb
elsif() This one's been around for a looong time and now, finally, it may be time to retire advice #11943 from Klortho.
Nicholas Clark took another look at it and decided that it would make a lovely opener for the Vienna Summer of TODOs project. Then when he took a closer look, he thought of a trivial solution that just might work after all.
He wrote up the new TODO, and within 12 hours, Rafael Garcia-Suarez had written and applied a patch to implement Nicholas's idea. Unfortunately it skewed another line numbering result. So he committed a better change (#33710). Nicholas wondered whether Rafael was going to fix each TODO he attempted to propose as worthy of a bounty.
Bram wondered if this was related to bug #47632, and asked whether the fix could be extended to resolve a variation on the theme (of reporting incorrect line numbers).
Tim Bunce was very pleased, because an unexpected benefit that came out of this was that all line-based execution profilers picked up the improvement for free.
Paul Johnson saw that Devel::Cover was flummoxed by the
change, but he noted happily that the test suite was reporting
the error in an appropriate way which should simplify the fix.
He also saw that B::Deparse got a little confused as well
and offered a patch to fix that up.
"Ah yes, and you are the first person to have noticed this bug since 1987. Sure." http://xrl.us/bj2td
The above work thus allowed Rafael Garcia-Suarez to announce that
the bug if ... elsif gives wrong line number for warning about
undefined value (#37302) was hereby fixed.
so backport it http://xrl.us/bj2tf
H.Merijn Brand took valgrind for a spin on his Text::CSV_XS module
to see what happened. In the process he discovered that
it works better if you have a perl built with -DDEBUGGING, but
a module written by Rafael (Perl::Destruct::Level) partially
obviates the need.
Marvin Humphrey explained what good valgrind figures should look
like and made some suggestions to reduce the numbers H.Merijn
was seeing. Vincent Pit asked whether his brand new Test::Valgrind
would be of any use, and this caught Marvin's attention.
the daily grind http://xrl.us/bj2th
ExtUtils::CBuilder with MinGW on Win32 Steve Hay asked about the status of ExtUtils::CBuilder (or more
specifically, the differences between the CPAN version, the development
version in its Subversion repository and blead). When all was said and
done, version 0.23 made it out to CPAN and this contains the MinGW
fixes that will clean up Steve's smokes.
On the other hand, the blead version still contains some VMS-specific fixes that need to be merged back into the development version of the module to get everyone in synch.
whither 0.24? http://xrl.us/bj2tj
Ricardo Signes reminded the porters about the perils of
$anything ~~ $obj_without_overload
and wrote a test case to try and nail it down. But something went wrong and he had a core dump on his hands. Rafael took over and cleaned everything up so that we know have a nicely-behaved TODO test.
http://xrl.us/bj2tm
In other news, he also wrote a testcase as a followup to the Array ~~ Any
discussion, but this appears to have been overlooked.
http://xrl.us/bj2to
In his continuing explorations of slab allocations, Jim Cromie offered a patch to allow structs with arbitrarily-sized arrays of structs to be allocated easily.
This was a follow-up to his Warnocked patch at the beginning of the month dealing with exposing the ptr-table subsystem, on the grounds that it offered a speed boost to XS authors. It turned out that freeing ptr-tables was very slow, and so switching to a slab allocator would simplify the freeing, since one could just throw the slab away. But for that to work, one needed to be able to calculate the overall required size needed for variable length allocations.
Those who were sufficiently well versed in the finer details of the C standard pointed out that not many current compiler implementations had implemented this part of the standard, which appears to have compromised the acceptance of the patch.
unwarranted chumminess with the C implementation http://xrl.us/bj2tq
A long digression about the relative merits of speed and usefulness of Perl, Ruby and Java, inspired by a web article written by Tim Bray.
not much porting going on http://xrl.us/bj2ts
Alberto Simões learnt that Slackware 12.1 was about to be released, and it is set to go with 5.8.8 rather than 5.10.0.
When he enquired as to why this was, he was told that according to the documentation on cpan.org, 5.10.0 is considered a testing release, and thus not suitable for general deployment (as in being bundled with a Linux distribution).
Matt S. Trout warned that anyone into Catalyst will run into problems with attributes on an unpatched 5.10.0. Reini Urban had several patches for Cygwin that had to make it back in.
The fact that given/when and smartmatch have problems
was brought up again, and a call was made for someone to go
through the archives and track down the exact issues (which
occurred during my summary sabbatical, sorry).
If a concise explanation can be made and a concensus can be reached as to what the desired behaviour is, Dave Mitchell, Matt S. Trout and Ricardo Signes offered to put in the work to get it done.
smartmatching the concept of stable http://xrl.us/bj2tu
Matt S. Trout reiterated the call for information.
http://xrl.us/bj2tw
Math::Complex/Math::Trig and Time::HiRes? Jarkko Hietaniemi put the maintenance of these dual-life modules on offer, citing lack of time to be able to devote the required tuits to shepherd them along. Zefram offered to take them over, since they were already of interest to him.
time for some maths http://xrl.us/bj2ty
Nicholas was surprised that the following code only produces one warning:
perl -lwe 'sub pie {print 0 + "pie"}; pie; pie;'
An even simpler variation on theme also didn't produce subsequent
warnings and one could argue that it should. The problem is that
the expression gets marked as valid numerically (or more precisely,
IOK gets set) after the first time through (and issuing a warning)
whereas the second time around the numeric context is used directly,
thereby skipping the chance for the warning to fire.
Jan Dubois therefore observed that this was the equivalent of saying
that IOK should be not be set if the conversion generated a
warning.
Abigail ventured the opinion that one warning was enough, and that if the problem the warning was signalling was so important as to merit repeated warnings about the same problem, then the warning should have been an error in the first place.
In the end, Nicholas suggested a series of tests to codify the behaviour and asked people to see if any loose ends needed to be tied up.
have your say http://xrl.us/bj2t2
File::Copy bug Nicholas fixed up the very silly bug that allowed one to copy a file using a buffer of 0 bytes, which is only useful if you want 0 bytes in the copied file.
The conversation then veered into a discussion about the fact
that File::Copy doesn't respect file permissions and
attributes, and other generally unhelpful problems the module
has.
it's ok to ask the OS to do it http://xrl.us/bj2t4
Spiros Denaxas wanted to know if the porters were aware of a Debian security issue concerning buffer overflows in regular expressions containing Unicode characters.
Tony Cook replied that there was an open ticket (#48156) on the issue in the bug database.
http://xrl.us/bj2t6
Marc Lehmann wrote an impassioned plea to see what could be done about helping XS modules work correctly with Unicode strings.
The first problem is that the raw interface to a string (char *)
is useless, since there is no side channel to tell the XS
code what encoding is in use.
In reaction to this, some XS authors have invented their own XS typemaps to get around the problem, however this can result in objects being stringified.
The only way out that Marc could see was to take a mortal copy of the input argument. Rafael thought that it might be possible to invent a more efficient mechanism, if only syntactically.
Marc stressed that the problem with the current situation is that when people encounter the problem on their own, they wind up learning about the utf-8 flag and begin to play around with that, and this leads to only more tears. Hence, if Perl wants to get really serious about Unicode, it needs to be addressed in a sane manner for XS.
http://xrl.us/bj2t8
Paul Marquess inquired about the right way to deal with CPAN updates
overwriting core versions of modules correctly. By default, the
CPAN shell will carefully install the new version in an @INC
directory listed after the core version (also known as shadowing).
The trick is to specify an override in the Makefile.PL (or
Build.PL) of the CPAN module.
Rafael wondered if there was a problem with the core installing files in architecture-dependent directories when in fact they should be installed in architecture-independent directories, and whether it was because of some blanket assumption about the modules living under ext/ in the codebase.
http://xrl.us/bj2ua
Bram trawled through RT and found close on a dozen tickets that he thought could be closed. So Steve Peters closed them. For another ticket concerning AIX, H.Merijn Brand suggested a hint that checks that the maths library is available.
http://xrl.us/bj2uc
DynaLoader and ExtUtils::Embed::ldopts since 5.10 Reini Urban reported that linking against DynaLoader had become quite difficult since the release of 5.10, due to changes in the way various linker symbols were exposed where. Rafael pointed to the exact change to help Reini understand what was going on.
Nicholas Clark thought that a test or two wouldn't go astray.
http://xrl.us/bj2ue
Johan Vromans had the misfortune to smoke change #33752, which was perfectly bracketed by change #33751, which introduced a bug into the forked debugger code that was then reverted by change #33753.
Unfortunately the bug caused the smoker log file to fill up the remaining disk space with an endless loop of debugger output.
you have been warned http://xrl.us/bj2ug
Hey! We got a bite! James Bence wrote a patch to make a reproducible
perlmodlib.PL . Note to budding TODO doers: please use unified diffs
for sending patches (diff -u, or the more melodious diff -dub).
smoke that http://xrl.us/bj2ui
Next up, I think the following two TODOs are dids.
threads::shared Investigate whether threads::shared could share aggregates properly
with only Perl level changes to shared.pm.
POSIX memory footprint Ilya observed that use POSIX eats memory like there's no tomorrow, and
at various times worked to cut it down. There is probably still fat to
cut out - for example POSIX passes Exporter some very memory hungry
data structures.
I believe that the first issue, if anything can be done about it, is receiving the appropriate amount of care from Jerry D. Hedden. And the second issue has been resolved with Nicholas Clark's new implementation for constant subs.
Here, then, is a TODO that requires a little C knowledge:
PERL_UNUSED_ARG The C code uses the macro PERL_UNUSED_ARG to stop compilers warning about
unused arguments. Often the arguments can't be removed, as there is an
external constraint that determines the prototype of the function, so this
approach is valid. However, there are some cases where PERL_UNUSED_ARG
could be removed. Specifically
The prototypes of (nearly all) static functions can be changed
Unused arguments generated by short cut macros are wasteful - the short cut macro used can be changed.
atan2(0,0) returns 0, not undef The porters continued to study the holy scriptures (that is, the C
standard) this past fortnight to figure just what was the best thing
for atan2(0,0) to return. Rafael Garcia-Suarez boldly went where
no pumpking had gone before, and declared with change #33676 that
it should return undef. And almost immediately began to have
second thoughts.
Andy Dougherty opened another can of worms and asked if we should also be checking for things like ±0. But it seems that, buried in the Configure infrastructure, we already do.
an error shall not occur http://xrl.us/bj2uk
->[] and ->{} instead of @{} and %{} Ben Morrow delivered an amazing hack to the parser to allow $x->[]
(currently a syntax error) to be semantically equivalent to @$x,
and this comes in handy when $x is a complex hash-array-hash-hash-array
dereference.
Rafael Garcia-Suarez commended Ben on the patch, and asked for a)
tests and b) whether qq{$x->p[]} worked, since the latter
involves working with the scarier parts of the lexer.
One problem that arose with builtins and there prototypes is that
the lexer really, really, really wants arrays to begin with a
@ sigil. Nevertheless Ben came back with another iteration of
the patch that solved that problem, by pushing the is-it-an-array
decision from the lexer into the various ops. As a bonus this slims
the PL_parser struct, and shaves off an op here and there.
Other people admitted to being a bit disturbed by the patch, citing that it added some inconsistencies to the language that were a little too weird to explain away with mere hand-waving.
Jonathan Rockway pointed out that this doesn't help the matter of protecting array dereferences from blowing up by guarding it with an empty list as in
@{ $might->{be}{undef} || [] }
This moved Nicholas Clark to say that autovivification would be less
inconsistent if @$x, where $x is undef, returned an empty list.
This garnered a certain amount of agreement, but Graham Barr
pointed out that code that dereferences undef expecting something
good to happen is probably buggy.
Aristotle Pagaltzis thought that autobox::Core already provides
a satisfactory solution to retrofitting a saner syntax onto Perl 5,
and for anything beyond becomes the realm of Perl 6.
People asked again why it was that autobox wasn't in core, and
Nicholas Clark did such a wonderful job of summarising the debate
that it deserves its own entry right here:
http://xrl.us/bj2un
Matt S. Trout wrapped up the thread to say that new, exotic syntax bending must first of all prove itself as a distinct CPAN module, and only afterwards should it move into core. And if it can't be done without patching the core itself, then the core needs to expose more hooks so that such syntax extensions can be made. Which is sort of the argument for putting autobox in the core, but like David Nicol says, the name is strange, or at least esoteric, and possibly it leads us to the Dark Side Of Laziness.
try this at home http://xrl.us/bj2up
Shlomi Fish suggested adding SEE ALSO references from core modules to other modules available on CPAN that solve the issue in better ways.
A number of people took issue with the subjective slant of "better" and thought that "alternative" would be, well, better.
One of the suggested modules, in relation to File::Spec was
Path::Class, but Sébastien Aperghis-Tramoni mentioned that he
had modified a number of programs at work in this very way, but had
to roll back the changes due to unexpected interactions between
Path::Class and other non-Path::Class-aware modules on CPAN.
http://xrl.us/bj2ur
Alexandr Ciornii continued to enhance perlbug to warn the user
if they tried to report a bug in a non-core module. Perhaps part
of the reason that no-one commented was that he leveraged CPAN.pm
to do the heavy lifting, which makes for one more thing to go
wrong.
and Module::Corelist? http://xrl.us/bj2ut
a2p Gregg Weber delivered a patch to fix no less than seven problems in a2p,
the awk-to-Perl convertor, as well as the smarts to deal with two
modern awk language extensions. Tels thought that the patch had
been inverted, but other than that the patch attracted no comments.
http://xrl.us/bj2uv
gcc -foptimize-sibling-calls cause trouble for perl's signal handler Gisle Aas reported that the above switch will cause gcc 3.3 to emit incorrect code. This can be patched by adding an explicit return statement at the end of the C function that causes the problem.
Another alternative would be to arrange the build process to not apply the -foptimize-sibling-calls switch when compiling mg.c.
http://xrl.us/bj2ux
length($@)>0 for empty $@ if utf8 is in use) (#51370) Animator took a stab at resolving this bug report that details how
magic associated with $@ persists long after the need has gone,
and proposed a series of approaches all deficient in one way or
another until finally hitting what looked like the right one.
Rafael thought the result looked correct, but thought that some more testing would be needed, and also wondered if there was a more concise way of achieving the same result (rather than 8 lines of code).
Bram wondered what could be tested, and how to do it. chromatic
couldn't think of anything better than scraping the output of
Devel::Peek.
ye gods, Devel::Peek::XML? http://xrl.us/bj2uz
Scalar::Util::looks_like_number versus Optimzation in regexp (#51568) Nicholas Clark situated the error within Scalar::Util and prodded Graham
Barr to integrate the change (or something that meets with his favour)
upstream, then it could be merged back into the core afterwards.
c'est utile http://xrl.us/bj2u3
Animator suggested overriding the core exit built-in function with an
appropriately verbose equivalent. John Gardiner Myers was doubtful as to
whether that would help in his situation, since things were exiting due
to memory allocation failures.
last exit to prompt http://xrl.us/bj2u5
Rafael fixed up the segfault by ensuring that the deleted stash stays dead, but wondered what the appropriate behaviour should be when asked to act upon a stash that is no more.
No clear concensus (between Nicholas, Rafael and Graham Barr) arose, perhaps because in the end this is just another case where the experts just say "yeah well things are a little weird around this part, so don't venture out too far", and move on to other matters.
doesn't crash == good enough http://xrl.us/bj2u7
Rafael backed out the optimisation that Yamashino Hio had written (that
sped up s///e substitutions by freeing intermediate temporaries).
choose correctness http://xrl.us/bj2u9
Matt Kraai spotted an error in the documentation where the dubious
$a and $b had been replaced by ordinary $x and $y
variables, except not entirely.
http://xrl.us/bj2vb
cop_free of nullified cop (#52920) While testing B::C, Reini Urban discovered that nulled opcodes
were being freed. He proposed a straight forward patch that addressed
the symptoms, but wondered if another more subtle patch might be a
better approach. Then he realised it was B::C itself generating
spurious data that could never be produced by the core, thus there
was no cause for alarm.
good cop, bad cop http://xrl.us/bj2vd
In other discussions, Rafael added some code to the core to keep an eye out for these sorts of shenanigans.
never can be too sure http://xrl.us/bj2vf
Robin Redeker reported that while (1) {map 1, 1} leaks memory.
Bram wondered if this was bug #48004 in another guise. Shlomi Fish
confirmed a leak under valgrind. Nicholas Clark used a machine with
real hardware watchpoints to pin-point exactly where the leak was
occurring, but was then not quite sure if it was more an issue of
particularly delayed house-keeping, rather than a leak per se.
http://xrl.us/bj2vh
Michael Koehn submitted a detailed report where UTF-8 being converted
to Latin1 in a Perl format went wrong. His workaround was to use
an explicit encode on the data.
Alexandr Ciornii confirmed the problem exists with 5.10 on Windows.
http://xrl.us/bj2vj
$_ inside given (#53186) Ed Avis was bitten by the fact that given takes a copy of its value
that is in turn passed to $_ for use in when statements. Paul
Fenwick pointed out that if one used for instead of given then
one could indeed obtain the desired aliasing behaviour.
forgiven http://xrl.us/bj2vm
A bug report that attracted no comments.
double free or corruption http://xrl.us/bj2vo
rand (#53238) David Dick noticed that some failures for testing fork involved the
parent and child processes generating a random number. Since the generator
wasn't explicitly seeded, it turns out that every once in a while both
processes would generate the same number and the test would consequently
fail.
David wrote a patch to ensure that the numbers are always different, and Rafael applied it.
that must have been hard to reproduce http://xrl.us/bj2vq
David Favor reported a failure in JSON::XS on the maintenance track
of 5.10. Nicholas Clark suggested a patch to fix JSON::XS. Marc
Lehmann was surprised as it seemed to him that SvCUR could no longer
be used as previously, and thought that many other modules could be
prone to the same sort of failure.
Jan Dubois was surprised as it seemed to him that people shouldn't be
using SvCUR unless SvPOK was known to be true. Marc still thought
it was a regression.
http://xrl.us/bj2vs
Devendra Purbiya reported a problem with a getcwd call failing
miserably. Sébastien Aperghis-Tramoni suggested that the first
thing to try would be to use a more modern release, such as 5.8.8
or 5.10.0, which may fix the problem due to fixes made since 5.8.3
was released (over four years ago).
http://xrl.us/bj2vu
Alexandra Bacher also reported having problems building a slightly more modern perl from source on the HP platform. H.Merijn Brand enquired as to whether there was a reason she didn't want to a precompiled bundle.
http://xrl.us/bj2vw
Another bug report from the module that would not die.
rrrrr, chainsaw, rrrrrrrrr http://xrl.us/bj2vy
In the second week we saw a welcome decline of 4 tickets, although sadly not enough to make up for the difference of 9 new tickets the previous week.
296 + 1524 = 1820 (+11 -2) http://xrl.us/bj2v2
293 + 1523 = 1816 (+6 -10) http://xrl.us/bj2v4 http://rt.perl.org/rt3/NoAuth/perl5/Overview.html
Now fixed in 0.64
http://xrl.us/bj2v6
Paul Marquess synched blead with the latest compression modules available on CPAN.
2.009 http://xrl.us/bj2v8
Tels released v1.89, closing out 4 tickets in the process.
http://xrl.us/bj2wa
Jan Dubois uploaded 0.36 to CPAN, and Steve Hay synched it with blead. Not much more than a few tweaks to make it behave nicely when compiled in 64-bit land.
http://xrl.us/bj2wc
Reini Urban found the time to figure out Tels's sins with
Devel::Size and bleadperl, and wrote a patch to fix it up.
all part of the service http://xrl.us/bj2we
Brian Greenfield announced that he had taken up smoking.
http://xrl.us/bj2wg
Reini Urban updated the Perl 5 wiki with a summary of hints for distributors wishing to distribute Perl with their operating system.
comments welcome http://xrl.us/bj2wi
Dave Mitchell wanted to know if it there was anything preventing the inclusion
of Test::Harness 3.x in maint-5.10.x. Andy Armstrong thought it would
be fine.
and there was colour! http://xrl.us/bj2wk
Aschwin van der Woude cross-posted a question from an spctools
mailing list regarding a tpp_gui.pl forking problem. Tels
wondered if the problem was due to /dev/null missing inside a
chroot jail.
http://xrl.us/bj2wn
Adriano Ferreira synched blead with the ongoing developments of Pod::Perldoc .
http://xrl.us/bj2wp
Robin Barker had another go at [[:print:]] versus \p{Print} that
Rafael liked sufficiently to accept. (Bug #49302).
documents and tests http://xrl.us/bj2wr
Paul Fenwick wanted to know if he could use %^H in Perl 5.8.x,
especially the upcoming 5.8.9. Nicholas Clark said no, and that it
was unlikely that the 5.8 track would ever be able to.
time to let go http://xrl.us/bj2wt
Rafael applied a patch for perl5db.pl to get the forked debugger to work on Linux/Cygwin and reverted it after noticing it caused a failure in perl5db.t.
back to the drawing board http://xrl.us/bj2wv
Bram documented perlrun -x .
see bug #46369 http://xrl.us/bj2wx
6-12 April 2008 http://xrl.us/bj2wz
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.