Fix comment typos in Lua typemaps

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

Lib/lua/_std_common.i

@@ -4,7 +4,7 @@
  * std::helpers for LUA
  * ----------------------------------------------------------------------------- */
 
-%include <std_except.i> // the general exepctions
+%include <std_except.i> // the general exceptions
 
 /*
 The basic idea here, is instead of trying to feed SWIG all the
@@ -16,9 +16,9 @@ so the class declarations become just a set of %defines
 */
 
 /* #define for basic container features
-note: I allow front(), back() & pop_back() to throw execptions
+note: I allow front(), back() & pop_back() to throw exceptions
 upon empty containers, rather than coredump
-(as we have'nt defined the methods, we can use %extend to add with
+(as we haven't defined the methods, we can use %extend to add with
 new features)
 
 */

Lib/lua/carrays.i

@@ -1,5 +1,5 @@
 /* Small change to the standard carrays.i
-renaming the field to __getitem__ & __setitem__ 
+renaming the field to __getitem & __setitem
 for operator[] access
 */
 %rename(__getitem) *::getitem; // the v=X[i] (get operator)

Lib/lua/lua.swg

@@ -142,8 +142,8 @@
 /* ------------------------------------------------------------
  *                              Exceptions
  * ------------------------------------------------------------ */
-/* Confession: I dont really like C++ exceptions
-The python/lua ones are great, but C++ ones I dont like
+/* Confession: I don't really like C++ exceptions
+The python/lua ones are great, but C++ ones I don't like
 (mainly because I cannot get the stack trace out of it)
 Therefore I have not bothered to try doing much in this
 
@@ -191,7 +191,7 @@ There are a few options:
 - return a copy of it: but not all objects are copyable
 	(see exception_partial_info in the test suite for a case where you cannot do this)
 - convert to a string & throw that
-	its not so useful, but it works (this is more lua like).
+	it's not so useful, but it works (this is more lua like).
 The third option (though not nice) is used
 For a more useful solution: see std_except for more details
 */

Lib/lua/lua_fnptr.i

@@ -8,7 +8,7 @@
  *                          Basic function pointer support
  * ----------------------------------------------------------------------------- */
 /*
-The structure: SWIGLUA_FN provides a simple (local only) wrappering for a function.
+The structure: SWIGLUA_FN provides a simple (local only) wrapping for a function.
 
 For example if you wanted to have a C/C++ function take a lua function as a parameter.
 You could declare it as:
@@ -29,7 +29,7 @@ just push the parameters, call the function and return the result.
     return luaL_checknumber(fn.L,-1);
   }
 
-SWIG will automatically performs the wrappering of the arguments in and out.
+SWIG will automatically performs the wrapping of the arguments in and out.
 
 However: if you wish to store the function between calls, look to the SWIGLUA_REF below.
 
@@ -64,8 +64,8 @@ Then call it later, You could declare it as:
 note: it should be passed by value, not byref or as a pointer.
 
 The SWIGLUA_REF holds a pointer to the lua_State, and an integer reference to the object.
-Because it holds a permenet ref to an object, the SWIGLUA_REF must be handled with a bit more care.
-It should be initalised to {0,0}. The function swiglua_ref_set() should be used to set it.
+Because it holds a permanent ref to an object, the SWIGLUA_REF must be handled with a bit more care.
+It should be initialised to {0,0}. The function swiglua_ref_set() should be used to set it.
 swiglua_ref_clear() should be used to clear it when not in use, and swiglua_ref_get() to get the
 data back.
 
@@ -82,7 +82,7 @@ if you need that you must add it yourself.
     return luaL_checknumber(fn.L,-1);
   }
 
-SWIG will automatically performs the wrappering of the arguments in and out.
+SWIG will automatically performs the wrapping of the arguments in and out.
 
 However: if you wish to store the function between calls, look to the SWIGLUA_REF below.
 

Lib/lua/luarun.swg

@@ -121,7 +121,7 @@ typedef struct swig_lua_class {
   const char **base_names;
 } swig_lua_class;
 
-/* this is the struct for wrappering all pointers in SwigLua
+/* this is the struct for wrapping all pointers in SwigLua
 */
 typedef struct {
   swig_type_info   *type;
@@ -129,7 +129,7 @@ typedef struct {
   void        *ptr;
 } swig_lua_userdata;
 
-/* this is the struct for wrapping arbitary packed binary data
+/* this is the struct for wrapping arbitrary packed binary data
 (currently it is only used for member function pointers)
 the data ordering is similar to swig_lua_userdata, but it is currently not possible
 to tell the two structures apart within SWIG, other than by looking at the type
@@ -213,7 +213,7 @@ SWIG_Lua_SetModule(lua_State* L, swig_module_info *module) {
  * ----------------------------------------------------------------------------- */
 
 /* this function is called when trying to set an immutable.
-default value is to print an error.
+default action is to print an error.
 This can removed with a compile flag SWIGLUA_IGNORE_SET_IMMUTABLE */
 SWIGINTERN int SWIG_Lua_set_immutable(lua_State* L)
 {
@@ -634,7 +634,7 @@ SWIGINTERN void SWIG_Lua_init_base_class(lua_State* L,swig_lua_class* clss)
       swig_type_info *info = SWIG_TypeQueryModule(module,module,clss->base_names[i]);
       if (info) clss->bases[i] = (swig_lua_class *) info->clientdata;
     }
-  }	
+  }
 }
 
 /* performs the entire class registration process */
