fix docs, path provided by Olly

git-svn-id: https://swig.svn.sourceforge.net/svnroot/swig/trunk/SWIG@9047 626c5289-ae23-0410-ae9c-e8d60b6d4f22

Doc/Manual/Modules.html

@@ -169,7 +169,7 @@ a <tt>Derived</tt> instance and call the wrapper for <tt>Base::method</tt>.
 
 <p>
 <b>%feature("compactdefaultargs")</b><br>
-This feature can reduce the number of wrapper methods when wrapping methods with default arguments. The section on <a href="SWIGPlus.html#SWIGPlus_default_args">default arguments</a> discusses the feature and it's limitations.
+This feature can reduce the number of wrapper methods when wrapping methods with default arguments. The section on <a href="SWIGPlus.html#SWIGPlus_default_args">default arguments</a> discusses the feature and its limitations.
 </p>
 
 </body>

Doc/Manual/Python.html

@@ -1021,7 +1021,7 @@ dereference the pointer from Python. Of course, that isn't much of a concern in
 In older versions of Swig (1.3.22 or older), pointers were represented
 using a plain string object. If you have an old package that still
 requires that representation, or you just feel nostalgic, you can
-always retreive it by casting the pointer object to a string:
+always retrieve it by casting the pointer object to a string:
 </p>
 
 <div class="targetlang"><pre>
@@ -4583,7 +4583,7 @@ class object (if applicable).
 <p>
 Using docstrings in Python code is becoming more and more important
 and more tools are coming on the scene that take advantage of them,
-everything from full-blown documentaiton generators to class browsers
+everything from full-blown documentation generators to class browsers
 and popup call-tips in Python-aware IDEs.  Given the way that SWIG
 generates the proxy code by default, your users will normally get
 something like <tt>"function_name(*args)"</tt> in the popup calltip of

Doc/Manual/SWIGPlus.html

@@ -822,7 +822,7 @@ public:
 
 <p>
 SWIG handles default arguments by generating an extra overloaded method for each defaulted argument.
-SWIG is effectively handling methods with default arguments as if it had wrapped the equivalent overloaded methods.
+SWIG is effectively handling methods with default arguments as if it was wrapping the equivalent overloaded methods.
 Thus for the example above, it is as if we had instead given the following to SWIG:
 </p>
 
@@ -839,7 +839,7 @@ public:
 
 <p>
 The wrappers produced are exactly the same as if the above code was instead fed into SWIG.
-Details of this is covered later in the <a href="#SWIGPlus_overloaded_methods">Wrapping Overloaded Functions and Methods</a> section.
+Details of this are covered later in the <a href="#SWIGPlus_overloaded_methods">Wrapping Overloaded Functions and Methods</a> section.
 This approach allows SWIG to wrap all possible default arguments, but can be verbose.
 For example if a method has ten default arguments, then eleven wrapper methods are generated.
 </p>

Examples/test-suite/argout.i

@@ -1,6 +1,6 @@
 /* This interface file checks how well SWIG handles passing data back
-   through arguments WITHOUT returning it seperatly; for the cases where
+   through arguments WITHOUT returning it separately; for the cases where
-   maybe multiple values are passed by refernce and all want changing */
+   maybe multiple values are passed by reference and all want changing */
 
 %module argout
 

Lib/perl5/perlfragments.swg

@@ -14,7 +14,7 @@
    }
   }
   
-  this will replace the code used to retreive an integer value for all
+  this will replace the code used to retrieve an integer value for all
   the typemaps that need it, including:
   
     int, std::vector<int>, std::list<std::pair<int,int> >, etc.

Lib/php4/php4run.swg

@@ -93,7 +93,7 @@ SWIG_ZTS_SetPointerZval(zval *z, void *ptr, swig_type_info *type, int newobject,
 
 /* This is a new pointer conversion routine
    Taking the native pointer p (which would have been converted from the old
-   string pointer) and it's php type id, and it's type name (which also would
+   string pointer) and its php type id, and its type name (which also would
    have come from the old string pointer) it converts it to ptr calling 
    appropriate casting functions according to ty
    Sadly PHP has no API to find a type name from a type id, only from an instance

Lib/python/director_h.swg

@@ -22,7 +22,7 @@
 
 /*
   Use -DSWIG_PYTHON_DIRECTOR_NO_VTABLE if you don't want to generate a 'virtual
-  table', and avoid multiple GetAttr calls to retreive the python
+  table', and avoid multiple GetAttr calls to retrieve the python
   methods.
 */
 

Lib/python/pyfragments.swg

@@ -14,7 +14,7 @@
    }
   }
   
-  this will replace the code used to retreive an integer value for all
+  this will replace the code used to retrieve an integer value for all
   the typemaps that need it, including:
   
     int, std::vector<int>, std::list<std::pair<int,int> >, etc.

Lib/ruby/rubyfragments.swg

@@ -14,7 +14,7 @@
    }
   }
   
-  this will replace the code used to retreive an integer value for all
+  this will replace the code used to retrieve an integer value for all
   the typemaps that need it, including:
   
     int, std::vector<int>, std::list<std::pair<int,int> >, etc.

Lib/tcl/tclfragments.swg

@@ -20,7 +20,7 @@
    }
   }
   
-  this will replace the code used to retreive an integer value for all
+  this will replace the code used to retrieve an integer value for all
   the typemaps that need it, including:
   
     int, std::vector<int>, std::list<std::pair<int,int> >, etc.

Lib/typemaps/swigmacros.swg

@@ -49,8 +49,8 @@
     %delete_array(cptr)             Delete an array
 
 
-  Auxiliar loop macros:
+  Auxiliary loop macros:
-  ---------------------
+  ----------------------
 
     %formacro(Macro, Args...) or %formacro_1(Macro, Args...)
        for i in Args

Source/Modules/php4.cxx

@@ -1048,13 +1048,13 @@ public:
     }
     
     /* Now convert from php to C variables */
-    // At this point, argcount if used is the number of deliberatly passed args
+    // At this point, argcount if used is the number of deliberately passed args
     // not including this_ptr even if it is used.
     // It means error messages may be out by argbase with error
     // reports.  We can either take argbase into account when raising 
     // errors, or find a better way of dealing with _thisptr
     // I would like, if objects are wrapped, to assume _thisptr is always
-    // _this and the and not the first argument
+    // _this and not the first argument
     // This may mean looking at Lang::memberfunctionhandler
 
     for (i = 0, p = l; i < num_arguments; i++) {