X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=blobdiff_plain;f=pod%2Fperltodo.pod;h=a8a6d797cc656c8d6a8f5f1ea164dd8c8c487de4;hb=3246d7a3ad86dfa806dd7e514ae5fd2dacd5c0ef;hp=0ae7aea02aa78d272ee53fca178e92b9a75ad56c;hpb=30222c0f41971add379ea16c00a07c51f510eb5d;p=p5sagit%2Fp5-mst-13.2.git

diff --git a/pod/perltodo.pod b/pod/perltodo.pod
index 0ae7aea..a8a6d79 100644
--- a/pod/perltodo.pod
+++ b/pod/perltodo.pod
@@ -15,9 +15,42 @@ ideas, and any discussion about them. One set of archives may be found at:
 
     http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/
 
+What can we offer you in return? Fame, fortune, and everlasting glory? Maybe
+not, but if your patch is incorporated, then we'll add your name to the
+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
 
@@ -36,6 +69,37 @@ 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 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,
@@ -56,7 +120,7 @@ A full test suite for the B module would be nice.
 
 =head2 A decent benchmark
 
-perlbench seems impervious to any recent changes made to the perl core. It
+C<perlbench> seems impervious to any recent changes made to the perl core. It
 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
@@ -97,6 +161,12 @@ for example POSIX passes Exporter some very memory hungry data structures.
 Or if you prefer, tasks that you would learn from, and broaden your skills
 base...
 
+=head2 Relocatable perl
+
+The C level patches needed to create a relocatable perl binary are done, as
+is the work on F<Config.pm>. All that's left to do is the C<Configure> tweaking
+to let people specify how they want to do the install.
+
 =head2 make HTML install work
 
 There is an C<installhtml> target in the Makefile. It's marked as
@@ -113,12 +183,13 @@ and the core documentation (files in F<pod/>)
 
 =item 2
 
-Work out how to split perlfunc into chunks, preferably one per function group,
-preferably with general case code that could be used elsewhere. Challenges
-here are correctly identifying the groups of functions that go together, and
-making the right named external cross-links point to the right page. Things to
-be aware of are C<-X>, groups such as C<getpwnam> to C<endservent>, two or
-more C<=items> giving the different parameter lists, such as
+Work out how to split C<perlfunc> into chunks, preferably one per function
+group, preferably with general case code that could be used elsewhere.
+Challenges here are correctly identifying the groups of functions that go
+together, and making the right named external cross-links point to the right
+page. Things to be aware of are C<-X>, groups such as C<getpwnam> to
+C<endservent>, two or more C<=items> giving the different parameter lists, such
+as
 
     =item substr EXPR,OFFSET,LENGTH,REPLACEMENT
     
@@ -214,12 +285,24 @@ possibly involving probing at install time or later, so that the C<%Config> in
 a binary distribution better describes the installed machine, when the
 installed machine differs from the build machine in some significant way.
 
-=head2 Relocatable perl
+=head2 make parallel builds work
 
-The C level patches needed to create a relocatable perl binary are done, as
-is the work on Config.pm. All that's left to do is the C<Configure> tweaking
-to let people specify how they want to do the install.
+Currently parallel builds (such as C<make -j3>) don't work reliably. We believe
+that this is due to incomplete dependency specification in the F<Makefile>.
+It would be good if someone were able to track down the causes of these
+problems, so that parallel builds worked properly.
 
+=head2 linker specification files
+
+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
+export list is correct, and to build a perl that does not pollute the global
+namespace with private symbols.
 
 
 
@@ -231,9 +314,9 @@ background or experience with XS, or how the Perl interpreter works
 
 =head2 Make it clear from -v if this is the exact official release
 
-Currently perl from p4/rsync ships with a patchlevel.h file that usually
-defines one local patch, of the form "MAINT12345" or "RC1". The output of
-perl -v doesn't report that a perl isn't an official release, and this
+Currently perl from C<p4>/C<rsync> ships with a F<patchlevel.h> file that
+usually defines one local patch, of the form "MAINT12345" or "RC1". The output
+of perl -v doesn't report that a perl isn't an official release, and this
 information can get lost in bugs reports. Because of this, the minor version
 isn't bumped up until RC time, to minimise the possibility of versions of perl
 escaping that believe themselves to be newer than they actually are.
@@ -251,11 +334,93 @@ such that it's trivial for the Pumpking to flag "this is an official release"
 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
