This is a live mirror of the Perl 5 development currently hosted at https://github.com/perl/perl5
Porting/todo.pod: refaliasing needs fixing still
[perl5.git] / Porting / todo.pod
index c410c05..f0f01cb 100644 (file)
@@ -25,6 +25,28 @@ programming languages offer you 1 line of immortality?
 
 =head1 Tasks that only need Perl knowledge
 
+=head2 Classify bug tickets by type
+
+Known bugs in Perl are tracked by L<https://rt.perl.org/> (which also
+includes Perl 6).  A summary can be found at
+L<https://rt.perl.org/NoAuth/perl5/Overview.html>.
+It shows bugs classified by "type".  However, the type of many of the
+bugs is "unknown".  This greatly lowers the chances of them getting
+fixed, as the number of open bugs is overwhelming -- too many to wade
+through for someone to try to find the bugs in the parts of
+Perl that s/he knows well enough to try to fix.  This task involves
+going through these bugs and classifying them into one or more types.
+
+=head2 Ongoing: investigate new bug reports
+
+When a bug report is filed, it would be very helpful to have someone do
+a quick investigation to see if it is a real problem, and to reply to
+the poster about it, asking for example code that reproduces the
+problem.  Such code should be added to the test suite as TODO tests, and
+the ticket should be classified by type.  To get started on this task,
+look at the tickets that are marked as "New Issues" in
+L<https://rt.perl.org/NoAuth/perl5/Overview.html>.
+
 =head2 Migrate t/ from custom TAP generation
 
 Many tests below F<t/> still generate TAP by "hand", rather than using library
@@ -35,8 +57,8 @@ instead there is an intentionally simpler library, F<t/test.pl>. However,
 quite a few tests in F<t/> have not been refactored to use it. Refactoring
 any of these tests, one at a time, is a useful thing TODO.
 
-The subdirectories F<base>, F<cmd> and F<comp>, that contain the most
-basic tests, should be excluded from this task.
+The subdirectories F<base>, F<cmd>, F<comp> and F<opbasic>, that contain the
+most basic tests, should be excluded from this task.
 
 =head2 Automate perldelta generation
 
@@ -56,18 +78,6 @@ automated with a bit of perl, specifically the generation of
 
 See F<Porting/how_to_write_a_perldelta.pod> for details.
 
-=head2 POD -E<gt> HTML conversion in the core still sucks
-
-Which is crazy given just how simple POD purports to be, and how simple HTML
-can be. It's not actually I<as> simple as it sounds, particularly with the
-flexibility POD allows for C<=item>, but it would be good to improve the
-visual appeal of the HTML generated, and to avoid it having any validation
-errors. See also L</make HTML install work>, as the layout of installation tree
-is needed to improve the cross-linking.
-
-The addition of C<Pod::Simple> and its related modules may make this task
-easier to complete.
-
 =head2 Make Schwern poorer
 
 We should have tests for everything. When all the core's modules are tested,
@@ -75,6 +85,14 @@ Schwern has promised to donate to $500 to TPF. We may need volunteers to
 hold him upside down and shake vigorously in order to actually extract the
 cash.
 
+=head2 Write descriptions for all tests
+
+Many individual tests in the test suite lack descriptions (or names, or labels
+-- call them what you will).  Many files completely lack descriptions, meaning
+that the only output you get is the test numbers.  If all tests had
+descriptions, understanding what the tests are testing and why they sometimes
+fail would both get a whole lot easier.
+
 =head2 Improve the coverage of the core tests
 
 Use Devel::Cover to ascertain the core modules' test coverage, then add
@@ -91,12 +109,14 @@ would be useful to have a reasonable general benchmarking suite that roughly
 represented what current perl programs do, and measurably reported whether
 tweaks to the core improve, degrade or don't really affect performance, to
 guide people attempting to optimise the guts of perl. Gisle would welcome
-new tests for perlbench.
+new tests for perlbench. Steffen Schwingon would welcome help with
+L<Benchmark::Perl::Formance>
 
 =head2 fix tainting bugs
 
-Fix the bugs revealed by running the test suite with the C<-t> switch (via
-C<make test.taintwarn>).
+Fix the bugs revealed by running the test suite with the C<-t> switch.
+Setting the TEST_ARGS environment variable to C<-taintwarn> will accomplish
+this.
 
 =head2 Dual life everything
 
