Fix assorted comment and documentation typos

Doc/Devel/internals.html

@@ -347,7 +347,7 @@ Delete(a);              /* Destroy a */
 
 All objects are referenced counted and given a reference count of 1 when initially created.  The
 <tt>Delete()</tt> function only destroys an object when the reference count reaches zero.  When
-an object is placed in a list or hash table, it's reference count is automatically increased. For example:
+an object is placed in a list or hash table, its reference count is automatically increased. For example:
 
 <blockquote>
 <pre>
@@ -844,7 +844,7 @@ Returns a type object corresponding to the type string produced by the Swig_cloc
 <li><tt>char *Swig_clocal_deref(DataType *t, char *name)</tt><br>
 This function is the inverse of the <tt>clocal()</tt> function.  Given a type and a name,
 it produces a string containing the code needed to cast/convert the type produced by
-<tt>Swig_clocal()</tt> back into it's original type.
+<tt>Swig_clocal()</tt> back into its original type.
 
 <p>
 <li><tt>char *Swig_clocal_assign(DataType *t, char *name)</tt><br>

Doc/Devel/tree.html

@@ -185,7 +185,7 @@ this function merely records that those attributes did not exist in the original
 <blockquote>
 This function is similar to <tt>Swig_save()</tt> except that adds additional attribute checking. There are different interpretations
 of the attribute names.  A name of "attr" merely requests that the function check for the presence of an attribute.  If the attribute is missing, SWIG will exit with a failed assertion.   An attribute name of "?attr" specifies that the attribute "attr" is optional and
-that it's old value must be saved (if any).   An attribute name of "*attr" specifies that the attribute is required and that
+that its old value must be saved (if any).   An attribute name of "*attr" specifies that the attribute is required and that
 its value must be saved.   The saving of attributes is performed in the same manner as with <tt>Swig_save()</tt>. Here is an example:
 
 <pre>

Doc/Manual/Allegrocl.html