+per-thread under ithreads, where the variables are actually elements in a
+structure. As C dictates, the variables must be laid out in order of
+declaration. There is a comment
+C</* Important ones in the first cache line (if alignment is done right) */>
+which implies that at some point in the past the ordering was carefully chosen
+(at least in part). However, it's clear that the ordering is less than perfect,
+as currently there are things such as 7 C<bool>s in a row, then something
+typically requiring 4 byte alignment, and then an odd C<bool> later on.
+(C<bool>s are typically defined as C<char>s). So it would be good for someone
+to review the ordering of the variables, to see how much alignment padding can
+be removed.
+
 =head2 bincompat functions
 
 There are lots of functions which are retained for binary compatibility.
 Clean these up. Move them to mathom.c, and don't compile for blead?
 
+=head2 am I hot or not?
+
+The idea of F<pp_hot.c> is that it contains the I<hot> ops, the ops that are
+most commonly used. The idea is that by grouping them, their object code will
+be adjacent in the executable, so they have a greater chance of already being
+in the CPU cache (or swapped in) due to being near another op already in use.
+
+Except that it's not clear if these really are the most commonly used ops. So
+anyone feeling like exercising their skill with coverage and profiling tools
+might want to determine what ops I<really> are the most commonly used. And in
+turn suggest evictions and promotions to achieve a better F<pp_hot.c>.
+
+=head2 emulate the per-thread memory pool on Unix
+
+For Windows, ithreads allocates memory for each thread from a separate pool,
+which it discards at thread exit. It also checks that memory is free()d to
+the correct pool. Neither check is done on Unix, so code developed there won't
+be subject to such strictures, so can harbour bugs that only show up when the
+code reaches Windows.
+
+It would be good to be able to optionally emulate the Window pool system on
+Unix, to let developers who only have access to Unix, or want to use
+Unix-specific debugging tools, check for these problems. To do this would
+involve figuring out how the C<PerlMem_*> macros wrap C<malloc()> access, and
+providing a layer that records/checks the identity of the thread making the
+call, and recording all the memory allocated by each thread via this API so
+that it can be summarily free()d at thread exit. One implementation idea
+would be to increase the size of allocation, and store the C<my_perl> pointer
+(to identify the thread) at the start, along with pointers to make a linked
+list of blocks for this thread. To avoid alignment problems it would be
+necessary to do something like
+
+  union memory_header_padded {
+    struct memory_header {
+      void *thread_id;   /* For my_perl */
+      void *next;        /* Pointer to next block for this thread */
+    } data;
+    long double padding; /* whatever type has maximal alignment constraint */
+  };
+
+
+although C<long double> might not be the only type to add to the padding
+union.
+
+=head2 reduce duplication in sv_setsv_flags
+
+C<Perl_sv_setsv_flags> has a comment
+C</* There's a lot of redundancy below but we're going for speed here */>
+
+Whilst this was true 10 years ago, the growing disparity between RAM and CPU
+speeds mean that the trade offs have changed. In addition, the duplicate code
+adds to the maintenance burden. It would be good to see how much of the
+redundancy can be pruned, particular in the less common paths. (Profiling
+tools at the ready...). For example, why does the test for
+"Can't redefine active sort subroutine" need to occur in two places?
 
 
 
@@ -270,6 +435,23 @@ C.
 
 Clean this up. Check everything in core works
 
+=head2 shrink C<GV>s, C<CV>s
+
+By removing unused elements and careful re-ordering, the structures for C<AV>s
+and C<HV>s have recently been shrunk considerably. It's probable that the same
+approach would find savings in C<GV>s and C<CV>s, if not all the other
+larger-than-C<PVMG> types.
+
+=head2 merge Perl_sv_2[inpu]v
+
+There's a lot of code shared between C<Perl_sv_2iv_flags>,
+C<Perl_sv_2uv_flags>, C<Perl_sv_2nv>, and C<Perl_sv_2pv_flags>. It would be
+interesting to see if some of it can be merged into common shared static
+functions. In particular, C<Perl_sv_2uv_flags> started out as a cut&paste
+from C<Perl_sv_2iv_flags> around 5.005_50 time, and it may be possible to
+replace both with a single function that returns a value or union which is
+split out by the macros in F<sv.h>
+
 =head2 UTF8 caching code
 
 The string position/offset cache is not optional. It should be.
@@ -354,10 +536,8 @@ or a willingness to learn.
 
 =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
 
@@ -366,16 +546,6 @@ 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 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
@@ -398,6 +568,11 @@ would be good to fix.
 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
@@ -451,12 +626,6 @@ instated.
 
 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
@@ -470,8 +639,6 @@ the imagination of future CPAN authors.
 
 
 
-
-
 =head1 Big projects
 
 Tasks that will get your name mentioned in the description of the "Highlights
@@ -479,7 +646,7 @@ of 5.10"
 
 =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.