@@ -114,17 +134,16 @@ 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.
 
-=head2 embed.pl/makedef.pl
+=head2 makedef.pl and conditional compilation
 
-There is a script F<embed.pl> that generates several header files to prefix
-all of Perl's symbols in a consistent way, to provide some semblance of
-namespace support in C<C>. Functions are declared in F<embed.fnc>, variables
-in F<interpvar.h>. Quite a few of the functions and variables
-are conditionally declared there, using C<#ifdef>. However, F<embed.pl>
-doesn't understand the C macros, so the rules about which symbols are present
-when is duplicated in F<makedef.pl>. Writing things twice is bad, m'kay.
-It would be good to teach C<embed.pl> to understand the conditional
-compilation, and hence remove the duplication, and the mistakes it has caused.
+The script F<makedef.pl> that generates the list of exported symbols on
+platforms which need this. Functions are declared in F<embed.fnc>, variables
+in F<intrpvar.h>. Quite a few of the functions and variables are conditionally
+declared there, using C<#ifdef>. However, F<makedef.pl> doesn't understand the
+C macros, so the rules about which symbols are present when is duplicated in
+the Perl code. Writing things twice is bad, m'kay. It would be good to teach
+F<.pl> to understand the conditional compilation, and hence remove the
+duplication, and the mistakes it has caused.
 
 =head2 use strict; and AutoLoad
 
@@ -162,6 +181,44 @@ whole category.
 Many diagnostic messages are not currently documented.  The list is at the end
 of t/porting/diag.t.
 
+=head2 Write TODO tests for open bugs
+
+Sometimes bugs get fixed as a side effect of something else, and
+the bug remains open because no one realizes that it has been fixed.
+Ideally, every open bug should have a TODO test in the core test suite.
+
+=head2 deparse warnings nicely
+
+Currently Deparse punts on deparsing the bitmask for warnings, which it
+dumps uglily as-is. Try running this:
+
+    $ ./perl -Ilib -MO=Deparse -e 'use warnings "pipe"; die'
+
+Deparse.pm could use the package variables in warnings.pm that warnings.pm
+itself uses to convert the list passed to it into a bitfield. Deparse just
+needs to reverse that.
+
+=head2 test and fix Deparse with perl's test suite
+
+If you run perl's tests with the TEST_ARGS environment variable set to
+C<-deparse> (e.g., run C<TEST=-deparse make test>), each test file will be
+deparsed and the deparsed output will be run. Currently there are many 
+failures, which ought to be fixed. There is in F<Porting/deparse-skips.txt>
+a list of tests known to fail, but it is out of date. Updating it would
+also help.
+
+This is an incremental task. Every small bit helps. It is also a task that
+may never end. As new tests are added, they tickle corner cases that
+B::Deparse cannot yet handle correctly.
+
+This task I<may> need a bit of perl guts knowledge. But what changes need
+to be made is usually easy to see by dumping op trees with B::Concise:
+
+    $ ./perl -Ilib -MO=Concise -e 'foo(); print @_; die $$_'
+
+and adjusting B::Deparse to handle whatever you see B::Concise produce.
+This is also a good way to I<learn> how perl's op trees work.
+
 =head1 Tasks that need a little sysadmin-type knowledge
 
 Or if you prefer, tasks that you would learn from, and broaden your skills
@@ -228,7 +285,7 @@ do a normal C<Configure>, but include Devel::Cover as a module to install
 
 =item *
 
   cd t; HARNESS_PERL_SWITCHES=-MDevel::Cover ./perl -I../lib harness
+ cd t; HARNESS_PERL_SWITCHES=-MDevel::Cover ./perl -I../lib harness
 
 =item *
 
@@ -291,33 +348,48 @@ installed machine differs from the build machine in some significant way.
 
 Some platforms mandate that you provide a list of a shared library's external
 symbols to the linker, so the core already has the infrastructure in place to
-do this for generating shared perl libraries. My understanding is that the
-GNU toolchain can accept an optional linker specification file, and restrict
-visibility just to symbols declared in that file. It would be good to extend
-F<makedef.pl> to support this format, and to provide a means within
-C<Configure> to enable it. This would allow Unix users to test that the
+do this for generating shared perl libraries. Florian Ragwitz has been working
+to offer this for the GNU toolchain, to  allow Unix users to test that the
 export list is correct, and to build a perl that does not pollute the global
 namespace with private symbols, and will fail in the same way as msvc or mingw 
