From 9e9f5d84b3c37b415ba5fbf9deeec636657ceedd Mon Sep 17 00:00:00 2001 From: John Lenz Date: Fri, 18 Mar 2005 00:03:54 +0000 Subject: [PATCH] Update documentation to use the right div class="targetlang" and such. The only docs left to update are the individual language chapters. git-svn-id: https://swig.svn.sourceforge.net/svnroot/swig/trunk@7081 626c5289-ae23-0410-ae9c-e8d60b6d4f22 --- SWIG/Doc/Manual/Arguments.html | 10 ++-- SWIG/Doc/Manual/Contract.html | 2 +- SWIG/Doc/Manual/Customization.html | 2 +- SWIG/Doc/Manual/Extending.html | 90 +++++++++++++++--------------- SWIG/Doc/Manual/Introduction.html | 8 +-- SWIG/Doc/Manual/Library.html | 28 +++++----- SWIG/Doc/Manual/Preface.html | 6 +- SWIG/Doc/Manual/SWIG.html | 40 ++++++------- SWIG/Doc/Manual/SWIGPlus.html | 62 ++++++++++---------- SWIG/Doc/Manual/Scripting.html | 18 +++--- SWIG/Doc/Manual/Typemaps.html | 40 ++++++------- SWIG/Doc/Manual/Varargs.html | 6 +- SWIG/Doc/Manual/Warnings.html | 10 ++-- 13 files changed, 161 insertions(+), 161 deletions(-) diff --git a/SWIG/Doc/Manual/Arguments.html b/SWIG/Doc/Manual/Arguments.html index e06e689f4..a0c09e081 100644 --- a/SWIG/Doc/Manual/Arguments.html +++ b/SWIG/Doc/Manual/Arguments.html @@ -98,7 +98,7 @@ When the resulting module is created, you can now use the function like this (shown for Python):

-
+
 >>> a = add(3,4)
 >>> print a
 7
@@ -153,7 +153,7 @@ void getwinsize(int winid, int *width, int *height);
 In this case, the function returns multiple values, allowing it to be used like this:
 

 
-
+
 >>> w,h = genwinsize(wid)
 >>> print w
 400
@@ -234,7 +234,7 @@ extern double add(double *INPUT, double *INPUT);
 When the function is used in the scripting language interpreter, it will work like this:
 

 
-
+
 result = add(3,4)
 

 
@@ -297,7 +297,7 @@ extern int foo(double a, double b, double *OUTPUT);
 The function will return two values like this:
 

 
-

+

 
 iresult, dresult = foo(3.5, 2)
 

@@ -347,7 +347,7 @@ extern void negate(double *INOUT);
 

 Now within a script, you can simply call the function normally :

 
-
+
 a = negate(3);         # a = -3 after calling this
 

 
diff --git a/SWIG/Doc/Manual/Contract.html b/SWIG/Doc/Manual/Contract.html
index 6f8a5bf66..fc341fe23 100644
--- a/SWIG/Doc/Manual/Contract.html
+++ b/SWIG/Doc/Manual/Contract.html
@@ -82,7 +82,7 @@ Once a contract has been specified, it modifies the behavior of the
 resulting module.  For example:
 

 
-

+

 
 >>> example.sqrt(2)
 1.4142135623730951
diff --git a/SWIG/Doc/Manual/Customization.html b/SWIG/Doc/Manual/Customization.html
index 610df295c..46bcd9a13 100644
--- a/SWIG/Doc/Manual/Customization.html
+++ b/SWIG/Doc/Manual/Customization.html
@@ -425,7 +425,7 @@ As arguments, SWIG_exception() takes an error type code (an
 integer) and an error message string.  The currently supported error
 types are :

 
-
+
 SWIG_MemoryError
 SWIG_IOError
 SWIG_RuntimeError
diff --git a/SWIG/Doc/Manual/Extending.html b/SWIG/Doc/Manual/Extending.html
index 92660c029..acd5cd4a8 100644
--- a/SWIG/Doc/Manual/Extending.html
+++ b/SWIG/Doc/Manual/Extending.html
@@ -291,7 +291,7 @@ The current C++ parser handles a subset of C++.  Most incompatibilities with C a
 subtle aspects of how SWIG parses declarations.  Specifically, SWIG expects all C/C++ declarations to follow this general form:
 

 
-

+

 
 storage type declarator initializer;
 

@@ -395,7 +395,7 @@ The parse tree structure and tag names of an interface can be displayed using 
 
-

+

 
 $ swig -c++ -python -dump_tags example.i
  . top (example.i:1)
@@ -453,7 +453,7 @@ pairs.  Internally, the nodes are simply represented by hash tables.  A display
 the parse-tree structure can be obtained using swig -dump_tree. For example:
 

 
-

+

 
 $ swig -c++ -python -dump_tree example.i
 ...
@@ -683,7 +683,7 @@ void foo(Bar *b);
 Now, running SWIG:
 

 
-

+

 
 $ swig -dump_tree example.i
 ...
@@ -733,7 +733,7 @@ void foo(Bar *b);
 When you run SWIG on this you now get:
 

 
-

+

 
 $ ./swig example.i
 example.i:6. Overloaded declaration ignored.  foo_d(double )
@@ -777,7 +777,7 @@ given prototype.   When a feature is added, it shows up as an attribute in the <
 You can see this when running with the -dump_tree option.   For example:
 

 
