X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=blobdiff_plain;f=pod%2Fperltodo.pod;h=b48782c8cdab8d3de43da2bcc2560a516e10c2b8;hb=cb39f75f02caa9f23c14dfcac8a46fb1bd154b4f;hp=558921ce77011c32097fe603d24a9d8953632945;hpb=565590b5d66dafeef2ec402e8f2aecb5e1fc2a60;p=p5sagit%2Fp5-mst-13.2.git diff --git a/pod/perltodo.pod b/pod/perltodo.pod index 558921c..b48782c 100644 --- a/pod/perltodo.pod +++ b/pod/perltodo.pod @@ -4,11 +4,14 @@ perltodo - Perl TO-DO List =head1 DESCRIPTION -This is a list of wishes for Perl. 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. +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 @@ -23,55 +26,52 @@ programming languages offer you 1 line of immortality? =head1 Tasks that only need Perl knowledge -=head2 Smartmatch design issues - -In 5.10.0 the smartmatch operator C<~~> isn't working quite "right". But -before we can fix the implementation, we need to define what "right" is. -The first problem is that Robin Houston implemented the Perl 6 smart match -spec as of February 2006, when smart match was axiomatically symmetrical: -L - -Since then the Perl 6 target moved, but the Perl 5 implementation did not. - -So it would be useful for someone to compare the Perl 6 smartmatch table -as of February 2006 L -and the current table L -and tabulate the differences in Perl 6. The annotated view of changes is -L and the diff is -C --- search for C<=head1 Smart matching>. (In theory F can generate that, -but in practice when I tried it hung forever, I assume "thinking") - -With that done and published, someone (else) can then map any changed Perl 6 -semantics back to Perl 5, based on how the existing semantics map to Perl 5: -L - +=head2 Migrate t/ from custom TAP generation -There are also some questions that need answering: +Many tests below F still generate TAP by "hand", rather than using library +functions. As explained in L, tests in F are +written in a particular way to test that more complex constructions actually +work before using them routinely. Hence they don't use C, but +instead there is an intentionally simpler library, F. However, +quite a few tests in F have not been refactored to use it. Refactoring +any of these tests, one at a time, is a useful thing TODO. -=over 4 +=head2 Test that regen.pl was run -=item * +There are various generated files shipped with the perl distribution, for +things like header files generate from data. The generation scripts are +written in perl, and all can be run by F. However, because they're +written in perl, we can't run them before we've built perl. We can't run them +as part of the F, because changing files underneath F confuses +it completely, and we don't want to run them automatically anyway, as they +change files shipped by the distribution, something we seek not do to. -How do you negate one? (documentation issue) -http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2008-01/msg00071.html +If someone changes the data, but forgets to re-run F then the +generated files are out of sync. It would be good to have a test in +F that checks that the generated files are in sync, and fails +otherwise, to alert someone before they make a poor commit. I suspect that this +would require adapting the scripts run from F to have dry-run +options, and invoking them with these, or by refactoring them into a library +that does the generation, which can be called by the scripts, and by the test. -=item * +=head2 Automate perldelta generation -Array behaviors -http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2007-12/msg00799.html +The perldelta file accompanying each release summaries the major changes. +It's mostly manually generated currently, but some of that could be +automated with a bit of perl, specifically the generation of -* Should smart matches be symmetrical? (Perl 6 says no) +=over -* Other differences between Perl 5 and Perl 6 smart match? +=item Modules and Pragmata -=item * +=item New Documentation -Objects and smart match -http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2007-12/msg00865.html +=item New Tests =back +See F for details. + =head2 Remove duplication of test setup. Schwern notes, that there's duplication of code - lots and lots of tests have @@ -91,24 +91,17 @@ is needed to improve the cross-linking. The addition of C and its related modules may make this task easier to complete. -=head2 merge checkpods and podchecker +=head2 Make ExtUtils::ParseXS use strict; -F (and C in the F subdirectory) -implements a very basic check for pod files, but the errors it discovers -aren't found by podchecker. Add this check to podchecker, get rid of -checkpods and have C use podchecker. +F contains this line -=head2 Parallel testing + # use strict; # One of these days... -(This probably impacts much more than the core: also the Test::Harness -and TAP::* modules on CPAN.) +Simply uncomment it, and fix all the resulting issues :-) -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. +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 Make Schwern poorer @@ -126,28 +119,6 @@ tests that are currently missing. A full test suite for the B module would be nice. -=head2 Deparse inlined constants - -Code such as this - - use constant PI => 4; - warn PI - -will currently deparse as - - use constant ('PI', 4); - warn 4; - -because the tokenizer inlines the value of the constant subroutine C. -This allows various compile time optimisations, such as constant folding -and dead code elimination. Where these haven't happened (such as the example -above) it ought be possible to make B::Deparse work out the name of the -original constant, because just enough information survives in the symbol -table to do this. Specifically, the same scalar is used for the constant in -the optree as is used for the constant subroutine, so by iterating over all -symbol tables and generating a mapping of SV address to constant name, it -would be possible to provide B::Deparse with this functionality. - =head2 A decent benchmark C seems impervious to any recent changes made to the perl core. It @@ -172,11 +143,13 @@ 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/ +=head2 Move dual-life pod/*.PL into 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. +Nearly all the dual-life modules have been moved to F. However, we +still need to move F into their respective directories +in F. They're referenced by (at least) C in F +and C in F and F, and listed +explicitly in F, F and F =head2 POSIX memory footprint @@ -426,6 +399,29 @@ C<$Config{link}> and institute a fall-back plan if it weren't found." Although I can see that as confusing, given that C<$Config{d_link}> is true when (hard) links are available. +=head2 Configure Windows using PowerShell + +Currently, Windows uses hard-coded config files based to build the +config.h for compiling Perl. Makefiles are also hard-coded and need to be +hand edited prior to building Perl. While this makes it easy to create a perl.exe +that works across multiple Windows versions, being able to accurately +configure a perl.exe for a specific Windows versions and VS C++ would be +a nice enhancement. With PowerShell available on Windows XP and up, this +may now be possible. Step 1 might be to investigate whether this is possible +and use this to clean up our current makefile situation. Step 2 would be to +see if there would be a way to use our existing metaconfig units to configure a +Windows Perl or whether we go in a separate direction and make it so. Of +course, we all know what step 3 is. + +=head2 decouple -g and -DDEBUGGING + +Currently F automatically adds C<-DDEBUGGING> to the C compiler +flags if it spots C<-g> in the optimiser flags. The pre-processor directive +C enables F's command line C<-D> options, but in the process +makes F slower. It would be good to disentangle this logic, so that +C-level debugging with C<-g> and Perl level debugging with C<-D> can easily +be enabled independently. + =head1 Tasks that need a little C knowledge These tasks would need a little C knowledge, but don't need any specific @@ -468,28 +464,6 @@ 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.12. -=head2 Make it clear from -v if this is the exact official release - -Currently perl from C/C ships with a F 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. - -It would be useful to find an elegant way to have the "this is an interim -maintenance release" or "this is a release candidate" in the terse -v output, -and have it so that it's easy for the pumpking to remove this just as the -release tarball is rolled up. This way the version pulled out of rsync would -always say "I'm a development release" and it would be safe to bump the -reported minor version as soon as a release ships, which would aid perl -developers. - -This task is really about thinking of an elegant way to arrange the C source -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 Profile Perl - am I hot or not? The Perl source code is stable enough that it makes sense to profile it, @@ -623,6 +597,45 @@ These tasks would need C knowledge, and roughly the level of knowledge of the perl API that comes from writing modules that use XS to interface to C. +=head2 Write an XS cookbook + +Create pod/perlxscookbook.pod with short, task-focused 'recipes' in XS that +demonstrate common tasks and good practices. (Some of these might be +extracted from perlguts.) The target audience should be XS novices, who need +more examples than perlguts but something less overwhelming than perlapi. +Recipes should provide "one pretty good way to do it" instead of TIMTOWTDI. + +Rather than focusing on interfacing Perl to C libraries, such a cookbook +should probably focus on how to optimize Perl routines by re-writing them +in XS. This will likely be more motivating to those who mostly work in +Perl but are looking to take the next step into XS. + +Deconstructing and explaining some simpler XS modules could be one way to +bootstrap a cookbook. (List::Util? Class::XSAccessor? Tree::Ternary_XS?) +Another option could be deconstructing the implementation of some simpler +functions in op.c. + +=head2 Remove the use of SVs as temporaries in dump.c + +F contains debugging routines to dump out the contains of perl data +structures, such as Cs, Cs and Cs. Currently, the dumping code +B Cs for its temporary buffers, which was a logical initial +implementation choice, as they provide ready made memory handling. + +However, they also lead to a lot of confusion when it happens that what you're +trying to debug is seen by the code in F, correctly or incorrectly, as +a temporary scalar it can use for a temporary buffer. It's also not possible +to dump scalars before the interpreter is properly set up, such as during +ithreads cloning. It would be good to progressively replace the use of scalars +as string accumulation buffers with something much simpler, directly allocated +by C. The F code is (or should be) only producing 7 bit +US-ASCII, so output character sets are not an issue. + +Producing and proving an internal simple buffer allocation would make it easier +to re-write the internals of the PerlIO subsystem to avoid using Cs for +B buffers, use of which can cause problems similar to those of F, +at similar times. + =head2 safely supporting POSIX SA_SIGINFO Some years ago Jarkko supplied patches to provide support for the POSIX @@ -845,6 +858,18 @@ also the warning messages (see L, C). These tasks would need C knowledge, and knowledge of how the interpreter works, or a willingness to learn. +=head2 truncate() prototype + +The prototype of truncate() is currently C<$$>. It should probably +be C<*$> instead. (This is changed in F) + +=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 explictly the syntax C<$foo ~~ %$object> or +C<$foo ~~ @$object>. + =head2 error reporting of [$a ; $b] Using C<;> inside brackets is a syntax error, and we don't propose to change @@ -923,6 +948,15 @@ L There is no method on tied filehandles to allow them to be called back by formats. +=head2 Propagate compilation hints to the debugger + +Currently a debugger started with -dE on the command-line doesn't see the +features enabled by -E. More generally hints (C<$^H> and C<%^H>) aren't +propagated to the debugger. Probably it would be a good thing to propagate +hints from the innermost non-C scope: this would make code eval'ed +in the debugger see the features (and strictures, etc.) currently in +scope. + =head2 Attach/detach debugger from running program The old perltodo notes "With C, you can attach the debugger to a running @@ -930,22 +964,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 Optimize away empty destructors - -Defining an empty DESTROY method might be useful (notably in -AUTOLOAD-enabled classes), but it's still a bit expensive to call. That -could probably be optimized. - =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 LVALUE functions in the debugger - -The old perltodo notes that lvalue functions don't work in the debugger. This -would be good to fix. - =head2 regexp optimiser optional The regexp optimiser is not optional. It should configurable to be, to allow @@ -1039,7 +1062,7 @@ See also L. =head2 Investigate PADTMP hash pessimisation -The peephole optimier converts constants used for hash key lookups to shared +The peephole optimiser converts constants used for hash key lookups to shared hash key scalars. Under ithreads, something is undoing this work. See http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2007-09/msg00793.html @@ -1189,3 +1212,24 @@ This will allow the use of a regex from inside (?{ }), (??{ }) and 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?) + +=head2 some of the uconfig.sh really needs to be probed (using cc) in buildtime: + +(uConfigure? :-) native datatype widths and endianness come to mind +