-builds or when using PERL_DL_NONLAZY=1.
+builds or when using PERL_DL_NONLAZY=1. See the branch smoke-me/rafl/ld_export
 
 =head2 Cross-compile support
 
-Currently C<Configure> understands C<-Dusecrosscompile> option. This option
+We get requests for "how to cross compile Perl". The vast majority of these
+seem to be for a couple of scenarios:
+
+=over 4
+
+=item *
+
+Platforms that could build natively using F<./Configure> (I<e.g.> Linux or
+NetBSD on MIPS or ARM) but people want to use a beefier machine (and on the
+same OS) to build more easily.
+
+=item *
+
+Platforms that can't build natively, but no (significant) porting changes
+are needed to our current source code. Prime example of this is Android.
+
+=back
+
+There are several scripts and tools for cross-compiling perl for other
+platforms. However, these are somewhat inconsistent and scattered across the
+codebase, none are documented well, none are clearly flexible enough to
+be confident that they can support any TARGET/HOST platform pair other than
+that which they were developed on, and it's not clear how bitrotted they are.
+
+For example, C<Configure> understands C<-Dusecrosscompile> option. This option
 arranges for building C<miniperl> for TARGET machine, so this C<miniperl> is
-assumed then to be copied to TARGET machine and used as a replacement of full
-C<perl> executable.
-
-This could be done little differently. Namely C<miniperl> should be built for
-HOST and then full C<perl> with extensions should be compiled for TARGET.
-This, however, might require extra trickery for %Config: we have one config
-first for HOST and then another for TARGET.  Tools like MakeMaker will be
-mightily confused.  Having around two different types of executables and
-libraries (HOST and TARGET) makes life interesting for Makefiles and
-shell (and Perl) scripts.  There is $Config{run}, normally empty, which
-can be used as an execution wrapper.  Also note that in some
-cross-compilation/execution environments the HOST and the TARGET do
-not see the same filesystem(s), the $Config{run} may need to do some
-file/directory copying back and forth.
+assumed then to be copied to TARGET machine and used as a replacement of
+full C<perl> executable. This code is almost 10 years old. Meanwhile, the
+F<Cross/> directory contains two different approaches for cross compiling to
+ARM Linux targets, relying on hand curated F<config.sh> files, but that code
+is getting on for 5 years old, and requires insider knowledge of perl's
+build system to draft a F<config.sh> for a new platform.
+
+Jess Robinson has submitted a grant to TPF to work on cleaning this up.
 
 =head2 Split "linker" from "compiler"
 
@@ -413,7 +485,7 @@ Natively 64-bit systems need neither -Duse64bitint nor -Duse64bitall.
 On these systems, it might be the default compilation mode, and there
 is currently no guarantee that passing no use64bitall option to the
 Configure process will build a 32bit perl. Implementing -Duse32bit*
-options would be nice for perl 5.14.
+options would be nice for perl 5.25.2.
 
 =head2 Profile Perl - am I hot or not?
 
@@ -435,19 +507,6 @@ suggest evictions and promotions to achieve a better F<pp_hot.c>.
 
 One piece of Perl code that might make a good testbed is F<installman>.
 
-=head2 Allocate OPs from arenas
-
-Currently all new OP structures are individually malloc()ed and free()d.
-All C<malloc> implementations have space overheads, and are now as fast as
-custom allocates so it would both use less memory and less CPU to allocate
-the various OP structures from arenas. The SV arena code can probably be
-re-used for this.
-
-Note that Configuring perl with C<-Accflags=-DPL_OP_SLAB_ALLOC> will use
-Perl_Slab_alloc() to pack optrees into a contiguous block, which is
-probably superior to the use of OP arenas, esp. from a cache locality
-standpoint.  See L<Profile Perl - am I hot or not?>.
-
 =head2 Improve win32/wince.c
 
 Currently, numerous functions look virtually, if not completely,
@@ -502,26 +561,6 @@ the correct answer.
 been written so that it reflects the state of the read-only attribute, even
 for directories (whatever CRT is being used), for symmetry with chmod().)
 