-

+

 
  +++ cdecl ----------------------------------------
  | sym:name     - "getitem"
@@ -828,7 +828,7 @@ When the parser constructs a node for the member bar, it creates a raw
 attributes:
 

 
-

+

 
 nodeType    : cdecl
 name        : bar
@@ -844,7 +844,7 @@ sym:name    : bar
 To produce wrapper code, this "cdecl" node undergoes a number of transformations.  First, the node is recognized as a function declaration.   This adjusts some of the type information--specifically, the declarator is joined with the base datatype to produce this:
 

 
-

+

 
 nodeType    : cdecl
 name        : bar
@@ -862,7 +862,7 @@ member function.  This produces a transformation to a low-level
 accessor function like this:
 

 
-

+

 
 nodeType    : cdecl
 name        : bar
@@ -1795,7 +1795,7 @@ Internally, types are represented as strings that are constructed in a very
 precise manner.  Here are some examples:
 

 
-

+

 
 C datatype                     SWIG encoding (strings)
 -----------------------------  --------------------------
@@ -1819,7 +1819,7 @@ a "pointer to a function(int,double) that returns int".
 The following operator encodings are used in type strings:
 

 
-

+

 
 Operator              Meaning
 -------------------   -------------------------------
@@ -1846,7 +1846,7 @@ is expected.  For instance, here is
 an extremely perverted example:
 

 
-

+

 
 `p.a(10).p.f(int,p.f(int).int)` foo(int, int (*x)(int));
 

@@ -1856,7 +1856,7 @@ an extremely perverted example:
 This corresponds to the immediately obvious C declaration:
 

 
-

+

 
 (*(*foo(int,int (*)(int)))[10])(int,int (*)(int));
 

@@ -2139,7 +2139,7 @@ typedef int Size;
 produces two trees like this:
 

 
-

+

 
                  int               p.Integer
                ^  ^  ^                 ^ 
@@ -2169,7 +2169,7 @@ resolving types, the process starts in the leaf nodes and moves up
 the tree towards the root.   Here are a few examples that show how it works:
 

 
-

+

 
 Original type            After typedef_resolve()
 ------------------------ -----------------------
@@ -2185,7 +2185,7 @@ For complicated types, the process can be quite involved.  Here is the
 reduction of a function pointer:
 

 
-

+

 
 p.f(Integer, p.IntegerPtr, Size).Integer          : Start
 p.f(Integer, p.IntegerPtr, Size).int
@@ -2318,7 +2318,7 @@ functions and templates.  Parameter list are represented as a list of
 nodes with the following attributes:
 

 
-

+

 
 "type"        -  Parameter type  (required)
 "name"        -  Parameter name  (optional)
@@ -2332,7 +2332,7 @@ Typically parameters are denoted in the source by using a typename of
 code like this:
 

 
-

+

 
 Parm *parms;
 Parm *p;
@@ -2510,7 +2510,7 @@ Next, at the top level of the SWIG distribution, re-run the autogen.sh
 to regenerate the various build files:
 

 
-

+

 
 $ sh autogen.sh
 

@@ -2520,7 +2520,7 @@ $ sh autogen.sh
 Next re-run configure to regenerate all of the Makefiles:
 

 
-

+

 
 $ ./configure
 

@@ -2530,7 +2530,7 @@ $ ./configure
 Finally, rebuild SWIG with your module added:
 

 
-

+

 
 $ make
 

@@ -2974,7 +2974,7 @@ A declaration is parsed as "storage T D" where storage is a storage class, T is
 and D is a declarator.
 

 
-

+

 
 "name"          - Declarator name
 "type"          - Base type T
@@ -2995,7 +2995,7 @@ and D is a declarator.
 C++ constructor declaration.
 

 
-

+

 
 "name"          - Name of constructor
 "parms"         - Parameters
@@ -3014,7 +3014,7 @@ C++ constructor declaration.
 C++ destructor declaration.
 

 
-

+

 
 "name"          - Name of destructor
 "code"          - Function body code (if any)
@@ -3032,7 +3032,7 @@ C++ destructor declaration.
 C++ access change.
 

 
-

+

 
 "kind"          - public, protected, private
 

@@ -3047,7 +3047,7 @@ C++ access change.
 Constant created by %constant or #define.
 

 
-

+

 
 "name"          - Name of constant.
 "type"          - Base type.
@@ -3065,7 +3065,7 @@ Constant created by %constant or #define.
 C++ class definition or C structure definition.
 

 
-

+

 
 "name"          - Name of the class.
 "kind"          - Class kind ("struct", "union", "class")
@@ -3087,7 +3087,7 @@ C++ class definition or C structure definition.
 Enumeration.
 

 
-

+

 
 "name"          - Name of the enum (if supplied).
 "storage"       - Storage class (if any)
@@ -3105,7 +3105,7 @@ Enumeration.
 Enumeration value.
 

 
-

+

 
 "name"          - Name of the enum value.
 "type"          - Type (integer or char)
@@ -3122,7 +3122,7 @@ Enumeration value.
 C++ namespace.
 

 
-

+

 
 "name"          - Name of the namespace.
 "symtab"        - Symbol table for enclosed scope.
@@ -3140,7 +3140,7 @@ C++ namespace.
 C++ using directive.
 

 
