F<AUTHORS> file, which ships in the official distribution. How many other
programming languages offer you 1 line of immortality?
+=head1 The roadmap to 5.10
+The roadmap to 5.10 envisages feature based releases, as various items in this
+TODO are completed.
+
+=head2 Needed for a 5.9.4 release
+
+=over
+
+=item *
+
+Review assertions. Review syntax to combine assertions. Assertions could take
+advantage of the lexical pragmas work. L</What hooks would assertions need?>
+
+=back
+
+=head2 Needed for a 5.9.5 release
+
+=over
+
+=item *
+Implement L</_ prototype character>
+
+=item *
+Implement L</state variables>
+
+=back
+
+=head2 Needed for a 5.9.6 release
+
+Stabilisation. If all goes well, this will be the equivalent of a 5.10-beta.
=head1 Tasks that only need Perl knowledge
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 Parallel testing
+
+The core regression test suite is getting ever more comprehensive, which has
+the side effect that it takes longer to run. This isn't so good. Investigate
+whether it would be feasible to give the harness script the B<option> of
+running sets of tests in parallel. This would be useful for tests in
+F<t/op/*.t> and F<t/uni/*.t> and maybe some sets of tests in F<lib/>.
+
+Questions to answer
+
+=over 4
+
+=item 1
+
+How does screen layout work when you're running more than one test?
+
+=item 2
+
+How does the caller of test specify how many tests to run in parallel?
+
+=item 3
+
+How do setup/teardown tests identify themselves?
+
+=back
+
+Pugs already does parallel testing - can their approach be re-used?
+
=head2 Make Schwern poorer
We should have for everything. When all the core's modules are tested,
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 Refactor C<xsubpp> to be a thin wrapper around C<ExtUtils::ParseXS>
-
-C<ExtUtils::ParseXS> encapsulates a version of the C<xsubpp> into a module.
-In effect this is a code fork, and it's likely that C<xsubpp> has had some
-bug fixes since the code from C<ExtUtils::ParseXS> was derived. It would be
-good to merge the differences in, reduce down to 1 canonical implementation,
-and convert C<xsubpp> to a very thin command line wrapper to
-C<ExtUtils::ParseXS>.
-
-In theory this needs no real C knowledge, as one way of approaching this task
-is to ensure that C<ExtUtils::ParseXS> generates identical output to C<xsubpp>
-for input XS files, which does not require understanding the contents of the
-output C file. However, some C knowledge is likely to help with testing, and
-locating/producing comprehensive test cases.
when making a tarball, yet leave the default source saying "I'm not the
official release".
+=head2 Tidy up global variables
+
+There's a note in F<intrpvar.h>
+
+ /* These two variables are needed to preserve 5.8.x bincompat because
+ we can't change function prototypes of two exported functions.
+ Probably should be taken out of blead soon, and relevant prototypes
+ changed. */
+
+So doing this, and removing any of the unused variables still present would
+be good.
+
=head2 Ordering of "global" variables.
F<thrdvar.h> and F<intrpvarh> define the "global" variables that need to be
=head2 lexical pragmas
-Reimplement the mechanism of lexical pragmas to be more extensible. Fix
-current pragmas that don't work well (or at all) with lexical scopes or in
-run-time eval(STRING) (C<sort>, C<re>, C<encoding> for example). MJD has a
-preliminary patch that implements this.
+Document the new support for lexical pragmas in 5.9.3 and how %^H works.
+Maybe C<re>, C<encoding>, maybe other pragmas could be made lexical.
=head2 Attach/detach debugger from running program
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 inlining autoloaded constants
-
-Currently the optimiser can inline constants when expressed as subroutines
-with prototype ($) that return a constant. Likewise, many packages wrapping
-C libraries export lots of constants as subroutines which are AUTOLOADed on
-demand. However, these have no prototypes, so can't be seen as constants by
-the optimiser. Some way of cheaply (low syntax, low memory overhead) to the
-perl compiler that a name is a constant would be great, so that it knows to
-call the AUTOLOAD routine at compile time, and then inline the constant.
-
=head2 Constant folding
The peephole optimiser should trap errors during constant folding, and give
Study the possibility of adding a new prototype character, C<_>, meaning
"this argument defaults to $_".
+=head2 state variables
+
+C<my $foo if 0;> is deprecated, and should be replaced with
+C<state $x = "initial value\n";> the syntax from Perl 6.
+
=head2 @INC source filter to Filter::Simple
The second return value from a sub in @INC can be a source filter. This isn't
The old perltodo notes "Look at the "reification" code in C<av.c>".
-=head2 switch ops
-
-The old perltodo notes "Although we have C<Switch.pm> in core, Larry points to
-the dormant C<nswitch> and C<cswitch> ops in F<pp.c>; using these opcodes would
-be much faster."
-
=head2 What hooks would assertions need?
Assertions are in the core, and work. However, assertions needed to be added
-
-
=head1 Big projects
Tasks that will get your name mentioned in the description of the "Highlights
=head2 make ithreads more robust
-Generally make ithreads more robust. See also L<iCOW>
+Generally make ithreads more robust. See also L</iCOW>
This task is incremental - even a little bit of work on it will help, and
will be greatly appreciated.
projects / p5sagit/p5-mst-13.2.git / blobdiff