-=head2 strcat(), strcpy(), strncat(), strncpy(), sprintf(), vsprintf()
-
-Maybe create a utility that checks after each libperl.a creation that
-none of the above (nor sprintf(), vsprintf(), or *SHUDDER* gets())
-ever creep back to libperl.a.
-
-  nm libperl.a | ./miniperl -alne '$o = $F[0] if /:$/; print "$o $F[1]" if $F[0] eq "U" && $F[1] =~ /^(?:strn?c(?:at|py)|v?sprintf|gets)$/'
-
-Note, of course, that this will only tell whether B<your> platform
-is using those naughty interfaces.
-
-=head2 -D_FORTIFY_SOURCE=2, -fstack-protector
-
-Recent glibcs support C<-D_FORTIFY_SOURCE=2> and recent gcc
-(4.1 onwards?) supports C<-fstack-protector>, both of which give
-protection against various kinds of buffer overflow problems.
-These should probably be used for compiling Perl whenever available,
-Configure and/or hints files should be adjusted to probe for the
-availability of these features and enable them as appropriate.
-
 =head2 Arenas for GPs? For MAGIC?
 
 C<struct gp> and C<struct magic> are both currently allocated by C<malloc>.
@@ -588,6 +627,11 @@ term, once the run-time implementation is proven, it should be possible to
 progressively update ExtUtils::ParseXS to generate OP implementations for
 some XSUBs.
 
+=head2 Document how XS modules can install lexical subs
+
+There is an example in XS::APItest (look for C<lexical_import> in
+F<ext/XS-APItest/APItest.xs>). The documentation could be based on it.
+
 =head2 Remove the use of SVs as temporaries in dump.c
 
 F<dump.c> contains debugging routines to dump out the contains of perl data
@@ -721,6 +765,11 @@ L</"Virtualize operating system access">.
 Currently the %ENV entries are always byte strings.
 See L</"Virtualize operating system access">.
 
+(See RT ticket #113536 for information on Win32's handling of %ENV,
+which was fixed to work with native ANSI codepage characters in the
+environment, but still doesn't work with other characters outside of
+that codepage present in the environment.)
+
 =head2 Unicode and glob()
 
 Currently glob patterns and filenames returned from File::Glob::glob()