-

+

 
 "name"          - Name of the object being referred to.
 "uname"         - Qualified name actually given to using.
@@ -3158,7 +3158,7 @@ C++ using directive.
 A forward C++ class declaration.
 

 
-

+

 
 "name"          - Name of the class.
 "kind"          - Class kind ("union", "struct", "class")
@@ -3175,7 +3175,7 @@ Code insertion directive.  For example, %{ ... %} or
 %insert(section).
 

 
-

+

 
 "code"          - Inserted code
 "section"       - Section name ("header", "wrapper", etc.)
@@ -3190,7 +3190,7 @@ Code insertion directive.  For example, %{ ... %} or
 Top of the parse tree.
 

 
-

+

 
 "module"        - Module name
 

@@ -3204,7 +3204,7 @@ Top of the parse tree.
 %extend directive.
 

 
-

+

 
 "name"          - Module name
 "symtab"        - Symbol table of enclosed scope.
@@ -3219,7 +3219,7 @@ Top of the parse tree.
 %apply pattern { patternlist }.
 

 
-

+

 
 "pattern"       - Source pattern.
 "symtab"        - Symbol table of enclosed scope.
@@ -3234,7 +3234,7 @@ Top of the parse tree.
 %clear patternlist;
 

 
-

+

 
 "firstChild"    - Patterns to clear
 

@@ -3248,7 +3248,7 @@ Top of the parse tree.
 %include directive.
 

 
-

+

 
 "name"         - Filename
 "firstChild"   - Children
@@ -3263,7 +3263,7 @@ Top of the parse tree.
 %import directive.
 

 
-

+

 
 "name"         - Filename
 "firstChild"   - Children
@@ -3279,7 +3279,7 @@ Top of the parse tree.
 %module directive.
 

 
-

+

 
 "name"         - Name of the module
 

@@ -3294,7 +3294,7 @@ Top of the parse tree.
 %typemap directive.
 

 
-

+

 
 "method"       - Typemap method name.
 "code"         - Typemap code.
@@ -3311,7 +3311,7 @@ Top of the parse tree.
 %typemap directive with copy.
 

 
-

+

 
 "method"       - Typemap method name.
 "pattern"      - Typemap source pattern.
@@ -3328,7 +3328,7 @@ Top of the parse tree.
 %typemap pattern. Used with %apply, %clear, %typemap.
 

 
-

+

 
 "pattern"      - Typemap pattern (a parameter list)
 "parms"        - Typemap parameters.
@@ -3343,7 +3343,7 @@ Top of the parse tree.
 %types directive.
 

 
-

+

 
 "parms"        - List of parameter types.
 

@@ -3358,7 +3358,7 @@ Top of the parse tree.
 extern "X" { ... } declaration.
 

 
-

+

 
 "name"       - Name "C", "Fortran", etc.
 

diff --git a/SWIG/Doc/Manual/Introduction.html b/SWIG/Doc/Manual/Introduction.html
index 15c411150..890e5ccaa 100644
--- a/SWIG/Doc/Manual/Introduction.html
+++ b/SWIG/Doc/Manual/Introduction.html
@@ -203,7 +203,7 @@ SWIG is invoked using the swig command. We can use this to
 build a Tcl module (under Linux) as follows :
 

 
-
+
 unix > swig -tcl example.i
 unix > gcc -c -fpic example.c example_wrap.c -I/usr/local/include
 unix > gcc -shared example.o example_wrap.o -o example.so
@@ -237,7 +237,7 @@ Now, let's turn these functions into a Perl5 module. Without making
 any changes type the following (shown for Solaris):
 

 
-
+
 unix > swig -perl5 example.i
 unix > gcc -c example.c example_wrap.c \
 	-I/usr/local/lib/perl5/sun4-solaris/5.003/CORE
@@ -262,7 +262,7 @@ unix >
 Finally, let's build a module for Python (shown for Irix).
 

 
-
+
 unix > swig -python example.i
 unix > gcc -c -fpic example.c example_wrap.c -I/usr/local/include/python2.0
 unix > gcc -shared example.o example_wrap.o -o _example.so
@@ -289,7 +289,7 @@ it. For example, you could also build a Perl5 module by just running
 SWIG on the C header file and specifying a module name as follows
 

 
-
+
 unix > swig -perl5 -module example example.h
 unix > gcc -c example.c example_wrap.c \
 	-I/usr/local/lib/perl5/sun4-solaris/5.003/CORE
diff --git a/SWIG/Doc/Manual/Library.html b/SWIG/Doc/Manual/Library.html
index ccf51e8f6..c6331f8d8 100644
--- a/SWIG/Doc/Manual/Library.html
+++ b/SWIG/Doc/Manual/Library.html
@@ -182,7 +182,7 @@ void add(int x, int y, int *result);
 Now, in Python:
 

 
-

+

 
 >>> import example
 >>> c = example.new_intp()     # Create an "int" for storing result
@@ -262,7 +262,7 @@ void add(int x, int y, int *result);
 Now, in Python (using proxy classes)
 

 
-

+

 
 >>> import example
 >>> c = example.intp()         # Create an "int" for storing result
@@ -626,7 +626,7 @@ Here is a simple example that illustrates the use of these macros:
 Now, in a script:
 

 
-