@@ -882,8 +882,8 @@ SWIG_Lua_InstallConstants(lua_State* L, swig_lua_const_info constants[]) {
 #ifndef SWIG_DOSTRING_FAIL /* Allows redefining of error function */
 #define SWIG_DOSTRING_FAIL(S) fprintf(stderr,"%s\n",S)
 #endif
-/* Executes a C string in Lua a really simple way of calling lua from C
-Unfortunately lua keeps changing its API's, so we need a conditional compile
+/* Executes a C string in Lua which is a really simple way of calling lua from C
+Unfortunately lua keeps changing its APIs, so we need a conditional compile
 In lua 5.0.X its lua_dostring()
 In lua 5.1.X its luaL_dostring()
 */

Lib/lua/luatypemaps.swg

@@ -13,7 +13,7 @@
    the fn call must be of the form
      int checkfn(lua_State *L, int index);
    and return 1/0 depending upon if this is the correct type
-   For the typemap(out), an additional SWIG_arg parmeter must be incremented
+   For the typemap(out), an additional SWIG_arg parameter must be incremented
    to reflect the number of values returned (normally SWIG_arg++; will do)
 */
 // numbers
@@ -33,7 +33,7 @@ $1 = ($type)lua_tonumber(L, $input);%}
              float,double
 %{  lua_pushnumber(L, (lua_Number) $1); SWIG_arg++;%}
 
-// we must also provide typemaps for privitives by const reference:
+// we must also provide typemaps for primitives by const reference:
 // given a function:
 //	int intbyref(const int& i);
 // SWIG assumes that this code will need a pointer to int to be passed in
@@ -132,7 +132,7 @@ SWIGINTERN int SWIG_lua_isnilstring(lua_State *L, int idx) {
 // it should be converted to a SWIG NULL.
 // This will only be allowed for pointers & arrays, not refs or by value
 // the checkfn lua_isuserdata will only work for userdata
-// the checkfn SWIG_isptrtype will work for both userdata and nil's
+// the checkfn SWIG_isptrtype will work for both userdata and nil
 %typemap(in,checkfn="SWIG_isptrtype") SWIGTYPE*,SWIGTYPE[]
 %{
   if (!SWIG_IsOK(SWIG_ConvertPtr(L,$input,(void**)&$1,$descriptor,$disown))){
@@ -219,9 +219,9 @@ $1=($1_ltype)&temp;%}
 
 // member function pointer
 // a member fn ptr is not 4 bytes like a normal pointer, but 8 bytes (at least on mingw)
-// so the standard wrappering cannot be done
+// so the standard wrapping cannot be done
 // nor can you cast a member function pointer to a void* (obviously)
-// therefore a special wrappering functions SWIG_ConvertMember() & SWIG_NewMemberObj() were written
+// therefore a special wrapping functions SWIG_ConvertMember() & SWIG_NewMemberObj() were written
 #ifdef __cplusplus
 %typemap(in,checkfn="lua_isuserdata") SWIGTYPE (CLASS::*)
 %{
@@ -241,7 +241,7 @@ $1=($1_ltype)&temp;%}
 
 /* void* is a special case
 A function void fn(void*) should take any kind of pointer as a parameter (just like C/C++ does)
-but if its an output, then it should be wrappered like any other SWIG object (using default typemap)
+but if its an output, then it should be wrapped like any other SWIG object (using default typemap)
 */
 %typemap(in,checkfn="SWIG_isptrtype") void*
 %{$1=($1_ltype)SWIG_MustGetPtr(L,$input,0,0,$argnum,"$symname");%}
@@ -269,7 +269,7 @@ void fn(int a, float b, lua_State* s) is wrappable as
  * ----------------------------------------------------------------------------- */
 /* These are needed for the overloaded functions
 These define the detection routines which will spot what
-parmeters match which function
+parameters match which function
 */
 
 // unfortunately lua only considers one type of number
@@ -341,7 +341,7 @@ parmeters match which function
   }
 }
 
-// Also needed for object ptrs by const ref
+// Also needed for object pointers by const ref
 // eg const A* ref_pointer(A* const& a);
 // found in mixed_types.i
 %typecheck(SWIG_TYPECHECK_POINTER) SWIGTYPE *const&

Lib/lua/std_except.i

@@ -24,8 +24,8 @@ namespace std
   }; 
 }
 
