The roadmap to 5.10 envisages feature based releases, as various items in this
TODO are completed.
-=head2 Needed for a 5.9.3 release
+=head2 Needed for a 5.9.4 release
=over
=item *
-Implement L</lexical pragmas>
-
-=back
-
-=head2 Needed for a 5.9.4 release
-=over
+Review assertions. Review syntax to combine assertions. Assertions could take
+advantage of the lexical pragmas work. L</What hooks would assertions need?>
=item *
-Review assertions. Review syntax to combine assertions. Can assertions take
-advantage of the lexical pragams work? L</What hooks would assertions need?>
+
+C<encoding::warnings> should be turned into a lexical pragma.
+C<encoding> should, too (probably).
=back
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
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?
+It's also worth checking that all variables are actually used. Perl 5.8.0
+shipped with C<PL_nrs> still defined in F<thrdvar.h>, despite it being unused
+since a change over a year earlier. Had this been spotted before release, it
+could have been removed, but now it has to remain in the 5.8.x releases to
+keep the structure the same size, to retain binary compatibility.
=head2 am I hot or not?
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?
-
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.
=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
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
This task is incremental - even a little bit of work on it will help, and
will be greatly appreciated.
+One bit would be to write the missing code in sv.c:Perl_dirp_dup.
+
=head2 iCOW
Sarathy and Arthur have a proposal for an improved Copy On Write which
projects / p5sagit/p5-mst-13.2.git / blobdiff