+

 
 >>> from example import *
 >>> a = malloc_int()
@@ -698,7 +698,7 @@ Here is a short example:
 Python example:
 

 
-

+

 
 >>> a = intArray(10)
 >>> for i in range(0,10):
@@ -949,7 +949,7 @@ void get_path(char *path);
 In the target language:
 

 
-

+

 
 >>> get_path()
 /home/beazley/packages/Foo/Bar
@@ -992,7 +992,7 @@ void get_packet(char *packet);
 In the target language:
 

 
-

+

 
 >>> get_packet()
 '\xa9Y:\xf6\xd7\xe1\x87\xdbH;y\x97\x7f"\xd3\x99\x14V\xec\x06\xea\xa2\x88'
@@ -1035,7 +1035,7 @@ void make_upper(char *ustr);
 In the target language:
 

 
-

+

 
 >>> make_upper("hello world")
 'HELLO WORLD'
@@ -1087,7 +1087,7 @@ void attach_header(char *hstr);
 In the target language:
 

 
-

+

 
 >>> make_upper("hello world")
 'HELLO WORLD'
@@ -1138,7 +1138,7 @@ void get_path(char *path, int maxpath);
 In the target language:
 

 
-

+

 
 >>> get_path(1024)
 '/home/beazley/Packages/Foo/Bar'
@@ -1184,7 +1184,7 @@ void get_data(char *data, int *maxdata);
 In the target language:
 

 
-

+

 
 >>> get_data(1024)
 'x627388912'
@@ -1241,7 +1241,7 @@ void foo(char **s);
 In the target language:
 

 
-

+

 
 >>> foo()
 'Hello world\n'
@@ -1291,7 +1291,7 @@ void foo(char **s, int *slen);
 In the target language:
 

 
-

+

 
 >>> foo()
 '\xa9Y:\xf6\xd7\xe1\x87\xdbH;y\x97\x7f"\xd3\x99\x14V\xec\x06\xea\xa2\x88'
@@ -1377,7 +1377,7 @@ void        bar(const std::string &x);
 In the target language:
 

 
-

+

 
 x = foo();                # Returns a string object
 bar("Hello World");       # Pass string as std::string
@@ -1522,7 +1522,7 @@ namespace std {
 Now, to illustrate the behavior in the scripting interpreter, consider this Python example:
 

 
-

+

 
 >>> from example import *
 >>> iv = IntVector(4)         # Create an vector<int>
diff --git a/SWIG/Doc/Manual/Preface.html b/SWIG/Doc/Manual/Preface.html
index 5478ceb96..7c95ad5ef 100644
--- a/SWIG/Doc/Manual/Preface.html
+++ b/SWIG/Doc/Manual/Preface.html
@@ -83,7 +83,7 @@ of SWIG-1.3 scare you---it is much more stable (and capable) than SWIG-1.1p5.
 The official location of SWIG related material is
 

 
-
+
 http://www.swig.org
 

 
@@ -96,7 +96,7 @@ implementation tricks.
 You can also subscribe to the SWIG mailing list by visiting the page
 

 
-
+
 http://www.swig.org/mail.html
 

 
@@ -110,7 +110,7 @@ CVS access to the latest version of SWIG is also available.  More information
 about this can be obtained at:
 

 
-
+
 http://www.swig.org/cvs.html
 

 
diff --git a/SWIG/Doc/Manual/SWIG.html b/SWIG/Doc/Manual/SWIG.html
index 953e6fc39..725d2fc51 100644
--- a/SWIG/Doc/Manual/SWIG.html
+++ b/SWIG/Doc/Manual/SWIG.html
@@ -96,7 +96,7 @@ To run SWIG, use the swig command with one or more of the
 following options and a filename like this:
 

 
-
+
 swig [ options ] filename
 
 -chicken              Generate CHICKEN wrappers
@@ -203,7 +203,7 @@ language (C, C++, etc.). Therefore, you have to use the
 file if you want something different than the default. For example:
 

 
-
+
 $ swig -c++ -python -o example_wrap.cpp example.i
 

 
@@ -224,13 +224,13 @@ specific files is the same directory as the generated C/C++ file. This can
 can be modified using the -outdir option. For example:
 

 
-
+
 $ swig -c++ -python -outdir pyfiles -o cppfiles/example_wrap.cpp example.i
 

 

 If the directories cppfiles and pyfiles exist, the following
 will be generated:

-
+
 cppfiles/example_wrap.cpp
 pyfiles/example.py
 

@@ -414,7 +414,7 @@ declarations are accessible as scripting language functions, variables, and
 constants respectively.  For example, in Tcl:
 

 
-
+
 % sin 3
 5.2335956
 % strcmp Dave Mike
@@ -430,7 +430,7 @@ constants respectively.  For example, in Tcl:
 Or in Python:
 

 
-
+
 >>> example.sin(3)
 5.2335956
 >>> example.strcmp('Dave','Mike')
@@ -871,7 +871,7 @@ representation that contains the actual value of the pointer and a type-tag.
 Thus, the SWIG representation of the above
 pointers (in Tcl), might look like this:

 
-
+
 _10081012_p_int
 _1008e124_ppp_double
 _f8ac_pp_char
@@ -979,7 +979,7 @@ as a pointer, so it doesn't really matter what it is. If you wrapped
 this module into Python, you can use the functions just like you
 expect :

 
-
+
 # Copy a file 
 def filecopy(source,target):
 	f1 = fopen(source,"r")
@@ -1115,7 +1115,7 @@ For example:
 In this case, you might run SWIG as follows:
 

 
-

+

 
 $ swig -I/usr/include -includeall example.i
 

@@ -1334,7 +1334,7 @@ it as a function from the target scripting language (it does not work
 like a variable).  For example, in Python you will have to write:
 

 
-

+

 
 >>> set_foo("Hello World")
 

@@ -1374,7 +1374,7 @@ getting the value.  However, the default behavior does not release the
 a possible memory leak).  In fact, you may get a warning message such as this when wrapping such a variable:
 

 