@@ -749,17 +798,19 @@ allow taint to "leak" everywhere within an expression.
 
 system() accepts a LIST syntax (and a PROGRAM LIST syntax) to avoid
 running a shell. readpipe() (the function behind qx//) could be similarly
-extended.
+extended. Note that changing readpipe() itself may not be the solution, as
+it currently has unary precedence, and allowing a list would change the
+precedence.
 
 =head2 Audit the code for destruction ordering assumptions
 
 Change 25773 notes
 
   /* Need to check SvMAGICAL, as during global destruction it may be that
-       AvARYLEN(av) has been freed before av, and hence the SvANY() pointer
-       is now part of the linked list of SV heads, rather than pointing to
-       the original body.  */
   /* FIXME - audit the code for other bugs like this one.  */
+ /* Need to check SvMAGICAL, as during global destruction it may be that
+    AvARYLEN(av) has been freed before av, and hence the SvANY() pointer
+    is now part of the linked list of SV heads, rather than pointing to
+    the original body.  */
+ /* FIXME - audit the code for other bugs like this one.  */
 
 adding the C<SvMAGICAL> check to
 
@@ -786,14 +837,6 @@ readlink().
 
 See also L</"Virtualize operating system access">.
 
-=head2 -C on the #! line
-
-It should be possible to make -C work correctly if found on the #! line,
-given that all perl command line options are strict ASCII, and -C changes
-only the interpretation of non-ASCII characters, and not for the script file
-handle. To make it work needs some investigation of the ordering of function
-calls during startup, and (by implication) a bit of tweaking of that order.
-
 =head2 Organize error messages
 
 Perl's diagnostics (error messages, see L<perldiag>) could use
@@ -818,13 +861,42 @@ if available-- but B<only> if available, all platforms will B<not>
 have catgets().
 
 For the really pure at heart, consider extending this item to cover
-also the warning messages (see L<perllexwarn>, C<warnings.pl>).
+also the warning messages (see L<warnings>, F<regen/warnings.pl>).
 
 =head1 Tasks that need a knowledge of the interpreter
 
 These tasks would need C knowledge, and knowledge of how the interpreter works,
 or a willingness to learn.
 
+=head2 fix refaliasing with nested and recursive subroutines
+
+Currently aliasing lexical variables via reference only applies to the
+current subroutine, and does not propagate to inner closures, nor does
+aliasing of outer variables within closures propagate to the outer
+subroutine. This is because each subroutine has its own lexical pad and the
+aliasing works by changing which SV the pad points to.
+
+One possible way to fix this would be to create new ops for accessing
+variables that are closed over. So C<my $x; sub {$x}> would use a new op
+type, say C<padoutsv>, instead of the C<padsv> currently used in the
+sub. That new op would possibly check a flag or some such and see if it
+needs to fetch the variable from an outer pad. If we follow this approach,
+it should be possible at compile time to detect cases where the more
+complex C<padoutsv> op is unnecessary and revert back to the simpler,
+faster C<padsv>. There would need to be corresponding ops for arrays,
+hashes, and subs, too.
+
+There is also a related issue with recursion and C<state> variables. A
+subroutine actually has a list of lexical pads, each one used at a
+different recursion level. If a C<state> variable is aliased to another
+variable after a recursive call to the same subroutine, that higher call
+depth will not see the effect of aliasing, because the second pad will have
+been created already. Similarly, aliasing a state variable within a
+recursive call will not affect outer calls, even though all call depths are
+supposed to share the same C<state> variables.
+
+Both of these bugs affect C<foreach> aliasing, too.
+
 =head2 forbid labels with keyword names
 
 Currently C<goto keyword> "computes" the label value:
@@ -839,14 +911,7 @@ bareword expressions after a "goto" as a label and never as a keyword.
 =head2 truncate() prototype
 
 The prototype of truncate() is currently C<$$>. It should probably
-be C<*$> instead. (This is changed in F<opcode.pl>)
-
-=head2 decapsulation of smart match argument
-
-Currently C<$foo ~~ $object> will die with the message "Smart matching a
-non-overloaded object breaks encapsulation". It would be nice to allow
-to bypass this by using explicitly the syntax C<$foo ~~ %$object> or
-C<$foo ~~ @$object>.
+be C<*$> instead. (This is changed in F<regen/opcodes>.)
 
 =head2 error reporting of [$a ; $b]
 
@@ -865,6 +930,12 @@ I<';' isn't legal inside an expression - if you need multiple statements use a
 do {...} block>. See the thread starting at
 L<http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2008-09/msg00573.html>
 
+=head2 strict as warnings
+
+See L<http://markmail.org/message/vbrupaslr3bybmvk>, where Joshua ben Jore
+writes:  I've been of the opinion that everything strict.pm does ought to be
+able to considered just warnings that have been promoted to 'FATAL'.
+
 =head2 lexicals used only once
 
 This warns:
@@ -889,14 +960,7 @@ candidates.  The whole Unicode database could be placed in-core for a
 huge speed-up.  Only minimal work was done on the optimizer when utf8
 was added, with the result that the synthetic start class often will
 fail to narrow down the possible choices when given non-Latin1 input.
-
-=head2 Properly Unicode safe tokeniser and pads.
-
-The tokeniser isn't actually very UTF-8 clean. C<use utf8;> is a hack -
-variable names are stored in stashes as raw bytes, without the utf-8 flag
-set. The pad API only takes a C<char *> pointer, so that's all bytes too. The
-tokeniser ignores the UTF-8-ness of C<PL_rsfp>, or any SVs returned from
-source filters.  All this could be fixed.
+Karl Williamson has been working on this - talk to him.
 
 =head2 state variable initialization in list context
 
@@ -911,11 +975,6 @@ implement the necessary code in Perl 5. There are comments in
 C<Perl_newASSIGNOP()> that show the code paths taken by various assignment
 constructions involving state variables.
 
-=head2 Implement $value ~~ 0 .. $range
-
-It would be nice to extend the syntax of the C<~~> operator to also
-understand numeric (and maybe alphanumeric) ranges.
-
 =head2 A does() built-in
 
 Like ref(), only useful. It would call the C<DOES> method on objects; it
@@ -944,15 +1003,11 @@ program if you pass the process ID. It would be good to do this with the Perl
 debugger on a running Perl program, although I'm not sure how it would be
 done." ssh and screen do this with named pipes in /tmp. Maybe we can too.
 
-=head2 LVALUE functions for lists
-
-The old perltodo notes that lvalue functions don't work for list or hash
-slices. This would be good to fix.
+=head2 regexp optimizer optional
 
-=head2 regexp optimiser optional
-
-The regexp optimiser is not optional. It should configurable to be, to allow
-its performance to be measured, and its bugs to be easily demonstrated.
+The regexp optimizer is not optional. It should be configurable to be optional
+and to allow its performance to be measured and its bugs to be easily
+demonstrated.
 
 =head2 C</w> regex modifier
 
@@ -980,17 +1035,6 @@ have a general mechanism for this, backwards compatible and little speed hit.
 This would allow proposals such as short circuiting sort to be implemented
 as a module on CPAN.
 
-=head2 lexical aliases
-
-Allow lexical aliases (maybe via the syntax C<my \$alias = \$foo>.
-
-=head2 entersub XS vs Perl
-
-At the moment pp_entersub is huge, and has code to deal with entering both
-perl and XS subroutines. Subroutine implementations rarely change between 
-perl and XS at run time, so investigate using 2 ops to enter subs (one for
-XS, one for perl) and swap between if a sub is redefined.
-
 =head2 Self-ties
 
 Self-ties are currently illegal because they caused too many segfaults. Maybe
@@ -1004,14 +1048,15 @@ The old perltodo notes "Look at the "reification" code in C<av.c>".
 =head2 Virtualize operating system access
 
 Implement a set of "vtables" that virtualizes operating system access
-(open(), mkdir(), unlink(), readdir(), getenv(), etc.)  At the very
-least these interfaces should take SVs as "name" arguments instead of
-bare char pointers; probably the most flexible and extensible way
-would be for the Perl-facing interfaces to accept HVs.  The system
-needs to be per-operating-system and per-file-system
-hookable/filterable, preferably both from XS and Perl level
-(L<perlport/"Files and Filesystems"> is good reading at this point,
-in fact, all of L<perlport> is.)
+(chdir(), chmod(), dbmopen(), getenv(), glob(), link(), mkdir(), open(),
+opendir(), readdir(), rename(), rmdir(), stat(), sysopen(), uname(),
+unlink(), etc.)  At the very least these interfaces should take SVs as
+"name" arguments instead of bare char pointers; probably the most
+flexible and extensible way would be for the Perl-facing interfaces to
+accept HVs.  The system needs to be per-operating-system and
+per-file-system hookable/filterable, preferably both from XS and Perl
+level (L<perlport/"Files and Filesystems"> is good reading at this
+point, in fact, all of L<perlport> is.)
 
 This has actually already been implemented (but only for Win32),
 take a look at F<iperlsys.h> and F<win32/perlhost.h>.  While all Win32
@@ -1036,29 +1081,18 @@ implement per-thread working directories: Win32 already does this.
 
 See also L</"Extend PerlIO and PerlIO::Scalar">.
 
-=head2 Store the current pad in the OP slab allocator
-
-=for clarification
-I hope that I got that "current pad" part correct
-
-Currently we leak ops in various cases of parse failure. I suggested that we
-could solve this by always using the op slab allocator, and walking it to
-free ops. Dave comments that as some ops are already freed during optree
-creation one would have to mark which ops are freed, and not double free them
-when walking the slab. He notes that one problem with this is that for some ops
-you have to know which pad was current at the time of allocation, which does
-change. I suggested storing a pointer to the current pad in the memory allocated
-for the slab, and swapping to a new slab each time the pad changes. Dave thinks
-that this would work.
-
 =head2 repack the optree
 
+B<Note:> This entry was written in reference to the I<old> slab allocator,
+removed in commit 7aef8e5bd14.
+
 Repacking the optree after execution order is determined could allow
 removal of NULL ops, and optimal ordering of OPs with respect to cache-line
-filling.  The slab allocator could be reused for this purpose.  I think that
+filling.  I think that
 the best way to do this is to make it an optional step just before the
 completed optree is attached to anything else, and to use the slab allocator
-unchanged, so that freeing ops is identical whether or not this step runs.
+unchanged--but allocate a single slab the right size, avoiding partial
+slabs--, so that freeing ops is identical whether or not this step runs.
 Note that the slab allocator allocates ops downwards in memory, so one would
 have to actually "allocate" the ops in reverse-execution order to get them
 contiguous in memory in execution order.
@@ -1076,7 +1110,7 @@ This code
 
     use warnings;
     my $undef;
-    
+
     if ($undef == 3) {
     } elsif ($undef == 0) {
     }
@@ -1099,7 +1133,7 @@ most common and the most confusing). Ideally this code
 
     use warnings;
     my $undef;
-    
+
     my $a = $undef + 1;
     my $b
       = $undef
@@ -1107,8 +1141,8 @@ most common and the most confusing). Ideally this code
 
 would produce this output
 
   Use of uninitialized value $undef in addition (+) at wrong.pl line 4.
   Use of uninitialized value $undef in addition (+) at wrong.pl line 7.
