[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index][Thread Index][Top&Search][Original]

[PATCH] perltodo

From: Reini Urban <rurban@x-ray.at>
To: The Perl5 Porters Mailing List <perl5-porters@perl.org>
Date: Sat, 05 Jul 2008 13:40:27 +0200
Message-ID: <486F5DAB.4010403@x-ray.at>

some perltodo.pod changes

The most important:
Move "Virtualize operating system access" to the 5.12 highlights.

Add cygwin-1.7 unicode/utf8 filenames work.
Add the name of the new XS entersub OP: pp_enterxssub
Add some hints: optimizer and Enbugger
-- 
Reini Urban
http://phpwiki.org/  http://murbreak.at/

difforig perl-current/pod/perltodo.pod

diff -u perl-current/pod/perltodo.pod.orig perl-current/pod/perltodo.pod
--- perl-current/pod/perltodo.pod.orig	2008-05-21 11:18:19.000000000 +0200
+++ perl-current/pod/perltodo.pod	2008-07-05 12:56:54.625000000 +0200
@@ -450,7 +450,7 @@
 
 Currently all new OP structures are individually malloc()ed and free()d.
 All C<malloc> implementations have space overheads, and are now as fast as
-custom allocates so it would both use less memory and less CPU to allocate
+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.
 
@@ -504,7 +504,7 @@
 not actually be writable if access is indeed denied by DACLs).
 
 For the chdir() issue, see ActiveState bug #74552:
-http://bugs.activestate.com/show_bug.cgi?id=74552
+L<http://bugs.activestate.com/show_bug.cgi?id=74552>
 
 Therefore, DACLs should be checked both for consistency across CRTs and for
 the correct answer.
@@ -655,6 +655,9 @@
 temporarily retired in 5.8.1, and the -C has been repurposed, see
 L<perlrun>.)
 
+Currently only MSWin32 handles unicode filenames, converting them from
+and to UTF-8, but the upcoming cygwin-1.7 will also support it.
+
 Most probably the right way to do this would be this:
 L</"Virtualize operating system access">.
 
@@ -840,6 +843,8 @@
 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.
+For the Enbugger you have to know it in advance, e.g. by -MEnbugger or by 
+instrumenting suspicious code.
 
 =head2 Optimize away empty destructors
 
@@ -883,6 +888,7 @@
 it walks the optree - genuine peephole optimisations, and necessary fixups of
 ops. It would be good to find an efficient way to switch out the
 optimisations whilst keeping the fixups.
+See the optimizer CPAN module for additional perl level optimizations.
 
 =head2 You WANT *how* many
 
@@ -901,7 +907,8 @@
 At the moment pp_entersub is huge, and has code to deal with entering both
 perl and XS subroutines. Subroutine implementations rarely change between 
 perl and XS at run time, so investigate using 2 ops to enter subs (one for
-XS, one for perl) and swap between if a sub is redefined.
+XS, one for perl), by adding a pp_enterxssub and swap between if a sub is 
+redefined.
 
 =head2 Self-ties
 
@@ -913,46 +920,11 @@
 
 The old perltodo notes "Look at the "reification" code in C<av.c>".
 
-=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.)
-
-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
-variants go through a set of "vtables" for operating system access,
-non-Win32 systems currently go straight for the POSIX/UNIX-style
-system/library call.  Similar system as for Win32 should be
-implemented for all platforms.  The existing Win32 implementation
-probably does not need to survive alongside this proposed new
-implementation, the approaches could be merged.
-
-What would this give us?  One often-asked-for feature this would
-enable is using Unicode for filenames, and other "names" like %ENV,
-usernames, hostnames, and so forth.
-(See L<perlunicode/"When Unicode Does Not Happen">.)
-
-But this kind of virtualization would also allow for things like
-virtual filesystems, virtual networks, and "sandboxes" (though as long
-as dynamic loading of random object code is allowed, not very safe
-sandboxes since external code of course know not of Perl's vtables).
-An example of a smaller "sandbox" is that this feature can be used to
-implement per-thread working directories: Win32 already does this.
-
-See also L</"Extend PerlIO and PerlIO::Scalar">.
-
 =head2 Investigate PADTMP hash pessimisation
 
 The peephole optimier 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
+See L<http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2007-09/msg00793.html>
 
 =head2 Store the current pad in the OP slab allocator
 
@@ -981,7 +953,7 @@
 have to actually "allocate" the ops in reverse-execution order to get them
 contiguous in memory in execution order.
 
-See http://www.nntp.perl.org/group/perl.perl5.porters/2007/12/msg131975.html
+See L<http://www.nntp.perl.org/group/perl.perl5.porters/2007/12/msg131975.html>
 
 Note that running this copy, and then freeing all the old location ops would
 cause their slabs to be freed, which would eliminate possible memory wastage if
@@ -1080,6 +1052,42 @@
 
 Fix Perl_sv_dup, et al so that threads can return objects.
 
+=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.)
+
+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
+variants go through a set of "vtables" for operating system access,
+non-Win32 systems currently go straight for the POSIX/UNIX-style
+system/library call.  Similar system as for Win32 should be
+implemented for all platforms. cygwin-1.7 support will benefit and will be 
+the easiest for the start.
+The existing Win32 implementation probably does not need to survive 
+alongside this proposed new implementation, the approaches could be merged.
+
+What would this give us?  One often-asked-for feature this would
+enable is using Unicode for filenames, and other "names" like %ENV,
+usernames, hostnames, and so forth.
+(See L<perlunicode/"When Unicode Does Not Happen">.)
+
+But this kind of virtualization would also allow for things like
+virtual filesystems, virtual networks, and "sandboxes" (though as long
+as dynamic loading of random object code is allowed, not very safe
+sandboxes since external code of course know not of Perl's vtables).
+An example of a smaller "sandbox" is that this feature can be used to
+implement per-thread working directories: Win32 already does this.
+
+See also L</"Extend PerlIO and PerlIO::Scalar">.
+
 =head2 iCOW
 
 Sarathy and Arthur have a proposal for an improved Copy On Write which

[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index][Thread Index][Top&Search][Original]