-

+

 
 example.i:20. Typemap warning. Setting const char * variable may leak memory
 

@@ -1710,7 +1710,7 @@ In this case, SWIG generates wrapper code where the
 default arguments are optional in the target language. For example, this function could be
 used in Tcl as follows :

 
-
+
 % plot -3.4 7.5 				# Use default value
 % plot -3.4 7.5 10				# set color to 10 instead
 
@@ -1751,7 +1751,7 @@ When you first wrap something like this into an extension module, you
 may find the function to be impossible to use.  For instance, in Python:
 

 
-
+
 >>> def add(x,y):
 ...     return x+y
 ...
@@ -1785,7 +1785,7 @@ In this case, add, sub, and mul become function point
 constants in the target scripting language.  This allows you to use them as follows:
 

 
-

+

 
 >>> binary_op(3,4,add)
 7
@@ -1800,7 +1800,7 @@ Unfortunately, by declaring the callback functions as constants, they are no lon
 as functions. For example:
 

 
-

+

 
 >>> add(3,4)
 Traceback (most recent call last):
@@ -1835,7 +1835,7 @@ by the function name).  The callback mode remains in effect until it is explicit
 disabled using %nocallback.  When you do this, the interface now works as follows:
 

 
-

+

 
 >>> binary_op(3,4,add_cb)
 7
@@ -2070,7 +2070,7 @@ When this
 situation is detected, SWIG may generate a warning message such as the
 following :

 
-
+
 interface.i:116. Warning. Array member will be read-only
 

 
@@ -2203,7 +2203,7 @@ can use the %nodefault directive or the -no_default
 command line option.  For example:
 

 
-
+
 swig -no_default example.i 
 

 
@@ -2306,7 +2306,7 @@ You can make a Vector look alot like a class by writing a SWIG interfac
 Now, when used with proxy classes in Python, you can do things like
 this :

 
-
+
 >>> v = Vector(3,4,0)                 # Create a new vector
 >>> print v.magnitude()                # Print magnitude
 5.0
@@ -2530,7 +2530,7 @@ Although this process is a little hairy, it works like you would expect in the
 target scripting language--especially when proxy classes are used.  For instance, in Perl:
 

 
-
+
 # Perl5 script for accessing nested member
 $o = CreateObject();                    # Create an object somehow
 $o->{intRep}->{ivalue} = 7              # Change value of o.intRep.ivalue
diff --git a/SWIG/Doc/Manual/SWIGPlus.html b/SWIG/Doc/Manual/SWIGPlus.html
index 418cdbf06..f4f360ac0 100644
--- a/SWIG/Doc/Manual/SWIGPlus.html
+++ b/SWIG/Doc/Manual/SWIGPlus.html
@@ -205,7 +205,7 @@ When compiling and linking the resulting wrapper file,  it is normal
 to use the C++ compiler.  For example:
 

 
-

+

 
 $ swig -c++ -tcl example.i
 $ c++ -c example_wrap.cxx 
@@ -394,7 +394,7 @@ all cases, this is caused when classes are determined to be abstract.   To see i
 all of its warnings turned on:
 

 
-

+

 
 % swig -Wall -python module.i
 

@@ -445,7 +445,7 @@ public:
 then the copy constructor can be used as follows:
 

 
-

+

 
 x = new_List()               # Create a list
 y = new_List(x)              # Copy list x
@@ -805,7 +805,7 @@ public:
 

 Generates the following set of constants in the target scripting language :

 
-
+
 Swig_ALE = Swig::ALE
 Swig_LAGER = Swig::LAGER
 Swig_PORTER = Swig::PORTER
@@ -916,7 +916,7 @@ void foo(const int &x);
 it is called from a script as follows:
 

 
-

+

 
 foo(3)              # Notice pass by value
 

@@ -1117,7 +1117,7 @@ public:
 When wrapped into Python, we can now perform the following operations
 :

 
-
+
 $ python
 >>> import shapes
 >>> circle = shapes.new_Circle(7)
@@ -1170,7 +1170,7 @@ base classes to be defined in an interface.  Otherwise, you may get an
 warning message like this:
 

 
-

+

 
 example:18. Nothing known about class 'Foo'. Ignored.
 

@@ -1252,7 +1252,7 @@ pointer and a type string.  For example, in Tcl, a C++ pointer might
 be encoded as a string like this:
 

 
-

+

 
 _808fea88_p_Circle
 

@@ -1328,7 +1328,7 @@ representation of C. With multiple inheritance, the data from
 each base class is stacked together.  For example:
 

 
-

+

 
              ------------    <--- (C *),  (A *)
             |     A      |
