HTTP/1.1 -1 Read error in cache disk data: SuccessContent-Type: text/plain
Last-Modified: Sat, 20 Dec 2008 14:48:55 GMT
ETag: "4ba7d-14ac-45e7b865be3c0"
Content-length: 5292
Connection: Close
Proxy-Connection: Close
X-Cache: HIT from web1.osuosl.org
Server: ProxyTrack 0.5 (HTTrack 3.49.2)

Index: docs/book/ch02_getting_started.pod
===================================================================
--- docs/book/ch02_getting_started.pod	(revision 34145)
+++ docs/book/ch02_getting_started.pod	(working copy)
@@ -226,7 +226,7 @@
 and why.
 
 It's important that you create your patches from a checked-out subversion
-repository, not from a tarball or or snapshot. This way, you can ensure
+repository, not from a tarball or a snapshot. This way, you can ensure
 that your diff is made against the latest version of the files. If you patch
 an old version, the problem may have already been resolved! Make sure
 the paths listed in the patch match those in the repository. There are two
Index: docs/book/ch03_pir_basics.pod
===================================================================
--- docs/book/ch03_pir_basics.pod	(revision 34145)
+++ docs/book/ch03_pir_basics.pod	(working copy)
@@ -25,11 +25,11 @@
 X<PIR (Parrot intermediate representation);documentation>
 PIR is well documented, both in traditional documentation and in
 instructional code examples. The documentation for the PIR compiler IMCC
-in F<imcc/docs/> or the project documentation in F<docs/> are good
+in F<docs/imcc/> or the project documentation in F<docs/> are good
 sources for information about the current syntax, semantics, and
 implementation. The other PIR compiler, PIRC, has it's own documentation
 that is slowly maturing. This is a useful source of information too. The
-test suite in F<imcc/t> shows examples of proper working code. In fact,
+test suite in F<t/compilers/imcc/> shows examples of proper working code. In fact,
 the test suite is the definitive PIR resource, because it shows how PIR
 I<actually works>, even when the documentation may be out of date.
 
@@ -99,7 +99,7 @@
 
 Parrot registers are allocated in a linear array, and register numbers
 are indices into this array. Having more registers means Parrot must
-allocate more storage space for them, which can decrease memory efficency
+allocate more storage space for them, which can decrease memory efficiency
 and register allocation/fetch performance. In general, it's better to
 keep the number of registers small. However, the number of the register
 does not necessarily correspond to the actual storage location where the
@@ -373,7 +373,7 @@
 provide these structures would work well for some languages but would
 require all sorts of messy translation in others. The only way to make
 sure all languages and their control structures can be equally
-accomodated is to simply give them the most simple and fundamental
+accommodated is to simply give them the most simple and fundamental
 building blocks to work with. Language agnosticism is an important
 design goal in Parrot, and creates a very flexible and powerful
 development environment for our language developers.
Index: docs/book/ch04_pir_subroutines.pod
===================================================================
--- docs/book/ch04_pir_subroutines.pod	(revision 34145)
+++ docs/book/ch04_pir_subroutines.pod	(working copy)
@@ -18,7 +18,7 @@
 in that all code in PIR must exist in a subroutine. Execution starts,
 as we have seen, in the C<:main> subroutine, and others can be called
 to perform the tasks of a program. From subroutines we can construct
-more elaborate chunks of code reusability: methods and objects. In
+more elaborate chunks of code reusability methods and objects. In
 this chapter we will talk about how subroutines work in PIR, and how
 they can be used by developers to create programs for Parrot.
 
@@ -564,14 +564,14 @@
     .local pmc obj
     newclass class, "Foo"       # create a new Foo class
     new obj, "Foo"              # instantiate a Foo object
-    obj."meth"()                # call obj."_meth" which is actually
-    print "done\n"              # "_meth" in the "Foo" namespace
+    obj."meth"()                # call obj."meth" which is actually
+    print "done\n"              # in the "Foo" namespace
     end
   .end
 
   .namespace [ "Foo" ]          # start namespace "Foo"
 
-  .sub meth :method             # define Foo::_meth global
+  .sub meth :method             # define Foo::meth global
      print "in meth\n"
      $S0 = "other_meth"         # method names can be in a register too
      self.$S0()                 # self is the invocant
Index: docs/book/ch11_pmcs.pod
===================================================================
--- docs/book/ch11_pmcs.pod	(revision 34145)
+++ docs/book/ch11_pmcs.pod	(working copy)
@@ -107,7 +107,7 @@
 code to access the PMC using integer indices. C<provides hash> means
 that we can use string and PMC keys to access values in the PMC. These
 C<provides> each correspond to a series of VTABLE interfaces that the
-PMC must provide, or must inherit. Without the necessary VABLE
+PMC must provide, or must inherit. Without the necessary VTABLE
 interfaces available, Parrot may try to perform illegal operations and
 things will go badly. We'll talk about all the available C<provides>
 interfaces and the VTABLE interfaces that they must define.
@@ -314,4 +314,4 @@
 # Local variables:
 #   c-file-style: "parrot"
 # End:
-# vim: expandtab shiftwidth=4:
\ No newline at end of file
+# vim: expandtab shiftwidth=4:
. luister zout mijnschool 