[svn:ponie] r388 - trunk

[email protected] 31 Jan 2006 21:14:31 -0000
Newsgroups perl.ponie.changes
Message-ID <[email protected]>
Author: nicholas
Date: Tue Jan 31 13:14:30 2006
New Revision: 388

Modified:
   trunk/Roadmap
Log:
Revise timing estimates on the basis of experience, particularly with the
reference counting task.


Modified: trunk/Roadmap
==============================================================================
--- trunk/Roadmap	(original)
+++ trunk/Roadmap	Tue Jan 31 13:14:30 2006
@@ -249,14 +249,14 @@ via a function call, it is possible to m
 point assume set flags (NOK,pNOK) and morph the scalar to a larger type if
 any code requests the flags value read/write.
 
-4 days
+5 days
 
 =item *
 
 Replace the complex SV copying code in C<sv_setsv> with copying code
 encapsulated within the PMC.
 
-5 days
+6 days
 
 =item *
 
@@ -282,7 +282,7 @@ iCow. (mostly done in blead, partially m
 
 Make read only look ups such as C<SvNV()> call the appropriate PMC method.
 
-2 days
+3 days
 
 =item *
 
@@ -293,10 +293,12 @@ and C<SvNV>, and internals-aware direct 
 C<SvNVX>. The former expect magic to be called for them, the latter expect
 direct access and will handle magic themselves.
 
-4 days
+5 days
 
 =item *
 
+aMake a code distinction between readonly and read-write accesses to strings (2 days)
+
 Refactor the core to use a new C<SvPVX_readonly()> macro when requesting
 a pointer to a scalar's string that isn't going to be modified. Consider
 whether this also shouldn't return a C<'\0'> terminated string, or whether
@@ -329,6 +331,10 @@ Refactor the Perl core code to avoid usi
 think that this is possible, and Dave suspects that there may be speed
 benefits from removing all the special case code that deals with the stack.
 
+This change is risky, but Arthur and I believe it's the only way to get
+destruction right when Ponie's aggregate PMCs are passed out to unsuspecting
+Parrot code.
+
 This involves
 
 =over 4
@@ -365,14 +371,14 @@ There's a comment in F<sv.c> about fake 
 The comments in C<sv_dup> and the associated ithreads cloning routines in
 F<sv.c> are the best clues as to what needs to be done.
 
-10 days. (Partially done - chased down the reference loop between symbol tables
+12 days. (Partially done - chased down the reference loop between symbol tables
 and typeglobs)
 
 =item 2
 
 Making Parrot's GC walk the Perl 5 C stack.
 
-1 day
+2 days
 
 =item 3
 
@@ -385,35 +391,32 @@ Registering PMCs held in Perl globals.
 Amending the reference, array and hash code to properly mark the contained
 PMCs as "in use".
 
-2 days
+3 days
 
 =item 5
 
 Replacing C<SvREFCNT_inc()> and C<SvREFCNT_dec()> macros with null
-operations inside the core. (Unaware XS code would still use them)
+operations inside the core. (Unaware XS code would still use them - time is
+needed for actually testing that this boundary works)
 
-5 minutes
+1 day
 
 =item 6
 
 Experimenting to find out how much of the special case code for the Perl stack
 and C<@_> can be removed.
 
-3 days
+4 days
 
 =item 7
 
 Calling a high priority DOD run at every freetmps point. (Roughly every
 semicolon)
 
-2 days
+3 days
 
 =back
 
-This change is risky, but we suspect it's the only way to get destruction
-right when Ponie's aggregate PMCs are passed out to unsuspecting Parrot
-code.
-
 =item *
 
 Refactor stashes to be a derived type of hashes. This means that Perl's hashes