Change existing uses of strlcpy()/strlcat() to use new my_strlcpy()/
[p5sagit/p5-mst-13.2.git] / pod / perltodo.pod
index 83af8fe..9ffb628 100644 (file)
@@ -31,13 +31,16 @@ TODO are completed.
 
 =item *
 
+Implement L</state variables> (mostly done currently)
+
+=item *
+
 Review assertions. Review syntax to combine assertions. Assertions could take
 advantage of the lexical pragmas work. L</What hooks would assertions need?>
 
 =item *
 
-C<encoding::warnings> should be turned into a lexical pragma.
-C<encoding> should, too (probably).
+C<encoding> should be turned into a lexical pragma (probably).
 
 =back
 
@@ -46,10 +49,12 @@ C<encoding> should, too (probably).
 =over
 
 =item *
+
 Implement L</_ prototype character>
 
 =item *
-Implement L</state variables>
+
+Review smart match semantics in light of Perl 6 developments.
 
 =back
 
@@ -107,7 +112,7 @@ Pugs already does parallel testing - can their approach be re-used?
 
 =head2 Make Schwern poorer
 
-We should have for everything. When all the core's modules are tested,
+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.
@@ -177,12 +182,6 @@ compilation, and hence remove the duplication, and the mistakes it has caused.
 Or if you prefer, tasks that you would learn from, and broaden your skills
 base...
 
-=head2 Relocatable perl
-
-The C level patches needed to create a relocatable perl binary are done, as
-is the work on F<Config.pm>. All that's left to do is the C<Configure> tweaking
-to let people specify how they want to do the install.
-
 =head2 make HTML install work
 
 There is an C<installhtml> target in the Makefile. It's marked as
@@ -208,9 +207,7 @@ 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>)
@@ -301,13 +298,6 @@ possibly involving probing at install time or later, so that the C<%Config> in
 a binary distribution better describes the installed machine, when the
 installed machine differs from the build machine in some significant way.
 
-=head2 make parallel builds work
-
-Currently parallel builds (such as C<make -j3>) don't work reliably. We believe
-that this is due to incomplete dependency specification in the F<Makefile>.
-It would be good if someone were able to track down the causes of these
-problems, so that parallel builds worked properly.
-
 =head2 linker specification files
 
 Some platforms mandate that you provide a list of a shared library's external
@@ -320,6 +310,15 @@ C<Configure> to enable it. This would allow Unix users to test that the
 export list is correct, and to build a perl that does not pollute the global
 namespace with private symbols.
 
+=head2 Cross-compile support
+
+Currently C<Configure> understands C<-Dusecrosscompile> option. This option
+arranges for building C<miniperl> for TARGET machine, so this C<miniperl> is
+assumed then to be copied to TARGET machine and used as a replacement of full
+C<perl> executable.
+
+This should be done litle differently. Namely C<miniperl> should be built for
+HOST and then full C<perl> with extensions should be compiled for TARGET.
 
 
 
@@ -381,17 +380,23 @@ become C<char>s. Finding variables to downsize coupled with rearrangement
 could shrink the interpreter structure; a size saving which is multiplied by
 the number of threads running.
 
-=head2 am I hot or not?
+=head2 Profile Perl - am I hot or not?
 
-The idea of F<pp_hot.c> is that it contains the I<hot> ops, the ops that are
-most commonly used. The idea is that by grouping them, their object code will
-be adjacent in the executable, so they have a greater chance of already being
-in the CPU cache (or swapped in) due to being near another op already in use.
+The Perl source code is stable enough that it makes sense to profile it,
+identify and optimise the hotspots. It would be good to measure the
+performance of the Perl interpreter using free tools such as cachegrind,
+gprof, and dtrace, and work to reduce the bottlenecks they reveal.
+
+As part of this, the idea of F<pp_hot.c> is that it contains the I<hot> ops,
+the ops that are most commonly used. The idea is that by grouping them, their
+object code will be adjacent in the executable, so they have a greater chance
+of already being in the CPU cache (or swapped in) due to being near another op
+already in use.
 
 Except that it's not clear if these really are the most commonly used ops. So
-anyone feeling like exercising their skill with coverage and profiling tools
-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>.
+as part of exercising your skills with coverage and profiling tools you 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 Shrink struct context
 
@@ -418,7 +423,10 @@ custom allocates so it would both use less memory and less CPU to allocate
 the various OP structures from arenas. The SV arena code can probably be
 re-used for this.
 
+=head2 Improve win32/wince.c
 
+Currently, numerous functions look virtually, if not completely,
+identical in both C<win32/wince.c> and C<win32/win32.c> files, which can't be good.
 
 
 =head1 Tasks that need a knowledge of XS
@@ -427,11 +435,14 @@ 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 shrink C<IO>s
+=head2 shrink C<PVBM>s
 
 By removing unused elements and careful re-ordering, the structures for C<AV>s,
-C<HV>s, C<CV>s and C<GV>s have recently been shrunk considerably. C<PVIO>s and
-C<PVBM>s might have some savings to win.
+C<HV>s, C<CV>s and C<GV>s have recently been shrunk considerably. C<PVIO>s
+probably aren't worth it, as typical programs don't use more than 8, and
+(at least) C<Filter::Util::Call> uses C<SvPVX>/C<SvCUR>/C<SvLEN> on a C<PVIO>,
+so it would mean code changes to modules on CPAN. C<PVBM>s might have some
+savings to win.
 
 =head2 Implicit Latin 1 => Unicode translation
 
@@ -542,11 +553,7 @@ Study the possibility of adding a new prototype character, C<_>, meaning
 
 C<my $foo if 0;> is deprecated, and should be replaced with
 C<state $x = "initial value\n";> the syntax from Perl 6.
-
-=head2 @INC source filter to Filter::Simple
-
-The second return value from a sub in @INC can be a source filter. This isn't
-documented. It should be changed to use Filter::Simple, tested and documented.
+Rafael has sent a first cut patch to perl5-porters.
 
 =head2 regexp optimiser optional
 
@@ -605,9 +612,19 @@ investigate what hooks would need to be added to make it possible to provide
 the full assertion support from a CPAN module, so that we aren't constraining
 the imagination of future CPAN authors.
 
+=head2 Properly Unicode safe tokeniser and pads.
 
+The tokeniser isn't actually very UTF-8 clean. C<use utf8;> is a hack -
+variable names are stored in stashes as raw bytes, without the utf-8 flag
+set. The pad API only takes a C<char *> pointer, so that's all bytes too. The
+tokeniser ignores the UTF-8-ness of C<PL_rsfp>, or any SVs returned from
+source filters.  All this could be fixed.
 
+=head2 Integrate Russ Allbery's strlcat/strlcpy implementation
 
+And remove the last remaining uses of strcat() and strcpy().  Also, add
+my_strlcat() and my_strlcpy() to Devel::PPPort so previous versions of Perl can
+use these APIs. 
 
 =head1 Big projects