@@ -748,7 +748,7 @@ namespace car {
     
     <p>
       Constants, as declared by the preprocessor #define macro or SWIG
-      <tt>%constant</tt> directive, are included in SWIGs parse tree
+      <tt>%constant</tt> directive, are included in SWIG's parse tree
       when it can be determined that they are, or could be reduced to,
       a literal value. Such values are translated into defconstant
       forms in the generated lisp wrapper when the -nocwrap command-line
@@ -887,7 +887,7 @@ globalvar&gt; (globalvar.nnn::glob_float)
     <p>
       In C, an enumeration value is an integer value, while in C++ an
       enumeration value is implicitly convertible to an integer value,
-      but can also be distinguished by it's enum type. For each enum
+      but can also be distinguished by its enum type. For each enum
       declaration a def-foreign-type is generated, assigning the enum
       a default type of :int. Users may adjust the foreign type of
       enums via SWIG <tt>typemaps</tt>.
@@ -901,7 +901,7 @@ globalvar&gt; (globalvar.nnn::glob_float)
       of it not being necessary to probe into foreign space to retrieve enum
       values. When generating a .cxx wrapper file, a more general solution is
       employed. A wrapper variable is created in the module_wrap.cxx file, and
-      a ff:def-foreign-variable call is generated to retrieve it's value into lisp. 
+      a ff:def-foreign-variable call is generated to retrieve its value into lisp.
     </p>
 
     <p>For example, the following header file
@@ -1131,7 +1131,7 @@ namespace BAR {
       inheritance of the classes in foreign code, with the
       ff:foreign-pointer class at its root. ff:foreign-pointer is a thin
       wrapper for pointers that is made available by the foreign function
-      interface. It's key benefit is that it may be passed as an argument
+      interface. Its key benefit is that it may be passed as an argument
       to any ff:def-foreign-call that is expecting a pointer as the
       parameter.
     </p>
@@ -1617,7 +1617,7 @@ opoverload&gt;
       directive. This directive allows you to specify a (finite)
       argument list which will be inserted into the wrapper in place
       of the variable length argument indicator.  As an example,
-      consider the function <tt>printf()</tt>. It's declaration would
+      consider the function <tt>printf()</tt>. Its declaration would
       appear as follows:
     </p>
 
@@ -1735,7 +1735,7 @@ return-val wrapper-name(parm0, parm1, ..., parmN)
       The <tt>out</tt> typemap is used to generate code to form the
       return value of the wrapper from the return value of the wrapped
       function. This code is placed in the &lt;convert and bind result to lresult&gt;
-      section of the above code diagram. It's default mapping is as follows:
+      section of the above code diagram. Its default mapping is as follows:
     </p>
 
     <div class="code">
@@ -1758,7 +1758,7 @@ return-val wrapper-name(parm0, parm1, ..., parmN)
     <p>
       This typemap is not used for code generation, but purely for the
       transformation of types in the parameter list of the wrapper function.
-      It's primary use is to handle by-value to by-reference conversion in the
+      Its primary use is to handle by-value to by-reference conversion in the
       wrappers parameter list. Its default settings are:
     </p>
 
@@ -2093,7 +2093,7 @@ foreign environment.
 
 <p>
 The :type keyword argument provides more information on the type of
-identifier. It's value is a symbol. This allows the
+identifier. Its value is a symbol. This allows the
 identifier-converter to apply different heuristics when mapping
 different types of identifiers to symbols. SWIG will generate calls
 to your identifier-converter using the following types.
@@ -2123,7 +2123,7 @@ scope in the specified class.
 
 <p>
 The :arity keyword argument only appears in swig:swig-defmethod forms
-generated for overloaded functions. It's value is an integer
+generated for overloaded functions. Its value is an integer
 indicating the number of arguments passed to the routine indicated by
 this identifier.
 </p>

Doc/Manual/CSharp.html

@@ -881,7 +881,7 @@ set so should only be used when a C# exception is not created.
 
 
 <p>
-Lets say we have the following simple C++ method:
+Let's say we have the following simple C++ method:
 </p>
 
 

Doc/Manual/Extending.html

@@ -2761,8 +2761,8 @@ Within SWIG wrappers, there are five main sections. These are (in order)
 <li>begin: This section is a placeholder for users to put code at the beginning of the C/C++ wrapper file.
 <li>runtime: This section has most of the common SWIG runtime code.
 <li>header: This section holds declarations and inclusions from the .i file.
-<li>wrapper: This section holds all the wrappering code.
-<li>init: This section holds the module initalisation function
+<li>wrapper: This section holds all the wrapper code.
+<li>init: This section holds the module initialisation function
 (the entry point for the interpreter).
 </ul>
 <p>
@@ -3005,7 +3005,7 @@ virtual int functionWrapper(Node *n) {
   /* write typemaps(in) */
   ....
 
-  /* write constriants */
+  /* write constraints */
   ....
 
   /* Emit the function call */

Doc/Manual/Introduction.html

@@ -449,7 +449,7 @@ to work with complicated and unusual C/C++ applications.
 
 <p>
 Ironically, the freedom that SWIG provides is countered by an
-extremely conservative approach to code generation. At it's core, SWIG
+extremely conservative approach to code generation. At its core, SWIG
 tries to distill even the most advanced C++ code down to a small
 well-defined set of interface building techniques based on ANSI C
 programming.  Because of this, you will find that SWIG interfaces can

Doc/Manual/Lisp.html

@@ -122,7 +122,7 @@ swig -cffi -help
 
 
 As we mentioned earlier the ideal way to use SWIG is to use interface
-    files. To illustrate the use of it, lets assume that we have a
+    files. To illustrate the use of it, let's assume that we have a
     file named <i>test.h</i> with the following C code:
 
 <div class="code"><pre>

Doc/Manual/Modula3.html

@@ -45,7 +45,7 @@
 
 
 <p>
-This chapter describes SWIG's support of
+This chapter describes SWIG's support for
 <a href="http://modula3.org/">Modula-3</a>.
 You should be familiar with the
 <a href="SWIG.html#SWIG">basics</a>
@@ -109,7 +109,7 @@ into exceptions.
 
 <p>
 If the library API is ill designed
-writing appropriate typemaps can be still time-consuming.
+writing appropriate typemaps can still be time-consuming.
 E.g. C programmers are very creative to work-around
 missing data types like (real) enumerations and sets.
 You should turn such work-arounds back to the Modula-3 way
@@ -120,14 +120,14 @@ otherwise you lose static safety and consistency.
 Without SWIG you would probably never consider trying to call C++ libraries
 from Modula-3, but with SWIG this is becomes feasible.
 SWIG can generate C wrappers to C++ functions and object methods
-that may throw exceptions, and then wrap these C wrappers for Module-3.
+that may throw exceptions, and then wrap these C wrappers for Modula-3.
 To make it complete you can then hide the C interface with Modula-3 classes and
 exceptions.
 </p>
 
 <p>
 SWIG allows you to call C and C++ libraries from Modula-3 (even with call back
-functions), but it doesn't allow you to easily integrate a Module-3 module into
+functions), but it doesn't allow you to easily integrate a Modula-3 module into
 a C/C++ project.
 </p>
 

Doc/Manual/Modules.html

@@ -130,7 +130,7 @@ public:
 
 <p>To create the wrapper properly, module <tt>derived_module</tt> needs to know about the
 <tt>base</tt> class and that its interface is covered in another module. The
-line <tt>%import "base_module.i"</tt> lets SWIG know exactly that. Oftentimes
+line <tt>%import "base_module.i"</tt> lets SWIG know exactly that. Often
 the <tt>.h</tt> file is passed to <tt>%import</tt> instead of the <tt>.i</tt>, 
 which unfortunately doesn't work for all language modules. For example, Python requires the
 name of module that the base class exists in so that the proxy classes can fully inherit the

Doc/Manual/Ocaml.html

@@ -163,7 +163,7 @@ the user more freedom with respect to custom typing.
 
 <p>
 The camlp4 module (swigp4.ml -&gt; swigp4.cmo) contains a simple rewriter which
-makes C++ code blend more seamlessly with objective caml code.  It's use is
+makes C++ code blend more seamlessly with objective caml code.  Its use is
 optional, but encouraged.  The source file is included in the Lib/ocaml
 directory of the SWIG source distribution.  You can checkout this file with 
 <tt>"swig -ocaml -co swigp4.ml"</tt>.  You should compile the file with 
@@ -310,7 +310,7 @@ type c_obj =
           </li>
           <li>caml_val_ptr receives a void * and returns a c_obj.</li>
           <li>caml_val_bool receives a C int and returns a c_obj representing 
-  it's  bool value.</li>
+  its  bool value.</li>
           <li>caml_val_(u)?(char|short|int|long|float|double) receives an 
 appropriate    C value and returns a c_obj representing it.</li>
           <li>caml_val_string receives a char * and returns a string value.</li>

Doc/Manual/Octave.html

@@ -329,7 +329,7 @@ octave:4> swigexample.fclose(f);
 </pre></div>
 
 <p>
-     Simply printing the value of a wrapped C++ type will print it's typename. E.g., 
+     Simply printing the value of a wrapped C++ type will print its typename. E.g.,
 </p>
 
     <div class="targetlang"><pre>octave:1&gt; swigexample;