+ Use of uninitialized value $undef in addition (+) at wrong.pl line 4.
+ Use of uninitialized value $undef in addition (+) at wrong.pl line 7.
 
 (rather than lines 4 and 5), but this would seem to require every OP to carry
 (at least) line number information.
@@ -1116,7 +1150,7 @@ would produce this output
 What might work is to have an optional line number in memory just before the
 BASEOP structure, with a flag bit in the op to say whether it's present.
 Initially during compile every OP would carry its line number. Then add a late
-pass to the optimiser (potentially combined with L</repack the optree>) which
+pass to the optimizer (potentially combined with L</repack the optree>) which
 looks at the two ops on every edge of the graph of the execution path. If
 the line number changes, flags the destination OP with this information.
 Once all paths are traced, replace every op with the flag with a
@@ -1147,20 +1181,35 @@ combines the code in pp_entersub, pp_leavesub.  This should probably
 be done 1st in XS, and using B::Generate to patch the new OP into the
 optrees.
 
-=head2 Add C<00dddd>
+=head2 Add C<0odddd>
 
 It has been proposed that octal constants be specifiable through the syntax
 C<0oddddd>, parallel to the existing construct to specify hex constants
 C<0xddddd>
 
+=head2 Revisit the regex super-linear cache code
+
+Perl executes regexes using the traditional backtracking algorithm, which
+makes it possible to implement a variety of powerful pattern-matching
+features (like embedded code blocks), at the cost of taking exponential time
+to run on some pathological patterns.  The exponential-time problem is
+mitigated by the I<super-linear cache>, which detects when we're processing
+such a pathological pattern, and does some additional bookkeeping to avoid
+much of the work.  However, that code has bit-rotted a little; some patterns
+don't make as much use of it as they should.  The proposal is to analyse
+where the current cache code has problems, and extend it to cover those cases.
+
+See also
+L<http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2013-01/msg00339.html>
+
 =head1 Big projects
 
 Tasks that will get your name mentioned in the description of the "Highlights
