[perl #61786] [PATCH] docs/book typo corrections

Index: docs/book/ch12_opcodes.pod
===================================================================
--- docs/book/ch12_opcodes.pod	(revision 34470)
+++ docs/book/ch12_opcodes.pod	(working copy)
@@ -76,7 +76,7 @@
 The fast core is a bare-bones core that doesn't do any of the
 bounds-checking or context updating that the slow core does. The fast
 core is the way Parrot should run, and is used to find and debug places
-where execution strays outside of it's normal bounds. In pseudocode, the
+where execution strays outside of its normal bounds. In pseudocode, the
 fast core is very much like the slow core except it doesn't do the bounds
 checking between each instruction, and doesn't update the interpreter's
 current context for each dispatch.
@@ -88,7 +88,7 @@
 
 =item* Switch Core
 
-As it's name implies, the switch core uses a gigantic C C<switch / case>
+As its name implies, the switch core uses a gigantic C C<switch / case>
 structure to execute opcodes. Here's a brief example of how this
 architecture works:
 
@@ -306,7 +306,7 @@
 
 When Parrot parses through the file and sees the C<Foo> operation, it
 converts it to the real name C<Foo_i_n>. The real name of an opcode
-is it's name followed by an underscore-separated ordered list of
+is its name followed by an underscore-separated ordered list of
 the parameters to that opcode. This is how Parrot appears to use
 polymorphism: It translates the overloaded opcode common names into
 longer unique names depending on the parameter list of that opcode. Here
@@ -322,7 +322,7 @@
 This isn't a complete list, but you should get the picture. Each different
 combination of parameters translates to a different unique operation, and
 each operation is remarkably simple to implement. In some cases, Parrot
-can even use it's multi-method dispatch system to call opcodes which are
+can even use its multi-method dispatch system to call opcodes which are
 heavily overloaded, or for which there is no exact fit but the parameters
 could be coerced into different types to complete the operation. For
 instance, attempting to add a STRING to a PMC might coerce the string into
Index: docs/book/ch09_pct.pod
===================================================================
--- docs/book/ch09_pct.pod	(revision 34470)
+++ docs/book/ch09_pct.pod	(working copy)
@@ -5,7 +5,7 @@
 Z<CHP-8>
 
 So far we've talked a lot about low-level Parrot programming with
-PIR and PASM. However, the true power of Parrot is it's ability to
+PIR and PASM. However, the true power of Parrot is its ability to
 host programs written in high level languages such as Perl 6,
 Python, Ruby, Tcl, and PHP. In order to write code in these languages
 developers need there to be compilers that convert from the language
@@ -185,7 +185,7 @@
 
 A recursive descent parser, like the one used in PGE, is a top-down
 parser. This means it attempts to start at the highest-level rule and
-work it's way down to the individual input tokens in order to match
+work its way down to the individual input tokens in order to match
 the given input. Once the parser has matched the entire input N<a
 source code file, or a line of input at the terminal in interactive
 mode> the parse is considered successful and the generated AST is
@@ -342,7 +342,7 @@
     'Skywalker'
  }
 
-This is the same rule, except now it passes two arguments to it's
+This is the same rule, except now it passes two arguments to its
 action method: the match object and the name of the person who
 got matched.
 
@@ -371,7 +371,7 @@
 Notice that an C<if_statement> can contain a list of C<statement>s, and
 that each statement may itself be an C<if_statement>? This is called
 I<recursion> X<Recursion>, and is part of where the "Recursive Descent"
-algorithm gets it's name from.
+algorithm gets its name from.
 
 Now, let's look at a more direct example of a comma-separated list of
 integer digits to form an array. We can define this recursively as
@@ -450,7 +450,7 @@
 equation are split into two subtypes: I<terms> and I<operators>. Operators
 themselves are split into a number of types including postfix (C<-a>),
 suffix (C<i++>), infix (C<x + y>), circumfix (C<[z]>), postcircumix
-(C<a[b]>), and list (C<1, 2, 3>). Each operator gets it's own precidence
+(C<a[b]>), and list (C<1, 2, 3>). Each operator gets its own precidence
 number that specifies how closely it binds to the terms. In the example above,
 the expression is parsed
 
@@ -478,8 +478,8 @@
 of saying that the rule is overridable dynamically, and that it might be defined
 somewhere else. In this case, PCT takes information from the proto declaration
 and fills in the details for us. On another note, this also means that the HLL
-itself can modify it's own grammar at run time, by overriding the proto
-definitions for it's operator table. Some languages call this process "operator
+itself can modify its own grammar at run time, by overriding the proto
+definitions for its operator table. Some languages call this process "operator
 overloading".
 
 A proto is defined like this, taking some of our grammar rules above:
@@ -802,4 +802,4 @@
 # Local variables:
 #   c-file-style: "parrot"
 # End:
-# vim: expandtab shiftwidth=4:
\ No newline at end of file
+# vim: expandtab shiftwidth=4:
Index: docs/book/ch04_pir_subroutines.pod
===================================================================
--- docs/book/ch04_pir_subroutines.pod	(revision 34470)
+++ docs/book/ch04_pir_subroutines.pod	(working copy)
@@ -284,7 +284,7 @@
 
 In this example, the subroutine C<add_two> makes two calls to
 c<add_one>. The second call to C<add_one> is used as the return
-value. C<add_one> is called and it's result is immediately returned
+value. C<add_one> is called and its result is immediately returned
 to the caller of C<add_two>, it is never stored anywhere. We can
 optimize this situation is we realize that the second call to
 C<add_one> is returning to the same place that C<add_two> is. The
