Merge pull request #203 from ManDude/master

doc: typo fixes

doc/object_file_generation.md

@@ -15,7 +15,7 @@ Each segment also has linking data, which tells the linker how to link reference
 
 This format will be different between the PC and PS2 versions, as linking data for x86-64 will need to look different from MIPS.
 
-Each segments can contain functions and data. The top-level segment must start with a function which will be run to initialize the object.  All the data here goes through the GOAL compiler and type system.
+Each segment can contain functions and data. The top-level segment must start with a function which will be run to initialize the object.  All the data here goes through the GOAL compiler and type system.
 
 # The V4 format
 The V4 format contains just data. Like v3, the data is GOAL objects, but was probably generated by a tool that wasn't the compiler. A V4 object has no segments, but must start with a `basic` object.  After being linked, the `relocate` method of this `basic` will be called, which should do any additional linking required for the specific object.
@@ -36,7 +36,7 @@ The compiler will use the library in V3 mode to generate object files for each `
 # CGO files
 The only CGO files read are `KERNEL.CGO` and `GAME.CGO`. 
  
- The `KERNEL.CGO` contains the GOAL kernel and some very basic libraries (`gcommon`, `gstring`, `gstate`, ...). I believe that `KERNEL` was always loaded on boot during development, as its required for the Listener to function.  
+ The `KERNEL.CGO` file contains the GOAL kernel and some very basic libraries (`gcommon`, `gstring`, `gstate`, ...). I believe that `KERNEL` was always loaded on boot during development, as its required for the Listener to function.  
 
 The `GAME.CGO` file combines the contents of the `ENGINE`, `COMMON` and `ART` CGO files.  `ENGINE` contains the game engine code, `COMMON` contains level-specific code (outside of the game engine) that is always loaded.  If code is used in basically all the levels, it makes sense to put in in `COMMON`, so it doesn't have to be loaded for each currently active level.  The `ART` CGO contains common art/textures/models, like Jak and his animations.  
 

doc/porting_to_x86.md

@@ -147,7 +147,7 @@ The DMAC is a sophisticated DMA controller. It runs separately from the EE and c
 The VU1 takes the role of vertex shaders. It can be programmed, but only in assembly, and it is extremely challenging and confusing. It has an extremely small memory (16 kB), but this memory is extremely fast. It's role is usually to do vertex transformations and lighting, then generate a list of commands to send to the GS.  The `XGKICK` instruction on VU1 is used to send data from the VU1 memory to the GS.
 
 The GS is the actual GPU. It has VRAM and receives commands from a few different places, including:
-- VU1 `XGICK`s stuff to it directly, bypassing the main bus used by DMAC/CPU memory access. This is called PATH 1 and is most commonly used in Jak 1.
+- VU1 `XGKICK`s stuff to it directly, bypassing the main bus used by DMAC/CPU memory access. This is called PATH 1 and is most commonly used in Jak 1.
 - When DMAing stuff to VU1, it first goes through a thing called VIF1 which can "unpack" data.  There is a special command that you can give to VIF1 which tells it to "send data directly to the GS".
 - DMA sends data directly from EE main memory to GS (Path 3), unused by Jak 1
 

doc/type_system.md

@@ -2,7 +2,7 @@ Type System
 --------------
 This document explains the GOAL type system.  The GOAL type system supports runtime typing, single inheritance, virtual methods, and dynamically sized structures. 
  
- Everything in GOAL has a type at compile time.  A subset of compile-time types are also available in the runtime as objects with the same name as the type.  For example, there is a `string` type, and a runtime there is a global object named `string` which is an object of type `type` containing information about the `string` type.
+ Everything in GOAL has a type at compile time.  A subset of compile-time types are also available in the runtime as objects with the same name as the type.  For example, there is a `string` type, and at runtime there is a global object named `string` which is an object of type `type` containing information about the `string` type.
   
   Some objects have runtime type information, and others don't.  Objects which have runtime type information can have their type identified at runtime, and are called "boxed objects".  Objects without runtime type information are called "unboxed objects".  An unboxed object cannot reliably be detected as a unboxed object - you can't write a function that takes an arbitrary object and tells you if its boxed or not.  However, boxed objects can always be recognized as boxed.
   
@@ -82,7 +82,7 @@ There are many combinations of reference/value, dynamic/not-dynamic, inline/not-
 
 Bonus ones, for where the array is stored _outside_ of the type:
 - A dynamically typed GOAL array, stored outside your type (think `std::vector`): use `(name (array your-type))`
-- A dynamically type GOAL array, stored inside your type: Not allowed, `array` is dynamic!
+- A dynamically typed GOAL array, stored inside your type: Not allowed, `array` is dynamic!
 - An array of value types, stored outside your type: use `(name (pointer your-type))`
 - An array of references (C++ array of pointers), stored outside your type: use `(name (pointer your-ref-type))`
 - An array of objects of reference type (C++ array of structs), stored outside your type: use `(name (inline-array your-ref-type))`
@@ -151,7 +151,7 @@ The first is to allow children to specialize methods and have their own child ty
 Then, if you created a child class of `square` called `rectangle` (this is a terrible way to use inheritance, but it's just an example), and overrode the `is-same-shape` method, you would have to have arguments that are `square`s, which blocks you from accessing `rectangle`-specific fields.  The solution is to define the original method with type `_type_` for the first two arguments.  Then, the method defined for `rectangle` also will have arguments of type `_type_`, which will expand to `rectangle`. 
 
 
-The second use is for a return value.  For example, the `print` and `inspect` methods both return the object that is passed to them, which will always be the same type as the argument passed in.  If `print` was define as `(function object object)`, then `(print my-square)` would lose the information that the return object is a `square`.  If `print` is a `(function _type_ _type)`, the type system will know that `(print my-square)` will return a `square`.
+The second use is for a return value.  For example, the `print` and `inspect` methods both return the object that is passed to them, which will always be the same type as the argument passed in.  If `print` was define as `(function object object)`, then `(print my-square)` would lose the information that the return object is a `square`.  If `print` is a `(function _type_ _type_)`, the type system will know that `(print my-square)` will return a `square`.
 
 Inline Array Class
 --------------------