-of 5.14"
+of 5.25.2"
 
 =head2 make ithreads more robust
 
-Generally make ithreads more robust. See also L</iCOW>
+Generally make ithreads more robust.
 
 This task is incremental - even a little bit of work on it will help, and
 will be greatly appreciated.
@@ -1170,34 +1219,12 @@ without a C<fchdir> function (in sv.c:Perl_dirp_dup).
 
 Fix Perl_sv_dup, et al so that threads can return objects.
 
-=head2 iCOW
-
-Sarathy and Arthur have a proposal for an improved Copy On Write which
-specifically will be able to COW new ithreads. If this can be implemented
-it would be a good thing.
-
-=head2 (?{...}) closures in regexps
-
-Fix (or rewrite) the implementation of the C</(?{...})/> closures.
-
-=head2 Add class set operations to regexp engine
-
-Apparently these are quite useful. Anyway, Jeffery Friedl wants them.
-
-demerphq has this on his todo list, but right at the bottom.  
-
-
 =head1 Tasks for microperl
 
 
 [ Each and every one of these may be obsolete, but they were listed
   in the old Todo.micro file]
 
-
-=head2 make creating uconfig.sh automatic 
-
-=head2 make creating Makefile.micro automatic
-
 =head2 do away with fork/exec/wait?
 
 (system, popen should be enough?)