@@ -308,7 +308,7 @@
 What this means is that we can define a subroutine by name inside a
 larger subroutine, and our "inner" subroutine is only visible and callable
 from the "outer" subroutine. Plus, the "inner" subroutine inherits all the
-lexical variables from the outer subroutine, but is able to define it's
+lexical variables from the outer subroutine, but is able to define its
 own lexical variables that cannot be seen or modified by the outer subroutine.
 
 =head3 Scope and HLLs
Index: docs/book/ch10_hlls.pod
===================================================================
--- docs/book/ch10_hlls.pod	(revision 34470)
+++ docs/book/ch10_hlls.pod	(working copy)
@@ -14,11 +14,11 @@
 interoperating with each other then compiled languages have because
 compiled languages operate at the same machine-code level and typically
 can make use of the same application binary interface (ABI). With the
-right compiler settings, programs written in Visual Basic and interoperate
+right compiler settings, programs written in Visual Basic can interoperate
 with programs written in C N<On some systems anyway>, which can call
-functions written in C++, in Ada, Fortran, and Pascal. To try to mix
+functions written in C++, in Ada, Fortran, Pascal and so on. To try to mix
 two common dynamic languages, like Perl and Python, or Ruby and PHP, you
-would need to custom write some kind of "glue" function to try to include
+would need to write some kind of custom "glue" function to try to include
 an interpreter object from one language as a library for another language,
 and then write code to try and get the parser for one to interact nicely
 with the parser for the other. It's a nightmare, frankly, and you don't
@@ -33,7 +33,7 @@
 a binding for a popular library such as opengl or xlib once, and include
 that library into any language that needs it. Compare this to the current
 situation where a library like Gtk2 needs to have bindings for every
-language that wants to use it.In short, Parrot should make interoperation
+language that wants to use it. In short, Parrot should make interoperation
 easier for everybody.
 
 This chapter is going to talk about HLLs, the way they operate, and the
@@ -122,7 +122,7 @@
 the compiler fakecutables. The fakecutables contain a link to C<libparrot>,
 which contains all the necessary guts of Parrot. When the fakecutable is
 executed, a small driver program loads the PBC data into libparrot through
-it's API functions. The Parrot executable is just one small example of how
+its API functions. The Parrot executable is just one small example of how
 Parrot's functionality can be implemented, and we will talk about a few other
 ways here too.
 
@@ -135,7 +135,7 @@
 =head3 Creating and Interoperating Interpreters
 
 Parrot's executable, which is the interface which most users are going
-to be familiar with uses a single interpreter structure to perform a
+to be familiar with, uses a single interpreter structure to perform a
 single execution task. However, this isn't the only supported structural
 model that Parrot supports. In fact, the interpreter structure is not a
 singleton, and multiple interpreters can be created by a single program.
@@ -160,7 +160,7 @@
 specific environments (such as within a single program) are called
 I<Domain-Specific Languages> (DSL). DSLs are a very popular topic because
 a DSL allows developers to create a custom language that makes dealing
-with a given problem space or data set very easy. Parrot and it's suite
+with a given problem space or data set very easy. Parrot and its suite
 of compiler tools in turn make creating the DSLs very easy. It's all
 about ease of use.
 
@@ -251,4 +251,4 @@
 # Local variables:
 #   c-file-style: "parrot"
 # End:
-# vim: expandtab shiftwidth=4:
\ No newline at end of file
+# vim: expandtab shiftwidth=4:
Index: docs/book/ch05_pasm.pod
===================================================================
--- docs/book/ch05_pasm.pod	(revision 34470)
+++ docs/book/ch05_pasm.pod	(working copy)
@@ -66,7 +66,7 @@
 capital letters to make them stand out from the rest of the source code
 more clearly. A label definition is simply the name of the label
 followed by a colon. It can be on its own line N<In fact, we recommend
-that it be on it's own line, for readability.>:
+that it be on its own line, for readability.>:
 
   LABEL:
       print "Norwegian Blue\n"
Index: docs/book/ch03_pir_basics.pod
===================================================================
--- docs/book/ch03_pir_basics.pod	(revision 34470)
+++ docs/book/ch03_pir_basics.pod	(working copy)
@@ -27,7 +27,7 @@
 instructional code examples. The documentation for the PIR compiler IMCC
 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
+implementation. The other PIR compiler, PIRC, has its own documentation
 that is slowly maturing. This is a useful source of information too. The
 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
@@ -268,7 +268,7 @@
 The statement C<sum = $I42 + 5> translates to something like
 C<add I16, I17, 5> in PASM. The exact translation isn't too important
 N<Unless you're hacking on IMCC or PIRC!>, so we don't have to worry
-about it for now. We will talk more about PASM and it's instruction
+about it for now. We will talk more about PASM and its instruction
 set in X<CHP-5> Chapter 5.
 
 PIR also provides automatic assignment operators such as C<+=>, C<-=>,
Index: CREDITS
===================================================================
--- CREDITS	(revision 34470)
+++ CREDITS	(working copy)
@@ -252,6 +252,11 @@
 D: Rakudo builtins
 E: [email protected]
 
+N: Curtis 'Ovid' Poe
+U: Ovid
+D: docs/test cleanups/Makefile fixes
+E: [email protected]
+
 N: Curtis Rawls
 U: cgrawls
 D: imcc optimizer and register allocator patches and tests