F<AUTHORS> file, which ships in the official distribution. How many other
programming languages offer you 1 line of immortality?
-=head1 Tasks that need only a little Perl knowledge
-
-=head2 Fix POD errors in Perl documentation
-
-Perl documentation is furnished in POD (Plain Old Documentation); see
-L<perlpod>. We also have a utility that checks for various errors in
-this documentation: F<t/porting/podcheck.t>. Unfortunately many files
-have errors in them, and there is a database of known problems, kept in
-F<t/porting/known_pod_issues.dat>. The most prevalent errors are lines
-too wide to fit in a standard terminal window, but there are more
-serious problems as well; and there are items listed there that are not
-in fact errors. The task would be to go through and clean up the
-documentation. This would be a good way to learn more about Perl.
-
=head1 Tasks that only need Perl knowledge
=head2 Classify bug tickets by type
quite a few tests in F<t/> have not been refactored to use it. Refactoring
any of these tests, one at a time, is a useful thing TODO.
-The subdirectories F<base>, F<cmd> and F<comp>, that contain the most
-basic tests, should be excluded from this task.
+The subdirectories F<base>, F<cmd>, F<comp> and F<opbasic>, that contain the
+most basic tests, should be excluded from this task.
=head2 Automate perldelta generation
the bug remains open because no one realizes that it has been fixed.
Ideally, every open bug should have a TODO test in the core test suite.
+=head2 deparse warnings nicely
+
+Currently Deparse punts on deparsing the bitmask for warnings, which it
+dumps uglily as-is. Try running this:
+
+ $ ./perl -Ilib -MO=Deparse -e 'use warnings "pipe"; die'
+
+Deparse.pm could use the package variables in warnings.pm that warnings.pm
+itself uses to convert the list passed to it into a bitfield. Deparse just
+needs to reverse that.
+
+=head2 test and fix Deparse with perl's test suite
+
+If you run perl's tests with the TEST_ARGS environment variable set to
+C<-deparse> (e.g., run C<TEST=-deparse make test>), each test file will be
+deparsed and the deparsed output will be run. Currently there are many
+failures, which ought to be fixed. There is in F<Porting/deparse-skips.txt>
+a list of tests known to fail, but it is out of date. Updating it would
+also help.
+
+This is an incremental task. Every small bit helps. It is also a task that
+may never end. As new tests are added, they tickle corner cases that
+B::Deparse cannot yet handle correctly.
+
+This task I<may> need a bit of perl guts knowledge. But what changes need
+to be made is usually easy to see by dumping op trees with B::Concise:
+
+ $ ./perl -Ilib -MO=Concise -e 'foo(); print @_; die $$_'
+
+and adjusting B::Deparse to handle whatever you see B::Concise produce.
+This is also a good way to I<learn> how perl's op trees work.
+
=head1 Tasks that need a little sysadmin-type knowledge
Or if you prefer, tasks that you would learn from, and broaden your skills
=item *
- cd t; HARNESS_PERL_SWITCHES=-MDevel::Cover ./perl -I../lib harness
+ cd t; HARNESS_PERL_SWITCHES=-MDevel::Cover ./perl -I../lib harness
=item *
On these systems, it might be the default compilation mode, and there
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.19.10.
+options would be nice for perl 5.25.8.
=head2 Profile Perl - am I hot or not?
been written so that it reflects the state of the read-only attribute, even
for directories (whatever CRT is being used), for symmetry with chmod().)
-=head2 strcat(), strcpy(), strncat(), strncpy(), sprintf(), vsprintf()
-
-Maybe create a utility that checks after each libperl.a creation that
-none of the above (nor sprintf(), vsprintf(), or *SHUDDER* gets())
-ever creep back to libperl.a.
-
- nm libperl.a | ./miniperl -alne '$o = $F[0] if /:$/;
- print "$o $F[1]" if $F[0] eq "U" && $F[1] =~ /^(?:strn?c(?:at|py)|v?sprintf|gets)$/'
-
-Note, of course, that this will only tell whether B<your> platform
-is using those naughty interfaces.
-
-=head2 -D_FORTIFY_SOURCE=2
-
-Recent glibcs support C<-D_FORTIFY_SOURCE=2> which gives
-protection against various kinds of buffer overflow problems.
-It should probably be used for compiling Perl whenever available,
-Configure and/or hints files should be adjusted to probe for the
-availability of these feature and enable it as appropriate.
-
=head2 Arenas for GPs? For MAGIC?
C<struct gp> and C<struct magic> are both currently allocated by C<malloc>.
progressively update ExtUtils::ParseXS to generate OP implementations for
some XSUBs.
+=head2 Document how XS modules can install lexical subs
+
+There is an example in XS::APItest (look for C<lexical_import> in
+F<ext/XS-APItest/APItest.xs>). The documentation could be based on it.
+
=head2 Remove the use of SVs as temporaries in dump.c
F<dump.c> contains debugging routines to dump out the contains of perl data
system() accepts a LIST syntax (and a PROGRAM LIST syntax) to avoid
running a shell. readpipe() (the function behind qx//) could be similarly
-extended.
+extended. Note that changing readpipe() itself may not be the solution, as
+it currently has unary precedence, and allowing a list would change the
+precedence.
=head2 Audit the code for destruction ordering assumptions
Change 25773 notes
- /* Need to check SvMAGICAL, as during global destruction it may be that
- AvARYLEN(av) has been freed before av, and hence the SvANY() pointer
- is now part of the linked list of SV heads, rather than pointing to
- the original body. */
- /* FIXME - audit the code for other bugs like this one. */
+ /* Need to check SvMAGICAL, as during global destruction it may be that
+ AvARYLEN(av) has been freed before av, and hence the SvANY() pointer
+ is now part of the linked list of SV heads, rather than pointing to
+ the original body. */
+ /* FIXME - audit the code for other bugs like this one. */
adding the C<SvMAGICAL> check to
These tasks would need C knowledge, and knowledge of how the interpreter works,
or a willingness to learn.
+=head2 fix refaliasing with nested and recursive subroutines
+
+Currently aliasing lexical variables via reference only applies to the
+current subroutine, and does not propagate to inner closures, nor does
+aliasing of outer variables within closures propagate to the outer
+subroutine. This is because each subroutine has its own lexical pad and the
+aliasing works by changing which SV the pad points to.
+
+One possible way to fix this would be to create new ops for accessing
+variables that are closed over. So C<my $x; sub {$x}> would use a new op
+type, say C<padoutsv>, instead of the C<padsv> currently used in the
+sub. That new op would possibly check a flag or some such and see if it
+needs to fetch the variable from an outer pad. If we follow this approach,
+it should be possible at compile time to detect cases where the more
+complex C<padoutsv> op is unnecessary and revert back to the simpler,
+faster C<padsv>. There would need to be corresponding ops for arrays,
+hashes, and subs, too.
+
+There is also a related issue with recursion and C<state> variables. A
+subroutine actually has a list of lexical pads, each one used at a
+different recursion level. If a C<state> variable is aliased to another
+variable after a recursive call to the same subroutine, that higher call
+depth will not see the effect of aliasing, because the second pad will have
+been created already. Similarly, aliasing a state variable within a
+recursive call will not affect outer calls, even though all call depths are
+supposed to share the same C<state> variables.
+
+Both of these bugs affect C<foreach> aliasing, too.
+
=head2 forbid labels with keyword names
Currently C<goto keyword> "computes" the label value:
=head2 truncate() prototype
The prototype of truncate() is currently C<$$>. It should probably
-be C<*$> instead. (This is changed in F<opcode.pl>)
+be C<*$> instead. (This is changed in F<regen/opcodes>.)
=head2 error reporting of [$a ; $b]
=head2 strict as warnings
-See L<http://markmail.org/message/vbrupaslr3bybmvk>, where Josua ben Jore
+See L<http://markmail.org/message/vbrupaslr3bybmvk>, where Joshua ben Jore
writes: I've been of the opinion that everything strict.pm does ought to be
able to considered just warnings that have been promoted to 'FATAL'.
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 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 regexp optimizer optional
The regexp optimizer is not optional. It should be configurable to be optional
This would allow proposals such as short circuiting sort to be implemented
as a module on CPAN.
-=head2 lexical aliases
-
-Allow lexical aliases (maybe via the syntax C<my \$alias = \$foo>).
-
=head2 Self-ties
Self-ties are currently illegal because they caused too many segfaults. Maybe
=head2 Virtualize operating system access
Implement a set of "vtables" that virtualizes operating system access
-(open(), mkdir(), unlink(), readdir(), getenv(), etc.) At the very
-least these interfaces should take SVs as "name" arguments instead of
-bare char pointers; probably the most flexible and extensible way
-would be for the Perl-facing interfaces to accept HVs. The system
-needs to be per-operating-system and per-file-system
-hookable/filterable, preferably both from XS and Perl level
-(L<perlport/"Files and Filesystems"> is good reading at this point,
-in fact, all of L<perlport> is.)
+(chdir(), chmod(), dbmopen(), getenv(), glob(), link(), mkdir(), open(),
+opendir(), readdir(), rename(), rmdir(), stat(), sysopen(), uname(),
+unlink(), etc.) At the very least these interfaces should take SVs as
+"name" arguments instead of bare char pointers; probably the most
+flexible and extensible way would be for the Perl-facing interfaces to
+accept HVs. The system needs to be per-operating-system and
+per-file-system hookable/filterable, preferably both from XS and Perl
+level (L<perlport/"Files and Filesystems"> is good reading at this
+point, in fact, all of L<perlport> is.)
This has actually already been implemented (but only for Win32),
take a look at F<iperlsys.h> and F<win32/perlhost.h>. While all Win32
=head2 repack the optree
+B<Note:> This entry was written in reference to the I<old> slab allocator,
+removed in commit 7aef8e5bd14.
+
Repacking the optree after execution order is determined could allow
removal of NULL ops, and optimal ordering of OPs with respect to cache-line
filling. I think that
would produce this output
- Use of uninitialized value $undef in addition (+) at wrong.pl line 4.
- Use of uninitialized value $undef in addition (+) at wrong.pl line 7.
+ Use of uninitialized value $undef in addition (+) at wrong.pl line 4.
+ Use of uninitialized value $undef in addition (+) at wrong.pl line 7.
(rather than lines 4 and 5), but this would seem to require every OP to carry
(at least) line number information.
=head1 Big projects
Tasks that will get your name mentioned in the description of the "Highlights
-of 5.19.10"
+of 5.25.8"
=head2 make ithreads more robust