perltodo.pod

来自「视频监控网络部分的协议ddns,的模块的实现代码,请大家大胆指正.」· POD 代码 · 共 882 行 · 第 1/3 页

=head1 NAME

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<[e-mail]> to avoid duplication of
effort. 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<AUTHORS> 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 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<test.pl>. Throw in the handy tainting subroutines.

=head2 merge common code in installperl and installman

There are some common subroutines and a common C<BEGIN> block in F<installperl>
and F<installman>. These should probably be merged. It would also be good to
check for duplication in all the utility scripts supplied in the source
tarball. It might be good to move them all to a subdirectory, but this would
require careful checking to find all places that call them, and change those
correctly.

=head2 common test code for timed bail out

Write portable self destruct code for tests to stop them burning CPU in
infinite loops. This needs to avoid using alarm, as some of the tests are
testing alarm/sleep or timers.

=head2 POD -E<gt> 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<as> 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</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 merge checkpods and podchecker

F<pod/checkpods.PL> (and C<make check> in the F<pod/> 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<make check> use podchecker.

=head2 perlmodlib.PL rewrite

Currently perlmodlib.PL needs to be run from a source directory where perl
has been built, or some modules won't be found, and others will be
skipped. Make it run from a clean perl source tree (so it's reproducible).

=head2 Parallel testing

(This probably impacts much more than the core: also the Test::Harness
and TAP::* modules on CPAN.)

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 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 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<PI>.
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<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
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<make test.taintwarn>).

=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<t/lib/commonsense.t>.

=head2 Improving C<threads::shared>

Investigate whether C<threads::shared> could share aggregates properly with
only Perl level changes to shared.pm

=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<embed.pl> 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<C>. Functions are declared in F<embed.fnc>, variables
in F<interpvar.h>. Quite a few of the functions and variables
are conditionally declared there, using C<#ifdef>. However, F<embed.pl>
doesn't understand the C macros, so the rules about which symbols are present
when is duplicated in F<makedef.pl>. Writing things twice is bad, m'kay.
It would be good to teach C<embed.pl> 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<use strict;> 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.

=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<installhtml> 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<lib/>)
and the core documentation (files in F<pod/>)

=item 2

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
    =item substr EXPR,OFFSET,LENGTH
    =item substr EXPR,OFFSET

and different parameter lists having different meanings. (eg C<select>)

=back

=head2 compressed man pages

Be able to install them. This would probably need a configure test to see how
the system does compressed man pages (same directory/different directory?
same filename/different filename), as well as tweaking the F<installman> script
to compress as necessary.

=head2 Add a code coverage target to the Makefile

Make it easy for anyone to run Devel::Cover on the core's tests. The steps
to do this manually are roughly

=over 4

=item *

do a normal C<Configure>, but include Devel::Cover as a module to install
(see F<INSTALL> for how to do this)

=item *

    make perl

=item *

    cd t; HARNESS_PERL_SWITCHES=-MDevel::Cover ./perl -I../lib harness

=item *

Process the resulting Devel::Cover database

=back

This just give you the coverage of the F<.pm>s. To also get the C level
coverage you need to

=over 4

=item *

Additionally tell C<Configure> to use the appropriate C compiler flags for
C<gcov>

=item *

    make perl.gcov

(instead of C<make perl>)

=item *