@@ -1437,7 +1437,7 @@ void foo(char *x) {
 The function is used in a completely natural way.  For example:
 

 
-

+

 
 >>> foo(3)
 x is 3
@@ -1468,7 +1468,7 @@ public:
 it might be used like this
 

 
-

+

 
 >>> f = Foo()          # Create a Foo
 >>> f.bar(3)
@@ -1516,7 +1516,7 @@ required arguments.
 
  • Argument type precedence.  All C++ datatypes are assigned a numeric type precedence value
 (which is determined by the language module).
    
 
-
    
+
    
 
     Type              Precedence
 ----------------  ----------
@@ -1559,7 +1559,7 @@ The first rule simply ranks the functions by required argument count.
 This would produce the following list:
 
    
 
-
    
+
    
 
     rank
 -----
@@ -1578,7 +1578,7 @@ rank
 The second rule, simply refines the ranking by looking at argument type precedence values.
 
    
 
-
    
+
    
 
     rank
 -----
@@ -1624,7 +1624,7 @@ just by looking at the value of the integer itself (int and long
 
-
    
+
    
 
     example.i:4: Warning(509): Overloaded foo(long) is shadowed by foo(int) at example.i:3.
 
    
@@ -1634,7 +1634,7 @@ example.i:4: Warning(509): Overloaded foo(long) is shadowed by foo(int) at examp
 or for statically typed languages like Java:
 
    
 
-
    
+
    
 
     example.i:4: Warning(516): Overloaded method foo(long) ignored. Method foo(int)
 at example.i:3 used.
@@ -1684,7 +1684,7 @@ Therefore, earlier methods will shadow methods that appear later.
 When wrapping an overloaded function, there is a chance that you will get an error message like this:
 
    
 
-
    
+
    
 
     example.i:3: Warning(467): Overloaded foo(int) not supported (no type checking
 rule for 'int').
@@ -1703,7 +1703,7 @@ undefined.  You should report this as a bug to the
 If you get an error message such as the following,
 
    
 
-
    
+
    
 
     foo.i:6. Overloaded declaration ignored.  Spam::foo(double )
 foo.i:5. Previous declaration is Spam::foo(int )
@@ -2224,7 +2224,7 @@ When used in the target language, it may now be possible to use the overloaded
 operator normally. For example:
 
    
 
-
    
+
    
 
     >>> a = Complex(3,4)
 >>> b = Complex(5,2)
@@ -2248,7 +2248,7 @@ name.  If you wrote this:
 The resulting scripting interface might work like this:
 
    
 
-
    
+
    
 
     a = Complex(3,4)
 b = Complex(5,2)
@@ -2361,7 +2361,7 @@ allow us to print the value of an object using the print
 command.
 
    
 
-
    +
     >>>
 >>> v = Vector();
 >>> v.x = 3
@@ -2651,7 +2651,7 @@ then SWIG knows that List<int> was already wrapped as a class cal
 nothing is known about List<int>, you will get a warning message similar to this:
 
    
 
-
    
+
    
 
     example.h:42. Nothing known about class 'List<int >' (ignored). 
 example.h:42. Maybe you forgot to instantiate 'List<int >' using %template. 
@@ -3347,7 +3347,7 @@ namespace B {
 When this conflict occurs, you will get an error message that resembles this:
 
    
 
-
    
+
    
 
     example.i:26. Error. 'foo' is multiply defined in the generated module.
 example.i:23. Previous declaration of 'foo'
@@ -3612,7 +3612,7 @@ modules, wrapped exception classes themselves can be used to catch errors.  For
 write code like this:
 
    
 
-
    
+
    
 
     f = Foo()
 try:
@@ -3661,7 +3661,7 @@ When pointers to members are supported, the pointer value might appear as a spec
 string like this:
 
    
 
-
    
+
    
 
     >>> print example.FOO
 _ff0d54a800000000_m_Object__f_double_double__double
@@ -3791,7 +3791,7 @@ The end result is that access looks very similar to C++.  For
 example, you could do this in Python:
 
    
 
-
    
+
    
 
     >>> f = make_Foo()
 >>> print f.x
@@ -3869,7 +3869,7 @@ Alternatively, you can import the definition of Foo from a separate fil
 as a method __deref__().  For example:
 
    
 
-
    
+
    
 
     f = Foo()               # Smart-pointer
 p = f.__deref__()       # Raw pointer from operator->
@@ -3941,7 +3941,7 @@ SWIG emulates the same functionality when creating wrappers.  For example, if
 you wrap this code in Python, the module works just like you would expect:
 
    
 
-
    
+
    
 
     >>> import example
 >>> f = example.FooBar()
@@ -4125,7 +4125,7 @@ void blah() {
 Now, consider the behavior when wrapped into a Python module:
 
    
 
-
    
+
    
 
     >>> bar(foo())         # Okay
 >>> 
@@ -4214,7 +4214,7 @@ Of course, always keep in mind that the real proxy class is written in the targe
 For example, in Python, the proxy might look roughly like this:
 
    
 
-
    
+
    
 
     class Foo:
     def __init__(self):
@@ -4274,7 +4274,7 @@ public:
 Now, consider some script code that uses these classes:
 
    
 
-
    
+
    
 
     f = Foo()               # Creates a new Foo
 s = Spam()              # Creates a new Spam
diff --git a/SWIG/Doc/Manual/Scripting.html b/SWIG/Doc/Manual/Scripting.html
index 9ff09da2d..2ba2c446d 100644
--- a/SWIG/Doc/Manual/Scripting.html
+++ b/SWIG/Doc/Manual/Scripting.html
@@ -181,7 +181,7 @@ double Foo = 3.5;
 
    
 It might be nice to access it from a script as follows (shown for Perl):
    
 
-
    +
     $a = $Foo * 2.3;   # Evaluation
 $Foo = $a + 2.0;   # Assignment
 
    
@@ -269,7 +269,7 @@ void Vector_z_set(Vector *v, double z);
 Now, from an interpreter these function might be used as follows:
 
    
 
-
    +
     % set v [new_Vector]
 % Vector_x_set $v 3.5
 % Vector_y_get $v
@@ -309,7 +309,7 @@ A proxy classing mechanism would allow you to access the structure in
 a more natural manner from the interpreter. For example, in Python, you might want to do this:
 
    
 
-
    +
     >>> v = Vector()
 >>> v.x = 3
 >>> v.y = 4
@@ -321,7 +321,7 @@ a more natural manner from the interpreter. For example, in Python, you might wa
 
    
 Similarly, in Perl5 you may want the interface to work like this:
    
 
-
    +
     $v = new Vector;
 $v->{x} = 3;
 $v->{y} = 4;
@@ -332,7 +332,7 @@ $v->{z} = -13;
 Finally, in Tcl :
 
    
 
-
    +
     Vector v
 v configure -x 3 -y 4 -z 13
 
@@ -366,7 +366,7 @@ To create a shared library or DLL, you often need to look at the
 manual pages for your compiler and linker.  However, the procedure
 for a few common machines is shown below:
    
 
-
    +
     # Build a shared library for Solaris
 gcc -c example.c example_wrap.c -I/usr/local/include
 ld -G example.o example_wrap.o -o example.so
@@ -387,7 +387,7 @@ in the scripting language (load, import, use, etc...). This will
 import your module and allow you to start using it. For example:
 
    
 
-
    +
     % load ./example.so
 % fact 4
 24
@@ -401,7 +401,7 @@ additional code in order to operate correctly. On many machines, you
 can build a shared C++ module by following the above procedures, but
 changing the link line to the following :
    
 
-
    +
     c++ -shared example.o example_wrap.o -o example.so
 
    
 
@@ -415,7 +415,7 @@ order for the extension to work, it needs to be able to find all of
 these libraries at run-time. Otherwise, you may get an error such as
 the following :
    
 
-
    +
     >>> import graph
 Traceback (innermost last):
   File "<stdin>", line 1, in ?
diff --git a/SWIG/Doc/Manual/Typemaps.html b/SWIG/Doc/Manual/Typemaps.html
index 825d6942c..ded241e5a 100644
--- a/SWIG/Doc/Manual/Typemaps.html
+++ b/SWIG/Doc/Manual/Typemaps.html
@@ -603,7 +603,7 @@ you can't use typemaps to interchange the arguments, allowing you to call the
 function like this:
 
    
 
-
    
+
    
 
     foo("hello",3)          # Reversed arguments
 
    
@@ -682,7 +682,7 @@ are sometimes to attach extra information to a typemap and is often target-langu
 this list is as follows:
 
    
 
-
    
+
    
 
     typelist    :  typepattern [, typepattern, typepattern, ... ] ;
 
@@ -703,7 +703,7 @@ variables (parms).   The purpose of these variables will be explained shortly.
 forms:
 
    
 
-
    
+
    
 
     code       : { ... }
            | " ... "
@@ -1035,7 +1035,7 @@ int foo(const char *s);
 To find a typemap for the argument const char *s, SWIG will search for the following typemaps:
 
    
 
-
    
+
    
 
     const char *s           Exact type and name match
 const char *            Exact type match
@@ -1105,7 +1105,7 @@ To find the typemap for Integer x, SWIG will first search for the follo
 typemaps:
 
    
 
-
    
+
    
 
     Integer x
 Integer
@@ -1117,7 +1117,7 @@ Finding no match, it then applies a reduction Integer -> int to the
 repeats the search.
 
    
 
-
    
+
    
 
     int x
 int      --> match: typemap 1
@@ -1505,7 +1505,7 @@ and you wanted to pass a native string in the target language as an argument.
 in Perl, you wanted the function to work like this:
 
    
 
-
    
+
    
 
     $x = foo("Hello World");
 
    
@@ -1770,7 +1770,7 @@ on the left-hand side of a C assignment operation.   Here are a few examples of
 and ltypes:
 
    
 
-
    
+
    
 
     type              ltype
 ------            ----------------
@@ -2080,7 +2080,7 @@ with an "in" typemap---possibly to ignore the input value.  For example:
 The following special variables are available.
 
    
 
-
    
+
    
 
     $result           - Result object returned to target language.
 $input            - The original input object passed.
@@ -2307,7 +2307,7 @@ C stack.  The typemap then populates this array and passes it to the underlying
 When used from Python, the typemap allows the following type of function call:
 
    
 
-
    
+
    
 
     >>> set_vector(type, [ 1, 2.5, 5, 20 ])
 
    
@@ -2414,7 +2414,7 @@ When SWIG runs, it won't produce any code to set the vec member.
 You may even get a warning message like this:
 
    
 
-
    +
     swig -python  example.i
 Generating wrappers for Python
 example.i:10.  Warning. Array member value will be read-only.
@@ -2449,7 +2449,7 @@ When combined with the earlier typemaps for arrays, the combination of the "in"
 the following usage:
 
    
 
-
    
+
    
 
     >>> s = SomeObject()
 >>> s.x = [1, 2.5, 5, 10]
@@ -2462,7 +2462,7 @@ object.  For example, in this example, you will get very odd program behavior wh
 can be set nicely, but reading the member simply returns a pointer:
 
    
 
-
    
+
    
 
     >>> s = SomeObject()
 >>> s.x = [1, 2.5, 5. 10]
@@ -2493,7 +2493,7 @@ To fix this, you can write an "out" typemap.   For example:
 Now, you will find that member access is quite nice:
 
    
 
-
    
+
    
 
     >>> s = SomeObject()
 >>> s.x = [1, 2.5, 5, 10]
@@ -2581,7 +2581,7 @@ Suppose that you wanted to wrap this function so that it accepted a single
 list of strings like this:
 
    
 
-
    
+
    
 
     >>> foo(["ale","lager","stout"])
 
    
@@ -2766,7 +2766,7 @@ scripting language object being returned to the interpreter.).
 Now, in a script, you can write code that simply passes buffers as strings like this:
 
    
 
-
    
+
    
 
     >>> f = example.open("Makefile")
 >>> example.read(f,40)
@@ -2865,7 +2865,7 @@ into typed pointer objects.  For example, an instance of Foo * might be
 a string encoded like this:
 
    
 
-
    
+
    
 
     _108e688_p_Foo
 
    
@@ -2901,7 +2901,7 @@ When the class FooBar is organized in memory, it contains the contents
 of the classes Foo and Bar as well as its own data members.  For example:
 
    
 
-
    
+
    
 
     FooBar --> | -----------|  <-- Foo
            |   int x    |
@@ -3186,7 +3186,7 @@ int foo(char *s, int y);
 You can access the functions in a normal way from the scripting interpreter:
 
    
 
-
    
+
    
 
     # Python
 foo(3)           # foo(int)
@@ -3282,7 +3282,7 @@ is the mechanism by which it is implemented---as a collection of typemaps.
 To support dynamic dispatch, SWIG first defines a general purpose type hierarchy as follows:
 
    
 
-
    
+
    
 
     Symbolic Name                   Precedence Value
 ------------------------------  ------------------
diff --git a/SWIG/Doc/Manual/Varargs.html b/SWIG/Doc/Manual/Varargs.html
index 132f23047..f3ea17600 100644
--- a/SWIG/Doc/Manual/Varargs.html
+++ b/SWIG/Doc/Manual/Varargs.html
@@ -274,7 +274,7 @@ this actually provides enough support for many simple kinds of varargs functions
 instance, you could make function calls like this (in Python):
 
    
 
-
    
+
    
 
     >>> traceprintf("Hello World")
 >>> traceprintf("Hello %s. Your number is %d\n" % (name, num))
@@ -722,7 +722,7 @@ int printf(const char *fmt, ...);
 Much to your amazement, it even seems to work if you try it:
 
    
 
-
    
+
    
 
     >>> import example
 >>> example.printf("Grade: %s   %d/60 = %0.2f%%\n", "Dave", 47, 47.0*100/60)
@@ -735,7 +735,7 @@ Grade: Dave   47/60 = 78.33%
 Of course, there are still some limitations to consider:
 
    
 
-
    
+
    
 
     >>> example.printf("la de da de da %s", 42)
 Segmentation fault (core dumped)
diff --git a/SWIG/Doc/Manual/Warnings.html b/SWIG/Doc/Manual/Warnings.html
index 02121ab5c..aa6e13dd3 100644
--- a/SWIG/Doc/Manual/Warnings.html
+++ b/SWIG/Doc/Manual/Warnings.html
@@ -41,7 +41,7 @@
 During compilation, SWIG may generate a variety of warning messages.  For example:
 
    
 
-
    
+
    
 
     example.i:16: Warning(501): Overloaded declaration ignored.  bar(double)
 example.i:15: Warning(501): Previous declaration is bar(int)
@@ -63,7 +63,7 @@ To suppress the printing of a warning message, a number of techniques can be use
 First, you can run SWIG with the -w command line option. For example:
 
    
 
-
    
+
    
 
     % swig -python -w501 example.i
 % swig -python -w501,505,401 example.i
@@ -153,7 +153,7 @@ to provide additional diagnostics.  All warning messages can be
 enabled using the -Wall option. For example:
 
    
 
-
    
+
    
 
     % swig -Wall -python example.i
 
    
@@ -168,7 +168,7 @@ To selectively turn on extra warning messages, you can use the directives and op
 previous section--simply add a "+" to all warning numbers.  For example:
 
    
 
-
    
+
    
 
     % swig -w+309,+452 example.i
 
    
@@ -285,7 +285,7 @@ default except on Windows where the Microsoft format is used by default.
 These can be overridden using command line options, for example:
 
    
 
-
    +
     $ swig -python -Fstandard example.i
 example.i:4: Syntax error in input.
 $ swig -python -Fmicrosoft example.i