[svn:parrot] r42231 - in trunk/docs: . pdds pdds/draft

allison at svn.parrot.org allison at svn.parrot.org
Tue Nov 3 01:15:32 UTC 2009


Author: allison
Date: Tue Nov  3 01:15:28 2009
New Revision: 42231
URL: https://trac.parrot.org/parrot/changeset/42231

Log:
[cage] More documentation updates to remove references to "compilation unit".

Modified:
   trunk/docs/compiler_faq.pod
   trunk/docs/pdds/draft/pdd10_embedding.pod
   trunk/docs/pdds/pdd19_pir.pod

Modified: trunk/docs/compiler_faq.pod
==============================================================================
--- trunk/docs/compiler_faq.pod	Tue Nov  3 01:08:47 2009	(r42230)
+++ trunk/docs/compiler_faq.pod	Tue Nov  3 01:15:28 2009	(r42231)
@@ -96,7 +96,7 @@
 There are several ways to achieve this, depending on the location of
 the subroutine.
 
-If the sub is in the same compilation unit use a Sub constant:
+If the sub is in the same file use a Sub constant:
 
 =begin PIR_FRAGMENT
 

Modified: trunk/docs/pdds/draft/pdd10_embedding.pod
==============================================================================
--- trunk/docs/pdds/draft/pdd10_embedding.pod	Tue Nov  3 01:08:47 2009	(r42230)
+++ trunk/docs/pdds/draft/pdd10_embedding.pod	Tue Nov  3 01:15:28 2009	(r42231)
@@ -96,7 +96,7 @@
 
 =item * probably a continuation/control flow boundary
 
-=item * packfiles and compilation units probably too much information for
+=item * packfiles and subroutines probably too much information for
 either
 
 =item * do not let MMD and other implementation details escape

Modified: trunk/docs/pdds/pdd19_pir.pod
==============================================================================
--- trunk/docs/pdds/pdd19_pir.pod	Tue Nov  3 01:08:47 2009	(r42230)
+++ trunk/docs/pdds/pdd19_pir.pod	Tue Nov  3 01:15:28 2009	(r42231)
@@ -397,9 +397,9 @@
 =end PIR_FRAGMENT
 
 An annotation stays in effect until the next annotation with the same key or
-the end of the current compilation unit (that is, if you use a tool such as
-C<pbc_merge> to link multiple bytecode files, then annotations will not spill
-over from one mergee's bytecode to another).
+the end of the current file (that is, if you use a tool such as C<pbc_merge> to
+link multiple bytecode files, then annotations will not spill over from one
+mergee's bytecode to another).
 
 One annotation covers many PIR instructions. If the result of compiling one
 line of HLL code is 15 lines of PIR, you only need to emit one annotation


More information about the parrot-commits mailing list