=head1 NAME perltodo - Perl TO-DO List =head1 DESCRIPTION This is a list of wishes for Perl. The most up to date version of this file is at http://perl5.git.perl.org/perl.git/blob_plain/HEAD:/pod/perltodo.pod The tasks we think are smaller or easier are listed first. Anyone is welcome to work on any of these, but it's a good idea to first contact I to avoid duplication of effort, and to learn from any previous attempts. By all means contact a pumpking privately first if you prefer. Whilst patches to make the list shorter are most welcome, ideas to add to the list are also encouraged. Check the perl5-porters archives for past 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 file, which ships in the official distribution. How many other programming languages offer you 1 line of immortality? =head1 Tasks that only need Perl knowledge =head2 Remove macperl references from tests MacPerl is gone. The tests don't need to be there. =head2 Remove duplication of test setup. Schwern notes, that there's duplication of code - lots and lots of tests have some variation on the big block of C<$Is_Foo> checks. We can safely put this into a file, change it to build an C<%Is> hash and require it. Maybe just put it into F. Throw in the handy tainting subroutines. =head2 POD -E 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 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, as the layout of installation tree is needed to improve the cross-linking. The addition of C and its related modules may make this task easier to complete. =head2 Make ExtUtils::ParseXS use strict; F contains this line # use strict; # One of these days... Simply uncomment it, and fix all the resulting issues :-) The more practical approach, to break the task down into manageable chunks, is to work your way though the code from bottom to top, or if necessary adding extra C<{ ... }> blocks, and turning on strict within them. =head2 Parallel testing (This probably impacts much more than the core: also the Test::Harness and TAP::* modules on CPAN.) All of the tests in F can now be run in parallel, if C<$ENV{TEST_JOBS}> is set. However, tests within each directory in F and F are still run in series, with directories run in parallel. This is an adequate heuristic, but it might be possible to relax it further, and get more throughput. Specifically, it would be good to audit all of F, and make them use C. =head2 Make Schwern poorer We should have tests for everything. When all the core's modules are tested, 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 Improve the coverage of the core tests Use Devel::Cover to ascertain the core modules's test coverage, then add tests that are currently missing. =head2 test B A full test suite for the B module would be nice. =head2 A decent benchmark C 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 guide people attempting to optimise the guts of perl. Gisle would welcome new tests for perlbench. =head2 fix tainting bugs Fix the bugs revealed by running the test suite with the C<-t> switch (via C). =head2 Dual life everything As part of the "dists" plan, anything that doesn't belong in the smallest perl distribution needs to be dual lifed. Anything else can be too. Figure out what changes would be needed to package that module and its tests up for CPAN, and do so. Test it with older perl releases, and fix the problems you find. To make a minimal perl distribution, it's useful to look at F. =head2 Bundle dual life modules in ext/ For maintenance (and branch merging) reasons, it would be useful to move some architecture-independent dual-life modules from lib/ to ext/, if this has no negative impact on the build of perl itself. =head2 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. =head2 embed.pl/makedef.pl There is a script F 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. Functions are declared in F, variables in F. Quite a few of the functions and variables are conditionally declared there, using C<#ifdef>. However, F doesn't understand the C macros, so the rules about which symbols are present when is duplicated in F. Writing things twice is bad, m'kay. It would be good to teach C to understand the conditional compilation, and hence remove the duplication, and the mistakes it has caused. =head2 use strict; and AutoLoad Currently if you write package Whack; use AutoLoader 'AUTOLOAD'; use strict; 1; __END__ sub bloop { print join (' ', No, strict, here), "!\n"; } then C isn't in force within the autoloaded subroutines. It would be more consistent (and less surprising) to arrange for all lexical pragmas in force at the __END__ block to be in force within each autoloaded subroutine. There's a similar problem with SelfLoader. =head2 profile installman The F script is slow. All it is doing text processing, which we're told is something Perl is good at. So it would be nice to know what it is doing that is taking so much CPU, and where possible address it. =head1 Tasks that need a little sysadmin-type knowledge Or if you prefer, tasks that you would learn from, and broaden your skills base... =head2 make HTML install work There is an C target in the Makefile. It's marked as "experimental". It would be good to get this tested, make it work reliably, and remove the "experimental" tag. This would include =over 4 =item 1 Checking that cross linking between various parts of the documentation works. In particular that links work between the modules (files with POD in F) and the core documentation (files in F) =item 2 Work out how to split C 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 to C, two or more C<=items> giving the different parameter lists, such as =item substr EXPR,OFFSET,LENGTH,REPLACEMENT =item substr EXPR,OFFSET,LENGTH =item substr EXPR,OFFSET and different parameter lists having different meanings. (eg C