-// normally object which are thrown are returned to interpreter as errors
-// (which potentally may have problems if they are not copied)
+// normally objects which are thrown are returned to the interpreter as errors
+// (which potentially may have problems if they are not copied)
 // therefore all classes based upon std::exception are converted to their strings & returned as errors
 %typemap(throws) std::bad_exception     "SWIG_exception(SWIG_RuntimeError, $1.what());"
 %typemap(throws) std::domain_error      "SWIG_exception(SWIG_ValueError, $1.what());"

Lib/lua/std_pair.i

@@ -10,7 +10,7 @@
 /*
 A really cut down version of the pair class.
 
-this is not useful on its owns is it needs a %template definition with it
+this is not useful on its own - it needs a %template definition with it
 
 eg.
 namespace std {

Lib/lua/std_string.i

@@ -9,7 +9,7 @@
 %}
 
 /*
-Only std::string and const std::string& are typemaped
+Only std::string and const std::string& are typemapped
 they are converted to the Lua strings automatically
 
 std::string& and std::string* are not
@@ -34,7 +34,7 @@ namespace std {
 
 /*
 Bug report #1526022:
-Lua strings and std::string can contain embeded zero's
+Lua strings and std::string can contain embedded zero bytes
 Therefore a standard out typemap should not be:
   lua_pushstring(L,$1.c_str());
 but
@@ -73,7 +73,7 @@ Not using: lua_tolstring() as this is only found in Lua 5.1 & not 5.0.2
 }
 
 /*
-std::string& can be wrappered, but you must inform SWIG if it is in or out
+std::string& can be wrapped, but you must inform SWIG if it is in or out
 
 eg:
 void fn(std::string& str);
@@ -121,7 +121,7 @@ as this is overloaded by the const char* version
       void assign(const char*);
       //void assign(const string&);
       // no support for all the other features
-      // its probably better to do it in lua
+      // it's probably better to do it in lua
   };
 }
 

Lib/lua/std_vector.i

@@ -7,7 +7,7 @@
 %{
 #include <vector>
 %}
-%include <std_except.i> // the general exepctions
+%include <std_except.i> // the general exceptions
 /*
 A really cut down version of the vector class.
 

Lib/lua/typemaps.i

@@ -140,21 +140,21 @@ a few things of note:
 	so for the above mentioned return_array_5() would look like
 	arr=return_array_5() -- no parameters passed in
 * for INOUT arrays, a table must be passed in, and a new table will be returned
-	(this is consistant with the way that numbers are processed)
+	(this is consistent with the way that numbers are processed)
 	if you want just use
 	arr={...}
 	arr=process_var_array_inout(arr)	-- arr is replaced by the new version
 
 The following are not yet supported:
-* variable length output only array (inout's work ok)
-* multidimentional arrays
+* variable length output only array (inout works ok)
+* multidimensional arrays
 * arrays of objects/structs
 * arrays of pointers
 
 */
 
 /*
-The internals of the array managment stuff
+The internals of the array management stuff
 helper fns/macros
 SWIG_ALLOC_ARRAY(TYPE,LEN)	// returns a typed array TYPE[LEN]
 SWIG_FREE_ARRAY(PTR)		// delete the ptr (if not zero)
@@ -367,7 +367,7 @@ SWIG_TYPEMAP_NUM_ARR(double,double);
 %typemap(freearg) enum SWIGTYPE INPUT[ANY]
 %{	SWIG_FREE_ARRAY($1);%}
 
-// variable size array's
+// variable size arrays
 %typemap(in) (enum SWIGTYPE *INPUT,int)
 %{	$1 = ($ltype)SWIG_get_int_num_array_var(L,$input,&$2);
 	if (!$1) SWIG_fail;%}
@@ -414,7 +414,7 @@ void** SWIG_get_ptr_array_var(lua_State* L, int index, int* size,swig_type_info
 	// all pointers have the ownership value 'own' (normally 0)
 void SWIG_write_ptr_array(lua_State* L,void **array,int size,int own);
 	// read the specified table, and fills the array with ptrs
-	// returns 1 of ok (only fails if it doesnt find correct type of ptrs)
+	// returns 1 of ok (only fails if it doesn't find correct type of ptrs)
 	// helper fn (called by SWIG_get_ptr_array_*() fns)
 int SWIG_read_ptr_array(lua_State* L,int index,void **array,int size,swig_type_info *type);
 
@@ -424,7 +424,7 @@ modification of pointers ownership in the arrays
 eg A fn:
 void pointers_in(TYPE* arr[],int len);
 will make copies of the pointer into a temp array and then pass it into the fn
-Lua does not remeber that this fn held the pointers, so it is not safe to keep
+Lua does not remember that this fn held the pointers, so it is not safe to keep
 these pointers until later
 
 eg A fn:
@@ -551,7 +551,7 @@ free(ptr);
 With the following SWIG code
 %apply SWIGTYPE** OUTPUT{iMath **pptr };
 
-You can get natural wrappering in Lua as follows:
+You can get natural wrapping in Lua as follows:
 ok,ptr=Create_Math() -- ptr is a iMath* which is returned with the int
 ptr=nil -- the iMath* will be GC'ed as normal
 */