jyapayne/swig
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Reorginize the repo a bit from what cvs2svn imported

Browse source 
git-svn-id: https://swig.svn.sourceforge.net/svnroot/swig/trunk@9589 626c5289-ae23-0410-ae9c-e8d60b6d4f22
This commit is contained in:
John Lenz 2006-12-03 08:24:43 +00:00
commit d7d0095740
200 changed files with 0 additions and 74589 deletions
Download patch file Download diff file Expand all files Collapse all files

51
swigweb/Doc1.1/HTML/About.html
View file

@ -1,51 +0,0 @@
<html>
<head>
<title>About this manual</title>
</head>
<body bgcolor="#ffffff">
<h1>About This Manual</h1><p>
The HTML version of the SWIG Users Manual is a direct translation
of the printed version which is produced using Framemaker 5. The
conversion process was roughly as follows :
<ul>
<li> Raw HTML was produced using Framemaker 5 and Quadralay WebWorks Lite.
<li> Tables and figures were converted into GIF images.
<li> All of this output was fed into a magic Python script that cleaned
up the HTML source and merged the GIF figures into the text.
<li> A table of contents and alphabetized topic index were produced from
HTML heading tags by the same script.
</ul>
While the conversion process is mostly complete, there are a few things
to keep in mind :
<ul>
<li> Some sections of preformatted text may have weird formatting
problems.
<li> Framemaker tables were converted into GIF images instead
of HTML tables--this is a little weird, but the easiest
approach for now.
<li> There may be a few minor formatting problems throughout
due to minor "glitches" that slipped through the conversion process
(although I've tried to correct as many as these as possible).
<li> The printed version of the SWIG manual is more than
300 pages long--resulting in about 670 Kbytes of HTML. The HTML version
is broken up into chapters. Each chapter is fairly well-contained, but
some may contain as many as 50 pages of printed text.
</ul>
Please report any problems with the documentation to beazley@cs.utah.edu.
<hr>
<address>
Last Modified : August 3, 1997</address>
</body>
</html>

305
swigweb/Doc1.1/HTML/Advanced.html
View file

@ -1,305 +0,0 @@
<!-- Published by Quadralay WebWorks HTML Lite 1.5.1 -->
<!-- And munged by Dave's special Python script -->
<html>
<head>
<title>Advanced Topics</title>
</head>
<body bgcolor="#ffffff">
<a name="n0"></a><h1>11 Advanced Topics</h1><p><ul>
<li> <a href="#n1">Creating multi-module packages</a>
<li> <a href="#n2">Dynamic Loading of C++ modules</a>
<li> <a href="#n3">Inside the SWIG type-checker</a>
</ul>
<a name="n1"></a><h2> Creating multi-module packages</h2>
SWIG can be used to create packages consisting of many different modules. However, there are some technical aspects of doing this and techniques for managing the problem.<p>
<a name="n4"></a><h3> Runtime support (and potential problems)</h3>
All SWIG generated modules rely upon a small collection of functions that are used during run-time. These functions are primarily used for pointer type-checking, exception handling, and so on. When you run SWIG, these functions are included in the wrapper file (and declared as static). If you create a system consisting of many modules, each one will have an identical copy of these runtime libraries :<p>
<center><img src="ch11.1.png"></center><p>
<p>
This duplication of runtime libraries is usually harmless since there are no namespace conflicts and memory overhead is minimal. However, there is serious problem related to the fact that modules do not share type-information. This is particularly a problem when working with C++ (as described next).<p>
<a name="n5"></a><h3> Why doesn't C++ inheritance work between modules?</h3>
Consider for a moment the following two interface files :<p>
<p>
<blockquote><pre>// File : a.i
%module a
// Here is a base class
class a {
public:
a();
~a();
void foo(double);
};
// File : b.i
%module b
// Here is a derived class
%extern a.i // Gets definition of base class
class b : public a {
public:
bar();
};
</pre></blockquote>
When compiled into two separate modules, the code does not work properly. In fact, you get a type error such as the following :<p>
<p>
<blockquote><pre>[beazley@guinness shadow]$ python
Python 1.4 (Jan 16 1997) [GCC 2.7.2]
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
&gt;&gt;&gt; from a import *
&gt;&gt;&gt; from b import *
&gt;&gt;&gt; # Create a new "b"
&gt;&gt;&gt; b = new_b()
&gt;&gt;&gt; # Call a function in the base class
...
&gt;&gt;&gt; a_foo(b,3)
Traceback (innermost last):
File "&lt;stdin&gt;", line 1, in ?
TypeError: Type error in argument 1 of a_foo. Expected _a_p.
&gt;&gt;&gt;
</pre></blockquote>
<p>
However, from our class definitions we know that "b" is an "a" by inheritance and there should be no type-error. This problem is directly due to the lack of type-sharing between modules. If we look closely at the module modules created here, they look like this :<p>
<center><img src="ch11.2.png"></center><p>
<p>
The type information listed shows the acceptable values for various C datatypes. In the "a" module, we see that "a" can only accept instances of itself. In the "b" module, we see that "a" can accept both "a" and "b" instances--which is correct given that a "b" is an "a" by inheritance.<p>
<p>
Unfortunately, this problem is inherent in the method by which SWIG makes modules. When we made the "a" module, we had no idea what derived classes might be used at a later time. However, it's impossible to produce the proper type information until after we know all of the derived classes. A nice problem to be sure, but one that can be fixed by making all modules share a single copy of the SWIG run-time library.<p>
<a name="n6"></a><h3> The SWIG runtime library</h3>
To reduce overhead and to fix type-handling problems, it is possible to share the SWIG run-time functions between multiple modules. This requires the use of the SWIG runtime library which is optionally built during SWIG installation. To use the runtime libraries, follow these steps :<p>
<p>
1. Build the SWIG run-time libraries. The <tt>SWIG1.1/Runtime</tt> directory contains a makefile for doing this. If successfully built, you will end up with 6 files that are usually installed in <tt>/usr/local/lib</tt>.<p>
<p>
<blockquote><pre>libswigtcl.a # Tcl library (static)
libswigtcl.so # Tcl library (shared)
libswigpl.a # Perl library (static)
libswigpl.so # Perl library (shared)
libswigpy.a # Python library (static)
libswigpy.so # Python library (shared)
</pre></blockquote>
<p>
Note that certain libraries may be missing due to missing packages or unsupported features (like dynamic loading) on your machine.<p>
<p>
2. Compile all SWIG modules using the <tt>-c</tt> option. For example :<p>
<p>
<blockquote><pre>% swig -c -python a.i
% swig -c -python b.i
</pre></blockquote>
The <tt>-c</tt> option tells SWIG to omit runtime support. It's now up to you to provide it separately--which we will do using our libraries.<p>
<p>
3. Build SWIG modules by linking against the appropriate runtime libraries.<p>
<p>
<blockquote><pre>% swig -c -python a.i
% swig -c -python b.i
% gcc -c a_wrap.c b_wrap.c -I/usr/local/include
% ld -shared a_wrap.o b_wrap.o -lswigpy -o a.so
</pre></blockquote>
or if building a new executable (static linking)<p>
<p>
<blockquote><pre>% swig -c -tcl -ltclsh.i a.i
% gcc a_wrap.c -I/usr/local/include -L/usr/local/lib -ltcl -lswigtcl -lm -o mytclsh
</pre></blockquote>
<p>
When completed you should now end up with a collection of modules like this :<p>
<center><img src="ch11.3.png"></center><p>
<p>
<p>
In this configuration, the runtime library manages all datatypes and other information between modules. This management process is dynamic in nature--when new modules are loaded, they contribute information to the run-time system. In the C++ world, one could incrementally load classes as needed. As this process occurs, type information is updated and base-classes learn about derived classes as needed.<p>
<a name="n7"></a><h3> A few dynamic loading gotchas</h3>
When working with dynamic loading, it is critical to check that only one copy of the run-time library is being loaded into the system. When working with <tt>.a</tt> library files, problems can sometimes occur so there are a few approaches to the problem.<p>
<p>
1. Rebuild the scripting language executable with the SWIG runtime library attached to it. This is actually, fairly easy to do using SWIG. For example :<p>
<p>
<blockquote><pre>%module mytclsh
%{
static void *__embedfunc(void *a) { return a};
%}
void *__embedfunc(void *);
%include tclsh.i
</pre></blockquote>
<p>
Now, run SWIG and compile as follows :<p>
<p>
<blockquote><pre>% swig -c -tcl mytclsh.i
% gcc mytclsh_wrap.c -I/usr/local/include -L/usr/local/lib -ltcl -lswigtcl -ldl -lm \
-o tclsh
</pre></blockquote>
This produces a new executable "<tt>tclsh</tt>" that contains a copy of the SWIG runtime library. The weird <tt>__embedfunc()</tt> function is needed to force the functions in the runtime library to be included in the final executable. <p>
<p>
To make new dynamically loadable SWIG modules, simply compile as follows :<p>
<p>
<blockquote><pre>% swig -c -tcl example.i
% gcc -c example_wrap.c -I/usr/local/include
% ld -shared example_wrap.o -o example.so
</pre></blockquote>
Linking against the <tt>swigtcl</tt> library is no longer necessary as all of the functions are now included in the <tt>tclsh</tt> executable and will be resolved when your module is loaded.<p>
<p>
2. Using shared library versions of the runtime library<p>
<p>
If supported on your machine, the runtime libraries will be built as shared libraries (indicated by a <tt>.so</tt>, <tt>.sl</tt>, or .<tt>dll</tt> suffix). To compile using the runtime libraries, you link process should look something like this :<p>
<blockquote><pre>
% ld -shared swigtcl_wrap.o -o libswigtcl.so # Irix
% gcc -shared swigtcl_wrap.o -o libswigtcl.so # Linux
% ld -G swigtcl_wrap.o -o libswigtcl.so # Solaris
</pre></blockquote>
In order for the <tt>libswigtcl.so</tt> library to work, it needs to be placed in a location where the dynamic loader can find it. Typically this is a system library directory (ie. <tt>/usr/local/lib</tt> or <tt>/usr/lib</tt>). <p>
<p>
When running with the shared libary version, you may get error messages such as the following <p>
<p>
<blockquote><pre>Unable to locate libswigtcl.so
</pre></blockquote>
This indicates that the loader was unable to find the shared libary at run-time. To find shared libaries, the loader looks through a collection of predetermined paths. If the <tt>libswigtcl.so</tt> file is not in any of these directories, it results in an error. On most machines, you can change the loader search path by changing the Unix environment variable <tt>LD_LIBRARY_PATH</tt>. For example :<p>
<p>
<blockquote><pre>% setenv LD_LIBRARY_PATH .:/home/beazley/packages/lib
</pre></blockquote>
A somewhat better approach is to link your module with the proper path encoded. This is typically done using the `-rpath' or `-R' option to your linker (see the man page). For example :<p>
<p>
<blockquote><pre>% ld -shared example_wrap.o example.o -rpath /home/beazley/packages/lib \
-L/home/beazley/packages/lib -lswigtcl.so -o example.so
</pre></blockquote>
The <tt>-rpath</tt> option encodes the location of shared libraries into your modules and gets around having to set the <tt>LD_LIBRARY_PATH</tt> variable. <p>
<p>
If all else fails, pull up the man pages for your linker and start playing around. <p>
<a name="n2"></a><h2> Dynamic Loading of C++ modules</h2>
Dynamic loading of C++ modules presents a special problem for many systems. This is because C++ modules often need additional supporting code for proper initialization and operation. Static constructors are also a bit of a problem.<p>
<p>
While the process of building C++ modules is, by no means, and exact science, here are a few rules of thumb to follow :<p>
<p>
<ul>
<li>Don't use static constructors if at all possible (not always avoidable).
<li>Try linking your module with the C++ compiler using a command like `c++ -shared'. This often solves alot of problems.
<li>Sometimes it is necessary to link against special libraries. For example, modules compiled with g++ often need to be linked against the <tt>libgcc.a</tt>, <tt>libg++.a</tt>, and <tt>libstdc++.a</tt> libraries.
<li>Read the compiler and linker man pages over and over until you have them memorized (this may not help in some cases however).
<li>Search articles on Usenet, particularly in <tt>comp.lang.tcl</tt>, <tt>comp.lang.perl</tt>, and <tt>comp.lang.python</tt>. Building C++ modules is a common problem.
</ul>
<p>
The SWIG distribution contains some additional documentation about C++ modules in the Doc directory as well.<p>
<a name="n3"></a><h2> Inside the SWIG type-checker</h2>
The SWIG runtime type-checker plays a critical role in the correct operation of SWIG modules. It not only checks the validity of pointer types, but also manages C++ inheritance, and performs proper type-casting of pointers when necessary. This section provides some insight into what it does, how it works, and why it is the way it is.<p>
<a name="n8"></a><h3> Type equivalence</h3>
SWIG uses a name-based approach to managing pointer datatypes. For example, if you are using a pointer like "<tt>double *</tt>", the type-checker will look for a particular string representation of that datatype such as "<tt>_double_p</tt>". If no match is found, a type-error is reported.<p>
<p>
However, the matching process is complicated by the fact that datatypes may use a variety of different names. For example, the following declarations<p>
<p>
<blockquote><pre>typedef double Real;
typedef Real * RealPtr;
typedef double Float;
</pre></blockquote>
define two sets of equivalent types :<p>
<p>
<blockquote><pre>{double, Real, Float}
{RealPtr, Real *}
</pre></blockquote>
All of the types in each set are freely interchangable and the type-checker knows about the relationships by managing a table of equivalences such as the following :<p>
<blockquote><pre>
double =&gt; { Real, Float }
Real =&gt; { double, Float }
Float =&gt; { double, Real }
RealPtr =&gt; { Real * }
Real * =&gt; { RealPtr }
</pre></blockquote>
<p>
When you declare a function such as the following :<p>
<p>
<blockquote><pre>void foo(Real *a);
</pre></blockquote>
SWIG first checks to see if the argument passed is a "<tt>Real *</tt>". If not, it checks to see if it is any of the other equivalent types (<tt>double *</tt>, <tt>RealPtr</tt>, <tt>Float *</tt>). If so, the value is accepted and no error occurs.<p>
<p>
Derived versions of the various datatypes are also legal. For example, if you had a function like this,<p>
<p>
<blockquote><pre>void bar(Float ***a);
</pre></blockquote>
The type-checker will accept pointers of type <tt>double ***</tt> and <tt>Real ***.</tt> However, the type-checker does not always capture the full-range of possibilities. For example, a datatype of `<tt>RealPtr **</tt>' is equivalent to a `<tt>Float ***</tt>' but would be flagged as a type error. If you encounter this kind of problem, you can manually force SWIG to make an equivalence as follows:<p>
<p>
<blockquote><pre>// Tell the type checker that `Float_ppp' and `RealPtr_pp' are equivalent.
%init %{
SWIG_RegisterMapping("Float_ppp","RealPtr_pp",0);
%}
</pre></blockquote>
Doing this should hardly ever be necessary (I have never encountered a case where this was necessary), but if all else fails, you can force the run-time type checker into doing what you want.<p>
<p>
Type-equivalence of C++ classes is handled in a similar manner, but is encoded in a manner to support inheritance. For example, consider the following classes hierarchy :<p>
<p>
<blockquote><pre>class A { };
class B : public A { };
class C : public B { };
class D {};
class E : public C, public D {};
</pre></blockquote>
The type-checker encodes this into the following sets :<p>
<p>
<blockquote><pre>A =&gt; { B, C, E } "B isa A, C isa A, E isa A"
B =&gt; { C, E } "C isa B, E isa B"
C =&gt; { E } "E isa C"
D =&gt; { E } "E isa D"
E =&gt; { }
</pre></blockquote>
The encoding reflects the class hierarchy. For example, any object of type "A" will also accept objects of type B,C, and E because these are all derived from A. However, it is not legal to go the other way. For example, a function operating on a object from class E will not accept an object from class A.<p>
<a name="n9"></a><h3> Type casting</h3>
When working with C++ classes, SWIG needs to perform proper typecasting between derived and base classes. This is particularly important when working with multiple inheritance. To do this, conversion functions are created such as the following :<p>
<p>
<blockquote><pre>void *EtoA(void *ptr) {
E *in = (E *) ptr;
A *out = (A *) in; // Cast using C++
return (void *) out;
}
</pre></blockquote>
All pointers are internally represented as void *, but conversion functions are always invoked when pointer values are converted between base and derived classes in a C++ class hierarchy.<p>
<a name="n10"></a><h3> Why a name based approach?</h3>
SWIG uses a name-based approach to type-checking for a number of reasons :<p>
<p>
<ul>
<li>One of SWIG's main uses is code development and debugging. In this environment, the type name of an object turns out to be a useful piece of information in tracking down problems.
<li>In languages like Perl, the name of a datatype is used to determine things like packages and classes. By using datatype names we get a natural mapping between C and Perl.
<li>I believe using the original names of datatypes is more intuitive than munging them into something completely different.
</ul>
<p>
An alternative to a name based scheme would be to generate type-signatures based on the structure of a datatype. Such a scheme would result in perfect type-checking, but I think it would also result in a very confusing scripting language module. For this reason, I see SWIG sticking with the name-based approach--at least for the foreseeable future. <p>
<a name="n11"></a><h3> Performance of the type-checker</h3>
The type-checker performs the following steps when matching a datatype :<p>
<p>
<dl>
<dt>1. Check a pointer against the type supplied in the original C declaration. If there is a perfect match, we're done.
<dt>2. Check the supplied pointer against a cache of recently used datatypes.
<dt>3. Search for a match against the full list of equivalent datatypes.
<dt>4. If not found, report an error.
</dl>
<p>
Most well-structured C codes will find an exact match on the first attempt, providing the best possible performance. For C++ codes, it is quite common to be passing various objects of a common base-class around between functions. When base-class functions are invoked, it almost always results in a miscompare (because the type-checker is looking for the base-type). In this case, we drop down to a small cache of recently used datatypes. If we've used a pointer of the same type recently, it will be in the cache and we can match against it. For tight loops, this results in about 10-15% overhead over finding a match on the first try. Finally, as a last resort, we need to search the internal pointer tables for a match. This involves a combination of hash table lookup and linear search. If a match is found, it is placed into the cache and the result returned. If not, we finally report a type-mismatch.<p>
<p>
As a rule of thumb, C++ programs require somewhat more processing than C programs, but this seems to be avoidable. Also, keep in mind that performance penalties in the type-checker don't necessarily translate into big penalties in the overall application. Performance is most greatly affected by the efficiency of the target scripting language and the types of operations your C code is performing.<p>
<p>
<p>
<p><hr>
<address>SWIG 1.1 - Last Modified : Mon Aug 4 10:47:13 1997</address>
</body>
</html>

184
swigweb/Doc1.1/HTML/Contents.html
View file

@ -1,184 +0,0 @@
<html>
<head>
<title> SWIG 1.1 Users Manual - Table of Contents </title>
</head>
<body bgcolor="#ffffff">
<h1> SWIG 1.1 Users Manual </h1>
<ul>
<li> <a href="Copyright.html">Copyright</a>
<li> <a href="About.html">About this manual</a>
<li> <a href="Index.html">Alphabetical Topic Index</a>
</ul>
<h2><a href="Preface.html">Preface</a></h2><p><ul>
<li> <a href="Preface.html#n1">Introduction</a>
<li> <a href="Preface.html#n2">SWIG resources</a>
<li> <a href="Preface.html#n3">About this manual</a>
<li> <a href="Preface.html#n4">Credits</a>
<li> <a href="Preface.html#n5">What's new?</a>
<li> <a href="Preface.html#n6">Bug reports</a>
<li> <a href="Preface.html#n7">SWIG is free</a>
</ul>
<h2><a href="Introduction.html">1 Introduction</a></h2><p><ul>
<li> <a href="Introduction.html#n1">What is SWIG?</a>
<li> <a href="Introduction.html#n2">Life before SWIG</a>
<li> <a href="Introduction.html#n3">Life after SWIG</a>
<li> <a href="Introduction.html#n4">The SWIG package</a>
<li> <a href="Introduction.html#n5">A SWIG example</a>
<li> <a href="Introduction.html#n6">C syntax, but not a C compiler</a>
<li> <a href="Introduction.html#n7">Non-intrusive interface building</a>
<li> <a href="Introduction.html#n8">Hands off code generation</a>
<li> <a href="Introduction.html#n9">Event driven C programming</a>
<li> <a href="Introduction.html#n10">Automatic documentation generation</a>
<li> <a href="Introduction.html#n11">Summary</a>
<li> <a href="Introduction.html#n12">SWIG for Windows and Macintosh</a>
</ul>
<h2><a href="Scripting.html">2 Scripting Languages</a></h2><p><ul>
<li> <a href="Scripting.html#n1">The two language view of the world</a>
<li> <a href="Scripting.html#n2">How does a scripting language talk to C?</a>
<li> <a href="Scripting.html#n3">Building scripting language extensions</a>
<li> <a href="Scripting.html#n4">Shared libraries and dynamic loading</a>
</ul>
<h2><a href="SWIG.html">3 SWIG Basics</a></h2><p><ul>
<li> <a href="SWIG.html#n1">Running SWIG</a>
<li> <a href="SWIG.html#n2">Simple C functions, variables, and constants</a>
<li> <a href="SWIG.html#n3">Pointers and complex objects</a>
<li> <a href="SWIG.html#n4">Getting down to business</a>
<li> <a href="SWIG.html#n5">Structures, unions, and object oriented C programming</a>
<li> <a href="SWIG.html#n6">C++ support</a>
<li> <a href="SWIG.html#n7">Objective-C</a>
<li> <a href="SWIG.html#n8">Conditional compilation</a>
<li> <a href="SWIG.html#n9">Code Insertion</a>
<li> <a href="SWIG.html#n10">A general interface building strategy</a>
</ul>
<h2><a href="Library.html">4 Multiple files and the SWIG library</a></h2><p><ul>
<li> <a href="Library.html#n1">The %include directive</a>
<li> <a href="Library.html#n2">The %extern directive</a>
<li> <a href="Library.html#n3">The %import directive</a>
<li> <a href="Library.html#n4">Including files on the command line</a>
<li> <a href="Library.html#n5">The SWIG library</a>
<li> <a href="Library.html#n6">Library example</a>
<li> <a href="Library.html#n7">Creating Library Files</a>
<li> <a href="Library.html#n8">Working with library files</a>
<li> <a href="Library.html#n9">Static initialization of multiple modules</a>
<li> <a href="Library.html#n10">More about the SWIG library</a>
</ul>
<h2><a href="Documentation.html">5 Documentation System</a></h2><p><ul>
<li> <a href="Documentation.html#n1">Introduction</a>
<li> <a href="Documentation.html#n2">How it works</a>
<li> <a href="Documentation.html#n3">Choosing a documentation format</a>
<li> <a href="Documentation.html#n4">Function usage and argument names</a>
<li> <a href="Documentation.html#n5">Titles, sections, and subsections</a>
<li> <a href="Documentation.html#n6">Formatting</a>
<li> <a href="Documentation.html#n7">Adding Additional Text</a>
<li> <a href="Documentation.html#n8">Disabling all documentation</a>
<li> <a href="Documentation.html#n9">An Example</a>
<li> <a href="Documentation.html#n10">ASCII Documentation</a>
<li> <a href="Documentation.html#n11">HTML Documentation</a>
<li> <a href="Documentation.html#n12">LaTeX Documentation</a>
<li> <a href="Documentation.html#n13">C++ Support</a>
<li> <a href="Documentation.html#n14">The Final Word?</a>
</ul>
<h2><a href="Typemaps.html">6 Pointers, Constraints, and Typemaps</a></h2><p><ul>
<li> <a href="Typemaps.html#n1">Introduction</a>
<li> <a href="Typemaps.html#n2">The SWIG Pointer Library</a>
<li> <a href="Typemaps.html#n3">Introduction to typemaps</a>
<li> <a href="Typemaps.html#n4">Managing input and output parameters</a>
<li> <a href="Typemaps.html#n5">Applying constraints to input values</a>
<li> <a href="Typemaps.html#n6">Writing new typemaps</a>
<li> <a href="Typemaps.html#n7">Common typemap methods</a>
<li> <a href="Typemaps.html#n8">Writing typemap code</a>
<li> <a href="Typemaps.html#n9">Typemaps for handling arrays</a>
<li> <a href="Typemaps.html#n10">Typemaps and the SWIG Library</a>
<li> <a href="Typemaps.html#n11">Implementing constraints with typemaps</a>
<li> <a href="Typemaps.html#n12">Typemap examples</a>
<li> <a href="Typemaps.html#n13">How to break everything with a typemap</a>
<li> <a href="Typemaps.html#n14">Typemaps and the future</a>
</ul>
<h2><a href="Exceptions.html">7 Exception Handling</a></h2><p><ul>
<li> <a href="Exceptions.html#n1">The %except directive</a>
<li> <a href="Exceptions.html#n2">Handling exceptions in C code</a>
<li> <a href="Exceptions.html#n3">Exception handling with longjmp()</a>
<li> <a href="Exceptions.html#n4">Handling C++ exceptions</a>
<li> <a href="Exceptions.html#n5">Defining different exception handlers</a>
<li> <a href="Exceptions.html#n6">Using The SWIG exception library</a>
<li> <a href="Exceptions.html#n7">Debugging and other interesting uses for %except</a>
<li> <a href="Exceptions.html#n8">More Examples</a>
</ul>
<h2><a href="Perl5.html">8 SWIG and Perl5</a></h2><p><ul>
<li> <a href="Perl5.html#n1">Preliminaries</a>
<li> <a href="Perl5.html#n2">Building Perl Extensions under Windows 95/NT</a>
<li> <a href="Perl5.html#n3">Modules, packages, and classes</a>
<li> <a href="Perl5.html#n4">Basic Perl interface</a>
<li> <a href="Perl5.html#n5">A simple Perl example</a>
<li> <a href="Perl5.html#n6">Accessing arrays and other strange objects</a>
<li> <a href="Perl5.html#n7">Implementing methods in Perl</a>
<li> <a href="Perl5.html#n8">Shadow classes</a>
<li> <a href="Perl5.html#n9">Getting serious</a>
<li> <a href="Perl5.html#n10">Wrapping C libraries and other packages</a>
<li> <a href="Perl5.html#n11">Building a Perl5 interface to MATLAB</a>
<li> <a href="Perl5.html#n12">Handling output values (the easy way)</a>
<li> <a href="Perl5.html#n13">Exception handling</a>
<li> <a href="Perl5.html#n14">Remapping datatypes with typemaps</a>
<li> <a href="Perl5.html#n15">The gory details on shadow classes</a>
<li> <a href="Perl5.html#n16">Where to go from here?</a>
</ul>
<h2><a href="Python.html">9 SWIG and Python</a></h2><p><ul>
<li> <a href="Python.html#n1">Preliminaries</a>
<li> <a href="Python.html#n2">Building Python Extensions under Windows 95/NT</a>
<li> <a href="Python.html#n3">The low-level Python/C interface</a>
<li> <a href="Python.html#n4">Python shadow classes</a>
<li> <a href="Python.html#n5">About the Examples</a>
<li> <a href="Python.html#n6">Solving a simple heat-equation</a>
<li> <a href="Python.html#n7">Wrapping a C library</a>
<li> <a href="Python.html#n8">Putting it all together</a>
<li> <a href="Python.html#n9">Exception handling</a>
<li> <a href="Python.html#n10">Remapping C datatypes with typemaps</a>
<li> <a href="Python.html#n11">Implementing C callback functions in Python</a>
<li> <a href="Python.html#n12">Other odds and ends</a>
<li> <a href="Python.html#n13">The gory details of shadow classes</a>
</ul>
<h2><a href="Tcl.html">10 SWIG and Tcl</a></h2><p><ul>
<li> <a href="Tcl.html#n1">Preliminaries</a>
<li> <a href="Tcl.html#n2">Building Tcl/Tk Extensions under Windows 95/NT</a>
<li> <a href="Tcl.html#n3">Basic Tcl Interface</a>
<li> <a href="Tcl.html#n4">The object oriented interface</a>
<li> <a href="Tcl.html#n5">About the examples</a>
<li> <a href="Tcl.html#n6">Binary trees in Tcl</a>
<li> <a href="Tcl.html#n7">Building C/C++ data structures with Tk</a>
<li> <a href="Tcl.html#n8">Accessing arrays</a>
<li> <a href="Tcl.html#n9">Building a simple OpenGL module</a>
<li> <a href="Tcl.html#n10">Exception handling</a>
<li> <a href="Tcl.html#n11">Typemaps</a>
<li> <a href="Tcl.html#n12">Configuration management with SWIG</a>
<li> <a href="Tcl.html#n13">Building new kinds of Tcl interfaces (in Tcl)</a>
<li> <a href="Tcl.html#n14">Extending the Tcl Netscape Plugin</a>
<li> <a href="Tcl.html#n15">Tcl8.0 features</a>
</ul>
<h2><a href="Advanced.html">11 Advanced Topics</a></h2><p><ul>
<li> <a href="Advanced.html#n1">Creating multi-module packages</a>
<li> <a href="Advanced.html#n2">Dynamic Loading of C++ modules</a>
<li> <a href="Advanced.html#n3">Inside the SWIG type-checker</a>
</ul>
<h2><a href="Extending.html">12 Extending SWIG</a></h2><p><ul>
<li> <a href="Extending.html#n1">Introduction</a>
<li> <a href="Extending.html#n2">Compiling a SWIG extension</a>
<li> <a href="Extending.html#n3">SWIG output</a>
<li> <a href="Extending.html#n4">The Language class (simple version)</a>
<li> <a href="Extending.html#n5">A tour of SWIG datatypes</a>
<li> <a href="Extending.html#n6">Typemaps (from C)</a>
<li> <a href="Extending.html#n7">File management</a>
<li> <a href="Extending.html#n8">Naming Services</a>
<li> <a href="Extending.html#n9">Code Generation Functions</a>
<li> <a href="Extending.html#n10">Writing a Real Language Module</a>
<li> <a href="Extending.html#n11">C++ Processing</a>
<li> <a href="Extending.html#n12">Documentation Processing</a>
<li> <a href="Extending.html#n13">The Future of SWIG</a>
</ul>
<p><hr>
<address>SWIG 1.1 - Last Modified : Mon Aug 4 10:47:18 1997 </address>
</body>
</html>

70
swigweb/Doc1.1/HTML/Copyright.html
View file

@ -1,70 +0,0 @@
<HTML>
<HEAD>
<title> SWIG Documentation Copyright</title>
</head>
<body BGCOLOR="#FFFFFF">
<h2> SWIG Users Manual </h2>
<b>
Version 1.1<br>
June, 1997 <br>
</b>
<p>
Copyright(C) 1996, 1997<br>
All Rights Reserved<br>
<br>
David M. Beazley<br>
Department of Computer Science <br>
University of Utah <br>
Salt Lake City, Utah 84112 </br>
<tt>beazley@cs.utah.edu</tt>
<p>
This document may be freely distributed in whole or part provided this
copyright notice is retained. Commercial distribution of this document
is prohibited without the express written consent of the author.
<hr>
SWIG 1.1 is Copyright (C) 1995-1997 by the University of Utah and the
Univerity of California and distributed under the following license.
<p>
This software is copyrighted by the University of Utah and the Regents
of the University of California. The following terms apply to all
files associated with the software unless explicitly disclaimed
in individual files.
<p>
Permission is hereby granted, without written agreement and without
license or royalty fees, to use, copy, modify, and distribute this
software and its documentation for any purpose, provided that
(1) The above copyright notice and the following two paragraphs
appear in all copies of the source code and (2) redistributions
including binaries reproduces these notices in the supporting
documentation. Substantial modifications to this software may be
copyrighted by their authors and need not follow the licensing terms
described here, provided that the new terms are clearly indicated in
all files where they apply.
<p>
IN NO EVENT SHALL THE AUTHOR, THE UNIVERSITY OF CALIFORNIA, THE
UNIVERSITY OF UTAH OR DISTRIBUTORS OF THIS SOFTWARE BE LIABLE TO ANY
PARTY FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL
DAMAGES ARISING OUT OF THE USE OF THIS SOFTWARE AND ITS DOCUMENTATION,
EVEN IF THE AUTHORS OR ANY OF THE ABOVE PARTIES HAVE BEEN ADVISED OF
THE POSSIBILITY OF SUCH DAMAGE.
<p>
THE AUTHOR, THE UNIVERSITY OF CALIFORNIA, AND THE UNIVERSITY OF UTAH
SPECIFICALLY DISCLAIM ANY WARRANTIES,INCLUDING, BUT NOT LIMITED TO,
THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE. THE SOFTWARE PROVIDED HEREUNDER IS ON AN "AS IS" BASIS, AND
THE AUTHORS AND DISTRIBUTORS HAVE NO OBLIGATION TO PROVIDE MAINTENANCE,
SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS.
<hr>
<address><a href="http://www.cs.utah.edu/~beazley"> beazley@cs.utah.edu </a> <br>
Last Modified, August 3, 1997</address>
</body>
</html>

652
swigweb/Doc1.1/HTML/Documentation.html
View file

@ -1,652 +0,0 @@
<!-- Published by Quadralay WebWorks HTML Lite 1.5.1 -->
<!-- And munged by Dave's special Python script -->
<html>
<head>
<title>Documentation System</title>
</head>
<body bgcolor="#ffffff">
<a name="n0"></a><h1>5 Documentation System</h1><p><ul>
<li> <a href="#n1">Introduction</a>
<li> <a href="#n2">How it works</a>
<li> <a href="#n3">Choosing a documentation format</a>
<li> <a href="#n4">Function usage and argument names</a>
<li> <a href="#n5">Titles, sections, and subsections</a>
<li> <a href="#n6">Formatting</a>
<li> <a href="#n7">Adding Additional Text</a>
<li> <a href="#n8">Disabling all documentation</a>
<li> <a href="#n9">An Example</a>
<li> <a href="#n10">ASCII Documentation</a>
<li> <a href="#n11">HTML Documentation</a>
<li> <a href="#n12">LaTeX Documentation</a>
<li> <a href="#n13">C++ Support</a>
<li> <a href="#n14">The Final Word?</a>
</ul>
<a name="n1"></a><h2> Introduction</h2>
While SWIG makes it easy to build interfaces, it is often difficult to keep track of all of the different functions, variables, constants, and other objects that have been wrapped. This especially becomes a problem when your interface starts to grow in size from a handful to several hundred functions. To address these concerns, SWIG can automatically generate documentation in a number of formats including ASCII, HTML, and LaTeX. The goal is that you could look at the documentation file to see what functions were wrapped and how they are used in the target scripting language.<p>
<p>
Usage documentation is generated for each declaration found in an interface file. This documentation is generated by the target language module so the Tcl module will follow Tcl syntax, the Perl module will use Perl syntax, and so on. In addition, C/C++ comments can be used to add descriptive text to each function. Comments can be processed in a number of different styles to suit personal preferences or to match the style used in a particular input file.<p>
<p>
Automatic documentation generation for C/C++ programs is a fairly formidable problem and SWIG was never intended to be a substitute for a full-blown documentation generator. However, I feel that is does a reasonable job of documenting scripting language interfaces. It seems to do just fine for many of SWIG's primary applications--rapid prototyping, debugging, and development.<p>
<a name="n2"></a><h2> How it works</h2>
For each declaration in an interface file, SWIG creates a "Documentation Entry." This entry contains three components; (1) a usage string, (2) a C information string, and (3) descriptive text. For example, suppose you have this declaration in an interface file :<p>
<p>
<blockquote><pre>int fact(int n);
/* This function computes a factorial */
</pre></blockquote>
The documentation entry produced by the SWIG ASCII module will look like this for Tcl:<p>
<p>
<blockquote><pre>fact n
[ returns int ]
This function computes a factorial
</pre></blockquote>
The first line shows how to call the function, the second line shows some additional information about the function (related to its C implementation), while the third line contains the comment text. The first two lines are automatically generated by SWIG and may be different for each language module. For example, the Perl5 module would generate the following output :<p>
<p>
<blockquote><pre>fact($n)
[ returns int ]
This function computes a factorial
</pre></blockquote>
<p>
Of course, this is only a simple example, more sophisticated things are possible.<p>
<a name="n3"></a><h2> Choosing a documentation format</h2>
The type of documentation is selected using the following command line options :<p>
<blockquote><pre>
-dascii Produce ASCII documentation
-dhtml Produce HTML documentation
-dlatex Produce LaTeX documentation
-dnone Produce no documentation
</pre></blockquote>
The various documentation modules are implemented in a manner similar to language modules so the exact choice may change in the future. With a little C++ hacking, it is also possible for you to add your own modules to SWIG. For example, with a bit of work you could turn all of the documentation into an online help command in your scripting language. <p>
<a name="n4"></a><h2> Function usage and argument names</h2>
The function usage string is produced to match the declaration given in the SWIG interface file. The names of arguments can be specified by using argument names. For example, the declarations<p>
<p>
<blockquote><pre>void insert_item(List *, char *);
char *lookup_item(char *name);
</pre></blockquote>
<p>
will produce the following documentation (for Python) :<p>
<p>
<blockquote><pre>insert_item(List *, char *)
[ returns void ]
lookup_item(name)
[ returns char * ]
</pre></blockquote>
When argument names are omitted, SWIG will use the C datatypes of the arguments in the documentation. If an argument name is specified, SWIG will use that in the documentation instead. Of course, it is up to each language module to create an appropriate usage string so your results may vary depending on how things have been implemented in each module.<p>
<a name="n5"></a><h2> Titles, sections, and subsections</h2>
The SWIG documentation system is hierarchical in nature and is organized into a collection of sections, subsections, subsubsections, and so on. The following SWIG directives can be used to organize an interface file :<p>
<p>
<ul>
<li><tt>%title "Title Text"</tt>. Set the documentation title (may only be used once)
<li><tt>%section "Section title"</tt>. Start a new section.
<li><tt>%subsection "Subsection title"</tt>. Create a new subsection.
<li><tt>%subsubsection "Subsubsection title"</tt>. Create a new subsubsection.
</ul>
<p>
The <tt>%title</tt> directive should be placed prior to the first declaration in an interface file and may only be used once (subsequent occurrences will simply be ignored). The section directives may be placed anywhere. However, <tt>%subsection</tt> can only be used after a <tt>%section</tt> directive and <tt>%subsubsection</tt> can only be used after a <tt>%subsection</tt> directive.<p>
<p>
With the organization directives, a SWIG interface file looks something like this :<p>
<p>
<blockquote><pre>%title "Example Interface File"
%module example
%{
#include "my_header.h"
%}
%section "Mathematical Functions"
... declarations ...
%section "Graphics"
%subsection "2D Plotting"
... Declarations ...
%subsection "3D Plotting"
%subsubsection "Viewing transformations"
... Declarations ...
%subsubsection "Lighting"
... Declarations ...
%subsubsection "Primitives"
... Declarations ...
%section "File I/O"
... Declarations ...
</pre></blockquote>
<a name="n6"></a><h2> Formatting</h2>
Documentation text can be sorted, chopped, sliced, and diced in a variety of ways. Formatting information is specified using a comma separated list of parameters after the <tt>%title</tt>, <tt>%section</tt>, <tt>%subsection</tt>, or <tt>%subsubsection</tt> directives. For example :<p>
<p>
<blockquote><pre>%title "My Documentation", sort, before, pre
</pre></blockquote>
This tells SWIG to sort all of the documentation, use comments that are before each declaration, and assume that text is preformatted. These formatting directives are applied to all children in the documentation tree--in this case, everything in an interface file.<p>
<p>
If formatting information is specified for a section like this<p>
<p>
<blockquote><pre>%subsection "3D Graphics", nosort, after
</pre></blockquote>
<p>
then the effect will only apply to that particular section (and all of its subsections). In this case, the formatting of the subsection would override any previous formatting, but these changes would only apply to this subsection. The next subsection could use its own formatting or that of its parent.<p>
<p>
Style parameters can also be specified using the <tt>%style</tt> and <tt>%localstyle</tt> parameters. The <tt>%style</tt> directive applies a new format to the current section and all of its parents. The <tt>%localstyle</tt> directive applies a new format to the current section. For example :<p>
<p>
<blockquote><pre>%style sort,before, skip=1 # Apply these formats everywhere
%localstyle sort # Apply this format to the current section
</pre></blockquote>
Use of these directives usually isn't required since it's easy enough to simply specify the information after each section.<p>
<a name="n15"></a><h3> Default Formatting</h3>
By default, SWIG will reformat comment text, produce documentation in the order encountered in an interface file (nosort), and annotate descriptions with a C information string. This behavior most closely matches that used in SWIG 1.0, although it is not an exact match due to differences in the old documentation system.<p>
<p>
When used in the default mode, comment text may contain documentation specific formatting markup. For example, you could embed LaTeX or HTML markup in comments to have precise control over the look of the final document.<p>
<a name="n16"></a><h3> Comment Formatting variables</h3>
The default formatting can be changed by changing one or more of the following formatting variables :<p>
<blockquote><pre>
after Use comments after a declaration (default)
before Use comments before a declaration
chop_top=nlines Comment chopping (preformatted)
chop_bottom=nlines Comment chopping (preformatted)
chop_left=nchar Comment chopping (preformatted)
chop_right=nchar Comment chopping (preformatted)
format Allow SWIG to reformat text (the default)
ignore Ignore comments
info Print C information text (default)
keep Keep comments (opposite of ignore)
noinfo Don't print C information text
nosort Don't sort documentation (default)
pre Assume text is preformatted
skip=nlines Number of blank lines between comment and declaration
sort Sort documentation
tabify Leave tabs intact
untabify Convert tabs to spaces (default)
</pre></blockquote>
<p>
More variables may be available depending on particular documentation modules. The use of these variables is described in the next few sections.<p>
<a name="n17"></a><h3> Sorting </h3>
Documentation can be sorted using the `<tt>sort</tt>' parameter. For example :<p>
<p>
<blockquote><pre>%title "My interface",sort
</pre></blockquote>
<p>
When used, all documentation entries, including sections will be alphabetically sorted. Sorting can be disabled in particular sections and subsection by specifying the `<tt>nosort</tt>' parameter in a section declaration. By default, SWIG does not sort documentation. As a general rule, it really only comes in handy if you have a really messy interface file.<p>
<p>
For backwards compatibility with earlier versions of SWIG, the following directives can be used to specify sorting. <p>
<p>
<blockquote><pre>%alpha Sort documentation alphabetically (obsolete)
%raw Keep documentation in order (obsolete)
</pre></blockquote>
These directives only apply globally and should near the beginning of file. Future support of these directives is not guaranteed and generally discouraged.<p>
<a name="n18"></a><h3> Comment placement and formatting</h3>
Comments may be placed before or after a declaration. This is specified using the `<tt>before</tt>' and `<tt>after</tt>' parameters. The space between a comment and a declaration can be set by changing the `<tt>skip</tt>' parameter. By default, <tt>skip=1</tt>, indicating that a comment and declaration must be on adjacent lines. Use of the <tt>skip</tt> parameter makes it possible for the documentation generator to ignore comments that are too far away and possibly unrelated to a declaration.<p>
<p>
By default, SWIG reformats the text found in a comment. However, in many cases, your file may have preformatted comments or comment blocks. To handle such comments correctly, you can use preformatted mode. This is specified using the `pre' parameter as follows :<p>
<p>
<blockquote><pre>%section "Preformatted Section",pre
%section "Reformatted Section", format
</pre></blockquote>
All declarations in this section will now be assumed to have preformatted comments. When using the preformat mode, a variety of other parameters are available as shown in the following diagram :<p>
<center><img src="ch5.1.png"></center>
.<p>
<p>
The chopping parameters can be used to strip out the text of block comments. For example, using <tt>chop_left=3</tt>, <tt>chop_top=1</tt>, <tt>chop_bottom=1</tt> on the above comment produces the following output :<p>
<blockquote><pre>
Plot2D_line x1 y1 x2 y2 color
[ returns void ]
void Plot2D_line(int x1, int y1, int x2, int y2, Pixel color)
Draws a line between the points (x1,y1) and (x2,y2) using the
the given color. The line is cropped to fit in the current
bounding box.
Uses the Bresenham line drawing algorithm.
</pre></blockquote>
<p>
The chopping parameters only apply if a comment is sufficiently large (i.e.. if the number of lines exceed <tt>chop_top</tt>+<tt>chop_bottom</tt>). Thus, in our example, a one line comment will be unaltered even though chopping has been set. By default, SWIG sets chop_left=3 and all others to zero. This setting removes the `<tt>/* </tt>` or `<tt>// </tt>` preceeding a comment.<p>
<a name="n19"></a><h3> Tabs and other annoyances</h3>
When using the preformatted mode, SWIG will automatically convert tabs to white space. This is done assuming that tabs are placed every 8 characters. The tabification mode can be selected using the `tabify' and `untabify' parameters :<p>
<p>
<blockquote><pre>%section "Untabified Section",untabify
%section "Leave those tabs alone", tabify
</pre></blockquote>
Tabs are simply ignored when comments are reformatted (well, actually, they're just copied into the output, but the target documentation method will ignore them).<p>
<a name="n20"></a><h3> Ignoring comments</h3>
To ignore the comments in a particular section, you can use the `ignore' parameter. For example :<p>
<blockquote><pre>
%section "No Comments", ignore
%section "Keep Comments", keep
</pre></blockquote>
The `<tt>keep</tt>' parameter is used to disable the effect of an ignore parameter (if set by a section's parent).<p>
<a name="n21"></a><h3> C Information</h3>
Normally, each declaration in a file will have a C information tag attached to it. This is usually enclosed in [ ] and contains the return type of a function along with other information. This text can disabled using the `noinfo' parameters and reenabled using the `info' parameter.<p>
<p>
<blockquote><pre>%section "No C Information", noinfo
%section "Print C Information", info
</pre></blockquote>
<a name="n7"></a><h2> Adding Additional Text</h2>
Additional documentation text can be added using the <tt>%text</tt> directive as shown :<p>
<p>
<blockquote><pre><tt>%text %{
</tt>
This is some additional documentation text.
%}
</pre></blockquote>
The <tt>%text</tt> directive is primarily used to add text that is not associated with any particular declaration. For example, you may want to provide a general description of a module before defining all of the functions. Any text can be placed inside the <tt>%{,%}</tt> block except for a `<tt>%}</tt>' that ends the block. For the purposes of sorting, text segments will always appear immediately after the previous declaration.<p>
<a name="n8"></a><h2> Disabling all documentation</h2>
All documentation can be suppressed for a portion of an interface file by using the <tt>%disabledoc</tt> and <tt>%enabledoc </tt>directives. These would be used as follows:<p>
<p>
<blockquote><pre>%disabledoc
... A a bunch of declarations with no documentation ...
%enabledoc
... Now declarations are documented again ...
</pre></blockquote>
These directives can be safely nested. Thus, the occurrence of these directives inside a <tt>%disabledoc </tt>section has no effect (only the outer-most occurrence is important).<p>
<p>
The primary use of these directives is for disabling the documentation on commonly used modules that you might use repeatedly (but don't want any documentation for). For example :<p>
<blockquote><pre>
%disabledoc
%include wish.i
%include array.i
%include timer.i
%enabledoc
</pre></blockquote>
<p>
<a name="n9"></a><h2> An Example</h2>
To illustrate the documentation system in action, here is some code from the SWIG library file `array.i'.<p>
<p>
<blockquote><pre>//
// array.i
// This SWIG library file provides access to C arrays.
%module carray
%section "SWIG C Array Module",info,after,pre,nosort,skip=1,chop_left=3,
chop_right=0,chop_top=0,chop_bottom=0
%text %{
%include array.i
This module provides scripting language access to various kinds of C/C++
arrays. For each datatype, a collection of four functions are created :
&lt;type&gt;_array(size) : Create a new array of given size
&lt;type&gt;_get(array, index) : Get an element from the array
&lt;type&gt;_set(array, index, value) : Set an element in the array
&lt;type&gt;_destroy(array) : Destroy an array
The functions in this library are only low-level accessor functions
designed to directly access C arrays. Like C, no bounds checking is
performed so use at your own peril.
%}
// -----------------------------------------------------------------------
// Integer array support
// -----------------------------------------------------------------------
%subsection "Integer Arrays"
/* The following functions provide access to integer arrays (mapped
onto the C 'int' datatype. */
%{
... Supporting C code ...
%}
int *int_array(int nitems);
/* Creates a new array of integers. nitems specifies the number of elements.
The array is created using malloc() in C and new() in C++. */
void int_destroy(int *array);
/* Destroys the given array. */
int int_get(int *array, int index);
/* Returns the value of array[index]. */
int int_set(int *array, int index, int value);
/* Sets array[index] = value. Returns value. */
// -----------------------------------------------------------------------
// Floating point
// -----------------------------------------------------------------------
%subsection "Floating Point Arrays"
/* The following functions provide access to arrays of floats and doubles. */
%{
.. Supporting C code ...
%}
double *double_array(int nitems);
/* Creates a new array of doubles. nitems specifies the number of elements.
The array is created using malloc() in C and new() in C++. */
void double_destroy(double *array);
/* Destroys the given array. */
double double_get(double *array, int index);
/* Returns the value of array[index]. */
double double_set(double *array, int index, double value);
/* Sets array[index] = value. Returns value. */
float *float_array(int nitems);
/* Creates a new array of floats. nitems specifies the number of elements.
The array is created using malloc() in C and new() in C++. */
void float_destroy(float *array);
/* Destroys the given array. */
float float_get(float *array, int index);
/* Returns the value of array[index]. */
float float_set(float *array, int index, float value);
/* Sets array[index] = value. Returns value. */
// -----------------------------------------------------------------------
// Character strings
// -----------------------------------------------------------------------
%subsection "String Arrays"
%text %{
The following functions provide support for the 'char **' datatype. This
is primarily used to handle argument lists and other similar structures that
need to be passed to a C/C++ function.
%}
#if defined(SWIGTCL)
%text %{
To convert from a Tcl list into a 'char **', the following code can be used :
# $list is a list
set args [string_array expr {[llength $list] + 1}]
set i 0
foreach a $list {
string_set $args $i $a
incr i 1
}
string_set $i ""
# $args is now a char ** type
%}
#elif defined(SWIGPERL)
%text %{
To convert from a Perl list into a 'char **', code similar to the following
can be used :
# @list is a list
my $l = scalar(@list);
my $args = string_array($l+1);
my $i = 0;
foreach $arg (@list) {
string_set($args,$i,$arg);
$i++;
}
string_set($args,$i,"");
(of course, there is always more than one way to do it)
%}
#elif defined(SWIGPYTHON)
%text %{
To convert from a Python list to a 'char **', code similar to the following
can be used :
# 'list' is a list
args = string_array(len(list)+1)
for i in range(0,len(list)):
string_set(args,i,list[i])
string_set(args,len(list),"")
%}
#endif
%{
... Supporting C code ...
%}
char **string_array(int nitems);
/* Creates a new array of strings. nitems specifies the number of elements.
The array is created using malloc() in C and new() in C++. Each element
of the array is set to NULL upon initialization. */
void string_destroy(char *array);
/* Destroys the given array. Each element of the array is assumed to be
a NULL-terminated string allocated with malloc() or new(). All of
these strings will be destroyed as well. (It is probably only safe to
use this function on an array created by string_array) */
char *string_get(char **array, int index);
/* Returns the value of array[index]. Returns a string of zero length
if the corresponding element is NULL. */
char *string_set(char **array, int index, char *value);
/* Sets array[index] = value. value is assumed to be a NULL-terminated
string. A string of zero length is mapped into a NULL value. When
setting the value, the value will be copied into a new string allocated
with malloc() or new(). Any previous value in the array will be
destroyed. */
</pre></blockquote>
<p>
In this file, all of the declarations are placed into a new section. We specify formatting information for our section. Since this is a general purpose library file, we have no idea what formatting our parent might be using so an explicit declaration makes sure we get it right. Each comment contains preformatted text describing each function. Finally, in the case of the string functions, we are using a combination of conditional compilation and documentation system directives to produce language-specific documentation. In this case, the documentation contains a usage example in the target scripting language.<p>
<p>
When processed through the ASCII module, this file will produce documentation similar to the following :<p>
<p>
<blockquote><pre>7. SWIG C Array Module
=======================
%include array.i
This module provides scripting language access to various kinds of C/C++
arrays. For each datatype, a collection of four functions are created :
&lt;type&gt;_array(size) : Create a new array of given size
&lt;type&gt;_get(array, index) : Get an element from the array
&lt;type&gt;_set(array, index, value) : Set an element in the array
&lt;type&gt;_destroy(array) : Destroy an array
The functions in this library are only low-level accessor functions
designed to directly access C arrays. Like C, no bounds checking is
performed so use at your own peril.
7.1. Integer Arrays
--------------------
The following functions provide access to integer arrays (mapped
onto the C 'int' datatype.
int_array(nitems)
[ returns int * ]
Creates a new array of integers. nitems specifies the number of elements.
The array is created using malloc() in C and new() in C++.
int_destroy(array)
[ returns void ]
Destroys the given array.
int_get(array,index)
[ returns int ]
Returns the value of array[index].
int_set(array,index,value)
[ returns int ]
Sets array[index] = value. Returns value.
7.2. Floating Point Arrays
---------------------------
The following functions provide access to arrays of floats and doubles.
double_array(nitems)
[ returns double * ]
Creates a new array of doubles. nitems specifies the number of elements.
The array is created using malloc() in C and new() in C++.
double_destroy(array)
[ returns void ]
Destroys the given array.
double_get(array,index)
[ returns double ]
Returns the value of array[index].
double_set(array,index,value)
[ returns double ]
Sets array[index] = value. Returns value.
float_array(nitems)
[ returns float * ]
Creates a new array of floats. nitems specifies the number of elements.
The array is created using malloc() in C and new() in C++.
float_destroy(array)
[ returns void ]
Destroys the given array.
float_get(array,index)
[ returns float ]
Returns the value of array[index].
float_set(array,index,value)
[ returns float ]
Sets array[index] = value. Returns value.
7.3. String Arrays
-------------------
The following functions provide support for the 'char **' datatype. This
is primarily used to handle argument lists and other similar structures that
need to be passed to a C/C++ function.
To convert from a Python list to a 'char **', code similar to the following
can be used :
# 'list' is a list
args = string_array(len(list)+1)
for i in range(0,len(list)):
string_set(args,i,list[i])
string_set(args,len(list),"")
string_array(nitems)
[ returns char ** ]
Creates a new array of strings. nitems specifies the number of elements.
The array is created using malloc() in C and new() in C++. Each element
of the array is set to NULL upon initialization.
string_destroy(array)
[ returns void ]
Destroys the given array. Each element of the array is assumed to be
a NULL-terminated string allocated with malloc() or new(). All of
these strings will be destroyed as well. (It is probably only safe to
use this function on an array created by string_array)
string_get(array,index)
[ returns char * ]
Returns the value of array[index]. Returns a string of zero length
if the corresponding element is NULL.
string_set(array,index,value)
[ returns char * ]
Sets array[index] = value. value is assumed to be a NULL-terminated
string. A string of zero length is mapped into a NULL value. When
setting the value, the value will be copied into a new string allocated
with malloc() or new(). Any previous value in the array will be
destroyed.
</pre></blockquote>
<a name="n10"></a><h2> ASCII Documentation</h2>
The ASCII module produces documentation in plaintext as shown in the previous example. Two formatting options are available (default values shown) :<p>
<p>
<blockquote><pre>ascii_indent = 8
ascii_columns = 70
</pre></blockquote>
`<tt>ascii_indent</tt>' specifies the number of characters to indent each function description. `<tt>ascii_columns</tt>' specifies the width of the output when reformatting text.<p>
<p>
When reformatting text, all extraneous white-space is stripped and text is filled to fit in the specified number of columns. The output text will be left-justified. A single newline is ignored, but multiple newlines can be used to start a new paragraph. The character sequence `\\' can be used to force a newline.<p>
<p>
Preformatted text is printed into the resulting output unmodified although it may be indented when used as part of a function description.<p>
<a name="n11"></a><h2> HTML Documentation</h2>
The HTML module produces documentation in HTML format (who would have guessed?). However, a number of style parameters are available (shown with default values)<p>
<blockquote><pre>
html_title = "&lt;H1&gt;:&lt;/H1&gt;"
html_contents = "&lt;H1&gt;:&lt;/H1&gt;"
html_section = "&lt;HR&gt;&lt;H2&gt;:&lt;/H2&gt;"
html_subsection = "&lt;H3&gt;:&lt;/H3&gt;"
html_subsubsection = "&lt;H4&gt;:&lt;/H4&gt;"
html_usage = "&lt;B&gt;&lt;TT&gt;:&lt;/TT&gt;&lt;/B&gt;"
html_descrip = "&lt;BLOCKQUOTE&gt;:&lt;/BLOCKQUOTE&gt;"
html_text = "&lt;P&gt;"
html_cinfo = ""
html_preformat = "&lt;PRE&gt;:&lt;/PRE&gt;"
html_body = "&lt;BODY bg_color=\"#ffffff\"&gt;:&lt;/BODY&gt;"
</pre></blockquote>
<p>
Any of these parameters can be changed, by simply specifying them after a <tt>%title</tt> or <tt>%section</tt> directive. However, the effects are applied globally so it probably makes sense to use the <tt>%style</tt> directive instead. For example :<p>
<p>
<blockquote><pre>%style html_contents="&lt;HR&gt;&lt;H1&gt;:&lt;/H1&gt;"
... Rest of declarations ...
</pre></blockquote>
Each tag uses a ":" to separate the start and end tags. Any text will be inserted in place of the ":". Since strings are specified in SWIG using quotes, any quotes that need to be inserted into a tag should be escaped using the "\" character.<p>
<p>
Sample HTML output is shown below :<p>
<p><a href="ch5.2.png">Sample Screenshot 1 </a><p>
<p>
<p>
Since our example used preformatted text, the output is very similar to the ASCII module. However, if you use the default mode, it is possible to insert HTML markup directly into your C comments for a more personalized document.<p>
<p>
For navigation within the document, SWIG also produces a table of contents with links to each section within the document. With a large interface, the contents may look something like this :<p>
<p><a href="ch5.3.png">Sample Screenshot 2 </a><p>
<p>
<p>
<a name="n12"></a><h2> LaTeX Documentation</h2>
The LaTeX module operates in a manner similar to the HTML module. The following style parameters are available (some knowledge of LaTeX is assumed).<p>
<blockquote><pre>
latex_parindent = "0.0in"
latex_textwidth = "6.5in"
latex_documentstyle = "[11pt]{article}"
latex_oddsidemargin = "0.0in"
latex_pagestyle = "\\pagestyle{headings}"
latex_title = "{\\Large \\bf :} \\\\\n"
latex_preformat = "{\\small \\begin{verbatim}:\\end{verbatim}}"
latex_usage = "{\\tt \\bf : }"
latex_descrip = "{\\\\\n \\makebox[0.5in]{} \begin{minipage}[t]{6in} : \n
\\end{minipage} \\\\";
latex_text = ":\\\\"
latex_cinfo = "{\\tt : }"
latex_section = "\\section{:}"
latex_subsection = "\\subsection{:}"
latex_subsubsection = "\\subsubsection{:}"
</pre></blockquote>
The style parameters, well, look downright ugly. Keep in mind that the strings used by SWIG have escape codes in them so it's necessary to represent the `\' character as `\\'. Thus, within SWIG your code will look something like this :<p>
<p>
<blockquote><pre>%style latex_section="\\newpage \n \\section{:}"
</pre></blockquote>
<p>
The default values should be sufficient for creating a readable LaTeX document in any case you don't want to worry changing the default style parameters.<p>
<a name="n13"></a><h2> C++ Support</h2>
C++ classes are encapsulated in a new subsection of the current section. This subsection contains descriptions of all of the member functions and variables. Since language modules are responsible for creating the documentation, the use of shadow classes will result in documentation describing the resulting shadow classes, not the lower level interface to the code.<p>
<p>
While it's not entirely clear that this is the best way to document C++ code, it is a start (and it's better than no documentation).<p>
<a name="n14"></a><h2> The Final Word?</h2>
Early versions of SWIG used a fairly primitive documentation system, that could best be described as "barely usable." The system described here represents an almost total rewrite of the documentation system. While it is, by no means, a perfect solution, I think it is a step in the right direction. The SWIG library is now entirely self-documenting and is a good source of documentation examples. As always suggestions and improvements are welcome.<p>
<p>
<p>
<p><hr>
<address>SWIG 1.1 - Last Modified : Mon Aug 4 10:46:55 1997</address>
</body>
</html>

295
swigweb/Doc1.1/HTML/Exceptions.html
View file

@ -1,295 +0,0 @@
<!-- Published by Quadralay WebWorks HTML Lite 1.5.1 -->
<!-- And munged by Dave's special Python script -->
<html>
<head>
<title>Exception Handling</title>
</head>
<body bgcolor="#ffffff">
<a name="n0"></a><h1>7 Exception Handling</h1><p><ul>
<li> <a href="#n1">The %except directive</a>
<li> <a href="#n2">Handling exceptions in C code</a>
<li> <a href="#n3">Exception handling with longjmp()</a>
<li> <a href="#n4">Handling C++ exceptions</a>
<li> <a href="#n5">Defining different exception handlers</a>
<li> <a href="#n6">Using The SWIG exception library</a>
<li> <a href="#n7">Debugging and other interesting uses for %except</a>
<li> <a href="#n8">More Examples</a>
</ul>
In some cases, it is desirable to catch errors that occur in C functions and propagate them up to the scripting language interface (ie. raise an exception). By default, SWIG does nothing, but you can create a user-definable exception handler using the <tt>%except</tt> directive.<p>
<a name="n1"></a><h2> The %except directive</h2>
The <tt>%except</tt> directive allows you to define an exception handler. It works something like this :<p>
<p>
<blockquote><pre>%except(python) {
try {
$function
}
catch (RangeError) {
PyErr_SetString(PyExc_IndexError,"index out-of-bounds");
return NULL;
}
}
</pre></blockquote>
<p>
As an argument, you need to specify the target language. The exception handling C/C++ code is then enclosed in braces. The symbol <tt>$function </tt>is replaced with the real C/C++ function call that SWIG would be ordinarily make in the wrapper code. The C code you specify inside the <tt>%except</tt> directive can be anything you like including custom C code and C++ exceptions.<p>
<p>
To delete an exception handler, simply use the <tt>%except</tt> directive with no code. For example :<p>
<p>
<blockquote><pre>%except(python); // Deletes any previously defined handler
</pre></blockquote>
Exceptions can be redefined as necessary. The scope of an exception handler is from the point of definition to the end of the file, the definition of a new exception handler, or until the handler is deleted.<p>
<a name="n2"></a><h2> Handling exceptions in C code</h2>
C has no formal mechanism for handling exceptions so there are many possibilities. The first approach is to simply provide some functions for setting and checking an error code. For example :<p>
<p>
<blockquote><pre>
/* File : except.c */
static char error_message[256];
static int error_status = 0;
void throw_exception(char *msg) {
strncpy(error_message,msg,256);
error_status = 1;
}
void clear_exception() {
error_status = 0;
}
char *check_exception() {
if (error_status) return error_message;
else return NULL;
}
</pre></blockquote>
To work, functions will need to explicitly call <tt>throw_exception()</tt> to indicate an error occurred. For example :<p>
<p>
<blockquote><pre>double inv(double x) {
if (x != 0) return 1.0/x;
else {
throw_exception("Division by zero");
return 0;
}
}
</pre></blockquote>
To catch the exception, you can write a simple exception handler such as the following (shown for Perl5) :<p>
<p>
<blockquote><pre>%except(perl5) {
char *err;
clear_exception();
$function
if ((err = check_exception())) {
croak(err);
}
}
</pre></blockquote>
<p>
Now, when an error occurs, it will be translated into a Perl error. The downside to this approach is that it isn't particularly clean and it assumes that your C code is a willing participant in generating error messages. (This isn't going to magically add exceptions to a code that doesn't have them).<p>
<a name="n3"></a><h2> Exception handling with longjmp()</h2>
Exception handling can also be added to C code using the <tt>&lt;setjmp.h&gt;</tt> library. This usually isn't documented very well (at least not in any of my C books). In any case, here's one implementation that uses the C preprocessor :<p>
<blockquote><pre>
/* File : except.c
Just the declaration of a few global variables we're going to use */
#include &lt;setjmp.h&gt;
jmp_buf exception_buffer;
int exception_status;
/* File : except.h */
#include &lt;setjmp.h&gt;
extern jmp_buf exception_buffer;
extern int exception_status;
#define try if ((exception_status = setjmp(exception_buffer)) == 0)
#define catch(val) else if (exception_status == val)
#define throw(val) longjmp(exception_buffer,val)
#define finally else
/* Exception codes */
#define RangeError 1
#define DivisionByZero 2
#define OutOfMemory 3
</pre></blockquote>
Now, within a C program, you can do the following :<p>
<p>
<blockquote><pre>double inv(double x) {
if (x) return 1.0/x;
else {throw(DivisionByZero);
}
</pre></blockquote>
Finally, to create a SWIG exception handler, write the following :<p>
<p>
<blockquote><pre>%{
#include "except.h"
%}
%except(perl5) {
try {
$function
} catch(RangeError) {
croak("Range Error");
} catch(DivisionByZero) {
croak("Division by zero");
} catch(OutOfMemory) {
croak("Out of memory");
} finally {
croak("Unknown exception");
}
}
</pre></blockquote>
<p>
At this point, you're saying this sure looks alot like C++ and you'd be right (C++ exceptions are often implemented in a similar manner). As always, the usual disclaimers apply--your mileage may vary. <p>
<a name="n4"></a><h2> Handling C++ exceptions</h2>
Handling C++ exceptions is almost completely trivial (well, all except for the actual C++ part). A typical SWIG exception handler will look like this :<p>
<p>
<blockquote><pre>%except(perl5) {
try {
$function
} catch(RangeError) {
croak("Range Error");
} catch(DivisionByZero) {
croak("Division by zero");
} catch(OutOfMemory) {
croak("Out of memory");
} catch(...) {
croak("Unknown exception");
}
}
</pre></blockquote>
The exception types need to be declared as classes elsewhere, possibly in a header file :<p>
<p>
<blockquote><pre>class RangeError {};
class DivisionByZero {};
class OutOfMemory {};
</pre></blockquote>
Newer versions of the SWIG parser should ignore exceptions specified in function declarations. For example :<p>
<p>
<blockquote><pre>double inv(double) throw(DivisionByZero);
</pre></blockquote>
<a name="n5"></a><h2> Defining different exception handlers</h2>
By default, the <tt>%except</tt> directive creates an exception handler that is used for all wrapper functions that follow it. Creating one universal exception handler for all functions may be unwieldy and promote excessive code bloat since the handler will be inlined into each wrapper function created. For this reason, the exception handler can be redefined at any point in an interface file. Thus, a more efficient use of exception handling may work like this :<p>
<p>
<blockquote><pre>%except(python) {
... your exception handler ...
}
/* Define critical operations that can throw exceptions here */
%except(python); // Clear the exception handler
/* Define non-critical operations that don't throw exceptions */
</pre></blockquote>
<a name="n9"></a><h3> Applying exception handlers to specific datatypes.</h3>
An alternative approach to using the <tt>%except</tt> directive is to use the "except" typemap. This allows you to attach an error handler to specific datatypes and function name. The typemap is applied to the return value of a function. For example :<p>
<p>
<blockquote><pre>%typemap(python,except) void * {
$function
if (!$source) {
PyExc_SetString(PyExc_MemoryError,"Out of memory in $name");
return NULL;
}
}
void *malloc(int size);
</pre></blockquote>
When applied, this will automatically check the return value of <tt>malloc()</tt> and raise an exception if it's invalid. For example :<p>
<p>
<blockquote><pre>Python 1.4 (Jan 16 1997) [GCC 2.7.2]
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
&gt;&gt;&gt; from example import *
&gt;&gt;&gt; a = malloc(2048)
&gt;&gt;&gt; b = malloc(1500000000)
Traceback (innermost last):
File "&lt;stdin&gt;", line 1, in ?
MemoryError: Out of memory in malloc
&gt;&gt;&gt;
</pre></blockquote>
<p>
Since typemaps can be named, you can define an exception handler for a specific function as follows :<p>
<p>
<blockquote><pre>%typemap(python,except) void *malloc {
...
}
</pre></blockquote>
This will only be applied to the <tt>malloc()</tt> function returning <tt>void *</tt>. While you probably wouldn't want to write a different exception handler for every function, it is possible to have a high degree of control if you need it. When typemaps are used, they override any exception handler defined with <tt>%except</tt>.<p>
<a name="n6"></a><h2> Using The SWIG exception library</h2>
The <tt>exception.i</tt> library file provides support for creating language independent exceptions in your interfaces. To use it, simply put an "<tt>%include exception.i</tt>" in your interface file. This creates a function<tt> SWIG_exception()</tt> that can be used to raise scripting language exceptions in a portable manner. For example :<p>
<p>
<blockquote><pre>// Language independent exception handler
%include exception.i
%except {
try {
$function
} catch(RangeError) {
SWIG_exception(SWIG_ValueError, "Range Error");
} catch(DivisionByZero) {
SWIG_exception(SWIG_DivisionByZero, "Division by zero");
} catch(OutOfMemory) {
SWIG_exception(SWIG_MemoryError, "Out of memory");
} catch(...) {
SWIG_exception(SWIG_RuntimeError,"Unknown exception");
}
}
</pre></blockquote>
As arguments, <tt>SWIG_exception()</tt> takes an error type code (an integer) and an error message string. The currently supported error types are :<p>
<p>
<blockquote><pre>SWIG_MemoryError
SWIG_IOError
SWIG_RuntimeError
SWIG_IndexError
SWIG_TypeError
SWIG_DivisionByZero
SWIG_OverflowError
SWIG_SyntaxError
SWIG_ValueError
SWIG_SystemError
SWIG_UnknownError
</pre></blockquote>
<p>
Since the <tt>SWIG_exception()</tt> function is defined at the C-level it can be used elsewhere in SWIG. This includes typemaps and helper functions. The exception library provides a language-independent exception handling mechanism, so many of SWIG's library files now rely upon the library as well.<p>
<a name="n7"></a><h2> Debugging and other interesting uses for %except</h2>
Since the <tt>%except </tt>directive allows you to encapsulate the actual C function call, it can also be used for debugging and tracing operations. For example :<p>
<p>
<blockquote><pre>%except(tcl) {
printf("Entering function : $name\n");
$function
printf("Leaving function : $name\n");
}
</pre></blockquote>
allows you to follow the function calls in order to see where an application might be crashing. <p>
<p>
Exception handlers can also be chained. For example :<p>
<p>
<blockquote><pre>%except(tcl) {
printf("Entering function : $name\n");
$except
printf("Leaving function : $name\n");
}
</pre></blockquote>
Any previously defined exception handler will be inserted in place of the "<tt>$except</tt>" symbol. As a result, you can attach debugging code to existing handlers if necessary. However, it should be noted that this must be done before any C/C++ declarations are made (as exception handlers are applied immediately to all functions that follow them).<p>
<a name="n8"></a><h2> More Examples</h2>
By now, you know most of the exception basics. See the SWIG Examples directory for more examples and ideas. Further chapters show how to generate exceptions in specific scripting languages.<p>
<p>
<p>
<p><hr>
<address>SWIG 1.1 - Last Modified : Mon Aug 4 10:46:57 1997</address>
</body>
</html>

1848
swigweb/Doc1.1/HTML/Extending.html
View file

File diff suppressed because it is too large Load diff

559
swigweb/Doc1.1/HTML/Index.html
View file

@ -1,559 +0,0 @@
<html>
<head>
<title> SWIG 1.1 Users Manual - Topic Index </title>
</head>
<body bgcolor="#ffffff">
<h1> Alphabetical Topic Index </h1>
<h2> - A - </h2>
<blockquote>
<a href="Python.html#n53">A complete application</a> (9 SWIG and Python)<br>
<a href="Advanced.html#n7">A few dynamic loading gotchas</a> (11 Advanced Topics)<br>
<a href="Tcl.html#n49">A few helper functions</a> (10 SWIG and Tcl)<br>
<a href="SWIG.html#n10">A general interface building strategy</a> (3 SWIG Basics)<br>
<a href="Python.html#n46">A mathematical function plotter</a> (9 SWIG and Python)<br>
<a href="Extending.html#n40">A Quick Intermission</a> (12 Extending SWIG)<br>
<a href="Python.html#n29">A simple example</a> (9 SWIG and Python)<br>
<a href="Typemaps.html#n16">A simple example</a> (6 Pointers, Constraints, and Typemaps)<br>
<a href="Perl5.html#n5">A simple Perl example</a> (8 SWIG and Perl5)<br>
<a href="Python.html#n67">A simple shadow class</a> (9 SWIG and Python)<br>
<a href="Perl5.html#n31">A simple SWIG interface file</a> (8 SWIG and Perl5)<br>
<a href="Perl5.html#n37">A simple typemap example</a> (8 SWIG and Perl5)<br>
<a href="Introduction.html#n5">A SWIG example</a> (1 Introduction)<br>
<a href="Extending.html#n5">A tour of SWIG datatypes</a> (12 Extending SWIG)<br>
<a href="Typemaps.html#n30">A Typemap Implementation</a> (6 Pointers, Constraints, and Typemaps)<br>
<a href="Tcl.html#n5">About the examples</a> (10 SWIG and Tcl)<br>
<a href="Python.html#n5">About the Examples</a> (9 SWIG and Python)<br>
<a href="Preface.html#n3">About this manual</a> (Preface)<br>
<a href="Python.html#n37">Accessing array data</a> (9 SWIG and Python)<br>
<a href="Perl5.html#n43">Accessing array structure members</a> (8 SWIG and Perl5)<br>
<a href="Python.html#n62">Accessing array structure members</a> (9 SWIG and Python)<br>
<a href="Tcl.html#n8">Accessing arrays</a> (10 SWIG and Tcl)<br>
<a href="Perl5.html#n6">Accessing arrays and other strange objects</a> (8 SWIG and Perl5)<br>
<a href="Tcl.html#n36">Accessing member data</a> (10 SWIG and Tcl)<br>
<a href="Documentation.html#n7">Adding Additional Text</a> (5 Documentation System)<br>
<a href="SWIG.html#n40">Adding member functions to C structures</a> (3 SWIG Basics)<br>
<a href="Python.html#n66">Adding native Python functions to a SWIG module</a> (9 SWIG and Python)<br>
<a href="SWIG.html#n55">Adding new methods</a> (3 SWIG Basics)<br>
<a href="SWIG.html#n71">Adding new methods</a> (3 SWIG Basics)<br>
<a href="Tcl.html#n17">Additional SWIG options</a> (10 SWIG and Tcl)<br>
<a href="Documentation.html#n9">An Example</a> (5 Documentation System)<br>
<a href="Tcl.html#n50">An OpenGL package</a> (10 SWIG and Tcl)<br>
<a href="Typemaps.html#n5">Applying constraints to input values</a> (6 Pointers, Constraints, and Typemaps)<br>
<a href="Typemaps.html#n27">Applying constraints to new datatypes</a> (6 Pointers, Constraints, and Typemaps)<br>
<a href="Exceptions.html#n9">Applying exception handlers to specific datatypes.</a> (7 Exception Handling)<br>
<a href="SWIG.html#n38">Array members</a> (3 SWIG Basics)<br>
<a href="SWIG.html#n30">Arrays</a> (3 SWIG Basics)<br>
<a href="Documentation.html#n10">ASCII Documentation</a> (5 Documentation System)<br>
<a href="Python.html#n31">Automated shadow class generation</a> (9 SWIG and Python)<br>
<a href="Introduction.html#n10">Automatic documentation generation</a> (1 Introduction)<br></blockquote>
<h2> - B - </h2>
<blockquote>
<a href="Perl5.html#n4">Basic Perl interface</a> (8 SWIG and Perl5)<br>
<a href="Tcl.html#n3">Basic Tcl Interface</a> (10 SWIG and Tcl)<br>
<a href="Tcl.html#n6">Binary trees in Tcl</a> (10 SWIG and Tcl)<br>
<a href="Preface.html#n6">Bug reports</a> (Preface)<br>
<a href="Tcl.html#n42">Building a C data structure in Tcl</a> (10 SWIG and Tcl)<br>
<a href="Perl5.html#n20">Building a dynamic module with MakeMaker</a> (8 SWIG and Perl5)<br>
<a href="Perl5.html#n11">Building a Perl5 interface to MATLAB</a> (8 SWIG and Perl5)<br>
<a href="Introduction.html#n15">Building a Perl5 module</a> (1 Introduction)<br>
<a href="Introduction.html#n16">Building a Python module</a> (1 Introduction)<br>
<a href="Python.html#n45">Building a simple 2D imaging class</a> (9 SWIG and Python)<br>
<a href="Tcl.html#n9">Building a simple OpenGL module</a> (10 SWIG and Tcl)<br>
<a href="Perl5.html#n21">Building a static version of Perl</a> (8 SWIG and Perl5)<br>
<a href="Tcl.html#n44">Building an object oriented C interface</a> (10 SWIG and Tcl)<br>
<a href="Tcl.html#n7">Building C/C++ data structures with Tk</a> (10 SWIG and Tcl)<br>
<a href="Python.html#n52">Building large multi-module systems</a> (9 SWIG and Python)<br>
<a href="Introduction.html#n19">Building libraries and modules</a> (1 Introduction)<br>
<a href="Tcl.html#n13">Building new kinds of Tcl interfaces (in Tcl)</a> (10 SWIG and Tcl)<br>
<a href="Perl5.html#n2">Building Perl Extensions under Windows 95/NT</a> (8 SWIG and Perl5)<br>
<a href="Python.html#n2">Building Python Extensions under Windows 95/NT</a> (9 SWIG and Python)<br>
<a href="Scripting.html#n3">Building scripting language extensions</a> (2 Scripting Languages)<br>
<a href="Tcl.html#n2">Building Tcl/Tk Extensions under Windows 95/NT</a> (10 SWIG and Tcl)<br></blockquote>
<h2> - C - </h2>
<blockquote>
<a href="SWIG.html#n39">C constructors and destructors</a> (3 SWIG Basics)<br>
<a href="Tcl.html#n40">C files</a> (10 SWIG and Tcl)<br>
<a href="Documentation.html#n21">C Information</a> (5 Documentation System)<br>
<a href="SWIG.html#n14">C Preprocessor directives</a> (3 SWIG Basics)<br>
<a href="Introduction.html#n6">C syntax, but not a C compiler</a> (1 Introduction)<br>
<a href="Tcl.html#n32">C++ Classes</a> (10 SWIG and Tcl)<br>
<a href="Python.html#n28">C++ Classes</a> (9 SWIG and Python)<br>
<a href="SWIG.html#n44">C++ example</a> (3 SWIG Basics)<br>
<a href="Extending.html#n11">C++ Processing</a> (12 Extending SWIG)<br>
<a href="SWIG.html#n6">C++ support</a> (3 SWIG Basics)<br>
<a href="Documentation.html#n13">C++ Support</a> (5 Documentation System)<br>
<a href="SWIG.html#n68">Categories</a> (3 SWIG Basics)<br>
<a href="Tcl.html#n37">Changing member data</a> (10 SWIG and Tcl)<br>
<a href="SWIG.html#n19">Character Strings</a> (3 SWIG Basics)<br>
<a href="SWIG.html#n37">Character strings and structures</a> (3 SWIG Basics)<br>
<a href="Library.html#n17">Checking in library files</a> (4 Multiple files and the SWIG library)<br>
<a href="Library.html#n15">Checking out library files</a> (4 Multiple files and the SWIG library)<br>
<a href="Documentation.html#n3">Choosing a documentation format</a> (5 Documentation System)<br>
<a href="SWIG.html#n62">Class methods</a> (3 SWIG Basics)<br>
<a href="Extending.html#n35">Cleanup</a> (12 Extending SWIG)<br>
<a href="SWIG.html#n77">Code blocks</a> (3 SWIG Basics)<br>
<a href="Extending.html#n9">Code Generation Functions</a> (12 Extending SWIG)<br>
<a href="SWIG.html#n9">Code Insertion</a> (3 SWIG Basics)<br>
<a href="Tcl.html#n66">Combining Tcl/Tk Extensions</a> (10 SWIG and Tcl)<br>
<a href="Extending.html#n30">Command Line Options and Basic Initialization</a> (12 Extending SWIG)<br>
<a href="Documentation.html#n16">Comment Formatting variables</a> (5 Documentation System)<br>
<a href="Documentation.html#n18">Comment placement and formatting</a> (5 Documentation System)<br>
<a href="SWIG.html#n13">Comments</a> (3 SWIG Basics)<br>
<a href="Typemaps.html#n7">Common typemap methods</a> (6 Pointers, Constraints, and Typemaps)<br>
<a href="Tcl.html#n22">Compilation problems</a> (10 SWIG and Tcl)<br>
<a href="Perl5.html#n22">Compilation problems and compiling with C++</a> (8 SWIG and Perl5)<br>
<a href="Python.html#n19">Compilation problems and compiling with C++</a> (9 SWIG and Python)<br>
<a href="Extending.html#n20">Compiling</a> (12 Extending SWIG)<br>
<a href="Perl5.html#n19">Compiling a dynamic module</a> (8 SWIG and Perl5)<br>
<a href="Python.html#n16">Compiling a dynamic module</a> (9 SWIG and Python)<br>
<a href="Tcl.html#n19">Compiling a dynamic module (Unix)</a> (10 SWIG and Tcl)<br>
<a href="Extending.html#n2">Compiling a SWIG extension</a> (12 Extending SWIG)<br>
<a href="Python.html#n32">Compiling modules with shadow classes</a> (9 SWIG and Python)<br>
<a href="SWIG.html#n8">Conditional compilation</a> (3 SWIG Basics)<br>
<a href="Tcl.html#n12">Configuration management with SWIG</a> (10 SWIG and Tcl)<br>
<a href="Extending.html#n39">Constants</a> (12 Extending SWIG)<br>
<a href="SWIG.html#n21">Constants</a> (3 SWIG Basics)<br>
<a href="Python.html#n25">Constants</a> (9 SWIG and Python)<br>
<a href="Scripting.html#n9">Constants</a> (2 Scripting Languages)<br>
<a href="Tcl.html#n29">Constants</a> (10 SWIG and Tcl)<br>
<a href="Perl5.html#n27">Constants</a> (8 SWIG and Perl5)<br>
<a href="Typemaps.html#n26">Constraint methods</a> (6 Pointers, Constraints, and Typemaps)<br>
<a href="SWIG.html#n60">Constructors and destructors</a> (3 SWIG Basics)<br>
<a href="Python.html#n72">Constructors and Destructors</a> (9 SWIG and Python)<br>
<a href="SWIG.html#n45">Constructors and destructors</a> (3 SWIG Basics)<br>
<a href="Tcl.html#n57">Converting a Tcl list to a char **</a> (10 SWIG and Tcl)<br>
<a href="Python.html#n58">Converting Python list to a char **</a> (9 SWIG and Python)<br>
<a href="Perl5.html#n41">Converting a Perl5 array to a char **</a> (8 SWIG and Perl5)<br>
<a href="Python.html#n59">Converting a Python file object to a FILE *</a> (9 SWIG and Python)<br>
<a href="Typemaps.html#n34">Copying a typemap</a> (6 Pointers, Constraints, and Typemaps)<br>
<a href="Tcl.html#n65">Creating a new package initialization library</a> (10 SWIG and Tcl)<br>
<a href="Typemaps.html#n32">Creating a new typemap</a> (6 Pointers, Constraints, and Typemaps)<br>
<a href="Extending.html#n47">Creating a usage string</a> (12 Extending SWIG)<br>
<a href="Extending.html#n37">Creating a Wrapper Function</a> (12 Extending SWIG)<br>
<a href="Typemaps.html#n17">Creating arrays</a> (6 Pointers, Constraints, and Typemaps)<br>
<a href="Extending.html#n36">Creating Commands</a> (12 Extending SWIG)<br>
<a href="Library.html#n7">Creating Library Files</a> (4 Multiple files and the SWIG library)<br>
<a href="Typemaps.html#n37">Creating local variables</a> (6 Pointers, Constraints, and Typemaps)<br>
<a href="Advanced.html#n1">Creating multi-module packages</a> (11 Advanced Topics)<br>
<a href="Tcl.html#n33">Creating new objects</a> (10 SWIG and Tcl)<br>
<a href="SWIG.html#n31">Creating read-only variables</a> (3 SWIG Basics)<br>
<a href="Preface.html#n4">Credits</a> (Preface)<br>
<a href="Introduction.html#n22">Cross platform woes</a> (1 Introduction)<br></blockquote>
<h2> - D - </h2>
<blockquote>
<a href="Exceptions.html#n7">Debugging and other interesting uses for %except</a> (7 Exception Handling)<br>
<a href="Documentation.html#n15">Default Formatting</a> (5 Documentation System)<br>
<a href="SWIG.html#n34">Default/optional arguments</a> (3 SWIG Basics)<br>
<a href="Exceptions.html#n5">Defining different exception handlers</a> (7 Exception Handling)<br>
<a href="SWIG.html#n73">Defining symbols</a> (3 SWIG Basics)<br>
<a href="Typemaps.html#n33">Deleting a typemap</a> (6 Pointers, Constraints, and Typemaps)<br>
<a href="Tcl.html#n35">Deleting objects</a> (10 SWIG and Tcl)<br>
<a href="SWIG.html#n24">Derived types, structs, and classes</a> (3 SWIG Basics)<br>
<a href="Documentation.html#n8">Disabling all documentation</a> (5 Documentation System)<br>
<a href="Extending.html#n46">Documentation entries</a> (12 Extending SWIG)<br>
<a href="Introduction.html#n18">Documentation generation</a> (1 Introduction)<br>
<a href="Extending.html#n12">Documentation Processing</a> (12 Extending SWIG)<br>
<a href="Tcl.html#n68">Dynamic loading</a> (10 SWIG and Tcl)<br>
<a href="Advanced.html#n2">Dynamic Loading of C++ modules</a> (11 Advanced Topics)<br></blockquote>
<h2> - E - </h2>
<blockquote>
<a href="Extending.html#n32">Emitting headers and support code</a> (12 Extending SWIG)<br>
<a href="SWIG.html#n50">Enums and constants</a> (3 SWIG Basics)<br>
<a href="Introduction.html#n9">Event driven C programming</a> (1 Introduction)<br>
<a href="Python.html#n9">Exception handling</a> (9 SWIG and Python)<br>
<a href="Perl5.html#n13">Exception handling</a> (8 SWIG and Perl5)<br>
<a href="Tcl.html#n10">Exception handling</a> (10 SWIG and Tcl)<br>
<a href="Exceptions.html#n3">Exception handling with longjmp()</a> (7 Exception Handling)<br>
<a href="Python.html#n44">Extending and fixing the gd module</a> (9 SWIG and Python)<br>
<a href="Tcl.html#n14">Extending the Tcl Netscape Plugin</a> (10 SWIG and Tcl)<br></blockquote>
<h2> - F - </h2>
<blockquote>
<a href="Extending.html#n7">File management</a> (12 Extending SWIG)<br>
<a href="Extending.html#n34">Final Initialization</a> (12 Extending SWIG)<br>
<a href="SWIG.html#n18">Floating Point</a> (3 SWIG Basics)<br>
<a href="Documentation.html#n6">Formatting</a> (5 Documentation System)<br>
<a href="Python.html#n48">From C to SWIG to Python</a> (9 SWIG and Python)<br>
<a href="Extending.html#n22">Function Parameters</a> (12 Extending SWIG)<br>
<a href="Documentation.html#n4">Function usage and argument names</a> (5 Documentation System)<br>
<a href="Tcl.html#n27">Functions</a> (10 SWIG and Tcl)<br>
<a href="Python.html#n23">Functions</a> (9 SWIG and Python)<br>
<a href="Perl5.html#n25">Functions</a> (8 SWIG and Perl5)<br></blockquote>
<h2> - G - </h2>
<blockquote>
<a href="SWIG.html#n4">Getting down to business</a> (3 SWIG Basics)<br>
<a href="Python.html#n39">Getting even more serious about array access</a> (9 SWIG and Python)<br>
<a href="Perl5.html#n9">Getting serious</a> (8 SWIG and Perl5)<br>
<a href="Perl5.html#n18">Getting the right header files</a> (8 SWIG and Perl5)<br>
<a href="Python.html#n15">Getting the right header files</a> (9 SWIG and Python)<br>
<a href="SWIG.html#n84">Getting the right header files</a> (3 SWIG Basics)<br>
<a href="Tcl.html#n18">Getting the right header files and libraries</a> (10 SWIG and Tcl)<br>
<a href="Tcl.html#n28">Global variables</a> (10 SWIG and Tcl)<br>
<a href="Perl5.html#n26">Global variables</a> (8 SWIG and Perl5)<br>
<a href="Perl5.html#n36">Graphical Web-Statistics in Perl5</a> (8 SWIG and Perl5)<br>
<a href="Perl5.html#n30">Graphs</a> (8 SWIG and Perl5)<br></blockquote>
<h2> - H - </h2>
<blockquote>
<a href="Exceptions.html#n4">Handling C++ exceptions</a> (7 Exception Handling)<br>
<a href="Exceptions.html#n2">Handling exceptions in C code</a> (7 Exception Handling)<br>
<a href="Perl5.html#n12">Handling output values (the easy way)</a> (8 SWIG and Perl5)<br>
<a href="Introduction.html#n8">Hands off code generation</a> (1 Introduction)<br>
<a href="Extending.html#n24">Hash Tables</a> (12 Extending SWIG)<br>
<a href="Extending.html#n45">Hints</a> (12 Extending SWIG)<br>
<a href="Extending.html#n43">How C++ processing works</a> (12 Extending SWIG)<br>
<a href="Scripting.html#n2">How does a scripting language talk to C?</a> (2 Scripting Languages)<br>
<a href="Documentation.html#n2">How it works</a> (5 Documentation System)<br>
<a href="Extending.html#n28">How many typemaps are there?</a> (12 Extending SWIG)<br>
<a href="SWIG.html#n88">How to avoid creating the interface from hell</a> (3 SWIG Basics)<br>
<a href="Preface.html#n10">How to avoid reading the manual</a> (Preface)<br>
<a href="Typemaps.html#n13">How to break everything with a typemap</a> (6 Pointers, Constraints, and Typemaps)<br>
<a href="SWIG.html#n87">How to cope with C++</a> (3 SWIG Basics)<br>
<a href="Introduction.html#n23">How to survive this manual</a> (1 Introduction)<br>
<a href="Documentation.html#n11">HTML Documentation</a> (5 Documentation System)<br></blockquote>
<h2> - I - </h2>
<blockquote>
<a href="Documentation.html#n20">Ignoring comments</a> (5 Documentation System)<br>
<a href="SWIG.html#n69">Implementations and Protocols</a> (3 SWIG Basics)<br>
<a href="Python.html#n11">Implementing C callback functions in Python</a> (9 SWIG and Python)<br>
<a href="Typemaps.html#n11">Implementing constraints with typemaps</a> (6 Pointers, Constraints, and Typemaps)<br>
<a href="Tcl.html#n43">Implementing methods in C</a> (10 SWIG and Tcl)<br>
<a href="Perl5.html#n7">Implementing methods in Perl</a> (8 SWIG and Perl5)<br>
<a href="Python.html#n40">Implementing special Python methods in C</a> (9 SWIG and Python)<br>
<a href="Library.html#n4">Including files on the command line</a> (4 Multiple files and the SWIG library)<br>
<a href="Perl5.html#n54">Inheritance</a> (8 SWIG and Perl5)<br>
<a href="SWIG.html#n52">Inheritance</a> (3 SWIG Basics)<br>
<a href="SWIG.html#n66">Inheritance</a> (3 SWIG Basics)<br>
<a href="Python.html#n77">Inheritance and shadow classes</a> (9 SWIG and Python)<br>
<a href="SWIG.html#n79">Initialization blocks</a> (3 SWIG Basics)<br>
<a href="SWIG.html#n78">Inlined code blocks</a> (3 SWIG Basics)<br>
<a href="SWIG.html#n11">Input format</a> (3 SWIG Basics)<br>
<a href="Typemaps.html#n21">Input Methods</a> (6 Pointers, Constraints, and Typemaps)<br>
<a href="Typemaps.html#n23">Input/Output Methods</a> (6 Pointers, Constraints, and Typemaps)<br>
<a href="Advanced.html#n3">Inside the SWIG type-checker</a> (11 Advanced Topics)<br>
<a href="SWIG.html#n61">Instance methods</a> (3 SWIG Basics)<br>
<a href="SWIG.html#n17">Integers</a> (3 SWIG Basics)<br>
<a href="Typemaps.html#n1">Introduction</a> (6 Pointers, Constraints, and Typemaps)<br>
<a href="Documentation.html#n1">Introduction</a> (5 Documentation System)<br>
<a href="Preface.html#n1">Introduction</a> (Preface)<br>
<a href="Extending.html#n1">Introduction</a> (12 Extending SWIG)<br>
<a href="Typemaps.html#n3">Introduction to typemaps</a> (6 Pointers, Constraints, and Typemaps)<br>
<a href="Tcl.html#n34">Invoking member functions</a> (10 SWIG and Tcl)<br>
<a href="Perl5.html#n55">Iterators</a> (8 SWIG and Perl5)<br></blockquote>
<h2> - L - </h2>
<blockquote>
<a href="Extending.html#n44">Language extensions</a> (12 Extending SWIG)<br>
<a href="Documentation.html#n12">LaTeX Documentation</a> (5 Documentation System)<br>
<a href="Library.html#n6">Library example</a> (4 Multiple files and the SWIG library)<br>
<a href="Introduction.html#n3">Life after SWIG</a> (1 Introduction)<br>
<a href="Introduction.html#n2">Life before SWIG</a> (1 Introduction)<br>
<a href="SWIG.html#n16">Limitations in the Parser (and various things to keep in mind)</a> (3 SWIG Basics)<br>
<a href="Tcl.html#n67">Limitations to this approach</a> (10 SWIG and Tcl)<br>
<a href="SWIG.html#n29">Linking to complex variables</a> (3 SWIG Basics)<br>
<a href="Scripting.html#n13">Linking with shared libraries</a> (2 Scripting Languages)<br></blockquote>
<h2> - M - </h2>
<blockquote>
<a href="Tcl.html#n41">Making a quick a dirty Tcl module</a> (10 SWIG and Tcl)<br>
<a href="Python.html#n35">Making a quick and dirty Python module</a> (9 SWIG and Python)<br>
<a href="Library.html#n12">malloc.i</a> (4 Multiple files and the SWIG library)<br>
<a href="Typemaps.html#n4">Managing input and output parameters</a> (6 Pointers, Constraints, and Typemaps)<br>
<a href="Typemaps.html#n29">Managing special data-types with helper functions</a> (6 Pointers, Constraints, and Typemaps)<br>
<a href="Extending.html#n38">Manipulating Global Variables</a> (12 Extending SWIG)<br>
<a href="Tcl.html#n60">Mapping C structures into Tcl Lists</a> (10 SWIG and Tcl)<br>
<a href="Python.html#n61">Mapping Python tuples into small arrays</a> (9 SWIG and Python)<br>
<a href="Python.html#n73">Member data</a> (9 SWIG and Python)<br>
<a href="SWIG.html#n48">Member data</a> (3 SWIG Basics)<br>
<a href="SWIG.html#n63">Member data</a> (3 SWIG Basics)<br>
<a href="SWIG.html#n46">Member functions</a> (3 SWIG Basics)<br>
<a href="Python.html#n49">Merging modules</a> (9 SWIG and Python)<br>
<a href="Python.html#n78">Methods that return new objects</a> (9 SWIG and Python)<br>
<a href="Perl5.html#n49">Module and package names</a> (8 SWIG and Perl5)<br>
<a href="Python.html#n68">Module names</a> (9 SWIG and Python)<br>
<a href="Python.html#n22">Modules</a> (9 SWIG and Python)<br>
<a href="Perl5.html#n3">Modules, packages, and classes</a> (8 SWIG and Perl5)<br>
<a href="Library.html#n10">More about the SWIG library</a> (4 Multiple files and the SWIG library)<br>
<a href="Exceptions.html#n8">More Examples</a> (7 Exception Handling)<br>
<a href="Typemaps.html#n28">Motivations for using typemaps</a> (6 Pointers, Constraints, and Typemaps)<br></blockquote>
<h2> - N - </h2>
<blockquote>
<a href="Tcl.html#n56">Name based type conversion</a> (10 SWIG and Tcl)<br>
<a href="Python.html#n57">Name based type conversion</a> (9 SWIG and Python)<br>
<a href="Perl5.html#n40">Name based type conversion</a> (8 SWIG and Perl5)<br>
<a href="Extending.html#n8">Naming Services</a> (12 Extending SWIG)<br>
<a href="Python.html#n76">Nested objects</a> (9 SWIG and Python)<br>
<a href="Perl5.html#n52">Nested Objects</a> (8 SWIG and Perl5)<br>
<a href="SWIG.html#n41">Nested structures</a> (3 SWIG Basics)<br>
<a href="Introduction.html#n7">Non-intrusive interface building</a> (1 Introduction)<br></blockquote>
<h2> - O - </h2>
<blockquote>
<a href="Perl5.html#n51">Object Ownership</a> (8 SWIG and Perl5)<br>
<a href="Python.html#n71">Object ownership</a> (9 SWIG and Python)<br>
<a href="SWIG.html#n7">Objective-C</a> (3 SWIG Basics)<br>
<a href="SWIG.html#n59">Objective-C Example</a> (3 SWIG Basics)<br>
<a href="Preface.html#n9">Organization of this manual</a> (Preface)<br>
<a href="SWIG.html#n72">Other issues</a> (3 SWIG Basics)<br>
<a href="Python.html#n12">Other odds and ends</a> (9 SWIG and Python)<br>
<a href="SWIG.html#n42">Other things to note about structures</a> (3 SWIG Basics)<br>
<a href="Typemaps.html#n22">Output Methods</a> (6 Pointers, Constraints, and Typemaps)<br>
<a href="SWIG.html#n33">Overriding call by reference</a> (3 SWIG Basics)<br></blockquote>
<h2> - P - </h2>
<blockquote>
<a href="Typemaps.html#n18">Packing a data structure</a> (6 Pointers, Constraints, and Typemaps)<br>
<a href="SWIG.html#n56">Partial class definitions</a> (3 SWIG Basics)<br>
<a href="SWIG.html#n27">Passing complex datatypes by value</a> (3 SWIG Basics)<br>
<a href="Tcl.html#n39">Performance concerns and disabling the object oriented interface</a> (10 SWIG and Tcl)<br>
<a href="Python.html#n79">Performance concerns and hints</a> (9 SWIG and Python)<br>
<a href="Advanced.html#n11">Performance of the type-checker</a> (11 Advanced Topics)<br>
<a href="Perl5.html#n38">Perl5 typemaps</a> (8 SWIG and Perl5)<br>
<a href="Library.html#n13">Placing the files in the library</a> (4 Multiple files and the SWIG library)<br>
<a href="Python.html#n47">Plotting an unstructured mesh</a> (9 SWIG and Python)<br>
<a href="Perl5.html#n47">Pointer handling</a> (8 SWIG and Perl5)<br>
<a href="Tcl.html#n63">Pointer handling</a> (10 SWIG and Tcl)<br>
<a href="Python.html#n65">Pointer handling</a> (9 SWIG and Python)<br>
<a href="Typemaps.html#n15">Pointer Library Functions</a> (6 Pointers, Constraints, and Typemaps)<br>
<a href="Perl5.html#n28">Pointers</a> (8 SWIG and Perl5)<br>
<a href="Tcl.html#n30">Pointers</a> (10 SWIG and Tcl)<br>
<a href="Python.html#n26">Pointers</a> (9 SWIG and Python)<br>
<a href="SWIG.html#n3">Pointers and complex objects</a> (3 SWIG Basics)<br>
<a href="SWIG.html#n35">Pointers to functions</a> (3 SWIG Basics)<br>
<a href="SWIG.html#n75">Predefined Symbols</a> (3 SWIG Basics)<br>
<a href="Tcl.html#n1">Preliminaries</a> (10 SWIG and Tcl)<br>
<a href="Perl5.html#n1">Preliminaries</a> (8 SWIG and Perl5)<br>
<a href="Python.html#n1">Preliminaries</a> (9 SWIG and Python)<br>
<a href="SWIG.html#n81">Preparing a C program for SWIG</a> (3 SWIG Basics)<br>
<a href="Python.html#n42">Preparing a module</a> (9 SWIG and Python)<br>
<a href="Preface.html#n8">Prerequisites</a> (Preface)<br>
<a href="Extending.html#n14">Prerequisites</a> (12 Extending SWIG)<br>
<a href="Python.html#n74">Printing</a> (9 SWIG and Python)<br>
<a href="Tcl.html#n52">Problems with the OpenGL interface</a> (10 SWIG and Tcl)<br>
<a href="SWIG.html#n49">Protection</a> (3 SWIG Basics)<br>
<a href="SWIG.html#n64">Protection</a> (3 SWIG Basics)<br>
<a href="Python.html#n8">Putting it all together</a> (9 SWIG and Python)<br>
<a href="Perl5.html#n35">Putting it all together</a> (8 SWIG and Perl5)<br>
<a href="Python.html#n4">Python shadow classes</a> (9 SWIG and Python)<br>
<a href="Python.html#n55">Python typemaps</a> (9 SWIG and Python)<br></blockquote>
<h2> - R - </h2>
<blockquote>
<a href="Python.html#n17">Rebuilding the Python interpreter (aka. static linking)</a> (9 SWIG and Python)<br>
<a href="SWIG.html#n51">References</a> (3 SWIG Basics)<br>
<a href="SWIG.html#n67">Referring to other classes</a> (3 SWIG Basics)<br>
<a href="Tcl.html#n38">Relationship with pointers</a> (10 SWIG and Tcl)<br>
<a href="Python.html#n10">Remapping C datatypes with typemaps</a> (9 SWIG and Python)<br>
<a href="Tcl.html#n58">Remapping constants</a> (10 SWIG and Tcl)<br>
<a href="Perl5.html#n14">Remapping datatypes with typemaps</a> (8 SWIG and Perl5)<br>
<a href="SWIG.html#n70">Renaming</a> (3 SWIG Basics)<br>
<a href="SWIG.html#n54">Renaming</a> (3 SWIG Basics)<br>
<a href="SWIG.html#n32">Renaming declarations</a> (3 SWIG Basics)<br>
<a href="Extending.html#n18">Required C++ compiler</a> (12 Extending SWIG)<br>
<a href="Extending.html#n17">Required files</a> (12 Extending SWIG)<br>
<a href="Tcl.html#n45">Required files</a> (10 SWIG and Tcl)<br>
<a href="SWIG.html#n28">Return by value</a> (3 SWIG Basics)<br>
<a href="Perl5.html#n48">Return values</a> (8 SWIG and Perl5)<br>
<a href="Tcl.html#n59">Returning values in arguments</a> (10 SWIG and Tcl)<br>
<a href="SWIG.html#n23">Run time pointer type checking</a> (3 SWIG Basics)<br>
<a href="Perl5.html#n17">Running SWIG</a> (8 SWIG and Perl5)<br>
<a href="Python.html#n14">Running SWIG</a> (9 SWIG and Python)<br>
<a href="SWIG.html#n1">Running SWIG</a> (3 SWIG Basics)<br>
<a href="Tcl.html#n16">Running SWIG</a> (10 SWIG and Tcl)<br>
<a href="Tcl.html#n25">Running SWIG from Developer Studio</a> (10 SWIG and Tcl)<br>
<a href="Python.html#n20">Running SWIG from Developer Studio</a> (9 SWIG and Python)<br>
<a href="Perl5.html#n23">Running SWIG from Developer Studio</a> (8 SWIG and Perl5)<br>
<a href="Advanced.html#n4">Runtime support (and potential problems)</a> (11 Advanced Topics)<br></blockquote>
<h2> - S - </h2>
<blockquote>
<a href="Perl5.html#n32">Sample Perl Script</a> (8 SWIG and Perl5)<br>
<a href="Typemaps.html#n36">Scope</a> (6 Pointers, Constraints, and Typemaps)<br>
<a href="Extending.html#n33">Setting a module name</a> (12 Extending SWIG)<br>
<a href="Tcl.html#n23">Setting a package prefix</a> (10 SWIG and Tcl)<br>
<a href="Perl5.html#n8">Shadow classes</a> (8 SWIG and Perl5)<br>
<a href="Tcl.html#n70">Shadow classes</a> (10 SWIG and Tcl)<br>
<a href="Scripting.html#n11">Shadow classes</a> (2 Scripting Languages)<br>
<a href="Perl5.html#n53">Shadow Functions</a> (8 SWIG and Perl5)<br>
<a href="Python.html#n75">Shadow Functions</a> (9 SWIG and Python)<br>
<a href="Scripting.html#n4">Shared libraries and dynamic loading</a> (2 Scripting Languages)<br>
<a href="Introduction.html#n17">Shortcuts</a> (1 Introduction)<br>
<a href="SWIG.html#n2">Simple C functions, variables, and constants</a> (3 SWIG Basics)<br>
<a href="Typemaps.html#n25">Simple constraint example</a> (6 Pointers, Constraints, and Typemaps)<br>
<a href="SWIG.html#n22">Simple pointers</a> (3 SWIG Basics)<br>
<a href="Python.html#n6">Solving a simple heat-equation</a> (9 SWIG and Python)<br>
<a href="Documentation.html#n17">Sorting</a> (5 Documentation System)<br>
<a href="Typemaps.html#n38">Special variables</a> (6 Pointers, Constraints, and Typemaps)<br>
<a href="Python.html#n64">Standard typemaps</a> (9 SWIG and Python)<br>
<a href="Tcl.html#n62">Standard typemaps</a> (10 SWIG and Tcl)<br>
<a href="Perl5.html#n46">Standard typemaps</a> (8 SWIG and Perl5)<br>
<a href="Extending.html#n31">Starting the parser</a> (12 Extending SWIG)<br>
<a href="Library.html#n9">Static initialization of multiple modules</a> (4 Multiple files and the SWIG library)<br>
<a href="Scripting.html#n12">Static linking</a> (2 Scripting Languages)<br>
<a href="Tcl.html#n21">Static linking</a> (10 SWIG and Tcl)<br>
<a href="SWIG.html#n47">Static members</a> (3 SWIG Basics)<br>
<a href="Tcl.html#n31">Structures</a> (10 SWIG and Tcl)<br>
<a href="Python.html#n27">Structures</a> (9 SWIG and Python)<br>
<a href="Perl5.html#n29">Structures and C++ classes</a> (8 SWIG and Perl5)<br>
<a href="Scripting.html#n10">Structures and classes</a> (2 Scripting Languages)<br>
<a href="SWIG.html#n5">Structures, unions, and object oriented C programming</a> (3 SWIG Basics)<br>
<a href="Introduction.html#n11">Summary</a> (1 Introduction)<br>
<a href="Python.html#n41">Summary (so far)</a> (9 SWIG and Python)<br>
<a href="SWIG.html#n43">Supported C++ features</a> (3 SWIG Basics)<br>
<a href="SWIG.html#n15">SWIG Directives</a> (3 SWIG Basics)<br>
<a href="Introduction.html#n12">SWIG for Windows and Macintosh</a> (1 Introduction)<br>
<a href="Introduction.html#n13">SWIG interface file</a> (1 Introduction)<br>
<a href="Preface.html#n7">SWIG is free</a> (Preface)<br>
<a href="Introduction.html#n21">SWIG on the Power Macintosh</a> (1 Introduction)<br>
<a href="Introduction.html#n20">SWIG on Windows 95/NT</a> (1 Introduction)<br>
<a href="Extending.html#n15">SWIG Organization</a> (12 Extending SWIG)<br>
<a href="Extending.html#n3">SWIG output</a> (12 Extending SWIG)<br>
<a href="SWIG.html#n12">SWIG Output</a> (3 SWIG Basics)<br>
<a href="Preface.html#n2">SWIG resources</a> (Preface)<br>
<a href="SWIG.html#n57">SWIG, C++, and the Legislation of Morality</a> (3 SWIG Basics)<br></blockquote>
<h2> - T - </h2>
<blockquote>
<a href="Documentation.html#n19">Tabs and other annoyances</a> (5 Documentation System)<br>
<a href="Tcl.html#n54">Tcl typemaps</a> (10 SWIG and Tcl)<br>
<a href="Tcl.html#n15">Tcl8.0 features</a> (10 SWIG and Tcl)<br>
<a href="Library.html#n11">tclsh.i</a> (4 Multiple files and the SWIG library)<br>
<a href="SWIG.html#n53">Templates</a> (3 SWIG Basics)<br>
<a href="SWIG.html#n74">The #if directive</a> (3 SWIG Basics)<br>
<a href="Exceptions.html#n1">The %except directive</a> (7 Exception Handling)<br>
<a href="Library.html#n2">The %extern directive</a> (4 Multiple files and the SWIG library)<br>
<a href="Library.html#n3">The %import directive</a> (4 Multiple files and the SWIG library)<br>
<a href="Library.html#n1">The %include directive</a> (4 Multiple files and the SWIG library)<br>
<a href="Python.html#n34">The C++ code</a> (9 SWIG and Python)<br>
<a href="Extending.html#n21">The DataType class</a> (12 Extending SWIG)<br>
<a href="Documentation.html#n14">The Final Word?</a> (5 Documentation System)<br>
<a href="SWIG.html#n58">The future of C++ and SWIG</a> (3 SWIG Basics)<br>
<a href="Extending.html#n13">The Future of SWIG</a> (12 Extending SWIG)<br>
<a href="Python.html#n13">The gory details of shadow classes</a> (9 SWIG and Python)<br>
<a href="Perl5.html#n15">The gory details on shadow classes</a> (8 SWIG and Perl5)<br>
<a href="Extending.html#n29">The header file</a> (12 Extending SWIG)<br>
<a href="Typemaps.html#n19">The idea (in a nutshell)</a> (6 Pointers, Constraints, and Typemaps)<br>
<a href="Extending.html#n4">The Language class (simple version)</a> (12 Extending SWIG)<br>
<a href="Python.html#n3">The low-level Python/C interface</a> (9 SWIG and Python)<br>
<a href="Perl5.html#n33">The MATLAB engine interface</a> (8 SWIG and Perl5)<br>
<a href="Tcl.html#n4">The object oriented interface</a> (10 SWIG and Tcl)<br>
<a href="Extending.html#n16">The organization of this chapter</a> (12 Extending SWIG)<br>
<a href="SWIG.html#n76">The output of SWIG</a> (3 SWIG Basics)<br>
<a href="Tcl.html#n71">The step-by-step process for making a plugin extension.</a> (10 SWIG and Tcl)<br>
<a href="Extending.html#n23">The String Class</a> (12 Extending SWIG)<br>
<a href="Introduction.html#n14">The swig command</a> (1 Introduction)<br>
<a href="SWIG.html#n82">The SWIG interface file</a> (3 SWIG Basics)<br>
<a href="Library.html#n5">The SWIG library</a> (4 Multiple files and the SWIG library)<br>
<a href="Extending.html#n42">The SWIG library and installation issues</a> (12 Extending SWIG)<br>
<a href="Introduction.html#n4">The SWIG package</a> (1 Introduction)<br>
<a href="Typemaps.html#n2">The SWIG Pointer Library</a> (6 Pointers, Constraints, and Typemaps)<br>
<a href="Advanced.html#n6">The SWIG runtime library</a> (11 Advanced Topics)<br>
<a href="Python.html#n70">The this pointer</a> (9 SWIG and Python)<br>
<a href="Scripting.html#n1">The two language view of the world</a> (2 Scripting Languages)<br>
<a href="Extending.html#n26">The typemap C API.</a> (12 Extending SWIG)<br>
<a href="SWIG.html#n65">The use of id</a> (3 SWIG Basics)<br>
<a href="Library.html#n16">The world's fastest way to write a Makefile</a> (4 Multiple files and the SWIG library)<br>
<a href="Extending.html#n25">The WrapperFunction class</a> (12 Extending SWIG)<br>
<a href="Documentation.html#n5">Titles, sections, and subsections</a> (5 Documentation System)<br>
<a href="Tcl.html#n69">Turning a SWIG module into a Tcl Package.</a> (10 SWIG and Tcl)<br>
<a href="Perl5.html#n44">Turning Perl references into C pointers</a> (8 SWIG and Perl5)<br>
<a href="Python.html#n69">Two classes</a> (9 SWIG and Python)<br>
<a href="Advanced.html#n9">Type casting</a> (11 Advanced Topics)<br>
<a href="Advanced.html#n8">Type equivalence</a> (11 Advanced Topics)<br>
<a href="SWIG.html#n26">Typedef</a> (3 SWIG Basics)<br>
<a href="SWIG.html#n36">Typedef and structures</a> (3 SWIG Basics)<br>
<a href="Typemaps.html#n12">Typemap examples</a> (6 Pointers, Constraints, and Typemaps)<br>
<a href="Typemaps.html#n35">Typemap matching rules</a> (6 Pointers, Constraints, and Typemaps)<br>
<a href="Perl5.html#n39">Typemap variables</a> (8 SWIG and Perl5)<br>
<a href="Python.html#n56">Typemap variables</a> (9 SWIG and Python)<br>
<a href="Tcl.html#n55">Typemap variables</a> (10 SWIG and Tcl)<br>
<a href="Tcl.html#n11">Typemaps</a> (10 SWIG and Tcl)<br>
<a href="Extending.html#n6">Typemaps (from C)</a> (12 Extending SWIG)<br>
<a href="Typemaps.html#n14">Typemaps and the future</a> (6 Pointers, Constraints, and Typemaps)<br>
<a href="Typemaps.html#n10">Typemaps and the SWIG Library</a> (6 Pointers, Constraints, and Typemaps)<br>
<a href="Typemaps.html#n9">Typemaps for handling arrays</a> (6 Pointers, Constraints, and Typemaps)<br></blockquote>
<h2> - U - </h2>
<blockquote>
<a href="Python.html#n38">Use Python for control, C for performance</a> (9 SWIG and Python)<br>
<a href="Python.html#n51">Use static linking</a> (9 SWIG and Python)<br>
<a href="Tcl.html#n61">Useful functions</a> (10 SWIG and Tcl)<br>
<a href="Perl5.html#n45">Useful functions</a> (8 SWIG and Perl5)<br>
<a href="Python.html#n63">Useful Functions</a> (9 SWIG and Python)<br>
<a href="Python.html#n36">Using our new module</a> (9 SWIG and Python)<br>
<a href="Tcl.html#n20">Using a dynamic module</a> (10 SWIG and Tcl)<br>
<a href="Extending.html#n49">Using a new documentation module</a> (12 Extending SWIG)<br>
<a href="Typemaps.html#n24">Using different names</a> (6 Pointers, Constraints, and Typemaps)<br>
<a href="Python.html#n50">Using dynamic loading</a> (9 SWIG and Python)<br>
<a href="Perl5.html#n24">Using NMAKE</a> (8 SWIG and Perl5)<br>
<a href="Tcl.html#n26">Using NMAKE</a> (10 SWIG and Tcl)<br>
<a href="Python.html#n21">Using NMAKE</a> (9 SWIG and Python)<br>
<a href="Typemaps.html#n20">Using some typemaps</a> (6 Pointers, Constraints, and Typemaps)<br>
<a href="Python.html#n43">Using the gd module</a> (9 SWIG and Python)<br>
<a href="Tcl.html#n51">Using the OpenGL module</a> (10 SWIG and Tcl)<br>
<a href="Tcl.html#n72">Using the plugin</a> (10 SWIG and Tcl)<br>
<a href="Exceptions.html#n6">Using The SWIG exception library</a> (7 Exception Handling)<br>
<a href="Python.html#n60">Using typemaps to return arguments</a> (9 SWIG and Python)<br>
<a href="Perl5.html#n42">Using typemaps to return values</a> (8 SWIG and Perl5)<br>
<a href="Python.html#n18">Using your module</a> (9 SWIG and Python)<br>
<a href="Tcl.html#n24">Using [incr Tcl] namespaces</a> (10 SWIG and Tcl)<br></blockquote>
<h2> - V - </h2>
<blockquote>
<a href="Python.html#n24">Variable Linking</a> (9 SWIG and Python)<br>
<a href="Scripting.html#n8">Variable linking</a> (2 Scripting Languages)<br>
<a href="SWIG.html#n20">Variables</a> (3 SWIG Basics)<br></blockquote>
<h2> - W - </h2>
<blockquote>
<a href="Perl5.html#n50">What gets created?</a> (8 SWIG and Perl5)<br>
<a href="Extending.html#n27">What happens on typemap lookup?</a> (12 Extending SWIG)<br>
<a href="SWIG.html#n25">What happens when SWIG encounters an unknown datatype?</a> (3 SWIG Basics)<br>
<a href="Python.html#n54">What is a typemap?</a> (9 SWIG and Python)<br>
<a href="Tcl.html#n53">What is a typemap?</a> (10 SWIG and Tcl)<br>
<a href="Typemaps.html#n31">What is a typemap?</a> (6 Pointers, Constraints, and Typemaps)<br>
<a href="Introduction.html#n1">What is SWIG?</a> (1 Introduction)<br>
<a href="SWIG.html#n85">What to do with main()</a> (3 SWIG Basics)<br>
<a href="Preface.html#n5">What's new?</a> (Preface)<br>
<a href="Python.html#n33">Where to go for more information</a> (9 SWIG and Python)<br>
<a href="Extending.html#n50">Where to go for more information</a> (12 Extending SWIG)<br>
<a href="Perl5.html#n16">Where to go from here?</a> (8 SWIG and Perl5)<br>
<a href="Advanced.html#n10">Why a name based approach?</a> (11 Advanced Topics)<br>
<a href="Advanced.html#n5">Why doesn't C++ inheritance work between modules?</a> (11 Advanced Topics)<br>
<a href="SWIG.html#n83">Why use separate interface files?</a> (3 SWIG Basics)<br>
<a href="Python.html#n30">Why write shadow classes in Python?</a> (9 SWIG and Python)<br>
<a href="Scripting.html#n6">Will adding a scripting language to my C program make it unmanagable?</a> (2 Scripting Languages)<br>
<a href="Scripting.html#n5">Will scripting languages make my C program inefficient?</a> (2 Scripting Languages)<br>
<a href="Library.html#n8">Working with library files</a> (4 Multiple files and the SWIG library)<br>
<a href="SWIG.html#n86">Working with the C preprocessor</a> (3 SWIG Basics)<br>
<a href="SWIG.html#n80">Wrapper code blocks</a> (3 SWIG Basics)<br>
<a href="Scripting.html#n7">Wrapper functions</a> (2 Scripting Languages)<br>
<a href="Python.html#n7">Wrapping a C library</a> (9 SWIG and Python)<br>
<a href="Library.html#n14">Wrapping a library file</a> (4 Multiple files and the SWIG library)<br>
<a href="Perl5.html#n10">Wrapping C libraries and other packages</a> (8 SWIG and Perl5)<br>
<a href="Tcl.html#n46">Wrapping gl.h</a> (10 SWIG and Tcl)<br>
<a href="Tcl.html#n47">Wrapping glu.h</a> (10 SWIG and Tcl)<br>
<a href="Tcl.html#n48">Wrapping the aux library</a> (10 SWIG and Tcl)<br>
<a href="Perl5.html#n34">Wrapping the MATLAB matrix functions</a> (8 SWIG and Perl5)<br>
<a href="Extending.html#n19">Writing a main program</a> (12 Extending SWIG)<br>
<a href="Tcl.html#n64">Writing a main program and Tcl_AppInit()</a> (10 SWIG and Tcl)<br>
<a href="Extending.html#n48">Writing a new documentation module</a> (12 Extending SWIG)<br>
<a href="Extending.html#n10">Writing a Real Language Module</a> (12 Extending SWIG)<br>
<a href="Typemaps.html#n6">Writing new typemaps</a> (6 Pointers, Constraints, and Typemaps)<br>
<a href="Extending.html#n41">Writing the default typemaps</a> (12 Extending SWIG)<br>
<a href="Typemaps.html#n8">Writing typemap code</a> (6 Pointers, Constraints, and Typemaps)<br></blockquote>
<p><hr>
<address>SWIG 1.1 - Last Modified : Mon Aug 4 10:47:18 1997 </address>
</body>
</html>

323
swigweb/Doc1.1/HTML/Introduction.html
View file

@ -1,323 +0,0 @@
<!-- Published by Quadralay WebWorks HTML Lite 1.5.1 -->
<!-- And munged by Dave's special Python script -->
<html>
<head>
<title>Introduction</title>
</head>
<body bgcolor="#ffffff">
<a name="n0"></a><h1>1 Introduction</h1><p><ul>
<li> <a href="#n1">What is SWIG?</a>
<li> <a href="#n2">Life before SWIG</a>
<li> <a href="#n3">Life after SWIG</a>
<li> <a href="#n4">The SWIG package</a>
<li> <a href="#n5">A SWIG example</a>
<li> <a href="#n6">C syntax, but not a C compiler</a>
<li> <a href="#n7">Non-intrusive interface building</a>
<li> <a href="#n8">Hands off code generation</a>
<li> <a href="#n9">Event driven C programming</a>
<li> <a href="#n10">Automatic documentation generation</a>
<li> <a href="#n11">Summary</a>
<li> <a href="#n12">SWIG for Windows and Macintosh</a>
</ul>
<a name="n1"></a><h2> What is SWIG?</h2>
SWIG is a code development tool that makes it possible to quickly build powerful scripting language interfaces to C, C++, or Objective-C programs. In a nutshell, SWIG is a compiler that takes C declarations and turns them into the "glue" needed to access them from common scripting languages including Perl, Python, and Tcl. SWIG usually requires no modifications to existing C code and can often be used to build a working interface in a matter of minutes. This makes it possible to do a number of interesting things including :<p>
<p>
<ul>
<li>Building powerful interfaces to existing C programs.
<li>Rapid prototyping and application development.
<li>Interactive debugging.
<li>Making a graphical user interface (using Tk for example).
<li>Powerful testing of C libraries and programs (using scripts).
<li>Building high performance C modules for scripting languages.
<li>Making C programming more enjoyable (or tolerable depending on your point of view)
<li>Impressing your friends.
</ul>
<p>
There are some computer scientists who seem to believe that the only way to solve complicated problems is to create software of epic proportions and to have some sort of "grand" software design. Unfortunately this seems to lead to solutions that are even more complicated than the original problem. This, in turn enables the user to forget about the original problem and spend their time cursing at their machine (hence, the term "enabling technology"). SWIG, on the other hand, was developed because I was fed up with how much time I was wasting trying to develop flexible scientific applications. I wanted a tool that would let me use scripting languages to glue different things together, but didn't get in the way of the real problems I was working on. I wanted a simple tool that scientists and engineers could use to put together applications involving number crunching, data analysis, and visualization without having to worry about tedious systems programming, making substantial modifications to existing code, trying to figure out a big monolithic computing "environment," or having to get a second degree in computer science. In short, I wanted to have a tool that would improve application development, but stay out of the way as much as possible.<p>
<a name="n2"></a><h2> Life before SWIG</h2>
SWIG was developed to make my life easier as a C programmer. While C is great for high performance and systems programming, trying to make an interactive and highly flexible C program is a nightmare (in fact, it's much worse than that). The real problem is that for every C program I wrote, I needed to have some sort of interface, but being more interested in other problems, I would always end up writing a really bad interface that was hard to extend, hard to modify, and hard to use. I suppose I could have tried to do something fancy using X11, but who has time to waste weeks or months trying to come up with an interface that is probably going to end up being larger than the original C code? There are more interesting problems to work on.<p>
<p>
The real problem, perhaps, is that most C programs end up being structured as follows :<p>
<p>
<ul>
<li>A collection of functions and variables.
<li>A <tt>main()</tt> program that starts everything up.
<li>A bunch of hacks added to make it usable.
</ul>
<p>
The <tt>main()</tt> program may be written to handle command line arguments or to read data from <tt>stdin</tt>, but either way, modifying or extending the program to do something new requires changing the C code, recompiling, and testing. If you make a mistake, you need to repeat this cycle until things work. Of course, as more and more features are added, your C program turns into a hideous unintelligible mess that is even more difficult to modify than it was before (Of course, if you're lucky, your project starts out as an unintelligible mess).<p>
<a name="n3"></a><h2> Life after SWIG</h2>
With SWIG, I was hoping to avoid many of the headaches of working with C programs, by structuring things as follows :<p>
<p>
<ul>
<li>A collection of functions and variables.
<li>A nice interpreted interface language that can be used to access everything.
</ul>
<p>
With this model, you keep all of the functionality of your C program, but access it through a scripting language interface instead of writing more C code. This is nice because you are given full freedom to call functions in any order, access variables, and write scripts to do all sorts of interesting things. If you want to change something, just modify a script, and rerun it. If you're trying to debug a collection of functions, you can call them individually and see what they do. If you're trying to build a package out of various components, you can just glue everything together with a scripting language and have a common interface to all of the various pieces. <p>
<p>
SWIG tries to make the integration between scripting languages and C as painless as possible. This allows you to focus on the underlying C program and using the high-level scripting language interface, but not the tedious and complex chore of making the two languages talk to each other.<p>
<p>
I like this model of programming. While it's certainly no "silver-bullet", it has made programming alot more enjoyable and has enabled us to solve complicated problems that would have been unneccessarily difficult using only C.<p>
<a name="n4"></a><h2> The SWIG package</h2>
SWIG is a compiler that takes ANSI C declarations and turns them into a file containing the C code for binding C functions, variables, and constants to a scripting language (SWIG also supports C++ class and Objective-C interface definitions). Input is specified in the form of an "interface file" containing declarations (input can also be given from C source files provided they are sufficiently clean). The SWIG parser takes this input file and passes it on to a code generation and documentation module. These modules produce an interface for a particular scripting language along with a document describing the interface that was created. Different scripting languages are supported by writing new back-end modules to the system.<p>
<p><center><img src="ch1.1.png"></center><p>
<p>
<a name="n5"></a><h2> A SWIG example</h2>
The best way to illustrate SWIG is with a simple example. Consider the following C code: <p>
<p>
<blockquote><pre>/* File : example.c */
double My_variable = 3.0;
/* Compute factorial of n */
int fact(int n) {
if (n &lt;= 1) return 1;
else return n*fact(n-1);
}
/* Compute n mod m */
int my_mod(int n, int m) {
return(n % m);
}
</pre></blockquote>
<p>
Suppose that you wanted to access these functions and the global variable <tt>My_variable</tt> from Tcl. We start by making a SWIG interface file as shown below (by convention, these files carry a .i suffix) : <p>
<a name="n13"></a><h3> SWIG interface file</h3>
<blockquote><pre>
/* File : example.i */
%module example
%{
/* Put headers and other declarations here */
%}
extern double My_variable;
extern int fact(int);
extern int my_mod(int n, int m);
</pre></blockquote>
<p>
The interface file contains ANSI C function prototypes and variable declarations. The <tt>%module</tt> directive defines the name of the module that will be created by SWIG. The <tt>%{,%}</tt> block provides a location for inserting additional code such as C header files or additional C functions. <p>
<a name="n14"></a><h3> The swig command</h3>
SWIG is invoked using the <tt>swig</tt> command. We can use this to build a Tcl module (under Linux) as follows :<p>
<p>
<blockquote><pre>unix &gt; swig -tcl example.i
Generating wrappers for Tcl.
unix &gt; gcc -c -fpic example.c example_wrap.c -I/usr/local/include
unix &gt; gcc -shared example.o example_wrap.o -o example.so
unix &gt; tclsh
% load ./example.so
% fact 4
24
% my_mod 23 7
2
% expr $My_variable + 4.5
7.5
%
</pre></blockquote>
<p>
The <tt>swig</tt> command produced a new file called <tt>example_wrap.c</tt> that should be compiled along with the <tt>example.c</tt> file. Most operating systems and scripting languages now support dynamic loading of modules. In our example, our Tcl module has been compiled into a shared library that can be loaded into Tcl and used. When loaded, Tcl will now have our new functions and variables added to it. Taking a careful look at the file <tt>example_wrap.c</tt> reveals a hideous mess, but fortunately you almost never need to worry about it.<p>
<a name="n15"></a><h3> Building a Perl5 module</h3>
Now, let's turn these functions into a Perl5 module. Without making any changes type the following (shown for Solaris):<p>
<p>
<p>
<blockquote><pre>unix &gt; swig -perl5 example.i
Generating wrappers for Perl5
unix &gt; gcc -c example.c example_wrap.c \
-I/usr/local/lib/perl5/sun4-solaris/5.003/CORE
unix&gt; ld -G example.o example_wrap.o -o example.so # This is for Solaris
unix &gt; perl5.003
use example;
print example::fact(4), "\n";
print example::my_mod(23,7), "\n";
print $example::My_variable + 4.5, "\n";
&lt;ctrl-d&gt;
24
2
7.5
unix &gt;
</pre></blockquote>
<a name="n16"></a><h3> Building a Python module</h3>
Finally, let's build a module for Python1.4 (shown for Irix).<p>
<p>
<blockquote><pre>unix &gt; swig -python example.i
Generating wrappers for Python
unix &gt; gcc -c example.c example_wrap.c -I/usr/local/include/python1.4
unix &gt; ld -shared example.o example_wrap.o -o examplemodule.so # Irix
unix &gt; Python
Python 1.4 (Sep 10 1996) [GCC 2.7.0]
Copyright 1991-1996 Stichting Mathematisch Centrum,
Amsterdam
&gt;&gt;&gt; import example
&gt;&gt;&gt; example.fact(4)
24
&gt;&gt;&gt; example.my_mod(23,7)
2
&gt;&gt;&gt; example.cvar.My_variable + 4.5
7.5
</pre></blockquote>
<a name="n17"></a><h3> Shortcuts</h3>
To the truly lazy programmer, one may wonder why we needed the extra interface file at all. As it turns out, we can often do without it. For example, we could also build a Perl5 module by just running SWIG on the C source and specifying a module name as follows<p>
<p>
<blockquote><pre>% swig -perl5 -module example example.c
unix &gt; gcc -c example.c example_wrap.c \
-I/usr/local/lib/perl5/sun4-solaris/5.003/CORE
unix&gt; ld -G example.o example_wrap.o -o example.so
unix &gt; perl5.003
use example;
print example::fact(4), "\n";
print example::my_mod(23,7), "\n";
print $example::My_variable + 4.5, "\n";
&lt;ctrl-d&gt;
24
2
7.5
</pre></blockquote>
<p>
Of course, there are some restrictions as SWIG is not a full C/C++ parser. If you make heavy use of the C preprocessor, complicated declarations, or C++, giving SWIG a raw source file probably isn't going to work very well (in this case, you would probably want to use a separate interface file). <p>
<p>
SWIG also supports a limited form of conditional compilation. If we wanted to make a combination SWIG/C header file, we might do the following :<p>
<p>
<blockquote><pre>/* File : example.h */
#ifdef SWIG
%module example
%include tclsh.i
#endif
extern double My_variable;
extern int fact(int);
extern int my_mod(int n, int m);
</pre></blockquote>
<a name="n18"></a><h3> Documentation generation</h3>
In addition to producing an interface, SWIG also produces documentation. For our simple example, the documentation file may look like this :<p>
<blockquote><pre>
example_wrap.c
[ Module : example, Package : example ]
$My_variable
[ Global : double My_variable ]
fact(n);
[ returns int ]
my_mod(n,m);
[ returns int ]
get_time();
[ returns char * ]
</pre></blockquote>
<p>
C comments can be used to provide additional descriptions. SWIG can even grab these out of C source files in a variety of ways. For example, if we process <tt>example.c</tt> as follows :<p>
<p>
<blockquote><pre>swig -perl5 -Sbefore -module example example.c
</pre></blockquote>
We will get a documentation file that looks like this (with our C comments added) :<p>
<blockquote><pre>
example_wrap.c
[ Module : example, Package : example ]
$My_variable
[ Global : double My_variable ]
fact(n);
[ returns int ]
Compute factorial of n
my_mod(n,m);
[ returns int ]
Compute n mod m
</pre></blockquote>
<a name="n19"></a><h3> Building libraries and modules</h3>
In addition to generating wrapper code, SWIG provides extensive support for handling multiple files and building interface libraries. For example, our <tt>example.i</tt> file, could be used in another interface as follows :<p>
<p>
<blockquote><pre>%module foo
%include example.i // Get definitions from example.i
... Now more declarations ...
</pre></blockquote>
In a large system, an interface might be built from a variety of pieces like this :<p>
<p>
<blockquote><pre>%module package
%include network.i
%include file.i
%include graphics.i
%include objects.i
%include simulation.i
</pre></blockquote>
SWIG comes with a library of existing functions known as the SWIG library. The library contains a mix of language independent and language dependent functionality. For example, the file `<tt>array.i</tt>' provides access to C arrays while the file `<tt>wish.i</tt>' includes specialized code for rebuilding the Tcl wish interpreter. Using the library, you can use existing modules to build up your own personalized environment for building interfaces. If changes are made to any of the components, they will appear automatically the next time SWIG is run. <p>
<a name="n6"></a><h2> C syntax, but not a C compiler</h2>
SWIG uses ANSI C syntax, but is not a full ANSI C compiler. By using C syntax, I hope to make SWIG easy to use with most C programs, easy to learn, and easy to remember. Other tools tend to use a precise interface definition language, but I personally find this approach to be painful. When I want to build an interface to a collection of several hundred C functions, I don't necessarily want to write a special interface definition for each one. Nor do I want to have to go dig up the manual because I can't remember the syntax.<p>
<p>
On the other hand, using C syntax can be ambiguous. For example, if you have the following declaration <p>
<p>
<blockquote><pre>int foo(double *a);
</pre></blockquote>
We don't really know if <tt>a</tt> is an array of some fixed size, a dynamically allocated block of memory, a single value, or an output value of the function. For the most part, SWIG takes a literal approach (<tt>a</tt> is obviously a <tt>double *</tt>) and leaves it up to the user to use the function in a correct manner. Fortunately, there are several ways to help SWIG out using additional directives and "helper" functions. Thus, the input to SWIG is often a mix of C declarations, special directives and hints. Like Perl programming, there is almost always more than one way to do almost anything.<p>
<p>
SWIG does not currently parse every conceivable type of C declaration that it might encounter in a C/C++ file. Many things may be difficult or impossible to integrate with a scripting language (C++ templates for example). Thus, SWIG may not recognize advanced C/C++ constructs. I make no apologies for this--SWIG was designed to access C, but was never intended to magically turn scripting languages into some sort of bizarre C++ interpreter. Of course, SWIG's parser is always being improved so currently unsupported features may be supported in later releases.<p>
<a name="n7"></a><h2> Non-intrusive interface building</h2>
When used as I intended, SWIG requires minimal modification to existing C code. This makes SWIG extremely easy to use with existing packages, but also promotes software reuse and modularity. By making the C code independent of the high level interface, you can change the interface and reuse the code in other applications. In a similar spirit, I don't believe that there is any one "best" scripting language--use whichever one you like (they're all pretty good). There's no real reason why a particular application couldn't support multiple scripting language interfaces to serve different needs (or to have no scripting language interface at all).<p>
<a name="n8"></a><h2> Hands off code generation</h2>
SWIG is designed to produce working code that needs no hand-modification (in fact, if you look at the output, you probably won't want to modify it). Ideally, SWIG should be invoked automatically inside a Makefile just as one would call the C compiler. You should think of your scripting language interface being defined entirely by the input to SWIG, not the resulting output file. While this approach may limit flexibility for hard-core hackers, it allows others to forget about the low-level implementation details. This is my goal.<p>
<a name="n9"></a><h2> Event driven C programming</h2>
By adding a scripting language interface to a program, SWIG encourages an event-driven style of programming (although it may not be immediately obvious). An event driven program basically consists of a large-collection of functions (called callback functions), and an infinite loop that just sits and waits for the user to do something. When the user does something like type a command, hit a key, or move the mouse the program will call a function to perform an operation--this is an event. Of course, unless you've been living in cave for the last 20 years, you've used this kind of approach when running any sort of graphical user interface.<p>
<p>
While you may not be using SWIG to develop a GUI, the underlying concept is the same. The scripting language acts as an event-loop waiting for you to issue commands. Unlike a traditional C application (that may use command line options), there is no longer a fixed sequence of operations. Functions may be issued in any order and at any time. Of course, this flexibility is exactly what we want! <p>
<p>
However, there are a number of things to keep in mind when developing an application with SWIG :<p>
<p>
<ul>
<li>Functions may be called at any time and in any order. It is always a good idea for functions to check their arguments and internal state to see if it's legal to proceed (Not doing so usually results in mysterious crashes later on).
<li>Code should be structured as a collection of independent modules, not a huge mess of interrelated functions and variables (ie. spaghetti code).
<li>Global variables should be used with care.
<li>Careful attention to the naming of variables and functions may be required to avoid namespace conflicts when combining packages.
</ul>
<p>
While it may be hard (or impossible) to address all these problems in a legacy code, I believe that using SWIG encourages all of the above qualities when developing new applications. This results in code that is more reliable, more modular, and easier to integrate into larger packages. By providing a non-intrusive, easy to use tool, it is possible to develop highly reliable event-driven code from the start--not as a hack to be added later. As a final sales pitch, in the initial application for which SWIG was developed, code reliability and flexibility has increased substantially while code size has decreased by more than 25%. I believe this is a good thing.<p>
<a name="n10"></a><h2> Automatic documentation generation</h2>
SWIG makes it very easy to build large interactive C programs, but it can sometimes be hard to remember what C functions are available and how they are called in the scripting language interface. To address this problem, SWIG automatically generates a documentation file in a number of different formats. C comments can be used to provide additional descriptions of each function, and documentation can be grouped into a hierarchy of sections and subsections. The documentation file is intended to provide a reasonable description of the scripting language interface. While it's no competition for a full-blown C code documentation generator, the documentation system can do a reasonable job of documenting an interface.<p>
<a name="n11"></a><h2> Summary</h2>
At this point, you know about 95% of everything you need to know to start using SWIG. First, functions and variables are specified using ANSI C, C++, or Objective-C syntax. These may appear in a separate interface file or you can use a C source file (if it is sufficiently clean). SWIG requires no modifications to existing C code so it's easy to get started. To build a module, use the <tt>swig</tt> command with an appropriate target language option. This generates a C file that you need to compile with the rest of your code and you're ready to go. <p>
<p>
I don't consider there to be a "right" or "wrong" way to use SWIG, although I personally use separate interface files for a variety of reasons :<p>
<p>
<ul>
<li>It helps keep me organized.
<li>It's usually not necessary to wrap every single C function in a program.
<li>SWIG provides a number of directives that I tend to use alot.
<li>Having a special interface file makes it clear where the scripting language interface is defined. If you decide to change something in the interface, it's easy to track down if you have special file.
</ul>
<p>
Of course, your mileage may vary. <p>
<a name="n12"></a><h2> SWIG for Windows and Macintosh</h2>
SWIG has been primarily developed and designed to work with Unix-based applications. However, most of the scripting languages supported by SWIG are available on a variety of other platforms including Windows 95/NT and Macintosh. SWIG generated code is mostly compatible with these versions (and SWIG itself can now run on these platforms). <p>
<a name="n20"></a><h3> SWIG on Windows 95/NT</h3>
The Windows 95/NT port of SWIG (provided by Kevin Butler), is a straightforward translation of the Unix version. At this time it is only known to work with Microsoft Visual C++ 4.x, but there is nothing to prevent its use with other compilers (at least not that I'm aware of). SWIG should be invoked from the MS-DOS prompt in exactly the same manner as in Unix. SWIG can also be used in NMAKE build files and added to Visual C++ projects under the custom build setting. As of this writing, SWIG is known to work with Windows versions of Tcl/Tk, Python, and Perl (including the ActiveWare Perl for Win32 port). SWIG makes extensive use of long filenames, so it is unlikely that the SWIG compiler will operate correctly under Windows 3.1 or DOS (the wrapper code generated by SWIG may compile however).<p>
<a name="n21"></a><h3> SWIG on the Power Macintosh</h3>
A Macintosh port of SWIG is also available, but is highly experimental at this time. It only works on PowerPC based Macintosh systems running System 7 or later. Modules can be compiled with the Metrowerks Code Warrior compiler, but support for other compilers is unknown. Due to the lack of command line options on the Mac, SWIG has been packaged in a Tcl/Tk interface that allows various settings and command line options to be specified with a graphical user interface. Underneath the hood, SWIG is identical to the Unix/Windows version. It recognizes the same set of options and generates identical code. Any SWIG command line option listed in this manual can be given to the Mac version under "Advanced Options" shown in the figure. At this writing, SWIG is only known to support Mac versions of Tcl/Tk. Work on Macintosh versions of Python and Perl is underway.<p>
<p>Click <a href="ch1.2.png">here</a> to see a Macintosh screen shot.<p>
<p>
<p>
<a name="n22"></a><h3> Cross platform woes</h3>
While SWIG and various freely available scripting languages are supported on different platforms, developing cross platform applications with these tools is still immature and filled with pitfalls. In fact, it's probably only recommended for true masochists. Despite this, it's interesting to think about using freely available tools to provide common interfaces to C/C++ code. I believe that SWIG may help, but it is by no means a cross-platform solution by itself. <p>
<a name="n23"></a><h3> How to survive this manual</h3>
This manual was written to support the Unix version of SWIG. However, all of the main concepts and usage of SWIG also apply to the Windows and Macintosh versions. You should be forewarned that most of the examples are Unix-centric and may not compile correctly on other machines. However, most of the examples provided with the SWIG distribution have now been tested under both Unix and Windows-NT. When applicable, I will try to point out incompatibilities, but make no promises... <p>
<p>
<p>
<p><hr>
<address>SWIG 1.1 - Last Modified : Mon Aug 4 10:46:50 1997</address>
</body>
</html>

225
swigweb/Doc1.1/HTML/Library.html
View file

@ -1,225 +0,0 @@
<!-- Published by Quadralay WebWorks HTML Lite 1.5.1 -->
<!-- And munged by Dave's special Python script -->
<html>
<head>
<title>Multiple Files and the SWIG Library</title>
</head>
<body bgcolor="#ffffff">
<a name="n0"></a><h1>4 Multiple files and the SWIG library</h1><p><ul>
<li> <a href="#n1">The %include directive</a>
<li> <a href="#n2">The %extern directive</a>
<li> <a href="#n3">The %import directive</a>
<li> <a href="#n4">Including files on the command line</a>
<li> <a href="#n5">The SWIG library</a>
<li> <a href="#n6">Library example</a>
<li> <a href="#n7">Creating Library Files</a>
<li> <a href="#n8">Working with library files</a>
<li> <a href="#n9">Static initialization of multiple modules</a>
<li> <a href="#n10">More about the SWIG library</a>
</ul>
For increased modularity and convenience, it is usually useful to break an interface specification up into multiple files or modules. SWIG provides a number of features for doing just this.<p>
<a name="n1"></a><h2> The %include directive</h2>
The <tt>%include</tt> directive inserts code from another file into the current interface file. It is primarily used to build a package from a collection of smaller modules. For example :<p>
<p>
<blockquote><pre>// File : interface.i
%module package
%include equations.i
%include graphics.i
%include fileio.i
%include data.i
%include network.c
%include "../Include/user.h"
</pre></blockquote>
<p>
When used in this manner, SWIG will create a single wrapper file containing all of the included functions. <p>
<p>
The <tt>%include</tt> directive can process SWIG interface files, C header files, and C source files (provided they are sufficiently clean). When processing a C source file, SWIG will automatically declare all functions it finds as "extern". Thus, use of a header file may not be required in this case.<p>
<a name="n2"></a><h2> The %extern directive</h2>
The <tt>%extern</tt> directive is like <tt>%include</tt> except that it only scans a file for type and class information. It does not actually wrap anything found in the input file. This directive is primarily used for handling class hierarchies and multiple modules. For example :<p>
<p>
<blockquote><pre>%module derived
%extern baseclass.h // Grab definition of a base class
// Now wrap a derived class
class Derived : public BaseClass {
public:
...
};
</pre></blockquote>
This interface file would grab the member functions and data from a baseclass, but only use them in the specification of a derived class. <tt>%extern</tt> processing of files is also useful for picking up common typedefs and definitions in a large package.<p>
<a name="n3"></a><h2> The %import directive</h2>
The <tt>%extern</tt> directive is used to gather declarations from files that you don't want to wrap into an interface. Unfornunately, the exact role of these files is not always clear. They could just contain definitions, or they might correspond to an entrirely different SWIG module. The <tt>%import</tt> directive is a stronger version of <tt>%extern</tt> that tells SWIG that all of the declarations in the file are indeed, in an entirely different module. This information may affect the code generated by various language modules since they will have a better idea of where things are defined and how they are to be used.<p>
<a name="n4"></a><h2> Including files on the command line</h2>
Much like the C or C++ compiler, SWIG can also include library files on the command line using the <tt>-l</tt> option as shown<p>
<p>
<blockquote><pre>
# Include a library file at compile time
% swig -tcl -lwish.i interface.i
</pre></blockquote>
This approach turns out to be particularly useful for debugging and building extensions to different kinds of languages. When libraries are specified in this manner, they are included after all of the declarations in <tt>interface.i</tt> have been wrapped. Thus, this does not work if you are trying to include common declarations, typemaps, and other files.<p>
<a name="n5"></a><h2> The SWIG library </h2>
SWIG comes with a library of functions that can be used to build up more complex interfaces. As you build up a collection of modules, you may also find yourself with a large number of interface files. While the <tt>%include</tt> directive can be used to insert files, it also searches the files installed in the SWIG library (think of this as the SWIG equivalent of the C library). When you use <tt>%include</tt>, SWIG will search for the file in the following order :<p>
<p>
<ul>
<li>The current directory
<li>Directories specified with the -I option
<li>.<tt>/swig_lib</tt>
<li><tt>/usr/local/lib/swig_lib</tt> (or wherever you installed SWIG)
</ul>
<p>
Within each directory, you can also create subdirectories for each target language. If found, SWIG will search these directories first, allowing the creation of language-specific implementations of a particular library file.<p>
<p>
You can override the location of the SWIG library by setting the <tt>SWIG_LIB</tt> environment variable.<p>
<a name="n6"></a><h2> Library example</h2>
The SWIG library is really a repository of "useful modules" that can be used to build better interfaces. To use a library file, you can simply use the <tt>%include </tt>directive with the name of a library file. For example :<p>
<p>
<blockquote><pre>%module example
%include pointer.i // Grab the SWIG pointer library
// a+b --&gt; c
extern double add(double a, double b, double *c);
</pre></blockquote>
In this example, we are including the SWIG pointer library that adds functions for manipulating C pointers. These added functions become part of your module that can be used as needed. For example, we can write a Tcl script like this that involves both the <tt>add()</tt> function and two functions from the <tt>pointer.i</tt> library :<p>
<p>
<blockquote><pre>set c [ptrcreate double 0] ;# Create a double * for holding the result
add 4 3.5 $c ;# Call our C function
puts [ptrvalue $c] ;# Print out the result
</pre></blockquote>
<a name="n7"></a><h2> Creating Library Files</h2>
It is easy to create your own library files. To illustrate the process, we consider two different library files--one to build a new <tt>tclsh</tt> program, and one to add a few memory management functions.<p>
<a name="n11"></a><h3> tclsh.i</h3>
To build a new <tt>tclsh</tt> application, you need to supply a <tt>Tcl_AppInit()</tt> function. This can be done using the following SWIG interface file (simplified somewhat for clarity) :<p>
<blockquote><pre>
// File : tclsh.i
%{
#if TCL_MAJOR_VERSION == 7 &amp;&amp; TCL_MINOR_VERSION &gt;= 4
int main(int argc, char **argv) {
Tcl_Main(argc, argv, Tcl_AppInit);
return(0);
}
#else
extern int main();
#endif
int Tcl_AppInit(Tcl_Interp *interp){
int SWIG_init(Tcl_Interp *);
if (Tcl_Init(interp) == TCL_ERROR)
return TCL_ERROR;
/* Now initialize our functions */
if (SWIG_init(interp) == TCL_ERROR)
return TCL_ERROR;
return TCL_OK;
}
%}
</pre></blockquote>
In this case, the entire file consists of a single code block. This code will be inserted directly into the resulting wrapper file, providing us with the needed <tt>Tcl_AppInit()</tt> function.<p>
<a name="n12"></a><h3> malloc.i</h3>
Now suppose we wanted to write a file <tt>malloc.i</tt> that added a few memory management functions. We could do the following :<p>
<p>
<blockquote><pre>// File : malloc.i
%{
#include &lt;malloc.h&gt;
%}
%typedef unsigned int size_t
void *malloc(size_t nbytes);
void *realloc(void *ptr, size_t nbytes);
void free(void *);
</pre></blockquote>
<p>
In this case, we have a general purpose library that could be used whenever we needed access to the <tt>malloc()</tt> functions. Since this interface file is language independent, we can use it anywhere.<p>
<a name="n13"></a><h3> Placing the files in the library</h3>
While both of our examples are SWIG interface files, they are quite different in functionality since <tt>tclsh.i</tt> would only work with Tcl while <tt>malloc.i</tt> would work with any of the target languages. Thus, we should put these files into the SWIG library as follows :<p>
<blockquote><pre><tt>
./swig_lib/malloc.i
./swig_lib/tcl/tclsh.i
</tt></pre></blockquote>
<p>
When used in other interface files, this allows us to use <tt>malloc.i</tt> with any target language while <tt>tclsh.i</tt> will only be accessible if creating for wrappers for Tcl (ie. when creating a Perl5 module, SWIG will not look in the <tt>tcl</tt> subdirectory.<p>
<p>
It should be noted that language specific libraries can mask general libraries. For example, if you wanted to make a Perl specific modification to <tt>malloc.i</tt>, you could make a special version and call it <tt>./swig_lib/perl5/malloc.i</tt>. When using Perl, you'd get this version, while all other target languages would use the general purpose version.<p>
<a name="n8"></a><h2> Working with library files</h2>
There are a variety of additional methods for working with files in the SWIG library described next.<p>
<a name="n14"></a><h3> Wrapping a library file</h3>
If you would like to wrap a file in the SWIG library, simply give SWIG the name of the appropriate library file on the command line. For example :<p>
<p>
<blockquote><pre>unix &gt; swig -python pointer.i
</pre></blockquote>
If the file <tt>pointer.i</tt> is not in the current directory, SWIG will look it up in the library, generate wrapper code, and place the output in the current directory. This technique can be used to quickly make a module out of a library file regardless of where you are working.<p>
<a name="n15"></a><h3> Checking out library files</h3>
At times, it is useful to check a file out of the library and copy it into the working directory. This allows you to modify the file or to simply retrieve useful files. To check a file out of the library, run SWIG as follows :<p>
<p>
<blockquote><pre>unix &gt; swig -co -python array.i
array.i checked out from the SWIG library
unix &gt;
</pre></blockquote>
The library file will be placed in the current directory unless a file with the same name already exists (in which case nothing is done). <p>
<p>
The SWIG library is not restricted to interface files. Suppose you had a cool Perl script that you liked to use alot. You could place this in the SWIG library. Now whenever you wanted to use it, you could retrieve it by issuing :<p>
<p>
<blockquote><pre>unix &gt; swig -perl5 -co myscript.pl
myscript.pl checked out from the SWIG library
</pre></blockquote>
Support files can also be checked out within an interface file using the <tt>%checkout</tt> directive.<p>
<p>
<blockquote><pre>%checkout myscript.pl
</pre></blockquote>
This will attempt to copy the file <tt>myscript.pl</tt> to the current directory when SWIG is run. If the file already exists, nothing is done.<p>
<a name="n16"></a><h3> The world's fastest way to write a Makefile</h3>
Since the SWIG library is not restricted to SWIG interface files, it can be used to hold other kinds of useful files. For example, if you need a quick Makefile for building Tcl extensions, type the following:<p>
<blockquote><pre>
unix&gt; swig -tcl -co Makefile
Makefile checked out from the SWIG library
</pre></blockquote>
During installation, SWIG creates a collection of preconfigured Makefiles for various scripting languages. If you need to make a new module, just check out one of these Makefiles, make a few changes, and you should be ready to compile and extension for your system.<p>
<a name="n17"></a><h3> Checking in library files</h3>
It is also possible to check files into the SWIG library. If you've made an interesting interface that you would like to keep around, simply type :<p>
<p>
<blockquote><pre>unix &gt; swig -ci -python cool.i
</pre></blockquote>
and the file `<tt>cool.i</tt>' will be placed in the Python section of the library. If your interface file is general purpose, you can install it into the general library as follows :<p>
<p>
<blockquote><pre>unix &gt; swig -ci ../cool.i
</pre></blockquote>
When files are checked in, they are placed into the directory defined by the <tt>SWIG_LIB</tt> variable that was used during SWIG compilation or the <tt>SWIG_LIB</tt> environment variable (if set). If you don't know what the value of this variable is, type the following to display its location.<p>
<p>
<blockquote><pre>unix &gt; swig -swiglib
/usr/local/lib/swig_lib
unix &gt;
</pre></blockquote>
<p>
In order to check files into the library, you must have write permission on the library directory. For this reason, one of the primary uses for the <tt>-ci</tt> option is to provide a simple mechanism for installing SWIG extensions. If these extensions need to install library files, that can be done by simply running SWIG.<p>
<a name="n9"></a><h2> Static initialization of multiple modules</h2>
When using static linking, some language modules allow multiple modules to be initialized as follows :<p>
<p>
<blockquote><pre>%module package, equations, graphics, fileio, data, network, user
... More declarations ...
</pre></blockquote>
The module list can contain SWIG generated modules or third-party applications. Refer to the appropriate language chapter for a detailed description of this feature.<p>
<a name="n10"></a><h2> More about the SWIG library</h2>
Full documentation about the SWIG library is included in the SWIG source distribution. In fact, the documentation is automatically generated by SWIG, which leads us to the next section...<p>
<p>
<p><hr>
<address>SWIG 1.1 - Last Modified : Mon Aug 4 10:46:54 1997</address>
</body>
</html>

1919
swigweb/Doc1.1/HTML/Perl5.html
View file

File diff suppressed because it is too large Load diff

83
swigweb/Doc1.1/HTML/Preface.html
View file

@ -1,83 +0,0 @@
<!-- Published by Quadralay WebWorks HTML Lite 1.5.1 -->
<!-- And munged by Dave's special Python script -->
<html>
<head>
<title>Preface</title>
</head>
<body bgcolor="#ffffff">
<a name="n0"></a><h1> Preface</h1><p><ul>
<li> <a href="#n1">Introduction</a>
<li> <a href="#n2">SWIG resources</a>
<li> <a href="#n3">About this manual</a>
<li> <a href="#n4">Credits</a>
<li> <a href="#n5">What's new?</a>
<li> <a href="#n6">Bug reports</a>
<li> <a href="#n7">SWIG is free</a>
</ul>
<a name="n1"></a><h2> Introduction</h2>
SWIG is a tool for solving problems.<p>
<p>
More specifically, SWIG is a simple tool for building interactive C, C++, or Objective-C programs with common scripting languages such as Tcl, Perl, and Python. Of course, more importantly, SWIG is a tool for making C programming more enjoyable and promoting laziness (an essential feature). SWIG is not part of an overgrown software engineering project, an attempt to build some sort of monolithic programming environment, or an attempt to force everyone to rewrite all of their code (ie. code reuse). In fact, none of these things have ever been a priority.<p>
<p>
SWIG was originally developed in the Theoretical Physics Division at Los Alamos National Laboratory for building interfaces to large materials science research simulations being run on the Connection Machine 5 supercomputer. In this environment, we were faced with the problems of working with huge amounts of data, complicated machines, and constantly changing code. As scientists, we needed a mechanism for building interactive programs that was extremely easy to use, could keep pace with code that was constantly changing, and didn't get in the way of the real problems that were being solved. Mainly, we just wanted to "cut the crap" and work on the real problems at hand.<p>
<p>
While SWIG was originally developed for scientific applications, it has become a general purpose tool that is being used in an increasing variety of other computing applications--in fact almost anything where C programming is involved. Some of the application areas that I am aware of include scientific applications, visualization, databases, semiconductor CAD, remote sensing and distributed objects. Development has been pragmatic in nature--features have been added to address interesting problems as they arise. Most of the really cool stuff has been contributed or suggested by SWIG's users. There has never really been a "grand" design to SWIG other than the goal of creating a practical programming tool that could be used in other applications.<p>
<a name="n2"></a><h2> SWIG resources</h2>
The official location of SWIG related material is<p>
<blockquote><pre>
http://www.cs.utah.edu/~beazley/SWIG
</pre></blockquote>
<p>
This site contains the latest version of the software, users guide, and information regarding bugs, installation problems, and implementation tricks. The latest version of the software and related files are also available via anonymous ftp at <p>
<p>
<blockquote><pre>ftp://ftp.cs.utah.edu/pub/beazley/SWIG
</pre></blockquote>
<p>
You can also subscribe to the SWIG mailing list by sending a message with the text "subscribe swig" to <p>
<p>
<blockquote><pre>majordomo@cs.utah.edu
</pre></blockquote>
<p>
The mailing list often discusses some of the more technical aspects of SWIG along with information about beta releases and future work.<p>
<a name="n3"></a><h2> About this manual</h2>
This manual has been written in parallel with the development of SWIG because I hate black boxes and I don't like using software that is poorly documented. This manual attempts to describe all aspects of SWIG and how it can be used to solve interesting problems. Don't let the size scare you, SWIG can be quite easy to use. However, covering automatic code generation for four different scripting languages takes abit of explanation. SWIG can do quite a few interesting things that might not be so obvious so I hope that the manual can shed some light on many of these issues. The manual also serves as a general reference describing many of SWIG's implementation issues (I use the manual quite regularly myself).<p>
<a name="n8"></a><h3> Prerequisites</h3>
This manual assumes that you are interested in writing interactive C programs and that you have at least heard of scripting languages such as Tcl, Python, and Perl. A detailed knowledge of these scripting languages is not required although some familiarity certainly won't hurt. No prior experience with building C extensions to these languages is required---after all, this is what SWIG allows you to do automatically. However, I do assume that you are reasonably familiar with the use of compilers, linkers, and makefiles since making scripting language extensions is somewhat more complicated than writing a normal C program (although not significantly more complex).<p>
<a name="n9"></a><h3> Organization of this manual</h3>
The first few chapters of this manual describe SWIG in general and provide an overview of its capabilities. The remaining chapters are devoted to specific SWIG language modules and are self contained. Thus, if you are using SWIG to build Python interfaces, you can skip right to that chapter and find just about everything you need to know. So, in a sense, you are really getting 3 or 4 manuals in one.<p>
<a name="n10"></a><h3> How to avoid reading the manual</h3>
If you hate reading manuals, glance at the "Introduction" which contains a few simple examples and the overall philosophy. These examples contain about 95% of everything you need to know to use SWIG. After that, simply use the language-specific chapters for reference. The SWIG distribution also comes with a large directory of examples that illustrate how to do most kinds of things. <p>
<a name="n4"></a><h2> Credits</h2>
This work would certainly not be possible without the support of many people. I would like to acknowledge Peter Lomdahl, Brad Holian, Shujia Zhou, Niels Jensen, and Tim Germann at Los Alamos National Laboratory for allowing me to pursue this project and for being the first users. Patrick Tullmann at the University of Utah suggested the idea of automatic documentation generation. John Schmidt and Kurtis Bleeker at the University of Utah tested out the early versions. I'd also like to acknowledge Chris Johnson and the Scientific Computing and Imaging Group at the University of Utah for their continued support. John Buckman, Larry Virden, and Tom Schwaller provided valuable input on the first releases and improving the portability of SWIG. David Fletcher and Gary Holt have provided a great deal of input on improving SWIG's Perl5 implementation. I'd also like to thank Kevin Butler for his valuable input and contribution of a Windows NT port. Finally, I'd like to acknowledge all of the users who have braved the first few releases and have been instrumental in suggesting way to make SWIG more fun to use than I ever imagined possible.<p>
<a name="n5"></a><h2> What's new?</h2>
The following significant features are new in version 1.1<p>
<p>
<ul>
<li>Support for typemaps (a mechanism for customizing SWIG).
<li>Multiple inheritance.
<li>Default/optional arguments.
<li>Perl5 shadow classes.
<li>Tcl8.0 module (uses the native Tcl8 object interface).
<li>An entirely new documentation system.
<li>Limited support for nested structures.
<li>New object oriented Tcl interface.
<li>User defined exception handling.
<li>New directives for better library support (%inline, %extern %import)
<li>Objective-C support.
<li>Support for Windows-NT and Macintosh.
<li>Lots of minor bug fixes to almost everything.
</ul>
<p>
This release should be backwards compatible with interface files generated for SWIG 1.0. However, many things have changed in the SWIG C++ API so special purpose SWIG C++ extensions written for 1.0 will need to be modified.<p>
<a name="n6"></a><h2> Bug reports</h2>
While every attempt has been made to make SWIG bug-free, occasionally bugs will arrise. To report a bug, send mail to the SWIG mailing list at <tt>swig@cs.utah.edu</tt>. In your message, be as specific as possible, including (if applicable), error messages, tracebacks (if a core dump occurred), corresponding portions of the SWIG interface file used, and any important pieces of the SWIG generated wrapper code. I attempt to respond to all bug reports, but I can only fix bugs if I know about them.<p>
<a name="n7"></a><h2> SWIG is free</h2>
SWIG is a completely free package that you can use in any manner that you wish, including modification, redistribution, and use in commercial products. The only restriction on its use is that redistributions of the SWIG compiler should reproduce the SWIG copyright notice in the supporting documentation. The code generated by SWIG can be redistributed in any manner. On a more personal note, if you've used SWIG to make something cool, I'd like to find out more about it so that I can make SWIG better (and to satisfy my curiosity).<p>
<p><hr>
<address>SWIG 1.1 - Last Modified : Mon Aug 4 10:46:49 1997</address>
</body>
</html>

2334
swigweb/Doc1.1/HTML/Python.html
View file

File diff suppressed because it is too large Load diff

1586
swigweb/Doc1.1/HTML/SWIG.html
View file

File diff suppressed because it is too large Load diff

255
swigweb/Doc1.1/HTML/Scripting.html
View file

@ -1,255 +0,0 @@
<!-- Published by Quadralay WebWorks HTML Lite 1.5.1 -->
<!-- And munged by Dave's special Python script -->
<html>
<head>
<title>Scripting Languages</title>
</head>
<body bgcolor="#ffffff">
<a name="n0"></a><h1>2 Scripting Languages</h1><p><ul>
<li> <a href="#n1">The two language view of the world</a>
<li> <a href="#n2">How does a scripting language talk to C?</a>
<li> <a href="#n3">Building scripting language extensions</a>
<li> <a href="#n4">Shared libraries and dynamic loading</a>
</ul>
SWIG is all about using scripting languages with C/C++ to make flexible applications. This chapter provides a brief overview of several concepts and important aspects of this interface. Many of SWIG's potential users may not have considered using a scripting language before, so I hope that this chapter can provide a little motivation.<p>
<a name="n1"></a><h2> The two language view of the world</h2>
By developing SWIG, I am trying to build systems that are loosely structured as follows :<p>
<p><center><img src="ch2.1.png"></center><p>
<p>
<p>
A real application might look more like this :<p>
<p><center><img src="ch2.2.png"></center><p>
<p>
In either case, we are interested in controlling a C/C++ program with a scripting language interface. Our interface may be for a small group of functions or a large collection of C libraries for performing a variety of tasks. In this model, C functions are turned into commands. To control the program, the user now types these commands or writes scripts to perform a particular operation. If you have used commercial packages such as MATLAB or IDL, it is a very similar model--you execute commands and write scripts, yet most of the underlying functionality is still written in C or Fortran for performance.<p>
<p>
The two-language model of computing is extremely powerful because it exploits the strengths of each language. C/C++ can be used for maximal performance and complicated systems programming tasks. Scripting languages can be used for rapid prototyping, interactive debugging, scripting, and access to high-level data structures such as lists, arrays, and hash tables.<p>
<a name="n5"></a><h3> Will scripting languages make my C program inefficient?</h3>
One of the criticisms of scripting languages is that they are interpreted and slow. No doubt about it, a scripting language will always run much slower than C. However, if you are using a scripting language to control a big C program, most of your functionality is still written in C and still fast. Thus, there is really no difference between writing the following in C <p>
<p>
<blockquote><pre>for (i = 0; i &lt; 1000; i++) {
call a bunch of C functions to do something
}
</pre></blockquote>
<p>
or writing the same thing in Python :<p>
<p>
<blockquote><pre>for i in range(0,1000):
call a bunch of C functions to do something
</pre></blockquote>
Most of the time is still spent in the underlying C functions. Of course, you wouldn't want to write the inner loop of a matrix multiply in a scripting language, but you already knew this. It is also worth noting that reimplementing certain operations in C might not lead to better performance. For example, Perl is highly optimized for text-processing operations. Most of these operations are already implemented in C (underneath the hood) so in certain cases, using a scripting language may actually be faster than an equivalent implementation in C. <p>
<a name="n6"></a><h3> Will adding a scripting language to my C program make it unmanagable?</h3>
A fear among some users is that by adding a second language, you will end up with a package that is hard to maintain and use. I believe that there are two answers to this question. If you find yourself modifying the C code to fit it into a specific scripting language, then it will be difficult to maintain. By doing this, you will lock yourself into a particular language. If that language changes or disappears off the face of the earth, then you will be left with serious maintenance problems. On the flip side of the coin, a non-invasive tool like SWIG can build interfaces without requiring language-specific modifications to the underlying C code. If the scripting language changes, it is easy to update the resulting interface. If you decide that you want to scrap the whole interface scheme and try something else, you still have a clean set of C libraries<p>
<p>
My personal experience has been that adding a scripting language to a C program makes the C program more managable! You are encouraged to think about how your C program is structured and how you want things to work. In every program in which I have added a scripting interface, the C code has actually decreased in size, improved in reliability, become easier to maintain, while becoming more functional and flexible than before.<p>
<a name="n2"></a><h2> How does a scripting language talk to C?</h2>
Scripting languages are built around a small parser that reads and executes statements on the fly as your program runs. Within the parser, there is a mechanism for executing commands or accessing variables. However, in order to access C functions and variables, it is necessary to tell the parser additional information such as the name of the function, what kind of arguments does it take, and what to do when it is called. Unfortunately, this process can be extremely tedious and technical. SWIG automates the process and allows you to forget about it. In any case, it's probably a good idea to know what's going on under the hood.<p>
<a name="n7"></a><h3> Wrapper functions</h3>
Suppose you have an ordinary C function like this :<p>
<p>
<blockquote><pre>int fact(int n) {
if (n &lt;= 1) return 1;
else return n*fact(n-1);
}
</pre></blockquote>
<p>
In order to access this function from a scripting language, it is necessary to write a special "wrapper" function that serves as the glue between the scripting language and the underlying C function. A wrapper function must do three things :<p>
<p>
<ul>
<li>Gather function arguments and make sure they are valid.
<li>Call the C function.
<li>Convert the return value into a form recognized by the scripting language.
</ul>
<p>
As an example, the Tcl wrapper function for the <tt>fact()</tt> function above example might look like the following : <p>
<blockquote><pre>
int wrap_fact(ClientData clientData, Tcl_Interp *interp,
int argc, char *argv[]) {
int _result;
int _arg0;
if (argc != 2) {
interp-&gt;result = "wrong # args";
return TCL_ERROR;
}
_arg0 = atoi(argv[1]);
_result = fact(_arg0);
sprintf(interp-&gt;result,"%d", _result);
return TCL_OK;
}
</pre></blockquote>
Once we have created a wrapper function, the final step is to tell the scripting language about our new function. This is usually done in an initialization function called by the language when our module is loaded. For example, adding the above function to the Tcl interpreter would require code like the following :<p>
<p>
<blockquote><pre>int Wrap_Init(Tcl_Interp *interp) {
Tcl_CreateCommand(interp, "fact", wrap_fact, (ClientData) NULL,
(Tcl_CmdDeleteProc *) NULL);
return TCL_OK;
}
</pre></blockquote>
<p>
When executed, Tcl will now have a new command called "<tt>fact</tt>" that you can use like any other Tcl command.<p>
<p>
While the process of adding a new function to Tcl has been illustrated, the procedure is almost identical for Perl and Python. Both require special wrappers to be written and both need additional initialization code. Only the specific details are different.<p>
<a name="n8"></a><h3> Variable linking</h3>
Variable linking is a slightly more difficult problem. The idea here is to map a C/C++ global variable into a variable in the scripting language (we are "linking" a variable in the scripting language to a C variable). For example, if you have the following variable:<p>
<p>
<blockquote><pre>double My_variable = 3.5;
</pre></blockquote>
<p>
It would be nice to be able to access it from a script as follows (shown for Perl):<p>
<p>
<blockquote><pre>$a = $My_variable * 2.3;
</pre></blockquote>
<p>
Unfortunately, the process of linking variables is somewhat problematic and not supported equally in all scripting languages. There are two primary methods for approaching this problem:<p>
<p>
<ul>
<li>Direct access. Tcl provides a mechanism for directly accessing C <tt>int</tt>, <tt>double</tt>, and <tt>char</tt> * datatypes as Tcl variables. Whenever these variables are used in a Tcl script, the interpreter will directly access the corresponding C variable. In order for this to work, one must first "register" the C variables with the Tcl interpreter. While this approach is easy to support it is also somewhat problematic. Not all C datatypes are supported, and having Tcl directly manipulate your variables in its native representation could be potentially dangerous.
<li>Access through function calls. Languages such as Perl and Python can access global variables using a function call mechanism. Rather than allowing direct access, the idea is to provide a pair of set/get functions that set or get the value of a particular variable. In many cases, this mechanism may be completely hidden. For example, it is possible to create a magical Perl variable that looks and feels just like a normal Perl variable, but is really mapped into a C variable via a pair of set/get functions. The advantage of this approach is that it is possible to support almost all C datatypes. The disadvantage is that it introduces alot of complexity to the wrapper code as it is now necessary to write a pair of C functions for every single global variable.
</ul>
<p>
SWIG supports both styles of variable linking although the latter is more common. In some cases, a hybrid approach is taken (for example, the Tcl module will create a pair of set/get functions if it encounters a datatype that Tcl can't support). Fortunately, global variables are relatively rare when working with modular code.<p>
<a name="n9"></a><h3> Constants</h3>
Constants can easily be created by simply creating a new variable in the target language with the appropriate value. Unfortunately, this can have the undesirable side-effect of making the constant non-constant. As a result, a somewhat better (although perhaps inefficient) method of creating constants is to install them as read-only variables. SWIG tends to prefer this approach.<p>
<a name="n10"></a><h3> Structures and classes</h3>
Most scripting languages have trouble directly dealing with C structures and C++ classes. This is because the use of structures is inherently C dependent and it doesn't always map well into a scripting language environment. Many of these problems are simply due to data representation issues and differences in the way C and a scripting language might represent integers, floats, strings, and so on. Other times, the problem is deeper than that--for example, what does it mean (if anything) to try and use C++ inheritance from Perl?<p>
<p>
Dealing with objects is a tough problem that many people are looking at. Packages such as CORBA and ILU are primarily concerned with the representation of objects in a portable manner. This allows objects to be used in distributed systems, used with different languages and so on. SWIG is not concerned with the representation problem, but rather the problem of accessing and using C/C++ objects from a scripting language (in fact SWIG has even been used in conjunction with CORBA-based systems).<p>
<p>
To provide access, the simplist approach is to transform a structure into a collection of accessor functions. For example :<p>
<p>
<blockquote><pre>struct Vector {
Vector();
~Vector();
double x,y,z;
};
</pre></blockquote>
can be transformed into the following set of functions :<p>
<p>
<blockquote><pre>Vector *new_Vector();
void delete_Vector(Vector *v);
double Vector_x_get(Vector *v);
double Vector_y_get(Vector *v);
double Vector_y_get(Vector *v);
void Vector_x_set(Vector *v, double x);
void Vector_y_set(Vector *v, double y);
void Vector_z_set(Vector *v, double z);
</pre></blockquote>
When accessed in Tcl, the functions could be used as follows :<p>
<p>
<blockquote><pre>% set v [new_Vector]
% Vector_x_set $v 3.5
% Vector_y_get $v
% delete_Vector $v
% ...
</pre></blockquote>
<p>
The accessor functions provide a mechanism for accessing a real C/C++ object. Since all access occurs though these function calls, Tcl does not need to know anything about the actual representation of a <tt>Vector</tt>. This simplifies matters considerably and steps around many of the problems associated with objects--in fact, it lets the C/C++ compiler do most of the work.<p>
<a name="n11"></a><h3> Shadow classes</h3>
As it turns out, it is possible to use the low-level accessor functions above to create something known as a "shadow" class. In a nutshell, a "shadow class" is a funny kind of object that gets created in a scripting language to access a C/C++ class (or struct) in a way that looks like the original structure (that is, it "shadows" the real C++ class). Of course, in reality, it's just a slick way of accessing objects that is more natural to most programmers. For example, if you have the following C definition :<p>
<blockquote><pre>
class Vector {
public:
Vector();
~Vector();
double x,y,z;
};
</pre></blockquote>
<p>
A shadow classing mechanism would allow you to access the structure in a natural manner. For example, in Python, you might do the following,<p>
<p>
<blockquote><pre>&gt;&gt;&gt; v = Vector()
&gt;&gt;&gt; v.x = 3
&gt;&gt;&gt; v.y = 4
&gt;&gt;&gt; v.z = -13
&gt;&gt;&gt; ...
&gt;&gt;&gt; del v
</pre></blockquote>
<p>
while in Perl5, it might look like this :<p>
<blockquote><pre>
$v = new Vector;
$v-&gt;{x} = 3;
$v-&gt;{y} = 4;
$v-&gt;{z} = -13;
</pre></blockquote>
and in Tcl :<p>
<blockquote><pre>
Vector v
v configure -x 3 -y 4 -z 13
</pre></blockquote>
When shadow classes are used, two objects are at really work--one in the scripting language, and an underlying C/C++ object. Operations affect both objects equally and for all practical purposes, it appears as if you are simply manipulating a C/C++ object. However, the introduction of additional "objects" can also produce excessive overhead if working with huge numbers of objects in this manner. Despite this, shadow classes turn out to be extremely useful. The actual implementation is covered later.<p>
<a name="n3"></a><h2> Building scripting language extensions</h2>
The final step in using a scripting language with your C/C++ application is adding your extensions to the scripting language itself. Unfortunately, this almost always seems to be the most difficult part. There are two fundamental approaches for doing this. First, you can build an entirely new version of the scripting language interpreter with your extensions built into it. Alternatively, you can build a shared library and dynamically load it into the scripting language as needed. Both approachs are described below :<p>
<a name="n12"></a><h3> Static linking</h3>
With static linking you rebuild the scripting language interpreter with extensions. The process usually involves compiling a short main program that adds your customized commands to the language and starts the interpreter. You then link your program with a library to produce a new executable. When using static linking, SWIG will provide a <tt>main()</tt> program for you so you usually just have to compile as follows (shown for Tcl) :<p>
<p>
<blockquote><pre>unix &gt; swig -tcl -ltclsh.i example.i
Generating wrappers for Tcl.
unix &gt; gcc example.c example_wrap.c -I/usr/local/include \
-L/usr/local/lib -ltcl -lm -o my_tclsh
</pre></blockquote>
<tt>my_tclsh</tt> is a new executable containing the Tcl intepreter. <tt>my_tclsh</tt> will be exactly the same as tclsh except with your new commands added to it. When invoking SWIG, the <tt>-ltclsh.i</tt> option includes support code needed to rebuild the <tt>tclsh</tt> application. <p>
<p>
Virtually all machines support static linking and in some cases, it may be the only way to build an extension. The downside to static linking is that you can end up with a large executable. In a very large system, the size of the executable may be prohibitively large.<p>
<a name="n4"></a><h2> Shared libraries and dynamic loading</h2>
An alternative to static linking is to build a shared library. With this approach, you build a shared object file containing only the code related to your module (on Windows, this is the same as building a DLL). Unfortunately the process of building these modules varies on every single machine, but the procedure for a few common machines is show below :<p>
<p>
<blockquote><pre># 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
# Build a shared library for Irix
gcc -c example.c example_wrap.c -I/usr/local/include
ld -shared example.o example_wrap.o -o example.so
# Build a shared library for Linux
gcc -fpic -c example.c example_wrap.c -I/usr/local/include
gcc -shared example.o example_wrap.o -o example.so
</pre></blockquote>
To use your shared library, you simply use the corresponding command in the scripting language (load, import, use, etc...). This will import your module and allow you to start using it. <p>
<p>
When working with C++ codes, the process of building shared libraries is more difficult--primarily due to the fact that C++ modules may need additional code in order to operate correctly. On most machines, you can build a shared C++ module by following the above procedures, but changing the link line to the following :<p>
<p>
<blockquote><pre>c++ -shared example.o example_wrap.o -o example.so
</pre></blockquote>
<p>
The advantages to dynamic loading is that you can use modules as they are needed and they can be loaded on the fly. The disadvantage is that dynamic loading is not supported on all machines (although support is improving). The compilation process also tends to be more complicated than what might be used for a typical C/C++ program.<p>
<a name="n13"></a><h3> Linking with shared libraries</h3>
When building extensions as shared libraries, it is not uncommon for your extension to rely upon other shared libraries on your machine. In 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 :<p>
<p>
<blockquote><pre>&gt;&gt;&gt; import graph
Traceback (innermost last):
File "&lt;stdin&gt;", line 1, in ?
File "/home/sci/data1/beazley/graph/graph.py", line 2, in ?
import graphc
ImportError: 1101:/home/sci/data1/beazley/bin/python: rld: Fatal Error: cannot
successfully map soname 'libgraph.so' under any of the filenames /usr/lib/libgraph.so:/
lib/libgraph.so:/lib/cmplrs/cc/libgraph.so:/usr/lib/cmplrs/cc/libgraph.so:
&gt;&gt;&gt;
</pre></blockquote>
<p>
What this error means is that the extension module created by SWIG depends upon a shared library called "<tt>libgraph.so</tt>" that the system was unable to locate. To fix this problem, there are a few approaches you can take.<p>
<p>
<ul>
<li>Set the UNIX environment variable <tt>LD_LIBRARY_PATH</tt> to the directory where shared libraries are located before running Python.
<li>Link your extension and explicitly tell the linker where the required libraries are located. Often times, this can be done with a special linker flag such as <tt>-R</tt>, <tt>-rpath</tt>, etc... This is not implemented in a standard manner so read the man pages for your linker to find out more about how to set the search path for shared libraries.
<li>Put shared libraries in the same directory as the executable. This technique is sometimes required for correct operation on non-Unix platforms.
</ul>
<p>
With a little patience and after some playing around, you can usually get things to work. Afterwards, building extensions becomes alot easier.<p>
<p>
<p><hr>
<address>SWIG 1.1 - Last Modified : Mon Aug 4 10:46:50 1997</address>
</body>
</html>

2048
swigweb/Doc1.1/HTML/Tcl.html
View file

File diff suppressed because it is too large Load diff

733
swigweb/Doc1.1/HTML/Typemaps.html
View file

@ -1,733 +0,0 @@
<!-- Published by Quadralay WebWorks HTML Lite 1.5.1 -->
<!-- And munged by Dave's special Python script -->
<html>
<head>
<title>Pointers, Constraints, and Typemaps</title>
</head>
<body bgcolor="#ffffff">
<a name="n0"></a><h1>6 Pointers, Constraints, and Typemaps</h1><p><ul>
<li> <a href="#n1">Introduction</a>
<li> <a href="#n2">The SWIG Pointer Library</a>
<li> <a href="#n3">Introduction to typemaps</a>
<li> <a href="#n4">Managing input and output parameters</a>
<li> <a href="#n5">Applying constraints to input values</a>
<li> <a href="#n6">Writing new typemaps</a>
<li> <a href="#n7">Common typemap methods</a>
<li> <a href="#n8">Writing typemap code</a>
<li> <a href="#n9">Typemaps for handling arrays</a>
<li> <a href="#n10">Typemaps and the SWIG Library</a>
<li> <a href="#n11">Implementing constraints with typemaps</a>
<li> <a href="#n12">Typemap examples</a>
<li> <a href="#n13">How to break everything with a typemap</a>
<li> <a href="#n14">Typemaps and the future</a>
</ul>
<a name="n1"></a><h2> Introduction</h2>
For most applications, SWIG's treatment of basic datatypes and pointers is enough to build an interface. However, in certain cases, it is desirable to change SWIG's treatment of particular datatypes. For example, we may want a <tt>char ** </tt>to act like a list of strings instead of a pointer. In another instance, we may want to tell SWIG that <tt>double *result</tt> is the output value of a function. Similarly, we might want to map a datatype of <tt>float[4]</tt> into a 4 element tuple. This chapter describes advanced methods for managing pointers, arrays, and complex datatypes. It also describes how you can customize SWIG to handle new kinds of objects and datatypes.<p>
<a name="n2"></a><h2> The SWIG Pointer Library</h2>
If your interface involves C pointers, chances are you will need to work with these pointers in some way or another. The SWIG pointer library provides a collection of useful methods for manipulating pointers. To use the library, simply put the following declaration in your interface file :<p>
<p>
<blockquote><pre>%include pointer.i // Grab the SWIG pointer library
</pre></blockquote>
or run SWIG as follows :<p>
<p>
<blockquote><pre>swig -perl5 -lpointer.i interface.i
</pre></blockquote>
Doing so adds a collection of pointer manipulation functions that are described below. The functions are mainly designed to work with basic C datatypes, but can often be used with more complicated structures.<p>
<a name="n15"></a><h3> Pointer Library Functions</h3>
<b>ptrcreate(type,?value?,?nitems?)</b><p>
<dl>
<dt><dd>
<dt><dd>Creates a new object and returns a pointer to it. <tt>type</tt> is a string containing the C datatype and may be one of "<tt>int</tt>","<tt>short</tt>","<tt>long</tt>","<tt>float</tt>","<tt>double</tt>","<tt>char</tt>","<tt>char *</tt>", or "<tt>void</tt>". <tt>value</tt> is the optional initial value to be assigned to the object. <tt>nitems</tt> is an optional parameter containing the number of objects to create. By default it is 1, but specifying another value allows you to create an array of values. This function is really just a wrapper around the C <tt>malloc()</tt> function.
</dl>
<b></b><p>
<b>ptrfree(ptr)</b><p>
<dl>
<dt><dd>Destroys an object created by <tt>ptrcreate</tt>. It is generally unsafe to use this function on objects not created by <tt>ptrcreate</tt>. Calls the C <tt>free()</tt> function.
</dl>
<p>
<b>ptrvalue(ptr,?index?,?type?)</b><p>
<dl>
<dt><dd>This dereferences a pointer and returns the value that it is pointing to. <tt>index</tt> is an optional parameter that allows array access by returning the value of <tt>ptr[index]</tt>. <tt>type</tt> is an optional parameter that explicitly specifies the datatype. Since SWIG pointers are encoded with type information, the type is usually unnecessary. The <tt>type</tt> parameter provides somewhat better performance and allows you to dereference a pointer of different type however.
<dt><dd>
</dl>
<b>ptrset(ptr, value, ?index?, ?type?)</b><p>
<dl>
<dt><dd>Sets the value of the object a pointer is pointing to. <tt>value</tt> is the new value of the object. <tt>index </tt>is an optional parameter allowing array access by setting <tt>ptr[index] = value</tt>. <tt>type </tt>is an optional parameter that explicitly specifies the datatype as described above.
<dt><dd>
</dl>
<b>ptrcast(ptr, newtype)</b><p>
<dl>
<dt><dd>Casts a pointer to a new datatype and returns the new value. <tt>newtype</tt> is a string containing the new datatype and may either be the "mangled" version used by SWIG (such as "<tt>_Vector_p</tt>") or the C version (such as "<tt>Vector *</tt>"). This function works with any kind of pointer value. In additional to pointers, <tt>ptr</tt> may also hold an integer value in which case the integer is turned into a pointer of given type.
<dt><dd>
</dl>
<b>ptradd(ptr, offset)</b><p>
<dl>
<dt><dd>Adds an offset to a pointer and returns a new pointer. <tt>offset</tt> is specified as the number of objects except for unknown complex datatypes in which case it is the number of bytes. For example, is <tt>ptr</tt> is a "<tt>double *</tt>", <tt>ptradd(ptr,1)</tt> will return the next double. On the other hand, if if <tt>ptr</tt> is "<tt>Vector *</tt>", then <tt>ptradd(ptr,1)</tt> will update the pointer by 1 byte.
<dt><dd>
</dl>
<b>ptrmap(type1,type2)</b><p>
<dl>
<dt><dd>This performs a "runtime typedef" and makes SWIG recognize pointers of <tt>type1</tt> and <tt>type2</tt> as equivalent. <tt>type1</tt> and <tt>type2</tt> are specified as strings. Not generally needed, but sometimes useful.
</dl>
<a name="n16"></a><h3> A simple example</h3>
Suppose you have the following C function :<p>
<blockquote><pre>
void add(double a, double b, double *result) {
*result = a + b;
}
</pre></blockquote>
To manage the result output, we can write an interface file like this :<p>
<p>
<blockquote><pre>%module example
%include pointer.i
extern void add(double a, double b, double *result);
</pre></blockquote>
Now, let's use the pointer library (shown for a few languages) :<p>
<blockquote><pre>
# Tcl
set result [ptrcreate double] ;# Create a double
add 4.5 3 $result ;# Call our C function
puts [ptrvalue $result] ;# Print out the result
ptrfree $result ;# Destroy the double
# Perl5
use example;
package example; # Functions are in example package
$result = ptrcreate("double"); # Create a double
add(4.5,3,$result); # Call C function
print ptrvalue($result),"\n"; # Print the result
ptrfree($result); # Destroy the double
# Python
import example
result = example.ptrcreate("double") # Create a double
example.add(4.5,3,result) # Call C function
print example.ptrvalue(result) # Print the result
example.ptrfree(result) # Destroy the double
</pre></blockquote>
In this case, the idea is simple--we create a pointer, pass it to our C function, and dereference it to get the result. It's essentially identical to how we would have done it in C (well, minus the function call to dereference the value).<p>
<a name="n17"></a><h3> Creating arrays</h3>
Now suppose you have a C function involving arrays :<p>
<p>
<blockquote><pre>void addv(double a[], double b[], double c[], int nitems) {
int i;
for (i = 0; i &lt; nitems; i++) {
c[i] = a[i]+b[i];
}
}
</pre></blockquote>
This is also easily handled by our pointer library. For example (in Python) :<p>
<p>
<blockquote><pre># Python function to turn a list into an "array"
def build_array(l):
nitems = len(l)
a = ptrcreate("double",0,nitems)
i = 0
for item in l:
ptrset(a,item,i)
i = i + 1
return a
# Python function to turn an array into list
def build_list(a,nitems):
l = []
for i in range(0,nitems):
l.append(ptrvalue(a,i))
return l
# Now use our functions
a = listtoarray([0.0,-2.0,3.0,9.0])
b = build_array([-2.0,3.5,10.0,22.0])
c = ptrcreate("double",0,4) # For return result
add(a,b,c,4) # Call our C function
result = build_list(c) # Build a python list from the result
print result
ptrfree(a)
ptrfree(b)
ptrfree(c)
</pre></blockquote>
This example may look quite inefficient on the surface (due to the translation of Python lists to and from C arrays). However, if you're working with lots of C functions, it's possible to simply pass C pointers around between them without any translation. As a result, applications can run fast--even when controlled from a scripting language. It's also worth emphasizing that the <tt>ptrcreate()</tt> function created a real C array that can be interchanged with other arrays. The <tt>ptrvalue()</tt> function can also dereference a C pointer even if it wasn't created from Python. <p>
<a name="n18"></a><h3> Packing a data structure</h3>
The pointer library can even be used to pack simple kinds of data-structures, perhaps for sending across a network, or simply for changing the value. For example, suppose you had this data structure:<p>
<p>
<blockquote><pre>struct Point {
double x,y;
int color;
};
</pre></blockquote>
<p>
You could write a Tcl function to set the fields of the structure as follows :<p>
<p>
<blockquote><pre>proc set_point { ptr x y c } {
set p [ptrcast $ptr "double *"] ;# Make a double *
ptrset $p $x ;# Set x component
set p [ptradd $p 1] ;# Update pointer
ptrset $p $y ;# Set y component
set p [ptrcast [ptradd $p 1] "int *"] ;# Update pointer and cast
ptrset $p $c ;# Set color component
}
</pre></blockquote>
<p>
This function could be used even if you didn't tell SWIG anything about the "Point" structure above. <p>
<a name="n3"></a><h2> Introduction to typemaps</h2>
Sometimes it's desirable to change SWIG behavior in some manner. For example, maybe you want to automatically translate C arrays to and from Perl lists. Or perhaps you would like a particular function argument to behave as an output parameter. Typemaps provide a mechanism for doing just this by modifying SWIG's code generator. Typemaps are new to SWIG 1.1, but it should be emphasized that they are not required to build an interface. <p>
<a name="n19"></a><h3> The idea (in a nutshell)</h3>
The idea behind typemaps is relatively simple--given the occurrence of a particular C datatype, we want to apply rules for special processing. For example, suppose we have a C function like this :<p>
<p>
<blockquote><pre>void add(double a, double b, double *result) {
*result = a + b;
}
</pre></blockquote>
<p>
It is clear to us that the result of the function is being returned in the <tt>result</tt> parameter. Unfortunately, SWIG isn't this smart--after all "result" is just like any other pointer. However, with a typemap, we can make SWIG recognize "<tt>double *result</tt>" as a special datatype and change the handling to do exactly what we want.<p>
<p>
So, despite being a common topic of discussion on the SWIG mailing list, a typemap is really just a special processing rule that is applied to a particular datatype. Each typemap relies on two essential attributes--a datatype and a name (which is optional). When trying to match parameters, SWIG looks at both attributes. Thus, special processing applied to a parameter of "<tt>double *result</tt>" will not be applied to "<tt>double *input</tt>". On the other hand, special processing defined for a datatype of "<tt>double *</tt>" could be applied to both (since it is more general). <p>
<a name="n20"></a><h3> Using some typemaps</h3>
It is easy to start using some typemaps right away. To wrap the above function, simply use the <tt>typemaps.i</tt> library file (which is part of the SWIG library) as follows :<p>
<p>
<blockquote><pre>// Simple example using typemaps
%module example
%include typemaps.i // Grab the standard typemap library
%apply double *OUTPUT { double *result };
extern void add(double a, double b, double *result);
</pre></blockquote>
The <tt>%apply</tt> directive tells SWIG that we are going to apply special processing to a datatype. The "<tt>double *OUTPUT</tt>" is the name of a rule describing how to return an output value from a "<tt>double *</tt>" (this rule is defined in the file <tt>typemaps.i</tt>). The rule gets applied to all of the datatypes listed in curly braces-- in this case "<tt>double *result</tt>".<p>
<p>
While it may sound complicated, when you compile the module and use it, you get a function that works as follows :<p>
<p>
<blockquote><pre># Perl code to call our add function
$a = add(3,4);
print $a,"\n";
7
</pre></blockquote>
Our function is much easier to use and it is no longer necessary to create a special double * object and pass it to the function. Typemaps took care of this automatically.<p>
<a name="n4"></a><h2> Managing input and output parameters</h2>
By default, when SWIG encounters a pointer, it makes no assumptions about what it is (well, other than the fact that it's a pointer). The <tt>typemaps.i</tt> library file contains a variety of methods for changing this behavior. The following methods are available in this file :<p>
<a name="n21"></a><h3> Input Methods</h3>
These methods tell SWIG that a pointer is a single input value. When used, functions will expect values instead of pointers.<p>
<blockquote><pre>
int *INPUT
short *INPUT
long *INPUT
unsigned int *INPUT
unsigned short *INPUT
unsigned long *INPUT
double *INPUT
float *INPUT
</pre></blockquote>
<p>
Suppose you had a C function like this :<p>
<blockquote><pre>
double add(double *a, double *b) {
return *a+*b;
}
</pre></blockquote>
You could wrap it with SWIG as follows :<p>
<p>
<blockquote><pre>%module example
%include typemaps.i
...
extern double add(double *INPUT, double *INPUT);
</pre></blockquote>
Now, when you use your function ,it will work like this :<p>
<p>
<blockquote><pre>% set result [add 3 4]
% puts $result
7
</pre></blockquote>
<a name="n22"></a><h3> Output Methods</h3>
These methods tell SWIG that pointer is the output value of a function. When used, you do not need to supply the argument when calling the function, but multiple return values can be returned.<p>
<p>
<blockquote><pre>int *OUTPUT
short *OUTPUT
long *OUTPUT
unsigned int *OUTPUT
unsigned short *OUTPUT
unsigned long *OUTPUT
double *OUTPUT
float *OUTPUT
</pre></blockquote>
These methods can be used as shown in an earlier example. For example, if you have this C function :<p>
<p>
<blockquote><pre>void add(double a, double b, double *c) {
*c = a+b;
}
</pre></blockquote>
<p>
A SWIG interface file might look like this :<p>
<p>
<blockquote><pre>%module example
%include typemaps.i
...
extern void add(double a, double b, double *OUTPUT);
</pre></blockquote>
In this case, only a single output value is returned, but this is not a restriction. For example, suppose you had a function like this :<p>
<p>
<blockquote><pre>// Returns a status code and double
int get_double(char *str, double *result);
</pre></blockquote>
When declared in SWIG as :<p>
<p>
<blockquote><pre>int get_double(char *str, double *OUTPUT);
</pre></blockquote>
The function would return a list of output values as shown for Python below :as follows :<p>
<p>
<blockquote><pre>&gt;&gt;&gt; get_double("3.1415926") # Returns both a status and value
[0, 3.1415926]
&gt;&gt;&gt;
</pre></blockquote>
<a name="n23"></a><h3> Input/Output Methods</h3>
When a pointer serves as both an input and output value you can use the following methods :<p>
<blockquote><pre>
int *BOTH
short *BOTH
long *BOTH
unsigned int *BOTH
unsigned short *BOTH
unsigned long *BOTH
double *BOTH
float *BOTH
</pre></blockquote>
A typical C function would be as follows :<p>
<p>
<blockquote><pre>void negate(double *x) {
*x = -(*x);
}
</pre></blockquote>
To make x function as both and input and output value, declare the function like this in an interface file :<p>
<p>
<blockquote><pre>%module example
%include typemaps.i
...
extern void negate(double *BOTH);
</pre></blockquote>
Now within a script, you can simply call the function normally :<p>
<p>
<blockquote><pre>$a = negate(3); # a = -3 after calling this
</pre></blockquote>
<a name="n24"></a><h3> Using different names</h3>
By explicitly using the parameter names of INPUT, OUTPUT, and BOTH in your declarations, SWIG performs different operations. If you would like to use different names, you can simply use the <tt>%apply</tt> directive. For example :<p>
<p>
<blockquote><pre>// Make double *result an output value
%apply double *OUTPUT { double *result };
// Make Int32 *in an input value
%apply int *INPUT { Int32 *in };
// Make long *x both
%apply long *BOTH {long *x};
</pre></blockquote>
<tt>%apply</tt> only renames the different type handling rules. You can use it to match up with the naming scheme used in a header file and so forth. To later clear a naming rule, the <tt>%clear</tt> directive can be used :<p>
<p>
<blockquote><pre>%clear double *result;
%clear Int32 *in, long *x;
</pre></blockquote>
<a name="n5"></a><h2> Applying constraints to input values</h2>
In addition to changing the handling of various input values, it is also possible to apply constraints. For example, maybe you want to insure that a value is positive, or that a pointer is non-NULL. This can be accomplished including the <tt>constraints.i</tt> library file (which is also based on typemaps).<p>
<a name="n25"></a><h3> Simple constraint example</h3>
The constraints library is best illustrated by the following interface file :<p>
<p>
<blockquote><pre>// Interface file with constraints
%module example
%include constraints.i
double exp(double x);
double log(double POSITIVE); // Allow only positive values
double sqrt(double NONNEGATIVE); // Non-negative values only
double inv(double NONZERO); // Non-zero values
void free(void *NONNULL); // Non-NULL pointers only
</pre></blockquote>
The behavior of this file is exactly as you would expect. If any of the arguments violate the constraint condition, a scripting language exception will be raised. As a result, it is possible to catch bad values, prevent mysterious program crashes and so on.<p>
<a name="n26"></a><h3> Constraint methods</h3>
The following constraints are currently available<p>
<blockquote><pre>
POSITIVE Any number &gt; 0 (not zero)
NEGATIVE Any number &lt; 0 (not zero)
NONNEGATIVE Any number &gt;= 0
NONPOSITIVE Any number &lt;= 0
NONZERO Nonzero number
NONNULL Non-NULL pointer (pointers only).
</pre></blockquote>
<a name="n27"></a><h3> Applying constraints to new datatypes</h3>
The constraints library only supports the built-in C datatypes, but it is easy to apply it to new datatypes using <tt>%apply</tt>. For example :<p>
<p>
<blockquote><pre>// Apply a constraint to a Real variable
%apply Number POSITIVE { Real in };
// Apply a constraint to a pointer type
%apply Pointer NONNULL { Vector * };
</pre></blockquote>
The special types of "Number" and "Pointer" can be applied to any numeric and pointer variable type respectively. To later remove a constraint, the %clear directive can be used :<p>
<p>
<blockquote><pre>%clear Real in;
%clear Vector *;
</pre></blockquote>
<a name="n6"></a><h2> Writing new typemaps</h2>
So far, we have only seen a high-level picture of typemaps and have utilized pre-existing typemaps in the SWIG library. However, it is possible to do more if you're willing to get your hands dirty and dig into the internals of SWIG and your favorite scripting language.<p>
<p>
Before diving in, first ask yourself do I really need to change SWIG's default behavior? The basic pointer model works pretty well most of the time and I encourage you to use it--after all, I wanted SWIG to be easy enough to use so that you didn't need to worry about low level details. If, after contemplating this for awhile, you've decided that you really want to change something, a word of caution is in order. Writing a typemap from scratch usually requires a detailed knowledge of the internal workings of a particular scripting language. It is also quite easy to break all of the output code generated by SWIG if you don't know what you're doing. On the plus side, once a typemap has been written it can be reused over and over again by putting it in the SWIG library (as has already been demonstrated). This section describes the basics of typemaps. Language specific information (which can be quite technical) is contained in the later chapters.<p>
<a name="n28"></a><h3> Motivations for using typemaps</h3>
Suppose you have a few C functions such as the following :<p>
<p>
<blockquote><pre>void glLightfv(GLenum light, Glenum pname, GLfloat parms[4]);
</pre></blockquote>
In this case, the third argument takes a 4 element array. If you do nothing, SWIG will convert the last argument into a pointer. When used in the scripting language, you will need to pass a "<tt>GLfloat *</tt>" object to the function to make it work. <p>
<a name="n29"></a><h3> Managing special data-types with helper functions</h3>
Helper functions provide one mechanism for dealing with odd datatypes. With a helper function, you provide additional functionality for creating and destroying objects or converting values into a useful form. These functions are usually just placed into your interface file with the rest of the functions. For example, a few helper functions to work with 4 element arrays for the above function, might look like this :<p>
<p>
<blockquote><pre>%inline %{
/* Create a new GLfloat [4] object */
GLfloat *newfv4(double x, double y, double z, double w) {
GLfloat *f = (GLfloat *) malloc(4*sizeof(GLfloat));
f[0] = x;
f[1] = y;
f[2] = z;
f[3] = w;
return f;
}
/* Destroy a GLfloat [4] object */
void delete_fv4(GLfloat *d) {
free(d);
}
%}
</pre></blockquote>
<p>
When wrapped, our helper functions will show up the interface and can be used as follows :<p>
<p>
<blockquote><pre>% set light [newfv4 0.0 0.0 0.0 1.0] # Creates a GLfloat *
% glLightfv GL_LIGHT0 GL_AMBIENT $light # Pass it to the function
...
% delete_fv4 $light # Destroy it (When done)
</pre></blockquote>
<p>
<p>
While not the most elegant approach, helper functions provide a simple mechanism for working with more complex datatypes. In most cases, they can be written without diving into SWIG's internals. Before typemap support was added to SWIG, helper functions were the only method for handling these kinds of problems. The pointer.i library file described earlier is an example of just this sort of approach. As a rule of thumb, I recommend that you try to use this approach before jumping into typemaps. <p>
<a name="n30"></a><h3> A Typemap Implementation</h3>
As we have seen, a typemap can often eliminate the need for helper functions. Without diving into the details, a more sophisticated typemap implementation of the previous example can permit you to pass an array or list of values directly into the C function like this :<p>
<p>
<blockquote><pre>% glLightfv GL_LIGHT0 GL_AMBIENT {0.0 0.0 0.0 1.0}
</pre></blockquote>
This is a more natural implementation that replaces the low-level pointer method. Now we will look into how one actually specifies a typemap.<p>
<a name="n31"></a><h3> What is a typemap?</h3>
A typemap is specified using the <tt>%typemap</tt> directive in your interface file. A simple typemap might look liks this :<p>
<p>
<blockquote><pre>%module example
%typemap(tcl,in) int {
$target = atoi($source);
printf("Received an integer : %d\n", $target);
}
int add(int a, int b);
</pre></blockquote>
<p>
In this case, we changed the processing of integers as input arguments to functions. When used in a Tcl script, we would get the following debugging information:<p>
<p>
<blockquote><pre>% set a [add 7 13]
Received an integer : 7
Received an integer : 13
</pre></blockquote>
In the typemap specification, the symbols <tt>$source</tt> and <tt>$target</tt> are holding places for C variable names that SWIG is going to use when generating wrapper code. In this example, <tt>$source</tt> would contain a Tcl string containing the input value and <tt>$target</tt> would be the C integer value that is going to be passed into the "add" function.<p>
<a name="n32"></a><h3> Creating a new typemap</h3>
A new typemap can be created as follows :<p>
<blockquote><pre>
%typemap(lang,method) Datatype {
... Conversion code ...
}
</pre></blockquote>
<tt>lang</tt> specifies the target language, <tt>method</tt> defines a particular conversion method, and <tt>Datatype</tt> gives the corresponding C datatype. The code corresponding to the typemap is enclosed in braces after the declaration. There are about a dozen different kinds of typemaps that are used within SWIG, but we will get to that shortly.<p>
<p>
A single conversion can be applied to multiple datatypes by giving a comma separated list of datatypes. For example :<p>
<p>
<blockquote><pre>%typemap(tcl,in) int, short, long, signed char {
$target = ($type) atol($source);
}
</pre></blockquote>
Here, <tt>$type</tt> will be expanded into the real datatype during code generation. Datatypes may also carry names as in<p>
<p>
<blockquote><pre>%typemap(perl5,in) char **argv {
... Turn a perl array into a char ** ...
}
</pre></blockquote>
A "named"typemap will only apply to an object that matches both the C datatype and the name. Thus the <tt>char **argv</tt> typemap will only be applied to function arguments that exactly match "<tt>char **argv</tt>". In some cases, the name may correspond to a function name (as is the case for return values).<p>
<p>
Finally, there is a shortened form of the typemap directive :<p>
<p>
<blockquote><pre>%typemap(method) Datatype {
...
}
</pre></blockquote>
When the language name is ommitted, the typemap will be applied to the current target language. This form is only recommended for typemap methods that are language independent (there are a few). It is not recommended if you are building interfaces for multiple languages.<p>
<a name="n33"></a><h3> Deleting a typemap</h3>
A typemap can be deleted by providing no conversion code. For example :<p>
<p>
<blockquote><pre>%typemap(lang,method) Datatype; // Deletes this typemap
</pre></blockquote>
<a name="n34"></a><h3> Copying a typemap</h3>
A typemap can be copied using the following declaration :<p>
<p>
<blockquote><pre>%typemap(python,out) unsigned int = int; // Copies a typemap
</pre></blockquote>
This specifies that the typemap for "<tt>unsigned int</tt>" should be the same as the "<tt>int</tt>" typemap.<p>
This is most commonly used when working with library files.<p>
<a name="n35"></a><h3> Typemap matching rules</h3>
When you specify a typemap, SWIG is going to try and match it with all future occurrences of the datatype you specify. The matching process is based upon the target language, typemap method, datatype, and optional name. Because of this, it is perfectly legal for multiple typemaps to exist for a single datatype at any given time. For example :<p>
<p>
<blockquote><pre>%typemap(tcl,in) int * {
... Convert an int * ...
}
%typemap(tcl,in) int [4] {
... Convert an int[4] ...
}
%typemap(tcl,in) int out[4] {
... Convert an out[4] ...
}
%typemap(tcl,in) int *status {
... Convert an int *status ...
}
</pre></blockquote>
These typemaps all involve the "<tt>int *</tt>" datatype in one way or another, but are all considered to be distinct. There is an extra twist to typemaps regarding the similarity between C pointers and arrays. A typemap applied to a pointer will also work for any array of the same type. On the other hand, a typemap applied to an array will only work for arrays, not pointers. Assuming that you're not completely confused at this point, the following rules are applied in order to match pointers and arrays :<p>
<p>
<ul>
<li>Named arrays
<li>Unnamed arrays
<li>Named datatypes
<li>Unnamed datatypes
</ul>
<p>
The following interface file shows how these rules are applied.<p>
<p>
<blockquote><pre>void foo1(int *); // Apply int * typemap
void foo2(int a[4]); // Apply int[4] typemap
void foo3(int out[4]); // Apply int out[4] typemap
void foo4(int *status); // Apply int *status typemap
void foo5(int a[20]); // Apply int * typemap (because int [20] is an int *)
</pre></blockquote>
Because SWIG uses a name-based approach, it is possible to attach special properties to named parameters. For example, we can make an argument of "<tt>int *OUTPUT</tt>" always be treated as an output value of a function or make a "<tt>char **argv</tt>" always accept a list of string values.<p>
<a name="n7"></a><h2> Common typemap methods</h2>
The following methods are supported by most SWIG language modules. Individual language may provide any number of other methods not listed here.<p>
<center>
<img src="ch6.table.1.png"><br>
<img src="ch6.table.2.png"><br>
</center>
<p>
Understanding how some of these methods are applied takes a little practice and better understanding of what SWIG does when it creates a wrapper function. The next few diagrams show the anatomy of a wrapper function and how the typemaps get applied. More detailed examples of typemaps can be found on the chapters for each target language.<p>
<p>
<center><img src="ch6.1.png">
<p></center>
<p>
<center><img src="ch6.2.png">
<p></center>
<a name="n8"></a><h2> Writing typemap code</h2>
The conversion code supplied to a typemap needs to follow a few conventions described here.<p>
<a name="n36"></a><h3> Scope</h3>
Typemap code is enclosed in braces when it is inserted into the resulting wrapper code (using C's block-scope). It is perfectly legal to declare local and static variables in a typemap. However, local variables will only exist in the tiny portion of code you supply. In other words, any local variables that you create in a typemap will disappear when the typemap has completed its execution.<p>
<a name="n37"></a><h3> Creating local variables</h3>
Sometimes it is necessary to declare a new local variable that exists in the scope of the entire wrapper function. This can be done by specifying a typemap with parameters as follows :<p>
<p>
<blockquote><pre>%typemap(tcl,in) int *INPUT(int temp) {
temp = atoi($source);
$target = &amp;temp;
}
</pre></blockquote>
What happens here is that <tt>temp</tt> becomes a local variable in the scope of the entire wrapper function. When we set it to a value, that values persists for the duration of the wrapper function and gets cleaned up automatically on exit. This is particularly useful when working with pointers and temporary values.<p>
<p>
It is perfectly safe to use multiple typemaps involving local variables in the same function. For example, we could declare a function as :<p>
<p>
<blockquote><pre>void foo(int *INPUT, int *INPUT, int *INPUT);
</pre></blockquote>
When this occurs, SWIG will create three different local variables named `temp'. Of course, they don't all end up having the same name---SWIG automatically performs a variable renaming operation if it detects a name-clash like this.<p>
<p>
Some typemaps do not recognize local variables (or they may simply not apply). At this time, only the "in", "argout", "default", and "ignore" typemaps use local variables.<p>
<a name="n38"></a><h3> Special variables</h3>
The following special variables may be used within a typemap conversion code :<p>
<center><img src="ch6.table.3.png"></center>
<p>
When found in the conversion code, these variables will be replaced with the correct values. Not all values are used in all typemaps. Please refer to the SWIG reference manual for the precise usage. <p>
<a name="n9"></a><h2> Typemaps for handling arrays</h2>
One of the most common uses of typemaps is providing some support for arrays. Due to the subtle differences between pointers and arrays in C, array support is somewhat limited unless you provide additional support. For example, consider the following structure appears in an interface file :<p>
<p>
<blockquote><pre>struct Person {
char name[32];
char address[64];
int id;
};
</pre></blockquote>
When SWIG is run, you will get the following warnings :<p>
<p>
<blockquote><pre>swig -python example.i
Generating wrappers for Python
example.i : Line 2. Warning. Array member will be read-only.
example.i : Line 3. Warning. Array member will be read-only.
</pre></blockquote>
<p>
These warning messages indicate that SWIG does not know how you want to set the name and address fields. As a result, you will only be able to query their value.<p>
<p>
To fix this, we could supply two typemaps in the file such as the following :<p>
<blockquote><pre>
%typemap(memberin) char [32] {
strncpy($target,$source,32);
}
%typemap(memberin) char [64] {
strncpy($target,$source,64);
}
</pre></blockquote>
The "memberin" typemap is used to set members of structures and classes. When you run the new version through SWIG, the warnings will go away and you can now set each member. It is important to note that <tt>char[32]</tt> and <tt>char[64]</tt> are different datatypes as far as SWIG typemaps are concerned. However, both typemaps can be combined as follows :<p>
<p>
<blockquote><pre>// A better typemap for char arrays
%typemap(memberin) char [ANY] {
strncpy($target,$source,$dim0);
}
</pre></blockquote>
The <tt>ANY</tt> keyword can be used in a typemap to match any array dimension. When used, the special variable <tt>$dim0</tt> will contain the real dimension of the array and can be used as shown above.<p>
<p>
Multidimensional arrays can also be handled by typemaps. For example :<p>
<p>
<blockquote><pre>// A typemap for handling any int [][] array
%typemap(memberin) int [ANY][ANY] {
int i,j;
for (i = 0; i &lt; $dim0; i++)
for (j = 0; j &lt; $dim1; j++) {
$target[i][j] = *($source+$dim1*i+j);
}
}
</pre></blockquote>
When multi-dimensional arrays are used, the symbols <tt>$dim0,</tt> <tt>$dim1</tt>,<tt> $dim2</tt>, etc... get replaced by the actual array dimensions being used. <p>
<p>
The ANY keyword can be combined with any specific dimension. For example :<p>
<p>
<blockquote><pre>%typemap(python,in) int [ANY][4] {
...
}
</pre></blockquote>
A typemap using a specific dimension always has precedence over a more general version. For example, <tt>[ANY][4]</tt> will be used before<tt>[ANY][ANY]</tt>.<p>
<a name="n10"></a><h2> Typemaps and the SWIG Library</h2>
Writing typemaps is a tricky business. For this reason, many common typemaps can be placed into a SWIG library file and reused in other modules without having to worry about nasty underlying details. To do this, you first write a file containing typemaps such as this :<p>
<p>
<blockquote><pre>// file : stdmap.i
// A file containing a variety of useful typemaps
%typemap(tcl,in) int INTEGER {
...
}
%typemap(tcl,in) double DOUBLE {
...
}
%typemap(tcl,out) int INT {
...
}
%typemap(tcl,out) double DOUBLE {
...
}
%typemap(tcl,argout) double DOUBLE {
...
}
// and so on...
</pre></blockquote>
This file may contain dozens or even hundreds of possible mappings. Now, to use this file with other modules, simply include it in other files and use the <tt>%apply</tt> directive :<p>
<p>
<blockquote><pre>// interface.i
// My interface file
%include stdmap.i // Load the typemap library
// Now grab the typemaps we want to use
%apply double DOUBLE {double};
// Rest of your declarations
</pre></blockquote>
<p>
In this case, <tt>stdmap.i</tt> contains a variety of standard mappings. The <tt>%apply</tt> directive lets us apply specific versions of these to new datatypes without knowing the underlying implementation details.<p>
<p>
To clear a typemap that has been applied, you can use the <tt>%clear</tt> directive. For example :<p>
<p>
<blockquote><pre>%clear double x; // Clears any typemaps being applied to double x
</pre></blockquote>
<a name="n11"></a><h2> Implementing constraints with typemaps</h2>
One particularly interesting application of typemaps is the implementation of argument constraints. This can be done with the "check" typemap. When used, this allows you to provide code for checking the values of function arguments. For example :<p>
<p>
<blockquote><pre>%module math
%typemap(perl5,check) double *posdouble {
if ($target &lt; 0) {
croak("Expecting a positive number");
}
}
...
double sqrt(double posdouble);
</pre></blockquote>
This provides a sanity check to your wrapper function. If a negative number is passed to this function, a Perl exception will be raised and your program terminated with an error message.<p>
<p>
This kind of checking can be particularly useful when working with pointers. For example :<p>
<p>
<blockquote><pre>%typemap(python,check) Vector * {
if ($target == 0) {
PyErr_SetString(PyExc_TypeError,"NULL Pointer not allowed");
return NULL;
}
}
</pre></blockquote>
will prevent any function involving a <tt>Vector *</tt> from accepting a NULL pointer. As a result, SWIG can often prevent a potential segmentation faults or other run-time problems by raising an exception rather than blindly passing values to the underlying C/C++ program.<p>
<a name="n12"></a><h2> Typemap examples</h2>
Typemaps are inherently language dependent so more examples appear in later chapters. The SWIG<tt> Examples </tt>directory also includes a variety of examples. Sophisticated users may gain more by examining the <tt>typemaps.i</tt> and <tt>constraints.i </tt>SWIG library files.<p>
<a name="n13"></a><h2> How to break everything with a typemap</h2>
It should be emphasized that typemaps provide a direct mechanism for modifying SWIG's output. As a result, it can be very easy to break almost everything if you don't know what you're doing. For this reason, it should be stressed that typemaps are not required in order to use SWIG with most kinds of applications. Power users, however, will probably find typemaps to be a useful tool for creating extremely powerful scripting language extensions. <p>
<a name="n14"></a><h2> Typemaps and the future</h2>
The current typemap mechanism, while new, will probably form the basis of SWIG 2.0. Rather than having code buried away inside a C++ module, it may soon be possible to redefine almost all of SWIG's code generation on the fly. Future language modules will rely upon typemaps almost exclusively. <p>
<p>
<p><hr>
<address>SWIG 1.1 - Last Modified : Mon Aug 4 10:46:56 1997</address>
</body>
</html>

BIN
swigweb/Doc1.1/HTML/ch1.1.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 6 KiB

BIN
swigweb/Doc1.1/HTML/ch1.2.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 8.2 KiB

BIN
swigweb/Doc1.1/HTML/ch10.1.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 12 KiB

BIN
swigweb/Doc1.1/HTML/ch10.table.1.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 6.8 KiB

BIN
swigweb/Doc1.1/HTML/ch10.table.10.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 8.7 KiB

BIN
swigweb/Doc1.1/HTML/ch10.table.11.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 6.1 KiB

BIN
swigweb/Doc1.1/HTML/ch10.table.12.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 9.3 KiB

BIN
swigweb/Doc1.1/HTML/ch10.table.2.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 14 KiB

BIN
swigweb/Doc1.1/HTML/ch10.table.3.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 5 KiB

BIN
swigweb/Doc1.1/HTML/ch10.table.4.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 5.7 KiB

BIN
swigweb/Doc1.1/HTML/ch10.table.5.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 8.7 KiB

BIN
swigweb/Doc1.1/HTML/ch10.table.6.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 20 KiB

BIN
swigweb/Doc1.1/HTML/ch10.table.7.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 4.8 KiB

BIN
swigweb/Doc1.1/HTML/ch10.table.8.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 7.7 KiB

BIN
swigweb/Doc1.1/HTML/ch10.table.9.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 6.2 KiB

BIN
swigweb/Doc1.1/HTML/ch11.1.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 2.4 KiB

BIN
swigweb/Doc1.1/HTML/ch11.2.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 2.6 KiB

BIN
swigweb/Doc1.1/HTML/ch11.3.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 2.9 KiB

BIN
swigweb/Doc1.1/HTML/ch12.1.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 3.5 KiB

BIN
swigweb/Doc1.1/HTML/ch2.1.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 3.1 KiB

BIN
swigweb/Doc1.1/HTML/ch2.2.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 3.3 KiB

BIN
swigweb/Doc1.1/HTML/ch3.1.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 3.4 KiB

BIN
swigweb/Doc1.1/HTML/ch5.1.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 5.4 KiB

BIN
swigweb/Doc1.1/HTML/ch5.2.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 22 KiB

BIN
swigweb/Doc1.1/HTML/ch5.3.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 19 KiB

BIN
swigweb/Doc1.1/HTML/ch6.1.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 10 KiB

BIN
swigweb/Doc1.1/HTML/ch6.2.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 8.3 KiB

BIN
swigweb/Doc1.1/HTML/ch6.table.1.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 18 KiB

BIN
swigweb/Doc1.1/HTML/ch6.table.2.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 6.7 KiB

BIN
swigweb/Doc1.1/HTML/ch6.table.3.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 11 KiB

BIN
swigweb/Doc1.1/HTML/ch8.1.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 3.2 KiB

BIN
swigweb/Doc1.1/HTML/ch8.2.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 8.5 KiB

BIN
swigweb/Doc1.1/HTML/ch8.3.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 24 KiB

BIN
swigweb/Doc1.1/HTML/ch8.table.1.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 5.4 KiB

BIN
swigweb/Doc1.1/HTML/ch8.table.2.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 5.7 KiB

BIN
swigweb/Doc1.1/HTML/ch8.table.3.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 9.1 KiB

BIN
swigweb/Doc1.1/HTML/ch8.table.4.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 5.3 KiB

BIN
swigweb/Doc1.1/HTML/ch8.table.5.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 4.9 KiB

BIN
swigweb/Doc1.1/HTML/ch8.table.6.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 7.4 KiB

BIN
swigweb/Doc1.1/HTML/ch8.table.7.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 7.5 KiB

BIN
swigweb/Doc1.1/HTML/ch9.1.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 7.7 KiB

BIN
swigweb/Doc1.1/HTML/ch9.2.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 26 KiB

BIN
swigweb/Doc1.1/HTML/ch9.3.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 3.1 KiB

BIN
swigweb/Doc1.1/HTML/ch9.table.1.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 18 KiB

BIN
swigweb/Doc1.1/HTML/ch9.table.10.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 8.4 KiB

BIN
swigweb/Doc1.1/HTML/ch9.table.2.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 3.7 KiB

BIN
swigweb/Doc1.1/HTML/ch9.table.3.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 3.8 KiB

BIN
swigweb/Doc1.1/HTML/ch9.table.4.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 6.6 KiB

BIN
swigweb/Doc1.1/HTML/ch9.table.5.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 11 KiB

BIN
swigweb/Doc1.1/HTML/ch9.table.6.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 5.9 KiB

BIN
swigweb/Doc1.1/HTML/ch9.table.7.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 4 KiB

BIN
swigweb/Doc1.1/HTML/ch9.table.8.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 13 KiB

BIN
swigweb/Doc1.1/HTML/ch9.table.9.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 6.8 KiB

416
swigweb/Doc1.1/PDF/Advanced.pdf
View file

@ -1,416 +0,0 @@
%PDF-1.2 %âãÏÓ
1 0 obj << /Type /Page /Parent 18 0 R /Resources 12 0 R /Contents 11 0 R /CropBox [ 0 0 612 792 ] /B [ 10 0 R ] >> endobj 2 0 obj << /D [ 1 0 R /XYZ null 823 null ] >> endobj 3 0 obj << /D [ 1 0 R /XYZ null 714 null ] >> endobj 4 0 obj << /CreationDate (D:19970623235346) /Producer (Acrobat Distiller 3.0 for Power Macintosh) /Author (Dave) /Title (SWIG Manual) /Creator (FrameMaker 5.1.1) /ModDate (D:19970624001931) >> endobj 5 0 obj << /D [ 1 0 R /XYZ null null null ] >> endobj 6 0 obj << /D [ 1 0 R /XYZ null null null ] >> endobj 7 0 obj << /D [ 1 0 R /XYZ null 659 null ] >> endobj 8 0 obj << /D [ 1 0 R /XYZ null 360 null ] >> endobj 9 0 obj << /I << /Title (A)>> /F 10 0 R >> endobj 10 0 obj << /T 9 0 R /P 1 0 R /R [ 63 63 549 729 ] /V 63 0 R /N 22 0 R >> endobj 11 0 obj << /Length 2925 /Filter [ /ASCII85Decode /LZWDecode ] >> stream
J/gkM&HS[n!uqRi,>ku'5W=FR%Rs9/>X302OG\S9Go1-9Je\^@0n=jK,oFcJ,B:NG
5ZBXoA>XUn?pH@iPf?#l3Qs`W/-A<B!D-,;%3ig70ppa>59Z03ACW`&hKCgr%Rn8r
jM#+[Ra("O\a9<J,q9bo;Y.R-VH5%*`!')-PiY(RSP:Fu/JaC=#/HmnBLF77%#74o
d5\46R2dF\A.n`tSuF"R5p_]YKaNZ+Uf+Jfgm(2t;j9nM[>NLT5FiK"9S[*a\Ai)8
9?lW%8W;h]d,8;N=?+;6$]*f:;+S''23=`t2#1mJb!2B!B=Jcc?Tt$EO`^0hEL'7#
>H[;s6XcSe=u7/K_ue>ra3h(7:l<k7RAA[u,QVjn('F\8l8K-F"0DV/+in[C]4fnj
,CuiHPc9X9R-p%]U1ceDMlA,GiNSAP*Z>5KF!R--Wm"6QZ9r"<.C`,/%)a=QM\tT`
@PD]h,[m/nP/pHu&sg-Z*$PU!Wbd)+!O=4-,-&HZC`BE@OC40I,26S[[]R/^.KpuS
bS3!Ql[CIDJl@9;3:&_j*BB("T//5tTOQ"nY/=YnYO*%m4b_1f:lnM<0PD?<_293O
;04@tm"M-`>Sm[HP1$$tdTk`Mc>6bNk9FuQW.]oJ]TGG#Ebc%]U$:3E)_44i@%FX)
6Id^pA!G+U"Tp0i3Xm<Qc4CG[W7bV`UM/L>=\qZI0T9LD_D@.W>h_3AY!Wj`0sr7"
-qr,Rar<n<iaX8k%chs"]JhD7=KpbWDANM.Z4gKkm,HbQ/aJ3X0t*bU`<;4%X)^61
p`4bB=>h1rC0K3*HniD)kiZDW_#W=J=Uh>#&.F1^c!Q/,1@:;7UN#I.=n[[6(Bae)
hE-[k[T9I5&0U0nAU&k@0]D^,q_h0j-sK/r'uTUL?f=942iY%4kVA*,5ht4T,@Ebj
NamgJ3[`SZ82o205(5>dc)qkaCI:YP3nkeXbVtPb#i0:`+U3F1BX9tB2@Q?o>SQE<
jDAg*2&4"Ma6bQiS[s[6BSY,^>l`g5aR:>;Ed':B=U"o2?!CACkYN]np*QdN%V)Hq
3,][Z\.ier#AL7#_bRi"E$Ki;_N&*`;oDmV"[C!e;;COd?4)PrH-3Jf2-/Q--`3n"
8_@\r.p'f4m*a>9*%G\I#hcCh/![@B%Tnp9B3H9!IDCf:Ak1N=qYsqB>3fL)&$<+/
j8dkc1'\5'&WF3Wd'27$p]M!NgbM.[*1Q6-=9ol^]S,&T!DtUMl_(Zde@b+".l7Tm
!4oXQ'a"PZD1Y'j$pY(Prh,_fDU%.r2MPIBS+(]>5dd]$JC`FN+Cu&fgc.Y$5m,#D
A.=YEYJh;c)rU2pKE*l%WGlC_Te^9jbg7lI"99K1G]b2qV@B1'g<ZI%$%XGW(dfWP
5u"S"%]/[MXB6Ho6bDl3E<%U+^hhs1"1NJ#n1f[;Ls$7N@!2Ru@@Pl-iS7+2I%\:t
^50W==TiDt6&kds-i=t%b8YE%%?.a833h3p!"I/3qD0O_[0&c;5lcEsL6pL*_[AM_
U_LO)ed2>9gEUOZr49k82$m1Q)?gVX1qNIZ(nZa(DP68G[%Lk:ck&2nNBRr;(8D5k
A/5Xe9nGdqbqu;nedXEDU'?qL3`npqJ1Q]cLEP=LM=LO&bup]*.3?il]+&[q<NrSn
'#k#qKa(r?hR6"eI+i(*KL!Ho:2%N4>,ojX;^n7s(4[63kroQW(2C8.B[)sa,m>jj
3&DD06"gRJ5KkG315CPA")Mad;E:e^[Mn&XZIEIPrF*q66MY6k,m=q3q_ia5*>2L$
6L%]IbJT2G=1Br3B<:m!@WkFYi&Cn_d"Kt=$4P&11.I-1EtCsm>/AI#>mI(Q`YW&J
A%6W:6'N.d<pr8KWW-R`]JNBOd^6oT`!gE1U-jIK:KW<8Q!rN*9?-K6f^-:ai.)u&
YZDT+CSjDYIANS`RS2@_;NXBB^'?Yi4Q*4F%ft*OWTC^]QMZ\4LNt8X-R_t%\`Rr\
Bm-F#SEJL`a!D4T"Wgju%@#>AN3%sn#5,;jCOe9R%)1/A\FDjP9U)2nGW>u:$lMF-
3+]2-qQ5j/(1("U7h7IS]pC#<a[)@AG:dtd'UaHA"oqL.d4JCn\R.Wf6^=M<]\%H+
Z^RpIO7;Q0ZZc4n=DGfiiQ*fOkn>5?XP>W8F`Np``atbZ35A1ejqN/F?GX-*S8iQ>
K0qV%JNtjli.*%Fj:Vrkpb!"'!cKJ`AO_59-)uq8-6G'CO0RP-aC-4'+IU\i_\6FO
ni/Y!o0JR\ISc0/J[U.1p2D5.-k6:._404Z;9<s_br3A2"rD1IJ_k@!+J:r3i)-.(
&OHuPT\R"qhX0b!FE!ZkclW$<PHo^eco3f?P<r13QU3o*%[ffui+NNH!F3qrV0eUT
(fX2Rf@3DR^*R0#J<IJ7<gqthlLZT.L`WhN+G,WbC`fdek.3'84'n%;BSDPq`RnAW
;kfgTZ3Wbd#6;u7D-_*JX-O#t3%Gc0_pPr(k21Q>n?o7+UDkPL]kY%8;XVIB>.3;D
esd[NCn"A/p!19!BP`7OQVY(K-Msqb,A(boP%,)t"Q5d,KC4`$#mlISS,gAsmHq*e
CSLDV204fGSZ],>B((_`UO$Y(.RZ.\$/"#dIdl1n_oSMri+*fFEt*o0Fg![S4Ptn`
",F]QlM'K,hfTSQ\:(j3`9Ee?)4:*XpCL9]h#0fknoDLf5t(5!9c`<`;JAXD^JX26
o3:g'GL:]]^YkZXMXrHQgNjr[i&a#qOFHHJ\t9f?X4XOo_?n8V-QlC#PJa!!<QTRR
,io0XQ#@^Gi^%KG[D_DIc36%R;XdCm1*@EcT0(@bTIBG6eHL8,AG?27Wq9sMp7F_o
%"4JD$.3BiOUG;O&$A`WYiZ;H.<;^p=D==>-Rk8H+;o/Kb%9o\#DZge*1en#X:Ck%
!Y9ek(YSTf!5%eIZ2t~> endstream endobj 12 0 obj << /ProcSet [ /PDF /Text ] /Font << /F3 13 0 R /F5 14 0 R /F7 15 0 R /F11 16 0 R >> /ExtGState << /GS2 17 0 R >> >> endobj 13 0 obj << /Type /Font /Subtype /Type1 /Name /F3 /FirstChar 32 /LastChar 255 /Widths [ 250 278 371 500 500 840 778 208 333 333 389 606 250 333 250 606 500 500 500 500 500 500 500 500 500 500 250 250 606 606 606 444 747 778 611 709 774 611 556 763 832 337 333 726 611 946 831 786 604 786 668 525 613 778 722 1000 667 667 667 333 606 333 606 500 333 500 553 444 611 479 333 556 582 291 234 556 291 883 582 546 601 560 395 424 326 603 565 834 516 556 500 333 606 333 606 0 778 778 709 611 831 786 778 500 500 500 500 500 500 444 479 479 479 479 287 287 287 287 582 546 546 546 546 546 603 603 603 603 500 400 500 500 500 606 628 556 747 747 979 333 333 0 944 833 0 606 0 0 500 603 0 0 0 0 0 333 333 0 758 556 444 278 606 0 500 0 0 500 500 1000 250 778 778 786 998 827 500 1000 500 500 278 278 606 0 556 667 167 500 331 331 605 608 500 250 278 500 1144 778 611 778 611 611 337 337 337 337 786 786 0 786 778 778 778 287 333 333 333 333 250 333 333 380 313 333 ] /Encoding /MacRomanEncoding /BaseFont /Palatino-Roman /FontDescriptor 80 0 R >> endobj 14 0 obj << /Type /Font /Subtype /Type1 /Name /F5 /FirstChar 32 /LastChar 255 /Widths [ 250 333 500 500 500 889 778 333 333 333 389 606 250 333 250 296 500 500 500 500 500 500 500 500 500 500 250 250 606 606 606 500 747 722 611 667 778 611 556 722 778 333 333 667 556 944 778 778 611 778 667 556 611 778 722 944 722 667 667 333 606 333 606 500 333 444 463 407 500 389 278 500 500 278 278 444 278 778 556 444 500 463 389 389 333 556 500 722 500 500 444 333 606 333 606 0 722 722 667 611 778 778 778 444 444 444 444 444 444 407 389 389 389 389 278 278 278 278 556 444 444 444 444 444 556 556 556 556 500 400 500 500 500 500 500 500 747 747 1000 333 333 0 941 778 0 606 0 0 500 556 0 0 0 0 0 333 333 0 638 444 500 333 606 0 500 0 0 500 500 1000 250 722 722 778 1028 669 500 1000 500 500 278 278 606 0 500 667 167 500 333 333 528 545 500 250 278 500 1000 722 611 722 611 611 333 333 333 333 778 778 0 778 778 778 778 278 333 333 333 333 333 333 333 333 333 333 ] /Encoding /MacRomanEncoding /BaseFont /Palatino-Italic /FontDescriptor 81 0 R >> endobj 15 0 obj << /Type /Font /Subtype /Type1 /Name /F7 /FirstChar 32 /LastChar 255 /Widths [ 250 333 500 500 500 889 833 250 333 333 444 606 250 389 250 315 500 500 500 500 500 500 500 500 500 500 250 250 606 606 606 444 833 722 667 685 778 611 556 778 778 389 389 722 611 944 778 833 667 833 722 556 611 778 667 1000 722 611 667 333 606 333 606 500 333 556 537 444 556 444 333 500 556 333 333 556 333 833 556 556 556 537 389 444 389 556 556 833 500 556 500 333 606 333 606 0 722 722 685 611 778 833 778 556 556 556 556 556 556 444 444 444 444 444 333 333 333 333 556 556 556 556 556 556 556 556 556 556 556 400 500 500 556 606 556 556 747 747 1000 333 333 0 944 833 0 606 0 0 500 556 0 0 0 0 0 333 333 0 738 556 444 333 606 0 500 0 0 500 500 1000 250 722 722 833 944 778 500 1000 500 500 278 278 606 0 556 611 167 500 333 333 611 611 556 250 250 500 1000 722 611 722 611 611 389 389 389 389 833 833 0 833 778 778 778 333 333 333 333 333 333 556 333 333 333 333 ] /Encoding /MacRomanEncoding /BaseFont /Palatino-BoldItalic /FontDescriptor 82 0 R >> endobj 16 0 obj << /Type /Font /Subtype /Type1 /Name /F11 /Encoding /MacRomanEncoding /BaseFont /Courier >> endobj 17 0 obj << /Type /ExtGState /SA true /OP false /HT /Default >> endobj 18 0 obj << /Type /Pages /Kids [ 1 0 R 19 0 R 26 0 R 32 0 R 39 0 R 46 0 R 53 0 R 59 0 R ] /Count 8 /MediaBox [ 0 0 612 792 ] >> endobj 19 0 obj << /Type /Page /Parent 18 0 R /Resources 24 0 R /Contents 23 0 R /CropBox [ 0 0 612 792 ] /B [ 22 0 R ] >> endobj 20 0 obj << /D [ 19 0 R /XYZ null null null ] >> endobj 21 0 obj << /D [ 19 0 R /XYZ null 340 null ] >> endobj 22 0 obj << /P 19 0 R /R [ 63 63 549 729 ] /V 10 0 R /N 29 0 R >> endobj 23 0 obj << /Length 2853 /Filter [ /ASCII85Decode /LZWDecode ] >> stream
J/gkM&HS[n!uqRi,>ku'5W=FR%Rs9/>X302OG\S9Go1-9Je\^@0n=jK,oF`o".4>k
BHScD6*aEOA?[0mOih/W!M&9p,*i8(JH2LEC'Kf1AJiX/4!0R*jYCSI9Q*$4N<^Zd
ST\EsRSB[nWT<o,6B[TBF#eg.L/TUc8E']MbfXsuOj9hf+dS*YV#t+%82MM)+GN7X
&EoWb027H=L9_,>8l&HMNb]9mr=4`UUsefGgmpo+<0Tu[&mEOt]-!Eea<j9ZK\U&m
R3i.0JY^;,^Z]W53%Q%Z$&-<;E@@Vd0cJ-_1:hkH9QMj+k;G.l%L/?JVr]109ZA2d
PLe>9h6E'oBu(RE#.;8IZu.VkC^?7\[G9n$NT5%E(Bu$j5U?o8E68^r6(A?#LEX`V
m\=JENWuD5;Q)H.K=X=2M4jpX/u56eLr+nfqQ^tBbaN&\X%7JL(,BB-)C`%&0OfVj
a^Zrh6:koumBc(Fn/4e.W_sX)$/hc\KqX$%(^?-AeeA;HGX*J_,@hQ1"9T3?1q4t_
>9h6FHA3&lUNjj@bL6mBqSeW!LAf:.d#blU@nM2(KF@#)1lfi%5V\7N#j1&%'/\)a
5@W8A&r`U$ke"Vt%)s!8Tu_4LcQN:K16.4fqD/R*E7-d4&.m\S9Jf]b6r?\Z\ge"Z
?s>\7WJ'eF;0*"/0Fe2``&9Qj"TU^2F$,jIcPA*mhZlm`?Y;s<nqJk-,ETDL$\:il
pfd<<ZkO%[)aM3CDF4us+tRN#*4eocG17cLi*agNBp6)MZqg`cnL@'SWe)_e5]!QW
_6@h&XXdYP(^@(/W4,Yk\Bm"H6Q"Z<\$GUJ</uTU5WTDN1@-u)UCAge9s]5[3P`P0
2abj:=NEF[WVG7-Ne%C43=TBsi&Lrn3)JHaj'_JSa'h5<&.($%bV4ucU^TAFj/RH(
=[>c#>g^n@EC_[K\/S!LK?3!TY51VP2i^0(juSH27?jG,creLNNItWq44PQ=LTsnh
NUIqG$"?g!4'2'3R>'+sk_.2YN2L!a8f4uk%&4+$0+T6,cFo4a<J!5j!tKK9MkMJV
4Qb!"Rr_:i5bZm@&.Ac0gYu.JO<Mu(-#eML&<7oiE*uoiab&i1.KrE]L>EFt(sXsO
4tpJ&_CV(P<c9j'h89Q0FuD8?e+W>D#^G:k3=_g#$m:P)SLuo2K*^3'hP_h-cjUHi
@-#AZ;$CJ>d@c)i!)VSj5(KjW2QS%M!lL63Jaa!J!]T%*fl@Hs#Up8c+N+PYg_!XR
oS\H#mMEbRhcqk4%_i"\i*])f5qQYKOAlA?<Jblql6Sm8Y[%k"U_4(ZID:O0^)2E/
1PTLml4bqN*1FZS>Chd.Xn>SDK9C)$5_:0b7DcHAU]G`iEB&OmGlE=>W<^4q""]*>
8.[PU"9AE1Kgsi867?l)iQ3cDk2$@_Mfa`t-oj>-gAHo(Y?=^V2hq%'&OXHSCFU/S
`3A/-U.Q+ZB,ngVOrh82BocXpeUju[((:LXfjCV&;'#4t^s+Y/@,sGA"#Nm`Qtm3j
/4I\`!+R^M^aKL!$o4b^OB+Y6#(XrD*&P/Tf3>8j<5FeO(!pcsQ!sbAiS=Zl[XO""
ZRu@oFX0<cAqNW(Im?r:)$Uu28&Gm`LWjU$LI5lq(/Sm-:%c%k<#4d<k\LZf+gNAj
bh=&`0M7&,[=X0!7G0J6D;_h3bsn$U_4smT!MM_7C'rD?3+[]KQ8m<3b19a:JI\V1
P-T7KU13%'P#Q*MK%F,6>Uj/]PECk]"PfLblVe*>_K&Jg)\l">a`'PZU8WV!?)`eJ
L^_;!<+][e<';je-L-%Wi6';Hh"n$f'k@N[Bh8X-eSK!a(kXYK%>bDg8jL?=b`JdJ
l/Y$HnV-\KjcKJ+2$a]ZnXHq=E#^7u.0Kk)2H)A\@-jFLCS^pk^Y/Q]".N5(OStZp
8aSUUSPF"!*OIOV*86XB>YE-VE]7CL>N]"`T'@?TTGk*Qm!D#u0C"&<#pcP9^h0rJ
<gt5BkrYesZE3F#KA1]hDJ+@iT(P,od2FBK!C1.>FuV81"N&M)e[i.&"Pm>[GAua8
[qDA@(5I3,qroUPOB%^MPLTt:B1kNe(V9:c)?W%gc)7-Hk'`S==)hdTF%jZ\?RL,V
jsEW!%FtqK+IGLERXd,]1tn,"H9</29e.UVVR!S.+WdZ;Uj&^%#%(kfhMZr*Ac[Xq
'DnV>?:u2HQE#^D`O*S"b8)\FU>!>uqf?^C8AR]Cl!$OklV5hm+Jn`r?YS#_YPGc!
<Icu^QaY7S\90FDl?+KY')pQH(C[U$1sAd4PGV$sS<GoHbm<nYVg()<E%OM5RjCdK
1NQ:_![)0EWm_ohJQ4T;p.c;)JlQ2p=[AN:>?T2.el4W,Ci8Z(>5(H"Q=*P"MBWjQ
JFYus1Rb!?'X:PlWi-,^V$VGTdonB[l#Ht:6.MX$)fX/B&d"g!G$bK.%>,a1CT&rE
9k4,og1F&DV9gLf^3&ATK7s*NBJ1?l2N]jn81di)4u-ebYT0*X42b5i`0_/C9iUZJ
-/d#R!X**E&0NkS.@g``(*6sZYW1N*J/NtHljR!9+=5e[qN0B]`-=TcBL`mVE2'tY
pidE3qu_a/oBZpr^BYs=iINuKV_3k,4Kc=J)%s/Y%M)]M-`%4ue9'];!sue+-CK^Q
'q>_!c$:^P!qKIqINIE<I?[sk#4KhPc8c&O1qZVInQo'H:1+MVI9W1n5-g)kQR(QQ
T9T$j=Y9Gip0c[rL*5?q9>Q]MYC&fJo<;*<CAPhC7Y@D*5)M_=5=o,Y1>lJ=8dIJ.
@G!htW@6I@7&CTA$qi+jo^<p,]W"H[M(fk;4oiQ@ZB>QFVnHW\9t>$38=XFs]kK#U
h)).6WQ#'kJ,~> endstream endobj 24 0 obj << /ProcSet [ /PDF /Text ] /Font << /F3 13 0 R /F5 14 0 R /F9 25 0 R /F11 16 0 R >> /ExtGState << /GS2 17 0 R >> >> endobj 25 0 obj << /Type /Font /Subtype /Type1 /Name /F9 /FirstChar 32 /LastChar 255 /Widths [ 250 278 402 500 500 889 833 227 333 333 444 606 250 333 250 296 500 500 500 500 500 500 500 500 500 500 250 250 606 606 606 444 747 778 667 722 833 611 556 833 833 389 389 778 611 1000 833 833 611 833 722 611 667 778 778 1000 667 667 667 333 606 333 606 500 333 500 611 444 611 500 389 556 611 333 333 611 333 889 611 556 611 611 389 444 333 611 556 833 500 556 500 310 606 310 606 0 778 778 722 611 833 833 778 500 500 500 500 500 500 444 500 500 500 500 333 333 333 333 611 556 556 556 556 556 611 611 611 611 500 400 500 500 500 606 641 611 747 747 998 333 333 0 1000 833 0 606 0 0 500 611 0 0 0 0 0 438 488 0 778 556 444 278 606 0 500 0 0 500 500 1000 250 778 778 833 1000 833 500 1000 500 500 278 278 606 0 556 667 167 500 389 389 611 611 500 250 333 500 1000 778 611 778 611 611 389 389 389 389 833 833 0 833 778 778 778 333 333 333 333 333 333 333 333 333 333 333 ] /Encoding /MacRomanEncoding /BaseFont /Palatino-Bold /FontDescriptor 83 0 R >> endobj 26 0 obj << /Type /Page /Parent 18 0 R /Resources 31 0 R /Contents 30 0 R /CropBox [ 0 0 612 792 ] /B [ 29 0 R ] >> endobj 27 0 obj << /D [ 26 0 R /XYZ null null null ] >> endobj 28 0 obj << /D [ 26 0 R /XYZ null 846 null ] >> endobj 29 0 obj << /P 26 0 R /R [ 63 63 549 729 ] /V 22 0 R /N 36 0 R >> endobj 30 0 obj << /Length 3951 /Filter [ /ASCII85Decode /LZWDecode ] >> stream
J/gkM&HS[n!uqRi,>ku'5W=FR%Rs9/>X302OG\S9Go1-9Je\^@0n=jK,oFc/;=V0S
BHScD6*aEOA?[0mOih/W!M&9p,*i8(JH2LEC'Kf1AJiX/4!0R*jYCSI9Q*$4N<^Zd
ST\EsRSB[nWT<o,6B[TBF#eg.L/TUc8E']MbfXsuOj9hf+dS*YV#t+%82MM)+GN7X
&EoWb027H=L9_,>8l&HP@\qWO*>X]-V;rl33fK6$.$P2e[@5op5;Ajn9S[*a\Ai)8
9F^.e8W;h^csWMc=?+;6$]*g%;+S''23FhKFP1u-`+97@bOuWF"pULAVr]104N8LT
PL`ech6E'oCVU^F#.;8IZu.VkCWM_q[G9n$NT5%E(Bu$j5U?o8E68_<E%k`@LEX:@
NMN:.)P.7-T[_*oklOI(KEBf;P)PD?$6(:BTO\ioBom)3+n8N6&.O/'VVsMY3td=C
/8L^%#f4-kW@*_#GSl0K,I5TVN;L:2851V9e"d>fYpm:oT[<qG$^)e=Ne9mW"c\.*
`&S5NORie!%Qb6_a0&nnn0?@"#(eml,`nA7DVI:h1c(o$nV/j:X!K-EY]:Wc_6@c"
2?A>5(aLVN[M0("89,RO"*d]\."dUZiron-lJ$soGjN&l@DG_lN%N4fgl@#35V=R\
Yj`26K?2t+Kqh(L16'125WD_C+Png^K.,G6^r&_,Ju@XZhDr@EA/AF&".b-Ve^iNa
&50'p79;buCr7u],3YsO/V.^,j!TGRpIS8=8?#5c"#LWFbV0BQ0ashMmP9a*&DB1)
P6g,ZKEGoE11>e`jqe.;b$[%8.K.(\N[rsNMcZ5^lFU%@2G5YT2_\0P%G+k,1JJNZ
5We"Y(t!N_i+T&(/XP*/9B3ENiIHp*#hV$G+TTHoiLpH(3=Rkuad/TpE992q6X[g-
@gRiH:/f[C6'L)#?-X-X',G4:bp,t8!t<(rQ8c^VUplS(@jp9-LKW`sP(g/CAfEg5
]dG@<O2`puC)*ScEhZ]cfJd)?FD71]34?^V6$s=j6I*oEE?)R+Ea=)XEb^^^5_5AL
Gt!-b@Fj5CQsM4Y[q)"gY]Fo0j[[dgSN=nm1/U1=M.8J/9of776)n6h5_92K]!`MG
!='2OdF<bZ9Bnl>7t;'EYf?b0R]:fjiZe`[1=mL0+hH0)FlC2liG`fH80[UiJDkga
TO81mX$[$kO>jRIN8Brf@0?TWPm90AD:ZT'Bl,`*L6`a/K?.s@XPOHl^d,b2aE7t(
OhEp>DQ[#S5As8D&13ZGWEVJ#CTTJg29(r")TbEt:5qCW+D_FC\ku=T_#5/"JF&h)
3F5Q8-A$bSahs2n4oig/U@T`4Q_V#<@B_\F2O"Tu-t5o3"W\rm(n?V-dn\2N4H]\Z
<ZZNAFiO[M*=1g#SK^Th!76<"?t0f+$;:WD!05,6U^g:uO9QiWoLG:=B>J<R##]:6
^k;4qJSOraLM4)]Q2)=cR!/u_S2pj.fF*<;.0ZC*f)gIl9I4bLD@G/M!f"/8c0/C9
/r@FeM)PHC<2c'[Z<%+ck,3cD3$J@Z>>'cH)Hj+8Q`GBgRu)g^RJb0#d\^$Kq-bh*
a>f_h<%&Q.Y3.+l^2&RY1!TKK3)mQ5S?fkAcA?<gk@en,o'U?fjhEaO*;=+[k&JVL
i#ZMnZ^j_"J-VD4J7[6`<qFIA:KeCWB>>pf6(WkUj_Re+N5qKR=>Wm3YaT5Vg`g0i
HSa+Q)\,/k:*r"]a6/VN,R?:cE`tW%o`ZH&!f/Q<'h5.n3*Js[TlF\XIK\Tc*>]DH
2W;dOTIO9u)'Ec)0Q@8NeiJ<7ZP6VYg9WAe*3mBe@guk"1U9O!g"Oq*>1IX9#%5U*
_lG"0o(=cQ3J`)bS-4dKR%]7"o$V;-@n)$_=MX0SW_aBQYV3td2,MI?bkm'4c6=tE
KN?*E(iKk\nVB'RY*YN>'S\=(\$r8%BB3kt4CI(`"!DJOcFI2:QBa[bd^BWOM(`hV
n/:"=lqkN3@uY(=S>40_:D*cZ:A#lo.&%e\/hKPQ<;nqLGr1Gq!&Q1u2=VR5G1[YY
7]t^749ca*`#K5r#gt^&aTF1AMS7n/;<m/5A-hE#CY=pG5,eVj7kP,c-!R],qUluq
6g2)_$m<&:S-b*lAED,@(eSg"CSH5r`@X>@M[j#LF*1e7E4[tO3eJ%gJ<FL&:cF?t
7n!nTalJ*ZGI".*"YdIIAc&r)N30[3&m'*#,/CDUBgqrn,&n@F`QnlM*4rIQmj:7Y
`bPUsFT;MRl/Bi>/It6i(eaE8;(N2082M^9HdDfqWspVP\OF&DQBRSG%*<D=VpZS)
#Y>M`i:E0%gtiu4.pJ<R?7TTL%Fn='6$`[G#6`K,_^eCaTXE0TPR-ks6j&hm0GH<q
H5[[4$^FF<W@MRV>N$-6UFp\IiTWC)/LA_@q$i<D#X!!0V6OL2%Ap3lf3@R6@>Cqe
)M\bSZBdaie/AY:kXrSE[Hp8i.GFe:8L+ckJpkFi_FPafGqnC`U6M$8$-Kn2MCE*R
_g$@OlCHmiYpL1'pg8F.]NSt2%O3?pNsf)5_AC,$BFY$RaTa@@`42N6#r,[F`L+ab
K4$?IZFDr^dt,ATODHiu[[BMn+2gMW'3<mmQuaM;)_ioT9n\c?W?^KKa>rW4kp@X<
OpFaaDaTWM&P=99Ch,IR-'B8o&1!V=$p&-P5-!?Hce!W8@r49<kl3>Hf`7V.?9!6O
Il+fuc$(iI17"?MTU)uIY(K@sK=n6u&TGmJDkLYM@F_M4W])ToURM_I4^u\5om\`-
OX(3&[;NN0PBT=c+ddjl@,)f,\#(J.l`+3Aef--*p)Jh"*2I$Arp+NbBAns(Mt7uF
$[CH/N=hI4nhAb=:fo:US9'a<c9iLq]WHkDRhGXpfF9GNkC:/_Lk+/J6@P7p+GePe
SGo5g,_su;JC`S"JjY)P0Q$,l7Z2SIGLu)rDsUVRZ=Ci[g!F77o!t2Q@m&=gm!qBY
4NdfAaM=rOA-@<rmU2uDdY5>e:/iG)+GC7KKoKJh#M+[m!7)ui@O<GTB/Y3N8nb9r
bi/mTWRO't?3X&WP[u*F!+rc1$8Q*08;(#+kj3eu#U(Q,5`2(q-i4+"-mW8H6_XdK
CO.gu2[=!.;2GcR:k2#F)Fj3uHYEuq+C,;8HO9-u#V<XpJ7/f%*0P8_7khCWml(MI
T'eqR"qY2N&@Dhkd0n<96KB7eE8M(cZOG4B$4tY/`,8"7\he<u%PW;Ad-1gSXR8JZ
&<N4hOUhi(U`to!W(0hl0.&!(L+BK>&$Wc7nLXqH?:"*="\TF@d&&Q,I*IRt#VMQ*
_d<D<C'=ieAgZ;-JdD^uAA(DYWPaZZ"El+hG)5=e.KWjPVe#&0cEq-SJ;B;6;3_rL
)G&jk7=obRT]ST2GQnb-FQ?OJ0nan*\@:H`)!"O4j=ZJ[JJk7a+pfA]Z$(W%VBcbR
Np`DG`dgDYMNH&<OQ9INOi#AjTbm4(4jfJuU:)R,7_N>/7Bt9jV%uilDE_SP+Yhp`
E=!h&OWb=%+,!rD/8SZ%!uhj$+Y4\Sa1qn"*;_K9*g.qB1-5fj1-T_+*UuE4!,3\Y
D^83-*tbkK?u$MI/L>EK4]'/3E+2@+C.Tq#52r5!k`D?2Wp#PMnqdj7Z:4kjP#71=
-,gccY+0Z(,ZALZM/40rdBb9XO@^&J56>"3/s,=,Zq;VZ)tD<+B2p-r]EZg#.<&C=
cK-+1bU)=c-c3H%&qj.\*(_j=(Xet%ZO&-ZGY&Ie"p2=^%Zq`%!(nJ8/!Bcb6h#3f
7i:RB/2<s6%*&`#mk#1uqI^<YYr=HP,gFPM*2Op(66.Lh#`:E-;3OX3;<9Y8E/<i0
qd:?ja12BD0Tbl@.WK_eK1RiFf]g_n,B6cb"0B%sQ9+%c;W+#HjrajWA:#N+"V\VY
6l#u*``$8^4O_)3?tP]k+Ls;a4TI_Ra$geU-Fj1O;IUig5[?W#fH;:~> endstream endobj 31 0 obj << /ProcSet [ /PDF /Text ] /Font << /F3 13 0 R /F5 14 0 R /F7 15 0 R /F11 16 0 R >> /ExtGState << /GS2 17 0 R >> >> endobj 32 0 obj << /Type /Page /Parent 18 0 R /Resources 38 0 R /Contents 37 0 R /CropBox [ 0 0 612 792 ] /B [ 36 0 R ] >> endobj 33 0 obj << /D [ 32 0 R /XYZ null null null ] >> endobj 34 0 obj << /D [ 32 0 R /XYZ null 767 null ] >> endobj 35 0 obj << /D [ 32 0 R /XYZ null 767 null ] >> endobj 36 0 obj << /P 32 0 R /R [ 63 63 549 729 ] /V 29 0 R /N 43 0 R >> endobj 37 0 obj << /Length 3795 /Filter [ /ASCII85Decode /LZWDecode ] >> stream
J/gkM&HS[n!uqRi,>ku'5W=FR%Rs9/>X302OG\S9Go1-9Je\^@0n=jK,oF`n6O66<
E&8+@%A;B'ShaCZ$cqEaOFYVt&.qP8d6N4[<&FbKZ*K=#2][t#A9+(q<i@sKNQ-U5
E6c-ORE]@8RG@Lc6(uCmL,l'JmmJUiaWtj,<9@aP:^H5_8W_+cUsd)`-mT]C$4oQJ
d0Ohh.i5*R#fBdJ`ht2b8qo#kFM_TWUJ`O?b`$`p;Nb$k&qRue[9Tn*oAY?.OR-C7
(sJjKM7hb\0q@_O4<+h=#8k<dE?&L].2Ik3Z;hmQV_M-g$tK+f#(q\_VY$l+=Vk9u
M&Bk^p"KDhA2YBG`M5`$F?hDsN.%0>,nR/j%V&&d2^AEC@MT(J;!KtJT`AU@_#]@4
*/<nX2NimSC3h0UUJiX(U^8H<&.;t48hrBM0Pp-2JWO-Z-=Np_LW-NC5W/Y;Ru6:3
$rS.&Z-ItGc*^+E#jeg1Hb,rg^h^fHaH!klXG/HNi#B;%J6Wp[X)Jt/K`XpR3Xl0`
J2+iKik-3=j/D#mNfXh."AFnjj:m@M6l.hBY\;ZGN)Ou^4G3fPE%m72.Y'44K4$r"
:(r0K3)MsDE8D&qW8rPi__Bq-:t(@-&.CoSkW=`u.,5MpU7daZKs/sgSr/TqZkruu
o%u,1UNjj@NKd7E&6OO[b+MSKFV$=SUN#E.%MQI;'FjHVk+GDtGk5JUXp$eCc4b.q
BoJa!>!%]Y;D'`C(%$KYd<:cG57QW[r%_$68Fok^^hBY]9Ar:dB+@l@l8h5+9fl/#
1QXj_%JYA"M,+f3g_S4tB]_F;GX1"lfTR's#)H\i<Y,c5pt:#t&0)WG=:OC,1#>2b
R8j`]@+djUQ`/#T<VQ?("%\$?GC^3U%BiCg='Kk(j8he`)n(V,a_]Zi*:mpm8d24L
c,6(98`;X75r`<(aQb`_(diRAe='C[1$L`&JRFE]Puh#M3!.U=K`_V!2rO=Sn2-0M
fKm)_9>)+66(3&>(J1\QPf1+q".mRr68Ypr9!U*:m%q!dB$db6-TfYc]aM!EVm0H:
REP^<;At:i.*Zp><oq#dhUkZMT2QsOdA:Ld-S6D2/8mH1WT`rpWM#E=*:0Bt11qpj
:BO8SF<7Ha.>.`+@f"7<bdJKlRQ.Km^mRaS2>C<>dkZ-B%D":6q=fPo+1VPKlkML7
2&O6`MoH1!N&@jci6+K/4+[mRh^CbH)4;EX:FIfR#*euT=qE8djKU?b"TG&ub(NtK
Q28,sm\^nT).RK*AhjVJ\t>2Y%F5GE^MqOsS)KN$Ndr"!i,F_XLc,FPcl<olC3PXM
<<^2!qB'sG'&mU[5G4Yc"rAatc<6'H7QorU2l8jt&L^3.bg&AMT^#Erh`?OX.)%B#
eB6],#:<7d!sG\7P/3ba#i.`o,m]rjQo87V+fqe"hADOaD+s*M&-joGT0[87"e`pU
`ACX2O>H6]7CAmE(,FKo)dlTb=cp$i)W"ZH2H%>Ah4and*$f<($ns-20bio[)6Am^
/lEgT=Z0>IZ(>"<D-TD(:k"]Q;@K7T^,!3/bl^LU:,)&SRtTM$_#S$W&1rOE-%c)f
`4moNc4)L?1Edo.K2TP5SA:nF$t$Uh-7^+tb[k?6U3hAt.qW(B5jHX]fp`0gT`bR-
_AYe+&e(lk6:2=*`'^O*S!0ouZ2fi]k6Q<^6,I\qVijPZ):\s@(6tQa[i:pt8QIP[
*!;("-GdJMI5*nt-*V&qMdRq9X1;U\d+TO.UN?uST]+5T>R[WcUSpKHVOqs9:ZbMB
A$)I(#@QCq5l`ABiI,;f:rjN9=CV_hU9@St<#@s[.0K\<k>5d_V1[tnWiF(:eJOoT
KC+#co_tgjds5&r+Dn41T\S,1%9RD*H8JV_W%1EI$!EX3%]/uVe=b.rK1oWBObFmi
kfFg>4EZWS3#T;+4SISs`(BKen@C!g%3h'!/0r0B-30PT_mh-#+NfF6e.r<<ig(%n
nMCI!IlZ4tSl)rsTMfHU8dHT=V.O2&gP<+Nj*2#6+OCo:!YTnGbrn^b!29Nt.h>r'
/Ur^f\gUaEB<;>a5?:ga?Js-ZDm`.GPq4SDFP[u<Fn5n^^5Rgi?I*"5C^'NEc(NEe
'/3g8_:V%C@.aMJ_e&tg!RCIL+Blq;Fsd`lJ1an:7*pf@`5Y'N?Wl\_jjEVC81noG
a#Bu7ODm$J2hIFO.oC.iYum%Mf%iqbfm84&:2&r2X@s@X[AB<#6kbGu1RTA<;cQYi
i>Rs$8<aM`aTMg)Be#8_[qoj<1J<M\25"Te?gne'`pYZ;>%E<LEV*qc#Gh#k$Y&k;
"f[J1)$`\>FSW4IIul;0'P7tAR36hYB.PK#\@=$3@)V=_7F=35[@IPdoS%uLN6T>c
A?h'j5uoa_QR.OaXQ:@.<>7c%S'8p@8t8KY3M6pfK";@$jl*(V:;S)/opiH].'.QU
h:Tm#V*Rk'[$^+@jEFh&dNS)+\J%?AXF$\I!YS-s["O&cA61O(CdIYR>#pnVJJQFk
L%*&W1K/E#G..-L$&sf,=l$)*KSG$bP?>$=@[;ga%bC7Q>:&3)KctdMK/+Pg/>XAR
)[9VN1[<W:A6gBob$YRC$K;9Z;@Em^L(.fT/O,Tr66GLdSB*VLe4CH&@.bdAQT"$L
nptnNk]aVLrp8(5=efhS9?mOX=q]l`6P4[TP]s.E(;&=J_bK[8G`$K=5"B:&S=mW^
rr6@6j[a_PA\bet"J:&XK5c.e_n9Bliq<CLOh&+.[4T&$Y01mP%s+&p\VT9@iSjqf
/s=t'b\,CqC%P.kNm_s7mR3O\cQAU`Gq,a=XlF=<)A7Ip&10*0FR[dK%h6a+%%KDa
C2(f^14[sS\f1U=$Kc"LTXWcWs*Y[Q-Xjes;]Ne>s1/(DN!<19mQ,h^\"fhY8EXOd
As]^cU]K;5E1_i&Q6OX`fm$e<=?46`/>CX3T\pdB3A27[bq9-f4%R(]nN/:dLB-dt
ADi+Zp<:VBW9?,GP!&lXMMe4pCBjQAC?4k(cO=W:U,I:6[e\-l[Z/#JDnPqI@/B=J
"6ZaG-"P(b*!Q^1af,L*$-LHWPW+DErZt0GKufFmfPrTYIK2VD-O<XgHsnAiB?$U.
6FaODL?.h>M<)H@`J?.elL9X82il&Y`tC$YlMaA(i5G?J&?\iC5[XuL,USNX-nl-C
ed_jID9*k*n:FK9G"e\K?R4uIYeEo9&oSo@;Qsn5cu,;&d_mfqP,F?JYkDJ$.]m:s
%"j(*#8@S8p6_gEf*_Kc.q854:aKgB-_P4P/YN4*j?cD']?c<J%?RSc,j!B,7r3-i
Y:fY?4Sp[[c:H[\d9?/I_$%jG6>`)5-$#(+&iO84!6p$;#aUN=',:tNl=i9a+DdqF
51o7snj(k'O^Q4Cb4IE5[:n2Mbmaf:Tc:*N8u(ZQ+rqLP*uJY!5mfktK1-GD>*H0m
+`Wna6UXs0c3CEt)KA*Ii5ed#Yk$2Kq[@q"aOm>.7(b)`*-#Zqj5>?*JB<=Y*JOWY
T]us-@cN".Xss#)CPH#Q?7;t5&7c]S-gM/EnC6t#$o%No:uDh_#S"inQR/U/OUQ2c
XCn3_%;@Ys-ZC=!r01q!"UQ_UVQQDAroRf<>:N>g0Fj'-[OS:Xh86K<1%IWrb3Hn6
5-EI$Y.2/u^qIjkn8SqX:Qc.Q"S#.snZU57'%4Qm<`jlM"f[Z_i(sPa5RAbE%gi+"
9)LoZ`[B'f$BicSVWf[n(d@NI$rZ)&O]O0.D?^b'0-EOQT\L$_r.l\R0QP;gP9(0s
'eRPd1c$?7j'sj[V@D[N@&&C2,6T,3~> endstream endobj 38 0 obj << /ProcSet [ /PDF /Text ] /Font << /F3 13 0 R /F5 14 0 R /F7 15 0 R /F11 16 0 R >> /ExtGState << /GS2 17 0 R >> >> endobj 39 0 obj << /Type /Page /Parent 18 0 R /Resources 45 0 R /Contents 44 0 R /CropBox [ 0 0 612 792 ] /B [ 43 0 R ] >> endobj 40 0 obj << /D [ 39 0 R /XYZ null 510 null ] >> endobj 41 0 obj << /D [ 39 0 R /XYZ null null null ] >> endobj 42 0 obj << /D [ 39 0 R /XYZ null 522 null ] >> endobj 43 0 obj << /P 39 0 R /R [ 63 63 549 729 ] /V 36 0 R /N 50 0 R >> endobj 44 0 obj << /Length 4412 /Filter [ /ASCII85Decode /LZWDecode ] >> stream
J/gkM&HS[n!uqRi,>ku'5W=FR%Rs9/>X302OG\S9Go1-9Je\^@0n=jK,oF`n@j/KI
E&8+@%A;B'ShaCZ$cqEaOFYVt&.qP8d6N4[<&FbKZ*K=#2][t#A9+(q<i@sKNQ-U5
E6c-ORE]@8RG@Lc6(uCmL,l'JmmJUiaWtj,<9@aP:^H5_8W_+cUsd)`-mT]C$4oQJ
d0Ohh.i5*R#fBdJ`ht2b8qq@`]Y;3MUJ`O?b`$`p;Nb$k&qS&C[p?2]W.Yg-fYVM\
R7reXH,.j<3T)`=3#i\D0ndF'367=^/JsIXW]=ok@]<\8kI+>r((-PYW+BLF>g=U+
Pc\";dJhe>CcC;\7Y=n.J6FlKlog"o+^4@qN?`]'O9NIV=:bd+W8'.]!K^prL*=WY
pbYYW8gAndk`i*,9W7B@,bes;/W6SVaPsG?Z9GAp6$"HBL8rrK)F^a#fER4N,EThu
89uK#3UDQ2Ji^ss]_"9WS%/m5Nf8_C,R>TuLP@NsD"k9pKF/]r!i"O'K`XpP2i^0s
O;'@cO?bTqJH4mj6%`Rn0b.^'dPHo9(t]W7@sC:"$q$,n3=dofr&`,T>RiTNLq(U`
-j-:C0gUGBfJ'cdf[Bk[1\ff]N$G,#!KQc)b;6tuHN#OSJl:;<^Fhj!.R0*C?l624
n/F%iK?2h%NNN.A0[1aE5lln$n8($^6_IZq-6Yp#(^1#bI8CB*AICGV.L!Bp;ko`N
3KA_?gHWu*'aP?ZK2#)\"Tp0n8R5f`:c+->GZ.XCaR#MJ#!nne(^DgX>q;bZUHmcC
!HMM4^A'gqK`qL%l8akjGhGlO,A&en];XHijKU=BIciHs!^-!&E[%V1#)Rso0$-fq
""(#C>>ZchY:sc/.fm^V)a[Ym&t-rE"Nc)BXHieM<Z1bITa(?K@fAr686YW!fP4`G
ig@//O,R3MFco7tA:^!./t9nQA`3W$)T?_l(FB0crnE_]H#c`59"5O=Ta&?QItUHF
Eel=O2LV7nn5[*f(5?8)])Dl@[&_/>!kdImbdW6>2cF3G5s%g4FPm]?@mpVY?4GH3
0i2s?m/PRS3:]"gT`Ee#d%`SD7^!VQ;)XE/.-<OK4q`B+Nh[H=E)Ji(fkcZ>YhdcB
QfsF,]Qt5GTl+[QmAtlMhPqKKW-4mOAj!iW>@o=AfX3<i5c\7N6Y0/fR+e3<Y0B#*
FRl$PlS^_=N?0ib)TiPBHY73k.(:=8Pb1&F43!PV*CeuEaE]q#kuik/([Oj5(c#n6
HkZ`Ld'qNYm=7t]eLDA7S3qV@0+OL+PQV[;?gI^p$RNrsaDU;aF2iAq!SX[[)X'IR
$3dGdjLF<EZpDbgGi5E56oC5ASSPE/!KlfMojSCGR^HO9iQ_L\QlMI.F$T#i@B<Kf
)oGn1Gg>e7]eqhf_g:!B8r3R*TZdZDKM!o@PW:9/(2h$ATa_%I`rqe@*@!'5E!K56
,3.fV)>H,pXb!Q=VAb+k'CV/`OJ4-/$D%pZHk#J3"rsBRaio,E3_f/U_,+_QbiBXX
c0ATN1n^&\S>1&mQ2/:[6OP(\2LiXZTEa?2UK#t*%E]ADa`QHHf4+/k$cRCg8E-B'
I,fK<e2@P#]Vc;[`LLcrXTF<['@7S5%I9/6.>V;^j,bC-DY7M@B3b/\8oT`bPuo/2
d+.)A[nEs1NPhRA?/lReH;YqY!W^04?BM]*mZo*4YgOQn!+cVUg2SH]"S+p#NAf2$
+AFjOpZ1#f-&$Kb&d#S.8IVFT8SK]:Q!mJ)PsHgL0Hp\iQkD^s;@"F:/;<Sd&43$\
QA-Gb,Np4%@,l-9ZQ18/dTk$9]/OXcL0d/6Sdb_2l3>7)L''?8Cm,!&#g'G/LP:6d
@jipqljU)EeR_,j_*h2B0HD,^1uBAe<IC#oR@3fs@$9"/Ec8)Rd0DGBhl1B>J<e\J
3`I,N"\boG6E*sWX]>Kg+9fRE(P[Isnj.Sd$mFm8#EW:<6PsTaY:6bW[!,SU<"Q0q
)4lI7E(b#HgOi2Z@_q?bP_nT]9"!Lh=sl07e^u8U+JncG<;Q/c/2gCWdRGhhi?Dp)
rgJ]^F9^[T5b6nLT0\W`+NI=Nj/)7A_8757(K3r%!IbH;3Yt-e,.3%tJ7"G-LIRH\
Y(8pl>>)4%+N?'+,GN:f+LF.:@*sdhU2@h6ck_<d:ssuLKKs9Er!-3NS?K:]?H(cS
TZ;M3jGUlpN]OkNWqrqN=<OlGMT;0D,"Z,ce#`7H"^!#?HI&fO?s-ol=n#j59400T
J[!s^fYU&$hFA$`/2)d$"<7G_Ia(nH31k"[7r>B;%(>4PgUhfNeA]:Mc&s6[_aQp'
a>2.B5bc5BXp[R.H++RSh?I24E&8<J:^>W29)&oJO1')4frb9I.u`1)EQtQnWj+M:
aP;?h8?EDs%I2*jX4!IlW08pCAf+d*/9NpjJB4l;U)XU69:KCY<h5iQ5F$eB8]&9<
&n5]R"(f/Q835Je2\9X223q4/G:r2rn7#J-LbL3flL%L\B$cgl8N40%Pad3[?_4>Y
J4bhh7#Eb4:"k,';8e(8'`C;cf(ZqU!8F!PKfbV(HU1Mm$%gXiqalKrU$O8IJqmW)
*o6H@l8D=Hc%Kg?g[KWNaiYpS)7'og30bbjY4C^(C8u\ZWc_@CeX`ma--"\k>Ete4
5[qs7'6on"LMjs2cG6eaPX^X4`*Fj))JQ5IETW,P^=V0%.I.=7&m90*RT$+\?tKfj
VbWn(iB%-L+:b*^,NJV[o93?pi>:!$_nI&T"/:EFW`e7X:&aSsA6+Yd$<j`@Z`:SK
OsR3rKUlQcdB86rX^*J&GrRtK9!J[pDH3<]#:+K0,/..e#UVp(gW4!j+:)AV't`lJ
s,IJ3nZA^^[`b]*m^OB/OCMGL3nLi%,B<?`d^sX"B:"1%$&+tI?`XgZ*GHn+p3tTk
n@9,DMnLk(NjAck5-`m^'(?A#"`pQaoPN)-i`qD18k"+G[u(6O<"*&4[+u;1Wt:uG
gA>f)^Q3>q`QCGV(3W-&?*%RHVc`@pi(Shmj=Cr2,hi2ENkg=t;e6gDi6i-)6Jmh&
2kogFA-<(WapNYu_WY)/DZWm6Y)iY=>_o&!-0X<DPjG=];kV'+NVZSX2#V(b%BrgK
C)H:BjAs;0NMeo+N-bBcju4ZRhk7n@N6%fV#lCh9>GMb(i\"$IOuDS,n*H'@B3>)U
&.G?E<6<YL0]#a$bRC04Tk!GJln#Ce_$9B=p*AK)T\9fIk^)AL6gGZ-A+J9m-DuX[
9E;S1+DM'+?j6]k"TX?D9MeTiq!\hb#%RlA^f#8GatFqGOQ^LjYL&nP!/N%X"UV8-
VE,4MJDl%F%H@6M/;F_\1r@W\&eQB80e*NaUfrK'`rO\dNqWp>r)&CQF`7VJ%+bgh
eAL]@O6^](mK*hMqMW>p$u]fCbg)bEaMeB(N3O"9YjVQ%`.b-r-jdKd-WlHXDW-=.
;6OI8DqL52"!$L[%gjHrUZWH`-sD.ucUb!hOFUQr(CGqb?#43l`P;oMf*8&i%WBMf
k@WXbPfSaWe8#gbnWYF6TYa0f+-G!UjsW1/r&8Ej-df[Ll;UX$AB'<OmuSD275gcu
8gu<[PD0u+!a9K"#j(++BB/,0N\%?\.+*_K%,f,6?sF*mIdtRnndg-4O-5/,R$]Oa
gi&;L%:7fLkTM'ZoYr.m"I)1=Jp[Vh7B58jnqAN0Q9HPa6>`>I,PICujp^]m.Pdmq
NO:8"4"Ll!g[(fK;S;47#i!BN5c+fQZHT8J/3rY'/S];OC)UKWKeF'p1eb=^_L!^e
L15i:YR\1d7N;Ueq]//1>_'p8^fN28FK:S'\Lgl;9#iW_W:NB2o8Qq?V>^\;ZuBJ>
\an%gNW`0lirr2g.*6ramP[:m!>7+7&tl&HUNVZ[Td<J3Ls_0:DX>FmBFX-B9i+JF
Y2lH4fZ'RLj6V(skE;H.i"&=h*6&L0&U)QUls#'lGNB2Io@aVGf^=U%]]9o/!q%HE
C_#CH4L&qmP"e.qf+IQU3jK%;Vi7Bh"?5iH5[s)V7u$E\2@O<P:i&%Z.W6nh)WlaO
1M3YO7M;Y!+Kj/8j!#=R!Z9=K[KXW&HXL*/o)@/desB:>0ljW*ZZdq&Ph_L^QcQI$
aOo_=)_sdi/P]#/7Xi`O#tFPq1T%NCK!6AX/Of;P@[)(,T[!_f3";+(naqT.PB/I>
75p3A2[s$UV5A\QRn?V?8u]0VF"D6e)Bom)9U'"g-do5u7KpSJh=Pftm,:YQe.3h]
5ZHJf[,3D+j"!G>0]m.*07Qo6.]G(i"tq<@FS]\Xm*WV&$P-Qcd'iZ=&H$O@T1jcr
DqPEYRT9o-.o@(&Ya2MN-7Fk&"9RR8Bu:.njpnNX#*/j61#dI)^^Q;E<,`rgKg-+U
<<b-J$qGP>[:93b&B8?a'&^d.F.j*mg0LYB'P.W,Vb]QGp@2TM+<U~> endstream endobj 45 0 obj << /ProcSet [ /PDF /Text ] /Font << /F3 13 0 R /F5 14 0 R /F7 15 0 R /F11 16 0 R >> /ExtGState << /GS2 17 0 R >> >> endobj 46 0 obj << /Type /Page /Parent 18 0 R /Resources 52 0 R /Contents 51 0 R /CropBox [ 0 0 612 792 ] /B [ 50 0 R ] >> endobj 47 0 obj << /D [ 46 0 R /XYZ null 852 null ] >> endobj 48 0 obj << /D [ 46 0 R /XYZ null null null ] >> endobj 49 0 obj << /D [ 46 0 R /XYZ null 837 null ] >> endobj 50 0 obj << /P 46 0 R /R [ 63 63 549 729 ] /V 43 0 R /N 56 0 R >> endobj 51 0 obj << /Length 3808 /Filter [ /ASCII85Decode /LZWDecode ] >> stream
J/gkM&HS[n!uqRi,>ku'5W=FR%Rs9/>X302OG\S9Go1-9Je\^@0n=jK,oF`nK8D#3
E&8+@%A;B'ShaCZ$cqEaOFYVt&.qP8d6N4[<&FbKZ*K=#2][t#A9+(q<i@sKNQ-U5
E6c-ORE]@8RG@Lc6(uCmL,l'JmmJUiaWtj,<9@aP:^H5_8W_+cUsd)`-mT]C$4oQJ
d0Ohh.i5*R#fBdJ`ht2b8r"#SFM_TWUJ`O?b`$`p;Nb$k&rC-_[p?3#`<6htfYVM\
R7reXH,.j<3T)`=3#i\D0ndF'367=^/JsIXW]=ok@]:m#B5AIr((-PYW+BLF>g=U+
g"4iNq]V'REP`KN#.;hYZu.VNHH;=;[G^1(NT5%E(Bu$j5U?o8E68^r6(A?#LEX`V
m\=JENWuDU;Q;T0UUi^RM4jpX/u56eMSfYBi+Nu3bbA\fX)2r\apil7VW'TE6PP<M
/9@E2Lr$^AWM(rM&s].Cdq$h0/L/(SaD<ttLT;SM'%mR9F8ioW"/+$FXt-$R4H9Ll
=u"4\(tQ>dOi*@#\T-r*a@Yfh`YbA/Z3[S5.=8Ltc*$o7O%M4G<0/5[^d.WX@BaSl
1Z<jh(a6bjhCXE_UqRC6/"kr;LB0dU3Xm<M(-5-Q1se#&9>EeP%>+rWTF;tD`]4Jc
+N?*pLlbNq"Ts#&"cY2M]`j@)Gi_`R'k$5:2lja3;F!-jbt]laT\;>`K<9kgKu$<k
.LAa]>5UAekc"I.6%EHf/`AsYB8sfWT)ak'c##:sC'BV/2T'#$>i.nsXuHma.-Xf5
'.E#G$q%.h?4LIi5W6(2#gP3(!Z4rQTVHVD>Rlb*Es">fgr_Vcekk)YZpLEbRSn*>
g]l40Kpbck,F$5(bi8ul;@UN,X]OI+Fr%`D"2)AL5u#G_3K,2Eo3]fE5[4jI,='\M
0&mtO!G>F3GWRRgi'E7MfaId8N>?sXMeUb2$9DEn+<-_#['GKC%J\um1_&sIF/IVl
mSGi$H?JnulgjF$44[WI$ZJhA,i9WQOn@m(aA#+\6hG-JZTh$'%"Zd:SK"Z3VkLI?
mF)-55SsY>83eqj/*6mg[gW/TEj/fuFZ?Y4S"W-nb+/%':LVJ2e0]8>7.3YfC'Wpu
'Mi4_"k7Z;R>&+dF2(WfkWh23oqF&meA5h;Tf57;_DlA?!8]ES'(.<j"*5A_XVldG
V-FlRRaY7eJ.MipPjZH,n5]RT!sY$n*^b0pIa%-m+Lg#(gWJVrMmOHW!f3sd.nWgc
#rR;7\.$381,q[E6Q1Je%S6XZ"i/n3V/uA'MF]=R#S?_P:h(!/j?@135t\<s!$+E>
_ZTt=ba<I9@agI#H"T]8]u:Ol6%VEp:K8_]2$Fd:'OFVOa;?,A7h7o'iDJcU&jg.a
$d`Vm?gKXM0?%0:_anTFTs-J1nC@j_CHdF]<F%3=WnP@b\7ho<B"sTt`uY=/Chm2c
JCVqo+Y5TXkRnMl("gdI6=+QV,#(.ljrIgp6A<e')&ao:5p<L<#70DO!oS,/jY>OI
5dVCD^i#F31i\lOiH:AM^D#U_AIIJ6.\iB6NugtuHSKZk&3st=9O$#68MgXkF2Jo.
l3p+"KGbF)(o(T/T8rEV)7?o_&luU:@d?bf\JAA#6R+!ll'T+La<'DMi+6<tab>I<
_XQXU0g9Z+JkSMB%?0iSI&ti?5(HHB*%5A.afqlKM"IRs^iW9^%9LngUei%gaUP8c
hlSj&(mi\N%+"HVb,(^\+B&cBC[(O8[;'QD^h$LT*&9ff>:2unUKoYY[4-&k)3\OS
BhuE@5falH_^lCsCCZQ$[TalE/M&QkNECr^VLT</SX/M0*#XQP2rV\bS8rlM7jNd"
Pa!n.<,$N.6TeR!8uXJe?>)bS\.jQF]E`'VW1StO0Pj?mZ!`1)/'+U>/EN!'JO2o\
2Iansagqnh1(;DH5S9e9e$RSdj%X_Yntt4+:Ige>=/^ZfXimi+:O!EQ73,a1TeWeU
qA4c<Ck@i6G@JPH3YVc,mbR)@GP,i;'EE7a_DF,2Q.2hcE+Kla'u)pTfbT3<*>"rF
)[7&rjV0uS@pl.,=,7dI5Hs>nCnsN(em;s?JG3\n*0EM=+t;FTY"%fYE/PB@+/`8P
DS`D.+nqih]o4O\Sq9qOZ%h<g)sY%2CH#/m#!k(jpB'"U]75C*[FD-5fq@\fTco\K
Z5/de'1')9iJ,r>QR&Q\8nX4/pbf6Om]?R*)5jKPKW?#`6nGF8Y\j&X[P6jqK7Q:c
'CGjTH<@:P/Zu\Qn_Yk;JCL&nYf;jKSLc2r+=*N8QIgjr?8W7!_4.>Yd?+,*89J?t
Jakp76MT2;%c?YjNba1;*s)H:IY250[OXQI'V)L\+oVnW)G`uiHh!u:n0$2^maPUp
mATZSQ38+u9PU>UhZ61P[#Fl[CFg;0[C)n\Rf?K)>qrMU%CD#F8o,L#[>4/aksbfb
%Q^_bSaIOCR&Ap5>a![`!C0_#i.;A'Wn1Hp`C>sq-*^M[j"+:&S#lGBQ<j>1>g5^u
,dlGCiOoJ&c\ukLi3\4?m1D$jQ1WhhTK=ikG0<6t>h:lk.>ADD$>l3K_Cfj[iE)G$
nHpt`)ueaRmQZLKmb.l/f5BSb^:Rlm.Kp?_k(@.6Zdi5o?e7t,X@9;,g9*CDiRLk,
Yi*ld\[ul3eiZ;On"15R/)\4mar9s087DF-R#AGR+'u#W]#-?/!5ac"*IfqOgW8('
H8KIY0LIeiJ&A6IPP4?1F,K-kSQrIFQ5(dk>OX&%'@tN+JhFa0Y;fmZmi(f\/^hOX
=."3(^R7]j.;!>^4_r('YP%8'm`'*GGB4U@/&?Ik*JU<[\OclW@",TjY*[N)qL`-Z
lft4.54YHG76])gn=OK;rO6T[,otcH:(Nl(#NFLMcAM_=2DU(G8TNF_J\=6q4D2*0
FpPlbIDuHV?ZI*Lh?iTJLD*aXn))l;47MDtG3(>tCAb'TTfGMJL&fUmRC!h):TPt*
Yg75a,\.hnU-A:s_#5q+7V#p#YL'Tb>Zp9hq+`j87m)]Jiq]`D#7Uh(9s!ce39;8p
+fTkO0;uglr;8%Gip#h!`[\'e!*=^9=G:Ds@r`%d)Lf^DPGs@p"EO)"[]6IFT1TI2
#TaHEE"8W5U#u!I,ZqV"1@.UYk!4_U$abA_7P?7L]$>b'C61[cf[a^K]<#mQVsFkI
.Kfp0aC*Yla;ej8_LbD$+K-oF+@$A9_Dc%@%*dFgBNTLUT"msq^neVYi)ok+kg/9%
#7%-eNjQ\Knij%5i=-dFktp?5q?.&c%Se;OBVkqu<8u1WrN2Hqm@OMOSD$P`q$dW/
c^>M`G#:M7!"SjDU=d1N_Nb9]aTd:Y,h?VM!6(l3#:5sq-C5+_#)o\R3f)EdCRclR
R_DA/pPg@_ECBr'P658`5%gZHK%.#br_a**#D73&:7sHMg]m)d)J@9NXbPhtZ<SsS
HUHp"AGmJs4Q[6sg]k9a!:HXT8-XrFaQ`uPk4FI$lA)Po>n8VpN!AbYXV_<RE$Bg=
VBub--rsnqIc0GsNRK#sr/a0IXi?5aCT_(MV@=ZdO<noV-92PC^oU'RTLs`qM)_4=
E/t!5&OTC!,$c*b+J#K.f1@2$/&6L)fU\q3o-=U,#k0U),0c%Qc-*V+cC"WPI(X#;
#1;0R@m"'P5oVSB8gPA[P+*Ws6NsDr156uUl_Ib&FppbS\Y*hM7Q1j5h'WboImlPs
WU'`u%,A(7ljO)cYmDT;QQf/>c0-p:7XYj-J.6(I2f_fhaeB6?%,A-L5Y(kbV0L%[
'$(3k>:9?@BNd=_6Ro9/2^dr?$I9k$7(!Hk%W(d-JcY~> endstream endobj 52 0 obj << /ProcSet [ /PDF /Text ] /Font << /F3 13 0 R /F5 14 0 R /F7 15 0 R /F11 16 0 R >> /ExtGState << /GS2 17 0 R >> >> endobj 53 0 obj << /Type /Page /Parent 18 0 R /Resources 58 0 R /Contents 57 0 R /CropBox [ 0 0 612 792 ] /B [ 56 0 R ] >> endobj 54 0 obj << /D [ 53 0 R /XYZ null null null ] >> endobj 55 0 obj << /D [ 53 0 R /XYZ null 476 null ] >> endobj 56 0 obj << /P 53 0 R /R [ 63 63 549 729 ] /V 50 0 R /N 63 0 R >> endobj 57 0 obj << /Length 2754 /Filter [ /ASCII85Decode /LZWDecode ] >> stream
J.RTgd<QR@+;fnAL1"]5?m(6BiPGW*as](dMhZ5];7%8Q1P84eJH3?C;i;O=@KIuf
570-gb(jqLTVbd9Oi.E%R?Ze`,FqOU6R\b/C4[%PY_Z76*%i4!+[eo$"NYa?RuCrX
,UhMg1mlR1C.&gJ$&+"$@mP5i*`T-H#")hDO;]\h%:_^*B\[)9Na*p-C%9EqD`9ud
_\$:,P]\o&6j"U(1h&HbNUF_e*'B5jM\<$ZWaX`r%jm)?A_;9k)B^km!Ma<fgh8IO
La0f>`*[LW2?QQl-l`q2$+*&)2(3r,*Dmc7/J6rT^g&Q3%42`cGeOl'2B)c(6UjW1
GrT>nIT%,eIH*.$:4`Q*b[`OT)\)fkq8<.,L.YXTY.t(2Ub[lR@%]Oj:[$a;5XU_\
16*gsYVlobE9J)jaEUn'L/A;TRY7G,gbc`R./(87;#"<-U<F6dS-\-P%Ps(hR-:.K
UC7#6%-$2B!!Z6Bp,YLdHgJnj!LsZ'_/O2i-&$o#\.j^6ZLGRr&JSagO/oS1VCaD^
R"QV2W'D:`+`M6:#3b>_R(BH3d$b>N5_qA?%tns7%V%c\3fT$_i]./cLi=%:K4+6]
%&:/c0euF[[Q0@X#j"Rt6:aB:dQms[8Ie^O[6_]%ob0cpJH3Ou$tBWj&.\.\&Ocj6
0[W+Fop%p#N+$Bt/rG6Y?PcR:MQ"#1(!SI-%l1a80b1CSdPFnL%3RQ0@kbbVgPfh;
6.QCa5VilB]b[`a%$_DnZ2nY&1l\[pd.KP_F\<AXK6TX::P3W4>!=U1`]D\.bVrt_
[QAFGc&isH(^A&]ROSIaaC#]giG9qN5qpR92qnBN<Ya0fARqC/F8OrU;7147=&9^0
_+cj\b9KD5_*t8:[L$8.2lMW%B31)'e),W5Q8C_=ff59K#1"N]lMk-JYh`MP$Hfdn
"9AL^FOC9,_D[Dc_\t87$o3Z;]Sr-&n;ZJ@qD%)2^rhqoC%X>`Kb%H1*GMNIbiF>X
=s=M<_1JC"L<>=Nl=+YS\%qG]=Fq(p@0$0UW:i?cAL>%/<Y,O&!-Ab^"/s-r/0P6W
cL^A+W"jEea?UpA?"[Hq%"1W+cZBLaDqt!E-TToQ5!LdNLqW7]fCgC-)sR+u#F%CI
M^f/k.EG:$1JL06@-^PYO!crbU8,m$j0)a>I8ns1Lm>W:rV:q\2`T[M)m]TB!L,VX
[g;1m0utfH,r<'ZU(%.8'n'fGllDat9N0-(#GCnOKHhE.M.<+\."('FFG>t78i]o1
"qS'X<b#Hp.X"B@_Rt!]l<rAaKF^L*U$uS%iWLVs0(KlGkX,qjU;U0\fG$EgEp$ll
,6fN+m)1#X$rkE^M(CP34K+kX@I-pMO]j:cn;.q?>IXhI7PCVU&GOsHApe<gMZZHh
S!/GE/`am-R>.T1?ZHfZiK6=,V/guMQoA+Y'm?mL:>\F&Iod*d7)EQOf[VB]CsAZ]
.cB*W_g#W";CiA78)S\hU%S[V"X^9=^j(r3F'lb:0pT!$*?6S*0jrtg5sqIj_*ju]
@?*fLA'ZVIoH6D<Kh<j,lE&`tZ][qcCn<!1)H;i)%+5tOL<r0mA4S*S/V"B8L?bR7
;`uk6TqJD.hL*\cB0do)Ig1,lH"!b`@W4eE:A&G?6d1f"+JMN;8Mo,T87aNU]JCE3
LgeM!?Z4-5!>pQ*0Vp&LE"dCb.>U=HQI'N?lFL/R=`5[a/>A8JjI%RQ1p/7eVPDUj
)pT]h&rK;$N[.ctO^usFd>8p+!2LSh[I1S&dQhcNN]=`sV"k;$p+;?&4WSK\6-5Tq
"T_m!R#paI6X"nUa-#2`H904XBf@Chr2r8<r-C_nkRLO93).QS.FnR+U5TOR#=.\p
:s/ecdpT=VaaF>YCs*5ZaRqQZpGj=:qB]Rd9eS3?TbPq82@Z@]Ybh_7CA;hN0FG(>
K63e'SI%1`DS_)t]GY?*$=b4$@"O\&^VbIN=d<_!LGm^m'd8=+e249\2VP4-1$Z:s
a]>fZeuPF\mque'!3eBg:*<3fJW;>f))H)Ojnod4YZR9EJF&m8kUHk=p/YL8cj0YO
[gku8c6C3:Mph-8H6B2TK@B''mtLDJ:D=#Oa#49h)=tVb$No9S9Ffech_,+K)1mLP
md&4BRHaC.!kMJ@&<LuDTub0J/'^u\#Uu"=<rs\T>`973.#lPtZbX*4;raR8@ZfXB
&a8pYbZqph.qgmr'R!:?6\$pbn=KpG'5"CAFid&E<0c!^M=4)%5&IM_>T+`qk]OlS
`3*gTQ*RS\b:Uo2]_;V%F+)c!K"#IU>1agQP8,P`%^#1FX+SrA$1^/.[J%Af)](?!
Kn9e8&?aJ/=_cWe*N\OR1q2]Y,p=iCWF6^9@qp9fl1#Mn.DG9l3ji$'HEYH6e.?;9
>*#tS0U@9_+6gFQR;-^Sa"^7-A&RH"CJd-\q=@TEE68Q2G#giVF'6g]n-`Tcm8(.3
RKh^8)cWQ.Ph.NjAiE]J9DPr(TXBQ['*SO?NEB>WE;P8iU^R9n)[YXr;QYq1KF(jS
ApXuQP.0dgMB\3J6,@l@WB=6S,1I%biIP2EP%&:nV@LG>D?fM9*=Q`^g^1NIB*ih4
WlQTUl;qJ6>#@a9+lgLfHN`]s.*XXj%6R(1?l:CeM5uh3bZ[::91qaifDp+M0%o#-
SRS>T$5a5GcC;&f?+@E9Uea(V]^GaX$938QAP<@jL(M\'*J*V]!C37]c8,:i?T)*q
]J:QRj\aM+_^he]_.7N=M3ZLS-%1Hg=[UrqZf?`qJ2De,~> endstream endobj 58 0 obj << /ProcSet [ /PDF /Text ] /Font << /F3 13 0 R /F5 14 0 R /F7 15 0 R /F11 16 0 R >> /ExtGState << /GS2 17 0 R >> >> endobj 59 0 obj << /Type /Page /Parent 18 0 R /Resources 77 0 R /Contents 76 0 R /CropBox [ 0 0 612 792 ] /B [ 63 0 R ] >> endobj 60 0 obj << /D [ 59 0 R /XYZ null null null ] >> endobj 61 0 obj << /D [ 59 0 R /XYZ null null null ] >> endobj 62 0 obj << /D [ 59 0 R /XYZ null 746 null ] >> endobj 63 0 obj << /P 59 0 R /R [ 63 63 549 729 ] /V 56 0 R /N 10 0 R >> endobj 64 0 obj << /Title (Advanced Topics) /Dest [ 1 0 R /XYZ null 864 null ] /Parent 84 0 R /First 65 0 R /Last 71 0 R /Count 3 >> endobj 65 0 obj << /Title (Creating multi-module packages) /Dest [ 1 0 R /XYZ null 726 null ] /Parent 64 0 R /Next 70 0 R /First 66 0 R /Last 69 0 R /Count -4 >> endobj 66 0 obj << /Title (Runtime support \(and potential problems\)) /Dest [ 1 0 R /XYZ null 659 null ] /Parent 65 0 R /Next 67 0 R >> endobj 67 0 obj << /Title (Why doesn\220t C++ inheritance work between modules?) /Dest [ 1 0 R /XYZ null 378 null ] /Parent 65 0 R /Prev 66 0 R /Next 68 0 R >> endobj 68 0 obj << /Title (The SWIG runtime library) /Dest [ 26 0 R /XYZ null 864 null ] /Parent 65 0 R /Prev 67 0 R /Next 69 0 R >> endobj 69 0 obj << /Title (A few dynamic loading gotchas) /Dest [ 32 0 R /XYZ null 785 null ] /Parent 65 0 R /Prev 68 0 R >> endobj 70 0 obj << /Title (Dynamic Loading of C++ modules) /Dest [ 39 0 R /XYZ null 522 null ] /Parent 64 0 R /Prev 65 0 R /Next 71 0 R >> endobj 71 0 obj << /Title (Inside the SWIG type-checker) /Dest [ 46 0 R /XYZ null 864 null ] /Parent 64 0 R /Prev 70 0 R /First 72 0 R /Last 75 0 R /Count -4 >> endobj 72 0 obj << /Title (Type equivalence) /Dest [ 46 0 R /XYZ null 771 null ] /Parent 71 0 R /Next 73 0 R >> endobj 73 0 obj << /Title (Type casting) /Dest [ 53 0 R /XYZ null 494 null ] /Parent 71 0 R /Prev 72 0 R /Next 74 0 R >> endobj 74 0 obj << /Title (Why a name based approach?) /Dest [ 53 0 R /XYZ null 318 null ] /Parent 71 0 R /Prev 73 0 R /Next 75 0 R >> endobj 75 0 obj << /Title (Performance of the type-checker) /Dest [ 59 0 R /XYZ null 746 null ] /Parent 71 0 R /Prev 74 0 R >> endobj 76 0 obj << /Length 2645 /Filter [ /ASCII85Decode /LZWDecode ] >> stream
J.RTgd<QR@+;fnAL1"]5?m(6BiPGW*as](dMhZ5];7%8Q1P84eJH3?C;i;O=@KIuf
570-gb(jqLTVbd9Oi.E%R?Ze`,FqOU6R\b/C4[%PY_Z76*%i4!+[eo$"NYa?RuCrX
,UhMg1mlR1C.&gJ$&+"$@mP5i*`T-H#"*BaO;]\h%:_^*B\[)9Na*p-C%9EqD`9ud
_\$:,P]\o&6j"U(1h&HbNUF_e*'B5jM\<$ZWaX`r%jm)?A_;9k)B^km!Ma<fgh8IO
La0f>`*[LW2?QQl-lBr;&VNJZeJn5?Cc36QB!n)lN7_Q!cV@s.#BW3t4GXKW@r\#(
A2'Q;-^09UggN+/AS6CQSB>pb(doG:U"&-WNK)<%3%PRg5VYIkTZY3/Dog_:M@&e)
(G<O=rn7S"ir0dM#dXXLL&l7$(^DHeBJ"o>i+0KS0X+q&L&jQ&'ZMgdau0\R..#&<
@n[:l%1J?T3=R2qI/lKMKB*RQj"o!Q]l.Xd1o4\uL(qOV6R<g=UIaT*a'f+$XLClV
N??4dCLB(2K6TWqMkZl/L5"!m1r[A4RUm.d".7s?a:\$f1!em1f_`\W#fni]d_Kf9
%*A/_/PV>&j#MgeQs@1piG3BML;B\Y&4Ag9d67ge9E7+$cfDm`9s;d(pqZ=7\.B-[
*7Dq=j*9iI/$MF\2a5HDs&Mfh@*07h_`RYn;K>mY>:ZdC`?<b7T]?g7j/Bs5c4c@J
$Vq?)W=XdnZqL\C&+-hWaAR*OoK>R<PjUW-S\-d[<R#[u=1.n:GL>lEIf)^P"55b5
,9-0"4eZ_715o^K"NHBfX7.CgnaP,^58Xi\E6_pc<0+s`X\X*D&-VnB@$8n"K?\P'
Fu_ZA+P\bCYVgJG%MJ[Jlb'!k_YZ8ZGfa<O\%mtHj/H?o1:mr^)ic;IP&?fE.h4-$
jFD,B4lq=/]m`K_FHdQpC$N;2NZ!Z00\8U(>4dI^40\Vkg4n#eDn;OG0T8sq!KC8!
L%2C?Y):T(,0iG_M^"hpC)k_iU-',V3+Rb%X")nm-ZAd6Q\j_/P)c?>l=q6tW_P;t
M[#lbD*#6<OAIE2*B#2docob:T5Z#i=244!@+[F)g%AH,5&q#Ecjl>k"^,/pM^0;q
a=(QLXZW&JM/o/[C:Btc6N7gUs#<gup_`o#3">H<I/Jr`%"((orU#iP"0)Jo$JgBE
oS/K+3WVOC&F0N8Na]hGp^&R8+GV5N9&H,V@Y`pHQh$HQ!K4KB8>5<!UDeO^i%kR&
e.fX\/:#H,9lYh'VEPf(7#4L$#,''#67:2dOJ"01!8ne[pYrU)P;@_[jK?6fm-pH*
q@1d@=U$eJ[M!@0=s\#D#/e<&e[sLVa)(1P&g%AmbTd8uBbnWHMA4d>0iq*NW#qs1
^ESU5J#5f/4Jq\7&&_TZTu<W>KasRbHM(E2D6UH*:g5/\6q0a-2[9!NYE4$hC2_HZ
+,%^2S!)Ma^nFCR.*ea@$@5tXjF`XS=;+&L<'H?lAhBjh$5W4#=s\:qW'Z;f_b>N5
.Y.hti'8/I_fS*Th'Nu)s"M9o5Eiq2<X.-,@p=hS%H5s5]lsC,+67$/k](Y[FjLO.
nMCC[d-QLR$=oN.`H3[gm^2_A&A_I!";:M*(t?37$!`-V`^rK$e?(NjEl&:k@.G@J
Y`T[j.h1Hn2*nf!]VjJ5>Rmm@U),0=;rn6bV"KQbF0^7!OcWZn,Vl%%%T\bgLl@+2
/%mE%l00oQB9^7=6&)8*_m"%gATE8li7O<m$C>R&STFsCQRe1b!"Rt@4LHK0bemh1
8nt<\,t\P3l1eKe#U1cg#`u>oMl<Rm#q@lqhb]oVJZS7HA\)9Z$=K+D%1,p%eAO``
l?[i8`:ak4+NW>jKJ3o.+b%!.r=t]hUPhd^/dFq[Gaif3HW83#5rJ]\@8&1F0nHg<
Vs9`n]NK)/oop$Pd`V`]9!&:hWS(CdQ4>SsW2p&.TG<.]<lL/)#?&mo[)k*KbYqpN
d<n_jr/j?4pj$Fu3LJ=u=R&m,ALM/h!f$oplIktA9)/;qj=Ca+.SOI>9d#0*Wm/?_
cp@,,4!'dO[AJ3gRP@ZV#FfZ@AKfn9cmIM;C]Is?_QouXiP?cnkR/tR9s?46pJTGN
X@_ag;K9sr`:Mi9@WeVo8#gd^W9So)W+]NJo!Y=YJf><W(o&7]0dM'S@UdDl3ru)^
R'SEVf5$%Yf1\';'HC1O_3';ki],o0<-N0Oou/`h3`<#&>?!D#J;LNi2uA8=Xs8G.
ok+Qk$bWiJEKLZk8kMZj$[cmD+0tHU#:h0L)cEJUPc;r,Of;66f0D&O2fp2&-+:9f
1g+#@f,>LZnNNhm=Uj>[s1E+o_.XQJ:WLC8j/J?0f7OEJ7;d:GKZJdfMN?23<pH?$
1t6.PBUl)b&a2(Heo\4&=@%\7PWXX_%e(nO@,)G!&D3V6D*n`?-%tH<MO;`.nT4<H
iSjFCP3rCU=\epQ<k)NVXU$coR.f-D@j@s)MF=c9BWQtFY-J]%#tV[.<MQ&$!L^M!
5V9el7;QkU*:35H:gKm99dmAE9t._cT3<++bSX;o=^e>8@%J/5)0h%"RK8BfQ(u63
SaICh-eS>QnC#Zi]0m(p)5Lj\r04:F?RNmkSq6t5YG]&O.%-B&!fXAR*;Y7RNi^M+dK0~> endstream endobj 77 0 obj << /ProcSet [ /PDF /Text ] /Font << /F3 13 0 R /F5 14 0 R /F7 15 0 R /F13 78 0 R >> /ExtGState << /GS2 17 0 R >> >> endobj 78 0 obj << /Type /Font /Subtype /Type1 /Name /F13 /Encoding /MacRomanEncoding /BaseFont /Times-Roman >> endobj 79 0 obj << /Type /Halftone /HalftoneType 1 /HalftoneName (Default) /Frequency 60 /Angle 45 /SpotFunction /Round >> endobj 80 0 obj << /Type /FontDescriptor /Ascent 733 /CapHeight 692 /Descent -281 /Flags 34 /FontBBox [ -166 -283 1021 927 ] /FontName /Palatino-Roman /ItalicAngle 0 /StemV 84 /XHeight 469 >> endobj 81 0 obj << /Type /FontDescriptor /Ascent 733 /CapHeight 692 /Descent -276 /Flags 98 /FontBBox [ -170 -276 1010 918 ] /FontName /Palatino-Italic /ItalicAngle -10 /StemV 84 /XHeight 482 >> endobj 82 0 obj << /Type /FontDescriptor /Ascent 726 /CapHeight 681 /Descent -271 /Flags 262242 /FontBBox [ -170 -271 1073 926 ] /FontName /Palatino-BoldItalic /ItalicAngle -10 /StemV 122 /XHeight 469 >> endobj 83 0 obj << /Type /FontDescriptor /Ascent 726 /CapHeight 681 /Descent -271 /Flags 262178 /FontBBox [ -152 -266 1000 924 ] /FontName /Palatino-Bold /ItalicAngle 0 /StemV 122 /XHeight 471 >> endobj 84 0 obj << /Count 4 /First 64 0 R /Last 64 0 R >> endobj 85 0 obj [ 9 0 R ] endobj 86 0 obj << /F.Advanced 6 0 R /G996747 2 0 R /G997894 3 0 R /G998504 40 0 R /G998545 47 0 R /I1.998949 7 0 R /I1.998950 8 0 R /I1.998951 21 0 R /I1.998952 28 0 R /I1.998953 34 0 R /I1.998954 35 0 R /I1.998955 42 0 R /I1.998956 49 0 R /I1.998957 55 0 R /I1.998958 62 0 R /L.Advanced 61 0 R /P.263 5 0 R /P.264 20 0 R /P.265 27 0 R /P.266 33 0 R /P.267 41 0 R /P.268 48 0 R /P.269 54 0 R /P.270 60 0 R >> endobj 87 0 obj << /Type /Catalog /Pages 18 0 R /Outlines 84 0 R /Threads 85 0 R /Dests 86 0 R /PageMode /UseOutlines >> endobj xref 0 88 0000000000 65535 f 0000000016 00000 n 0000000146 00000 n 0000000202 00000 n 0000000258 00000 n 0000000460 00000 n 0000000517 00000 n 0000000574 00000 n 0000000630 00000 n 0000000686 00000 n 0000000740 00000 n 0000000828 00000 n 0000003845 00000 n 0000003982 00000 n 0000005051 00000 n 0000006122 00000 n 0000007197 00000 n 0000007312 00000 n 0000007389 00000 n 0000007530 00000 n 0000007661 00000 n 0000007720 00000 n 0000007778 00000 n 0000007857 00000 n 0000010802 00000 n 0000010939 00000 n 0000012010 00000 n 0000012141 00000 n 0000012200 00000 n 0000012258 00000 n 0000012337 00000 n 0000016380 00000 n 0000016517 00000 n 0000016648 00000 n 0000016707 00000 n 0000016765 00000 n 0000016823 00000 n 0000016902 00000 n 0000020789 00000 n 0000020926 00000 n 0000021057 00000 n 0000021115 00000 n 0000021174 00000 n 0000021232 00000 n 0000021311 00000 n 0000025815 00000 n 0000025952 00000 n 0000026083 00000 n 0000026141 00000 n 0000026200 00000 n 0000026258 00000 n 0000026337 00000 n 0000030237 00000 n 0000030374 00000 n 0000030505 00000 n 0000030564 00000 n 0000030622 00000 n 0000030701 00000 n 0000033547 00000 n 0000033684 00000 n 0000033815 00000 n 0000033874 00000 n 0000033933 00000 n 0000033991 00000 n 0000034070 00000 n 0000034210 00000 n 0000034380 00000 n 0000034522 00000 n 0000034688 00000 n 0000034827 00000 n 0000034957 00000 n 0000035102 00000 n 0000035271 00000 n 0000035388 00000 n 0000035515 00000 n 0000035656 00000 n 0000035788 00000 n 0000038525 00000 n 0000038662 00000 n 0000038781 00000 n 0000038911 00000 n 0000039115 00000 n 0000039322 00000 n 0000039538 00000 n 0000039746 00000 n 0000039809 00000 n 0000039837 00000 n 0000040273 00000 n trailer << /Size 88 /Info 4 0 R /Root 87 0 R /ID[<c6d87963c24f0304e37a230f23e51bf4><384caee55e87f6feb1cd053173c45fa0>] >> startxref 40402 %%EOF

134
swigweb/Doc1.1/PDF/Contents.pdf
View file

File diff suppressed because one or more lines are too long

1280
swigweb/Doc1.1/PDF/Documentation.pdf
View file

File diff suppressed because one or more lines are too long

269
swigweb/Doc1.1/PDF/Exceptions.pdf
View file

@ -1,269 +0,0 @@
%PDF-1.2 %âãÏÓ
1 0 obj << /Type /Page /Parent 23 0 R /Resources 17 0 R /Contents 16 0 R /CropBox [ 0 0 612 792 ] /B [ 15 0 R ] >> endobj 2 0 obj << /D [ 1 0 R /XYZ null 823 null ] >> endobj 3 0 obj << /D [ 1 0 R /XYZ null 662 null ] >> endobj 4 0 obj << /D [ 1 0 R /XYZ null 327 null ] >> endobj 5 0 obj << /CreationDate (D:19970623235006) /Producer (Acrobat Distiller 3.0 for Power Macintosh) /Author (Dave) /Title (SWIG Manual) /Creator (FrameMaker 5.1.1) /ModDate (D:19970624001750) >> endobj 6 0 obj << /D [ 1 0 R /XYZ null null null ] >> endobj 7 0 obj << /D [ 1 0 R /XYZ null null null ] >> endobj 8 0 obj << /D [ 1 0 R /XYZ null 731 null ] >> endobj 9 0 obj << /D [ 1 0 R /XYZ null 647 null ] >> endobj 10 0 obj << /D [ 1 0 R /XYZ null 621 null ] >> endobj 11 0 obj << /D [ 1 0 R /XYZ null 444 null ] >> endobj 12 0 obj << /D [ 1 0 R /XYZ null 312 null ] >> endobj 13 0 obj << /D [ 1 0 R /XYZ null 509 null ] >> endobj 14 0 obj << /I << /Title (A)>> /F 15 0 R >> endobj 15 0 obj << /T 14 0 R /P 1 0 R /R [ 63 63 549 729 ] /V 64 0 R /N 30 0 R >> endobj 16 0 obj << /Length 3012 /Filter [ /ASCII85Decode /LZWDecode ] >> stream
J/gkM&HS[n!uqRi,>ku'5W=FR%Rs9/>X302OG\S9Go1-9Je\^@0n=jK,oFcJ,B:NG
5ZBXoA>XUn?pH@iPf?#l3Qs`W/-A<B!D-,;%3ig70ppa>59Z03ACW`&hKCgr%Rn8r
jM#+[Ra("O\a9<J,q9bo;Y.R-VH5%*`!')-PiY(RSP:Fu/JaC=#/HmnBLF77%#74o
d5\46R2dF\A.n`tSuF"R5p_]YKaNZ+Uf+Jfgm(2t;j9nM[>NLT5FiK#:BiU(_!#Jk
RtLos$+S&m1n0Hum1'=*"bVbB0Y!,m,nu8,,?YA&;br^Y%&<X0p3VXHV=a$*3>Z$U
LDaX1Q+HD#;E<_E7Y=msJ6FlKq_dG,&R+N][gggW(kmM@PWFfA-p[/bTnm_/L@4mr
P)/%2FsSVJ;^OT%#q25R$Y&Bn1-"VCD!ct.OBfmS+f_i'`A(I[2?BPAN9)b;66:rf
Nf-@O#4Ea*)7%@8M$:.5CV$4V5\n66a:]%',I5`YX:PTP]!N=Z#mt.o[V`'_gp_.d
Ic._Q!s$.tCce+-3Xg),(ksT*Yr[OFlaYS'lha+2cCo<de0G_;"r[^Y:hU[n@BaD_
cr04s#gGoqfc89'>iP!?%]dc6:mD#sX3"<$RjYe1PsIL*l.QuV#(a&mc@u@=?lC:@
BXST]/^WW=NNc7!0Wq1@$8dd!.X\rq"-CAS%?OEM2hVq`kV8%t!phoN/l5A'Y2KBE
1^l95hD't!W8rQ>65VsD5m&+H2^d'.5WDu6nD6,5,<a4a%0J$4&.YIh`&EAokbodZ
@;H0:V=3M]7Pfs9;/sE>R)V,q/[WnC\"bqKI_ebbkdq8@$YU(ZJO%X=Kuf@m1p3MS
HYlG9o5ZGe3J`>NKF?p?3fScf$Fd0!#i7>7_f4LQbn);A3nYb!hE&/uTN&=VQ-`B:
[ohIt*!HErs-mDSXn/h%X5LLj#/bSUB]fi%FPU2]oqQYiYQKT!?n*K<L*ND9U__Od
3ZTgV_9*XO]?LH+(Bu%O#Sus#FFku,JNug_k9Hdl9=^!Ti5X6292/EdN70X^bOb%X
<'5S4$!%7=^hsrcaS9KgdM7fOcI[@Je$\POOO?4&(etk+oTOJn9m%'GK@QYJ_H*"!
I>q%g<F3hHQ.<^3FrXA>m<0su4T@e/Glo^bk'>Tif#%'ahl.\[8G,sLh.[BGDSaDl
jID:\nPOf>TZn.UZ@*c,97;UEi]'o5X[0f`#!gj-+1MYCgn6>Ec=.832`OX+F*;Xt
<?%gbFE<T0E`91?:lmq^!6jK[KoXR\4(rA"!L^&\0K^.;(Pko*,KFV=,houOC`<Ia
D[tk(Ws;Z8cpK=%#&V<_1Nu+lO9ctI-N(IWP->92Le1_mh/ES(I';*/:iGLs26[9u
#Q`EI1(G/M3+FMuJ]XsCM)!*o?tKiKEjIuj+^5%93*MjE?VF/#3!Y_gcG<$o%qcH?
0]`EGM;0IfiQ7`aZU!*!&0tQ_\`FcrZIZiWI?in#CFt9C$3HD7%&"@q#:713,h0/F
1,u]Bf8:7Ebe+EOHmseHkS1q0*&pX#A/cZ2(Y.bt%hgC2!l.3CB$j#.ni:Wr5[#,E
0J*]->i,c?7*bnhHBY8h:eDKL0gS)=%Z@:A"Q69n!bCgX#KZd<8O2>_M=I0XIX;bX
AIBQ<06H[R)8kQ<j.I)HKBIgh6Ub+B_3k^fT\8:hnm5Lq?n_cq%BfmLl>D4^aCIpH
2`+o.'hGiG%&&h7LG7ZaK1KTf$t4-S(mZ'%F!*G9NheHJ-J_T7@>nh"^P":I&A_I!
>+rUC/?&24AF[g9XA.KrL+mLt/?F^Tet*im5T#f,Zjq4=^kXW7)eW8hG#2;i,,hqC
U'ls#nql$%)%[2WRR%+c"jKl#<4l;%Z@;#rr5/[s7qf71,q#]Yfd-Sd::%$QM<+t1
:h2n**@%Ad)4)$"iZ&&1.]6[)404.B;'1U&Y>nc-<N0%M>7J.QOm1(<TQ3Qg$P8!V
e<HEq]XZQA+DD#%2De$N(m%YRM/aiP0u2Gg")),'X0KG_T^K.=Kg/jONik/>?Jnn-
m&RMQT2Z/N]+>-O@hJ"?*G$?%J[lk(%T4FrLLjrE('-V?`#4u3&IMGMUONeGr>bR3
s'SD#JSGod]urJ2nAQHT7k%!_N(FV\1L7DL_BlrFR]r3nfOht29*U,8:*ZM[X[1P+
#'Hs'<gs3*2n'[RbBm2-]lU]H+YGd$r1fd7lNJEl)(k>U$mIrJ=tH9`jGP6^j"+h.
VuSa1#(YT5";Gfpm3u.VE^:sl]E\X5_AkgN#8(r;5#NP,B1G%:%CQnTQr;+9HU+Lu
g7SWmb7@IL#m$a^)73Ld6_@'?iprqGI8M17/aQa5mkqNtlVdObi/G/`^gYHhdQH[(
qKZT@;id#XN24)sSuEGJcbMH'bX0co1]VW\R+=q5ZA8lSZbH^;TGN4L5S5d$c=rZj
TJ(i<*K@sb]CB8b*#iOX(?TD<E4J[$C+/AL%Z)<g<S-I#4TY'^RC$[87S&J7f*bLj
6.6QSc"`tj8b6>lkUH;8k2:i*il%`Pa>q]\o!_PnBYEbEp/CHH3\p&bDXiQ>2mnm^
hEo#jX5#Y>DCug,r<75..>]Qk!P\Y*#)cp#A4@<3aQlP_itW1Y"(e3XC*tcS4Ol3,
JAY,Yk8MPAG;+Y7:k<aU#WDA@U2C=ORcR$og+8aL!pp0%*hMMK7R?@o(W8q?#*%3d
JLG\A5M=-\jR+FqoL^*$`Jro(A,RhVPNptcbNE52*JPEBQYX0@qiu-HG)b2Rd@qf\
=3g*_Hecj`bSP<\Brb&d/doR'Q3u8'XO2Upe^mdtgS+)/JR@88im#/biPqCL3M6Aj
)GU=BBpI'LF40L?]#.`]HIETZYetd4$S#@8hj`b%be<f^fW29n"^CZ^:VA]gRE"'t
Y@Xs9K3KFUde5!PNCqE;3pUl+W#!FQ:g+^DYX).Ict`,AX@Xsj<uTUf:c0@"`3MSD
+=h)REXd>Wie.Kn<!32[pCHE0^g%:U5QsDZ8YQ7~> endstream endobj 17 0 obj << /ProcSet [ /PDF /Text ] /Font << /F3 18 0 R /F5 19 0 R /F7 20 0 R /F9 21 0 R >> /ExtGState << /GS2 22 0 R >> >> endobj 18 0 obj << /Type /Font /Subtype /Type1 /Name /F3 /FirstChar 32 /LastChar 255 /Widths [ 250 278 371 500 500 840 778 208 333 333 389 606 250 333 250 606 500 500 500 500 500 500 500 500 500 500 250 250 606 606 606 444 747 778 611 709 774 611 556 763 832 337 333 726 611 946 831 786 604 786 668 525 613 778 722 1000 667 667 667 333 606 333 606 500 333 500 553 444 611 479 333 556 582 291 234 556 291 883 582 546 601 560 395 424 326 603 565 834 516 556 500 333 606 333 606 0 778 778 709 611 831 786 778 500 500 500 500 500 500 444 479 479 479 479 287 287 287 287 582 546 546 546 546 546 603 603 603 603 500 400 500 500 500 606 628 556 747 747 979 333 333 0 944 833 0 606 0 0 500 603 0 0 0 0 0 333 333 0 758 556 444 278 606 0 500 0 0 500 500 1000 250 778 778 786 998 827 500 1000 500 500 278 278 606 0 556 667 167 500 331 331 605 608 500 250 278 500 1144 778 611 778 611 611 337 337 337 337 786 786 0 786 778 778 778 287 333 333 333 333 250 333 333 380 313 333 ] /Encoding /MacRomanEncoding /BaseFont /Palatino-Roman /FontDescriptor 78 0 R >> endobj 19 0 obj << /Type /Font /Subtype /Type1 /Name /F5 /FirstChar 32 /LastChar 255 /Widths [ 250 333 500 500 500 889 778 333 333 333 389 606 250 333 250 296 500 500 500 500 500 500 500 500 500 500 250 250 606 606 606 500 747 722 611 667 778 611 556 722 778 333 333 667 556 944 778 778 611 778 667 556 611 778 722 944 722 667 667 333 606 333 606 500 333 444 463 407 500 389 278 500 500 278 278 444 278 778 556 444 500 463 389 389 333 556 500 722 500 500 444 333 606 333 606 0 722 722 667 611 778 778 778 444 444 444 444 444 444 407 389 389 389 389 278 278 278 278 556 444 444 444 444 444 556 556 556 556 500 400 500 500 500 500 500 500 747 747 1000 333 333 0 941 778 0 606 0 0 500 556 0 0 0 0 0 333 333 0 638 444 500 333 606 0 500 0 0 500 500 1000 250 722 722 778 1028 669 500 1000 500 500 278 278 606 0 500 667 167 500 333 333 528 545 500 250 278 500 1000 722 611 722 611 611 333 333 333 333 778 778 0 778 778 778 778 278 333 333 333 333 333 333 333 333 333 333 ] /Encoding /MacRomanEncoding /BaseFont /Palatino-Italic /FontDescriptor 79 0 R >> endobj 20 0 obj << /Type /Font /Subtype /Type1 /Name /F7 /FirstChar 32 /LastChar 255 /Widths [ 250 333 500 500 500 889 833 250 333 333 444 606 250 389 250 315 500 500 500 500 500 500 500 500 500 500 250 250 606 606 606 444 833 722 667 685 778 611 556 778 778 389 389 722 611 944 778 833 667 833 722 556 611 778 667 1000 722 611 667 333 606 333 606 500 333 556 537 444 556 444 333 500 556 333 333 556 333 833 556 556 556 537 389 444 389 556 556 833 500 556 500 333 606 333 606 0 722 722 685 611 778 833 778 556 556 556 556 556 556 444 444 444 444 444 333 333 333 333 556 556 556 556 556 556 556 556 556 556 556 400 500 500 556 606 556 556 747 747 1000 333 333 0 944 833 0 606 0 0 500 556 0 0 0 0 0 333 333 0 738 556 444 333 606 0 500 0 0 500 500 1000 250 722 722 833 944 778 500 1000 500 500 278 278 606 0 556 611 167 500 333 333 611 611 556 250 250 500 1000 722 611 722 611 611 389 389 389 389 833 833 0 833 778 778 778 333 333 333 333 333 333 556 333 333 333 333 ] /Encoding /MacRomanEncoding /BaseFont /Palatino-BoldItalic /FontDescriptor 80 0 R >> endobj 21 0 obj << /Type /Font /Subtype /Type1 /Name /F9 /Encoding /MacRomanEncoding /BaseFont /Courier >> endobj 22 0 obj << /Type /ExtGState /SA true /OP false /HT /Default >> endobj 23 0 obj << /Type /Pages /Kids [ 1 0 R 24 0 R 33 0 R 42 0 R 50 0 R 56 0 R ] /Count 6 /MediaBox [ 0 0 612 792 ] >> endobj 24 0 obj << /Type /Page /Parent 23 0 R /Resources 32 0 R /Contents 31 0 R /CropBox [ 0 0 612 792 ] /B [ 30 0 R ] >> endobj 25 0 obj << /D [ 24 0 R /XYZ null 339 null ] >> endobj 26 0 obj << /D [ 24 0 R /XYZ null null null ] >> endobj 27 0 obj << /D [ 24 0 R /XYZ null 522 null ] >> endobj 28 0 obj << /D [ 24 0 R /XYZ null 324 null ] >> endobj 29 0 obj << /D [ 24 0 R /XYZ null 324 null ] >> endobj 30 0 obj << /P 24 0 R /R [ 63 63 549 729 ] /V 15 0 R /N 39 0 R >> endobj 31 0 obj << /Length 2705 /Filter [ /ASCII85Decode /LZWDecode ] >> stream
J/gkM&HS[n!uqRi,>ku'5W=FR%Rs9/>X302OG\S9Go1-9Je\^@0n=jK,oFc/OQ!_-
BHScD6*aEOA?[0mOih/W!M&9p,*i8(JH2LEC'Kf1AJiX/4!0R*jYCSI9Q*$4N<^Zd
ST\EsRSB[nWT<o,6B[TBF#eg.L/TUc8E']MbfXsuOj9hf+dS*YV#t+%82MM)+GNN5
0fZ7@RiEX^A.o<7SuX=\_r]GF*>X]-V;pUH.ZBOi.$P2e[@5op5;Ajo:BiU(_!#Jk
RtLos$+S&m1n0Hur<<T6"bVbB0Y!'.*K5nG,?YA.;b`RWN(1$CCqjCHia?Jk3dsgm
f?<.X=Y43*^#'[LG_4>9f!lh<NQ+0LGnPi^0&rF?h*5>(=:bd+W8'.]!K^prL*=WY
)n[TQ8gAndi0:5N9UP70,bes;/W6SVaQ'LuZ9G@E6$"<>#--)m)F^`hfER4M&<+i?
XNN1:7P*$$R61oQ>5LK3,OuWp#Y:oo"egHO(^?#keeAU(TYfHB@0";($mUj!]8f7'
j=cLf.-<OK,<3gt]j\.V*OpqS>5a1Sb$b6B'%FFCNPhR33D?bAZRq3:pj/-!N;W&Y
b-(C33t:N65WT>f../aIXda([[j'a-0?bR><&TbH34KZU"5AWucJ`m9Sk82eZ8iB3
(uRO+;^BUE9iGTX(0(Gr=ZFrRC60nK8f`=I:Xhp$7><]s)YuZ3`:[;f"75=N;A-))
U!f10`\n73%673BclGPTe[9h3=^,t/ShJINV56V8(:CDLeor.Gi`V-Z8MLBHprY=N
G?\d)e0.9>=#9N'[9?@Y8B_WHZmC3Ld5QY)I9.+'$Xc\MBZk1!Tg6aY0$'-tOuG^H
W[8%=p+:T#$6?e*YUg`Z`&Xo&.-S]HX3ULIklM.X1G7uR,-VLaaH&I+OpLD9M;W+d
L;@hF)[>Zgd^@4`OE-*`Mf?*=$@t`g)$L+e;A^g7]Z`7Kj"qH)e,s`?4,kImfSb]`
.*5,Ao,-sV3!1#G3Xp_c]J/it.(Ul79S@ZV#83DEJkmP/BH/d.j#j+A+elLR>SMrj
JQ!96*DbMDOAcLrc;P4kU&$P`kpb?(9;ZK]!,R>R:B+AS]RDJuX_G@SBGnQnY[EOX
q[UZP[Ms]65R`99a">,emS">*>H$Tso6fb*)9&;Y7sVXJlI34[UDUuk<$U`7%(J%o
i'7m<1QDke[E'K+FSm-=SnfH+*u.1gIZb@CH0=8d4bgo.(E-.CCP]A40ZY3NW+'$>
!';YY:C:N4G[bI1J1jfT`gG[4%fh+kYJruShuX$R@(\TW`L=u<Jdc+B+e>hP\EuY0
Ro?CO^omFq%"]U9%`+tB)j!<%S?R;liOgd-5\@<(,Y)Bb"\'RnRgk`'7ZHd.342h6
d,"fKAkrl3_)IHU>'\@KD`QZ;'<*(BgjgR/n/;B1[eJN20Pq+i)PlQkgfp7jDWMK%
LIAkQ_a4chDW'<CE:XDV\[i:0aiV8Y5_,M</!Oj8h'N5O\e>Wr%^LI9PP$V^"#+Y4
d6uoIG]FeA6r=E?6-cB=$4\0*D('H/0a.XH)Zcu.J`_??\b",N8Lt['OprU$Y\oX2
C%sluTdM,hUm2Rt6Nj^=3[u922<N&_M-r5%YU0jZP9`V*bFs&S7roRWq^hr1q-:EH
dgas`mq'WRBr1&\_]?Cs?/VPZ__s!Wic9DTBp:<+[Q5D,5tGAL?%Fg.<BjOG/i]s>
hm?=RdEHZ5H=RLRP(oP<&R=BQZ5,X:H@"&9=q,r-IIJ!Y,YZXR0ijA)-Ueg3h%2Pi
PU>Yf-:e::JH0V<ci?)!G:!S8,FJs20KKF`H5sh4k](5<3]PL'#UZcrE:nMMVI3;&
5stnaP(XB5E:2YBj_Sq:@P.]^_AiZ1n#rF=0?h;cXC'-1S`%AaJC`Uf<5Mi^WX:?_
kfS5$&9(;lE&uSho];E#l)TR8dFdO2*E,YG9F;,*^]6V2ddV0.U_KHQHI?aB&0SAH
aY!de<1m1k4Ue8AaZqOaAXG%;.l0c+V7DK[lfqrg.g\'uAOU"nD5FVteNjC^.roF(
+:Y<Xo/VRV@tQ"aTZ6,$=)3G-m0\Gul)N2s9@sL`!-U$A`!3O#IN)9h/pEQ,jqt+:
*u_b&GiU.:&<i>O.MGd-#jVp?B75PM8eH2'3OYClf\g^7]f5\6_C:"#)\'l$%8\g>
iA1ps?4Icc'^A(L<hB9HCuqU`&u/uR;H<!lAd-^Uf9Y>kCndX+`\QE>^3[<5*,TK+
"nfjl)h8dn&e%VrIUBb`]9,CYp37(GiWBt6</=.:c9t*="2aCF1"^FK_4Vl[kC&F:
dEndE9-V$1A./oR+aN7.U>fpJopZ&\FejX<8I*+0%KKt?_8naQ_rG,rJ7u3f,Wah"
97n=R1WjR6r(RGa44`0a]iZ3S<\&03_kW(l(b8KbL0iih'r%@XA;c3>8Sm1dDe!4`
b?P%c)oHo9%X:AQ"J)4IbH_A;2cZ2NZ@6[f?tkoMPr+6]YCeIPg]\#]/RT,TU/P$a
6'hYoeamRe.h][L0L#bRoQnt[cB"nQ%\]\-;N$+*%R3"qf5#V$4@)4c"]-5V^ul^Q
!H;OQnCBW%%SVItAo03%SM8m`]sOk[+:Q)O%u,IN(nAU`9Hg2c_QEAL__(0uAG5cA
CZE,D0JDL&Kh2t47W;EgFgu_mRHPXrTi?.WNZ&$RL*5d$n(;OD]mlH*-*1KF#Q~> endstream endobj 32 0 obj << /ProcSet [ /PDF /Text ] /Font << /F3 18 0 R /F5 19 0 R /F7 20 0 R /F9 21 0 R >> /ExtGState << /GS2 22 0 R >> >> endobj 33 0 obj << /Type /Page /Parent 23 0 R /Resources 41 0 R /Contents 40 0 R /CropBox [ 0 0 612 792 ] /B [ 39 0 R ] >> endobj 34 0 obj << /D [ 33 0 R /XYZ null 279 null ] >> endobj 35 0 obj << /D [ 33 0 R /XYZ null null null ] >> endobj 36 0 obj << /D [ 33 0 R /XYZ null 322 null ] >> endobj 37 0 obj << /D [ 33 0 R /XYZ null 291 null ] >> endobj 38 0 obj << /D [ 33 0 R /XYZ null 322 null ] >> endobj 39 0 obj << /P 33 0 R /R [ 63 63 549 729 ] /V 30 0 R /N 47 0 R >> endobj 40 0 obj << /Length 2346 /Filter [ /ASCII85Decode /LZWDecode ] >> stream
J/gkM&HS[n!uqRi,>ku'5W=FR%Rs9/>X302OG\S9Go1-9Je\^@0n=jK,oF`n6O66<
E&8+@%A;B'ShaCZ$cqEaOFYVt&.qP8d6N4[<&FbKZ*K=#2][t#A9+(q<i@sKNQ-U5
E6c-ORE]@8RG@Lc6(uCmL,l'JmmJUiaWtj,<9@aP:^H5_8W_+cUsd)`-mT]C$4oQJ
d0Ohh.i5*R#fBdJ`ht2b8qo#kFM_TWUJ`O?b`$`p;Nb$k&qRue[9Tn*oAY?Ni5T=f
*=X@eE.F$Y2]3'ZPB!2qUVXb(Y]5UK(D4YTU60--CF)j$C3(+UON'MUY\6#k.W8La
Q'$6r30BM*?X9l%o4&h$ZtM>"L]sPnO2GKP."\bo3O`kkqA=p;!0fO(_^Ibf#&m+B
*/>]L`f6dg3#\BF8uU7^Np-U;-A2HQ\rr#4;[aU,iLj]t15VB5XeG9,?k<ctBVs46
_9:2fa3;JLm]gJQ_P4c<ML,5TaFY$S5QPP+(Bso84LPD'+Qs@FXg<!&2hLhe3Xd7+
l8aW;3_C1,o!:IZ"T`jI&.$0Ef`qa[jLj9%_a$I%"nP[bre=B%@lOU/+N?;LX7/@q
0&rVS2NAI7I,g*8;Md#dMo0m5NWT!o3fMP:DVW%8'hC,6'2(bfdpp?X3B+7o9eY$Q
*6U.gb"UDFb1&J.&[0).M$FNCORe"QU>Sm]9=6mt2b[-qbb,37"X?iI'A]Qd%+SbH
/d40V5T\Z'KulUaZm?/0=EZ9V&.EV.`\^i9Yei;'_^O0Lfms==Bid4"cZ@i"ebBj-
'[T]d%(7u2&.X=Xj>W+nc1c8gNSr-#"W!);0[t:Rn.oG6?!i@r(mH%t?XmZ6IkLJ,
JN'NkP(R[<\"MTm-klk)GiCZLUu2[A.#L#oj,cR)l0kB92;QCAiJ68lR#!SZ_b:?m
#Xc\?]FF@ZLTG1!R%?@!Jp>KdN2((DASM5GB+)7&CCnH.k_gGG7ukL8c*^+E#stt]
1M5"</L/K#8*CismB_Z5C)D\VE,6Htmg@RQ$Xl;kN!1BGA/%<S\C6>FJH3Ou#[m_k
3<_$K:cF?nOMWol,KS_&hMqS$12OJ'?8mk2mo8;"!RO^sMLnbQ+#OZ<X!,=cIh\<m
%2IV6aj8=H(\<%Ai@.Bb$J(qrK;caNTVHJnB77OB*'@KDgQ%Y,Tlg^mPCR@MTV;8b
PGFV3TccsX]K@^k)QXe`s$=KgMQq=[$6%Z)CZ2h.[PfbK+E@*ODu"UT!;bO\+jMei
6,+Er+QM5h;fZGP_h0.:p<O>F4H9Td\47r7alkQ3c=tQaiaV*P6?Na]`&tY12X2-S
AINJ(gBLX"K:R:-/o'3A)o+]W%KXF"!2Q_c!:Cht>0%-`*TXJXL`,&bc[%6=aLu%T
OMREC1XC'\!7fd3iZk!Xa7]#)-d\,V\O6S(l)DNYrihc9MG]6j/j:t"aHPWYHu7])
aJ_lZ;d_4PdQeGeJEX=lJTqWSebm1m*=5=^a]WX<UqapM,QT$"6%P#0T36";+9=k@
Y66m>Fe$k).nXN8c;pA_Ij<[[;[q]=26?$lTk6Y`-o3GpagaViV0p)_'+K93<Ug83
j'G!TFg=]oCH,jXd[HA'90nur(P<@D%o]oT!gl>2jb2Z]P8Ful[bBKjMfTCb\-C:d
`B:#tc]Zcp&-hf")e_jdRc)J0^$6U`-6"Xa1<rrcfq=i`K_/*7<&Y#cgr9fiVEhM+
Ng,o"8Z3&iVUU$pe"`$4>MLbaYdit_pE42ooJAklbp(3<EoTE!jf$PFaZ*?-<XAad
#1<]#5.%0q*lq;4mXu^Z[ocH/J8\(Up#"#5CD?lf+^76c4N@(C)B/2#%^j0a1!nbq
ao_GLl"o=5ZlBXn==\O7";!ZQlW\ua+:Le%1^7pGQI^27YuJg$=;psAhLj6kJ@Oac
)STjb)n-6uF]tb4mm[D"S['lUf:YC_SV%;F%As42XtW`]RWp7c@,)G!)Zgr\]lX`t
-0#%0c5g!@_e[CG0SZ#M?<qMh%LgDoK%h;`PI+A)1!/Z1!nD%&g<3hr.OP<0;/ck"
Tr7#mkErb_A*PM+F1!-DS[&l]&b4e!D;qO%W-a"dYq7?$Gfgs]IW/%$bd1/dBnnZF
I3DniW-@5B</>-Y*'?Q7<B9Kt$jq:Loi?+9)=g0o5?G\/W$n#qiE'hCB*3-=Y:K"N
-8p9fK.<F(9N!])gS2$,])E.p-(*XV5T-&^GDd+)kQ](9@U580PkP'LhJaE:!D#'P
V%brqOPh$YY#^HLdi:gO_O]D%Wd-#N2qR\@)Jh9TY:hs4&_Et)A$@(H@+(pJGl#$J
_6H3m\L*L(%;Flo.$UcY<(a,m!MuL2+<U~> endstream endobj 41 0 obj << /ProcSet [ /PDF /Text ] /Font << /F3 18 0 R /F5 19 0 R /F7 20 0 R /F9 21 0 R >> /ExtGState << /GS2 22 0 R >> >> endobj 42 0 obj << /Type /Page /Parent 23 0 R /Resources 49 0 R /Contents 48 0 R /CropBox [ 0 0 612 792 ] /B [ 47 0 R ] >> endobj 43 0 obj << /D [ 42 0 R /XYZ null 560 null ] >> endobj 44 0 obj << /D [ 42 0 R /XYZ null null null ] >> endobj 45 0 obj << /D [ 42 0 R /XYZ null 545 null ] >> endobj 46 0 obj << /D [ 42 0 R /XYZ null 336 null ] >> endobj 47 0 obj << /P 42 0 R /R [ 63 63 549 729 ] /V 39 0 R /N 53 0 R >> endobj 48 0 obj << /Length 2916 /Filter [ /ASCII85Decode /LZWDecode ] >> stream
J/gkM&HS[n!uqRi,>ku'5W=FR%Rs9/>X302OG\S9Go1-9Je\^@0n=jK,oF`n6WbJd
E&8+@%A;B'ShaCZ$cqEaOFYVt&.qP8d6N4[<&FbKZ*K=#2][t#A9+(q<i@sKNQ-U5
E6c-ORE]@8RG@Lc6(uCmL,l'JmmJUiaWtj,<9@aP:^H5_8W_+cUsd)`-mT]C$4oQJ
d0Ohh.i5*R#fBdJ`ht2b8qsYYFM_TWUJ`O?b`$`p;Nb$k&qRue[9Tn*oAY?Ni5T=f
*=X@eE.F$Y2]3'ZPB!2qUVXb(Y]5UK(D4YTU60--CF)j$C3(+]?7oSmcuJPShR,^$
,4/u^1:VaM]3j6M7O'NFZtM>"L]sPnO2#3L."\bo3O`kkqA=p;!0fO(_^Ibf#&m+B
*/>]L`/URe3#\BF8uU7^Np-U;-A2HQ\rr#4;[aTilHj&X15VJY*5/V(-oM+#Rn=np
NC7I(7YtA`cFaK7lM6.TJeJ%(.<8nu"egHO(^>rifG"gJOR`qnDE;/@^S-n2-`DS=
bm"Snds1`4o*iVg5QO.H&.E%SkV8%ui(tj^"$"FIN^Job3=CC3\M$0GEdKboK,k(K
NH<IV)9c%>M[*&m'a[J:F=;>k;'C&#7F!]ZlT<E95_q7W_b:?m#Xc\?]FFKb%ae"Y
']1mt_gN\";Lt*7<n6U$`@[-NV'cOIeHE]o</Mtr4&6O:SiVm`Gg%LnUMU2tf$`r*
:t0P/;-ql57@"fpj.JXrN55MKDVOkj3Y^'1'CBgAG*M6+<?ZMhE7#GLb=5b/I3Wl:
,,j9SNPg#/hMeSCEA\3W[@;SG3'BoI;-,IK$b7m*&B,gVM]D"PDSsis2+[iT)$\=F
^=fkE$V9i`cT7qT4)&GU)MZDmC`<TI!n=Xd@6gbJ6.i5Ugq]T`kWFk-.Y.e_UF*'$
KEDo.^C4U[_DqcPBMkpc!t'UbmE<(k16%4%n#1(B:s0!%"*iu1$q"R6ibb@nTJ3Re
O?lHm@BeDi#=1nl.LAe5HL/];XFm:Aq7:2`?U9Kd(heu]C!n0SA>:TrWJn$jDrCjO
5>sBY\3Ae"8kXeD[m&'hfQD9D=OqR1Dqoo<TN+JUl35pZ>F+ohj5c.DSA_uV;l7WK
R<F(IjoL\AcEl=*Eo]??IX9LU)@@OWX*Q[dV00nUVAZ_`I[VVmUUoq#"0r"oV#bfu
AtTD;M/re#_6]JP'HG"UD[rJGY6L*6`*:;BD.%po0mEm.".NF%@AUsGB%Z&U3,VGB
<O+MjjIMq\/oj]`[]K(hZqF87"T]Lq0i5_+6\CF&%Re\Vf.M@haX'J(C%<NNcBnXJ
/kW*j)4uSHR2oI19#V>s5pl_dNZ`L@;04k<okYWN6@o^3l/8XELpEAbeM-/K`P&#f
F^J'=I=rm5OI*nIh!s>[7u\P0UU&":lgFrVcks?W_YmYO6k$;a2]P*.#Ql2`%)AYV
K5aX)Mo07]6'O;\kW76'j+]Mu#m%q&.U\jS-[R0tmDjj^c\NN*.a6-*Udf=F+&'.l
P3A,e+@$@Oa>4"E*Mf+uZ4%2,3`\"D1592S"N-r?N<hN(`+a1DifH#QO]En5K.+S\
H:T3Y/oh%cbdi9UV[ej2P=J)@/L.kZS+@5[+Sh37Ac.0nDlN1uQbYluRJe;)IUl-O
R!9NcQjk`\[DKETSLC.B:<dL]Ysp;p%HqJjDEYs.K^:us!-Kp]GV_Eh_A`Sb+:dnR
3&R$;$:>X^Q,#72,p72'eI4B1NAZY/$;A(2D(oEe'KQ<R5uYW@)28A2GG*;JK,%ht
V=8MdZ&)G!BcnOpXt#de)KAVUOC:e!MQ;KimM]<&A.LNajZd-\%H`HUBsOlFd6QQt
K;2:Qc2OfB5i,k;#]*Sc\H5*n*B*3\XDq7SQo5es)ibgGK!LZG;5E_UWMMMS8YM)E
8!]BjJb(JDl%I2+f1*Y(:9!aRP(nZq7'1SM%VG9K5^DG@Bbb$*l.'8dl7u_BUMQah
!A1e0LqB0#^`]qI]M2mRil^kQ%'[jq\Q\;/D.?A<80fmm,mS<qjI:!_Q4_8.h+EcN
"h4'"i1)5J>#O!s:gpF:*&,uSmBJos2g*;:Llr#V#WXumQ9c4H=q%D"3(AG*Q3-?#
N?)#tFeu16:E$g9K7J6,#4[9t2gD\q6NX7'jp=#Jk=B;+s2@Z_BJLfn>sU_/"[IZ2
#%NIAP]1=q8_08`qJ?WMj[Q%=]&GtgeQ3Z[BQ"/9'a!uema6D\SeK9Y@ONG?=2dtZ
=c=/Kn3@Q?HY7l[$Rjd=@bM8,36,.lC?+k;DZO`AaE;DG(Q=FpZ;i91XCY!+<S\QK
IP3)e<dHoP:ioiEglF7=St305%.-ahI+&-`ksrNi8a[-eE^($8J:gR$(&,]@7Zp__
_$ECZ,JB7K4""XEetJ?1A@ag)SLO.(BAEf[ku1;af?ldZ*l9E1J="Khk%F'N'")R5
+Ih(l?pg#nL(mlHdouYdD"r*g'WV&`$?nFg5Vc"ji5C7>b;n%1:Yj?QLLEp541Bqb
Sm"$T7p5?)2?q9O^s!Xif`L@Tcjc?iRt45GL41-Ybh^c2cd<Ud7VK/:e^[p:k.@jb
ZJqBhg>"URgLSd`FZ[G'*=C:-E=O)$+b)bOZEYU)MZ^"eD5#<;D?/'S@,caFcJ&-G
*Q8:-'I::6O'6VUY1?2KI&u^:D(dt]9OL(\>J#'C>%62#3M,&_28QJ<HQbjGTQT!C
!ge[Hik01_;`C#bg/Z4D&6stQ8!k0]UJ;,Iic4WX!4_h96hZGjofU,hC_QqW[E1dj
?,U0](1kGn*J8Wc";pNG'UCfK;`1@9\D?7uM)=5.5Tp8rn$O*^9BVZ(-jg"9g4h;q
'Z2>@$>F*F-a.1M6Mo/7maO5u`U(3<HLY<[8\pnC8_%@?S7?+X*"bB`g;7f/$%Xhl
0>()?[F#!~> endstream endobj 49 0 obj << /ProcSet [ /PDF /Text ] /Font << /F3 18 0 R /F5 19 0 R /F7 20 0 R /F9 21 0 R >> /ExtGState << /GS2 22 0 R >> >> endobj 50 0 obj << /Type /Page /Parent 23 0 R /Resources 55 0 R /Contents 54 0 R /CropBox [ 0 0 612 792 ] /B [ 53 0 R ] >> endobj 51 0 obj << /D [ 50 0 R /XYZ null 504 null ] >> endobj 52 0 obj << /D [ 50 0 R /XYZ null null null ] >> endobj 53 0 obj << /P 50 0 R /R [ 63 63 549 729 ] /V 47 0 R /N 64 0 R >> endobj 54 0 obj << /Length 3506 /Filter [ /ASCII85Decode /LZWDecode ] >> stream
J/gkM&HS[n!uqRi,>ku'5W=FR%Rs9/>X302OG\S9Go1-9Je\^@0n=jK,oF`n@jiJT
E&8+@%A;B'ShaCZ$cqEaOFYVt&.qP8d6N4[<&FbKZ*K=#2][t#A9+(q<i@sKNQ-U5
E6c-ORE]@8RG@Lc6(uCmL,l'JmmJUiaWtj,<9@aP:^H5_8W_+cUsd)`-mT]C$4oQJ
d0Ohh.i5*R#fBdJ`ht2b8qp7NFM_TWUJ`O?b`$`p;Nb$k&qRue[9Tn*oAY?Ni5T=f
*=X@eE.F$Y2]3'ZPB!2qUVXb(Y]5UK(D4YTU60--CF)j$C3(+]?7oSmcuJPShR,^$
,4/u^,:o_+]3j6M7O()VZtM>"L]sPnO2#3L."\bo3O`kkqA=p;!0fO(_^Ibf#&m+B
*/>]L`/URe3#\BF8uU7^Np-U;-A2HQ\rr#4;[aTilHj&X15VB5XeF^L?HN_-BVs46
_9:,da3;JLQ,h,7^nSQEggD%oce)KY+X3]^'G%?-8f#D)UpQN)!GGjW"qoY@U(5(e
q@EftBYlY:K6YBg"V)[=&3tlpat<i@gb.ZuX@!\WU+CAb*]jm"jOGL],.u2_m@-GX
[#Z\"+/!9l[[*hbY\Y9_eBi+&/PBWg(^A3WW4.[n5cupPXm!V]%Ls>u1-m.Xcnq['
\C3>=!sn0Q%J*M?1!O39ndl4P@)b'W'snr@"YOIb16.!cjPGpG=R-2$j"cQGMLnbQ
+#OJ^6l-&Y`D%f/i+QgP^Q6fAFBqf(M)A"kFQ#>XCa5Ig\eGOLaAPteVb8Mh:h^]m
WLT't4EMku6djor[/PeG`BR'qPk2^jf<,H+0\6kWJ.N-kZZ$\62[.,8X3lO(Gm2K.
HRUPS3f)TNLb67rNe67k)Q4,lZJganE'Os?_g(:-%g**l=M_i&NfMnTb^uk9@ACK]
@Fo>")dO*/=r>`a`4[iu941RE%lLeArh^?ZQ'6qNF=.FA)HaEmLgh>G-\]Bu].7KE
QPFiN!Z9cR%jR1a1Q<'>p)*/cUF7SDI&i&ZKE>i)B380QOq7nAB]qGdUMLPcNMDm)
]F:6mN[b3)+FW(!"#/hEl5GteK'IZ(jqW(<aALcKe`]7>KGVS]2h_9s_AlpB(NJ8T
K,:0DfXK4((l"`>c1Ckib*24H!heU.[c81_Akig])EA8%Iq0*"K+DLa)RJ.C9e7M>
ZlB@&j0B)K&0Cs!&oc33+@.@d&-MZi;$(EBIj)lqKM^au_iQn^!BjeA"hO>6dnX$7
;<]Fk0(RiPr@mCs`NUR.F\6tD2%3?8JcKBl8S\bt/3uhEQ40Th6AK/m!#qoaCt_Mg
0iU_p(_RJ<$3HX62X<1^LBo`;ao]L?Tns!Yk+o**89k['eRUFUr6U"^2M*KNPac`7
JO'9L3!T`%44]qnK:H6V@AZ!d@)hY3?t3i,\=a%6hA[>@U.XVh*&D[:>,&TF%cm`l
Pa8PM)VHE-@+Bui#_l5T`(b5>op>h=i07.)UMZh=&r0#i(W1iDEXg)K!m'YE)@.bp
$'d<DQbsuafuGEKS\hnFE!cVfd6=lgN(i<0Q!tqb?g7LPW$Vf_R%"@-$7HgSP`2B$
g#SY7mVsY<*`#mAmpj@c:m4@`g'_mg$B!YEX0C7`K6"s7&WpD#"_8JdBQ%%RZ$+7^
b1QfW2^@8)re#L=iu8U$CoI/s;-GV/iG6qk7j3@0joT$p*&p"NL*W^o2FHI;%oNBc
F],d'92KsR"i0%8,O+5%U4<\`!LcEtZ6ZeC_UD\h?-fYG_RS*k9l%[.MBr$^]+-k"
P`i>Pd:m#PR*>@0',#s\M6fc^U4B'Oh2,'R.LaCP0U1).jAT"%>G:=?/!?!L;u,QX
B=hkX'1&Ip\-rWf<,<$P6"pPtj;=1=/ZJ*Q)hS2V1E!Ll<,"+8WfZZf_dI!abm="j
0^`lnR_T%,h8q`;SH?\d8-K$]]NZa_e0D@jO%0=28(em2_^K[]$Qc#HknJ\VRWDO1
J2fch$"OTiWfL3f?J-XCp=1#mB1f")\NiDeK0>0m+dHpsi5T[U?*]UZqSYk/06ns5
5\WqD&1Y(l(F&Eb%KuhdhBf$)"0$KFPUnSkE8PW-q0cei\RWhXmVa_^%D*@4h8dO-
)p7en<d(U<#)X=[<2F#Yj`\gEKBdMZ5m1d)i#1NWSdB@TFG<B\[*@<'>>EC)S8e=r
=!Wg<=Gm?ZN)dhhl?cM3anW($&/Sh:[n4l1Cf3lS*KZJn6:$tu8@6D[6rPCs1!WfL
e!Q`I'%FgW[8!9,34P;:EA/WR_[K>T%V4j!%;T."aAq7@K.q>@/"U%DR,LD-fThk?
Kg83)Y7J%)cjYfjpG.9H0;nW;fVjcK5?^pP&F#gG:adq*3SPIiD"TjZcA!I1;GuQN
e"IUA3,^C3-db'jP1:P;Z_\HuB17k)D=,Q^fH182!9P;%K>rts4>GaOb38,+rA^M#
0SXZhE=;DF3&]Yj)o1Wi6#.JF$@^37VJrL+L:`&'-)[Xbn/7jKAI`q/V1h04%RH1)
%H+$!'O1aJ_kIH&ND>$0#YN5++>Uej3:,YQ\daLH1o&TM\cU<i%V(Ngic]#i0,AX:
!A%C`J^hGHr#Qfb(8P=Uj!a2=D5q<j&h>t`=6I;*`G<mU`2'P]7.ig42btO&KR\-a
^"OErQu_$qDdWcSRV8ds0P6V`F6gC2EqX@YFF2-m>[*8B)0Jb5'irPR?sUbap6S?%
@?#!.?eQpJD$]*MDV?dA8B_f^j`RVic2M(DH&ITNm>%.qNrbA&_I,foqMf$kMQNEh
D2`-iJ'a*Qqq3H@fqG9)S6,K)"$Y5ggmUdVLTHjSY>a5t!E@.KMQ<mi`XFdln-8(D
$;/j%J<Bep]Ie`c]+5<5&qgfpjiu`F3"<iJh\@E]'\]CGSo)9U(P2XTkWK^5gO!VK
FH0(5UYWUe&kU$dBkbZ!+qF%PMY_eR&=+7aSk=7DPoGfN1//J4RBftd_9_P;:Wi]f
:]ufkO_L]n-Q!Amg(&h":&q*^!6Tr85]<jq.51=YB,L&3kl.Os:(T5h`O,aq5&%qJ
i@l<4U`BM+SEOMQ:JRSbn'"Cc(BL1*#_:>5`Ge)8KF]340*'l2O8t]10U_Dem]\f+
:?Mi.E'T&$#B5!5n4G!7AI21RB;!1FjQq*[=ALU]#Z,"37>V%qcqXj;%Y1,Za>/BU
o*>lu!>((o&2q!C$OGbS$h2Su:fIp$U2a#PKZ1S5W)A80[fslN"qUqH#=euTU'8os
!mo^pE/Og[k)0f/$:G^i;#q1M=Q(C&%D^O(^toR]HO.Jh#&mcSWN-U#;#bJIj[lu3
cMXj5DQbY?q$Q?,0+?DY.V<8Aq<4PHB%DjAFpKVn^X#7Y%Zh02&uijgpd.FrA=fM<
5XgCj?#Pm!"7VJUaVol^)UTuDY`/#.;\dNLS'"_H:CaQZr5Zq+Rk!c[;.djYfTj6e
-aA!>AjBLl_@:CmNefm47\5pe]NG6kjJ:^EmG-F2jDV!jA0t.qlPaL-!"NE!g7nT5
,6T,3~> endstream endobj 55 0 obj << /ProcSet [ /PDF /Text ] /Font << /F3 18 0 R /F5 19 0 R /F7 20 0 R /F9 21 0 R >> /ExtGState << /GS2 22 0 R >> >> endobj 56 0 obj << /Type /Page /Parent 23 0 R /Resources 76 0 R /Contents 75 0 R /CropBox [ 0 0 612 792 ] /B [ 64 0 R ] >> endobj 57 0 obj << /D [ 56 0 R /XYZ null 622 null ] >> endobj 58 0 obj << /D [ 56 0 R /XYZ null 302 null ] >> endobj 59 0 obj << /D [ 56 0 R /XYZ null null null ] >> endobj 60 0 obj << /D [ 56 0 R /XYZ null null null ] >> endobj 61 0 obj << /D [ 56 0 R /XYZ null 248 null ] >> endobj 62 0 obj << /D [ 56 0 R /XYZ null 607 null ] >> endobj 63 0 obj << /D [ 56 0 R /XYZ null 384 null ] >> endobj 64 0 obj << /P 56 0 R /R [ 63 63 549 729 ] /V 53 0 R /N 15 0 R >> endobj 65 0 obj << /Title (Exception Handling) /Dest [ 1 0 R /XYZ null 864 null ] /Parent 81 0 R /First 66 0 R /Last 74 0 R /Count 8 >> endobj 66 0 obj << /Title (The %except directive) /Dest [ 1 0 R /XYZ null 674 null ] /Parent 65 0 R /Next 67 0 R >> endobj 67 0 obj << /Title (Handling exceptions in C code) /Dest [ 1 0 R /XYZ null 339 null ] /Parent 65 0 R /Prev 66 0 R /Next 68 0 R >> endobj 68 0 obj << /Title (Exception handling with longjmp\(\)) /Dest [ 24 0 R /XYZ null 351 null ] /Parent 65 0 R /Prev 67 0 R /Next 69 0 R >> endobj 69 0 obj << /Title (Handling C++ exceptions) /Dest [ 33 0 R /XYZ null 291 null ] /Parent 65 0 R /Prev 68 0 R /Next 70 0 R >> endobj 70 0 obj << /Title (Defining different exception handlers) /Dest [ 42 0 R /XYZ null 572 null ] /Parent 65 0 R /Prev 69 0 R /Next 72 0 R /First 71 0 R /Last 71 0 R /Count -1 >> endobj 71 0 obj << /Title (Applying exception handlers to specific datatypes....) /Dest [ 42 0 R /XYZ null 354 null ] /Parent 70 0 R >> endobj 72 0 obj << /Title (Using The SWIG exception library) /Dest [ 50 0 R /XYZ null 516 null ] /Parent 65 0 R /Prev 70 0 R /Next 73 0 R >> endobj 73 0 obj << /Title (Debugging and other interesting uses for %except) /Dest [ 56 0 R /XYZ null 634 null ] /Parent 65 0 R /Prev 72 0 R /Next 74 0 R >> endobj 74 0 obj << /Title (More Examples) /Dest [ 56 0 R /XYZ null 314 null ] /Parent 65 0 R /Prev 73 0 R >> endobj 75 0 obj << /Length 2956 /Filter [ /ASCII85Decode /LZWDecode ] >> stream
J/gkM&HS[n!uqRi,>ku'5W=FR%Rs9/>X302OG\S9Go1-9Je\^@0n=jK,oF`nK0b_a
E&8+@%A;B'ShaCZ$cqEiBq4<.,*i8(JH2LEC'Kf1AJiX/4!0R*jYCSI9Q)L%N<^Zd
ST\L!Ra("O\a9<J1mjZt"[fs3VH5%*`!')-PiY+SSP:Fu/K0aD#/HmnBLF77%#74o
d5\46RiEX^A.olGSuX=ZA;9[Or=4`UUsef'gm(?#<0Tu[&mEOt]-!G;aJXY.Pi-X?
S'AeO6%n$(2B#<0HhN3s"+nA/0UQ*8'bZBmUCjS]6ReqV<97V8FMhTVinu8V8q'N(
fZW6n=fU"m^#'Zc7\!=nB"/s!NQ+0LJJ*\f0#O0!h7mBS=:bd+W8'.]!K^prL*=WY
)n[TQ8gAndBU#M+9UP70,bes;/W6SVaQ,%+Z9G@E6$"<>L8rZCQ:8UifER4N4-mc=
#^R]73_Xn[e0G;E1=e7Aq`_d%:8EX2TSg<%(r`2QD!j2*fMFSgK9LsEKu!o1.Lcqs
`]B,IOAb1o"";qc%>2_e3KBkbi&?Z`TZT"m$aeGB:B:IZ4H9LnIPB+,`7bb-5tJR:
#u#kio-AFI/P38u`0-P$%00QLLB2@*;83E.>q8PYn6-Y4_1G^pXil6T08ZGPgH5uj
/CQ^@W@1sKe7iTprridVi\--4I<7JNN<#ml<]2q6"ZHNsb@TA,7A"8E@S;/*Nu#[a
B3H'&A1rh)-*LV0G1FcG<am3"3t3kWF<M/=dd/p&[b]2<M;to.1C\t]mr;^DIEj:&
1O-fVh3^pH08dXQfK.i3A_I@Gf7:Vj99lptEaiLVgbk)D0\ql5Ojf]8\^C;Ka#o1N
."S%SJ3_>jN8)$@8T$?(Ve411SuTp^BPJI.ZF`/\MMkJ:q)/UtMW$J#'[*/E[$s`,
L:%S1O+pH_@/dLYTP%:L'UW+1e[n9M=kjIeDZPcI5e%NF\TE+aZ$Dh:U,pUaNg*)g
G'qTa\Sd/ek57?"#)5FW>0O5IAP]3s.Nlt>$uNn(Ju@qm\?:S5>kg"5Ra`/tKqi&!
JIRDg=u!M&!6#-PX/u(ONJjb(1=7p_Kh##@D13C'U!"`hL!EtWs(Z4ffETN#KYoQO
W$pFUip5TR6-uB?_DkBZpd$ZpPUPT(F8l2-2\'m;a0"d3\*"\>,7rq1'9I0XTtPb9
+@$c@Z+^CF+\8`DVU]"g-k,(a0SXPh$Vh:]:of"'Vpf>YO;mLE`rRiF"frQY6,$[!
[0)1<h[,;5EXgup&2+8`HHH!!J'\0,3cJ[?SWQ-J."1*f!:p:0im;EL=ZX,Jkgn_A
rshWA0U)"on,m&NDl*i-UXPfr)5BS]N>R>>OqJ3)ZBK9B.DE=_3uH8S4,h*?Q@hO_
B2[)E%&&J<L2bHF@2L*rnN=EHjRj*_j<]#M)>GTk9)_Pt82(Wq^R1<t@pBt7B[#S6
1U=<1>[p&^7ZF._)*$V#UH<1-D(HG,iinlU;elXo68cQ;f8dL."i0(;K-I`sa@a?e
.X2i*e7*V@I(olL"_($t5&KBn)j5t79/meD.3'd7PjV:XU9up6giV1h1Mn:f'!A4M
R4pEKKiCQm:`0@/7<C')"u0]s*Qe)%%H5i'6M0($+$arXNj;hGYeoU3UU:AG_9bEU
E#Smg#7W<Agp(NtmYg@k;BW?KT-i?E6,V/'EA??AfA9jZjF31$W@lPB8fQZ/X?^^S
0a)%h\-!"R%M$TM**0Yqe?MtO!8tf?pDWUZ@JC%aZ?FG<<oqWsC'>82]*Cgr*?PB1
"9IlKP6[bb8W(H:7gM-[B(HJJO@;n*g(M.<k30Y.+9[8,S;'kM(B\b<#&W]IYoljL
.s(<ceVuN=B([lEOA$(VKmF_")#U':ENXH8]@WI/?GT?a;q6/$.S5:#"705GZV_f=
A:i'<b;`%L%':foNANn:DNq:BE\rkCfICC$/.03F:M(&"BAEGZ6'sUY"q9h!I;_&d
4lF$<"S#.FmgbGl\tI)u?'AHLSu1oHe$.9g+4tE>+e1AMf6.E%)ugCVTeF/iMaiUl
D_$@jmjph=<FH:b2t"c!hMNfP@=@<m!JKDZ\*Zn^I5n-(nOArSIVGeg,uXg)Qq"N7
I1`,3#7\0]K.pOu-=b1uMRoaN3iN%X]ibLrDQ^!>7;&Y6?Egi/`)`iJ>A.l9Y#Wkb
=^(K*/+=gI!RegE.a*ed*K%+hilG10G@`;E5I3=Z(KLo.BMAVnZu!ToSI)K7-QT6Y
a@]8ubd*F;-=LOY8I%**>$BXCX[shH/HcX@!+IGMT4,u(Jd5!7*E4)p%Z^K-#mq]j
9b='1Ge0f;pN*=i#=4HsjAq)!KB:7>#-CV*eeu;%!HJf!TXRY/*BRp)'[OjgS\J?!
^>Pn'S'4>A(_E2hVr\t-ekG;0,2%@s-7l6<Q0C;aOP1PS/6\EuKGeQ1>kGDr:Bgg8
8\KN:Tu`MP9rZJt#=K(dVrP;!J^?GSE7(;QgjP7W3&-0Yq/DZ%of!XJ6JoY/)I]?J
2PJ>T^]`595t12J$lRaSK!G_3PHDN>lo#&=OTUkde0[3&'OGr\Ss/52FcC,'L=^ct
OC2TX828rU8;dN?\0)&b]HMm2=1TITLo*Z+6h5HG]A(P0cqo?]69X_Ri`?eF.O/e+
<:"RGG\IVf>'Nk;qfLa[MQeq^X`:t0EKL*O%B]%M?OX<%olQP-nVP?,;Q<(3*k/*E
kH[QM=07<m0a=Y5Bp'*@Q@`ka9o(LVe!bHRUm0<NEI4r[))WkNQo4;7QOE*%ASPJ:
C$mR*@2g4I[<SG@,4$-\K90Z]!=%Hb%&2d_FL`NfUp\9_KJ>o"^J,lMAY>tVGSC/J
hkCU0Simh8X,9UX]@GX!"Oi0tk,j6Iqrpn1m`#&'N1)":n%`Pk!2hNuEW3^UL%&4K
^\%3EgV5SU_9G<$0[gP`Y[^FPUboQ-*C.Ma$Y5>k$:/=ihae"~> endstream endobj 76 0 obj << /ProcSet [ /PDF /Text ] /Font << /F3 18 0 R /F5 19 0 R /F7 20 0 R /F9 21 0 R >> /ExtGState << /GS2 22 0 R >> >> endobj 77 0 obj << /Type /Halftone /HalftoneType 1 /HalftoneName (Default) /Frequency 60 /Angle 45 /SpotFunction /Round >> endobj 78 0 obj << /Type /FontDescriptor /Ascent 733 /CapHeight 692 /Descent -281 /Flags 34 /FontBBox [ -166 -283 1021 927 ] /FontName /Palatino-Roman /ItalicAngle 0 /StemV 84 /XHeight 469 >> endobj 79 0 obj << /Type /FontDescriptor /Ascent 733 /CapHeight 692 /Descent -276 /Flags 98 /FontBBox [ -170 -276 1010 918 ] /FontName /Palatino-Italic /ItalicAngle -10 /StemV 84 /XHeight 482 >> endobj 80 0 obj << /Type /FontDescriptor /Ascent 726 /CapHeight 681 /Descent -271 /Flags 262242 /FontBBox [ -170 -271 1073 926 ] /FontName /Palatino-BoldItalic /ItalicAngle -10 /StemV 122 /XHeight 469 >> endobj 81 0 obj << /Count 9 /First 65 0 R /Last 65 0 R >> endobj 82 0 obj [ 14 0 R ] endobj 83 0 obj << /F.Exceptions 7 0 R /G996747 2 0 R /G997896 3 0 R /G998041 4 0 R /G998055 34 0 R /G998113 25 0 R /G998328 43 0 R /G998353 58 0 R /G998422 51 0 R /G998549 57 0 R /I1.998478 8 0 R /I1.998479 61 0 R /I1.998480 9 0 R /I1.998481 10 0 R /I1.998482 11 0 R /I1.998483 12 0 R /I1.998484 27 0 R /I1.998486 28 0 R /I1.998487 29 0 R /I1.998488 37 0 R /I1.998489 45 0 R /I1.998490 46 0 R /I1.998491 62 0 R /I1.998492 13 0 R /I1.998493 63 0 R /I1.998494 38 0 R /I1.998503 36 0 R /L.Exceptions 60 0 R /P.109 6 0 R /P.110 26 0 R /P.111 35 0 R /P.112 44 0 R /P.113 52 0 R /P.114 59 0 R >> endobj 84 0 obj << /Type /Catalog /Pages 23 0 R /Outlines 81 0 R /Threads 82 0 R /Dests 83 0 R /PageMode /UseOutlines >> endobj xref 0 85 0000000000 65535 f 0000000016 00000 n 0000000146 00000 n 0000000202 00000 n 0000000258 00000 n 0000000314 00000 n 0000000516 00000 n 0000000573 00000 n 0000000630 00000 n 0000000686 00000 n 0000000742 00000 n 0000000799 00000 n 0000000856 00000 n 0000000913 00000 n 0000000970 00000 n 0000001025 00000 n 0000001114 00000 n 0000004218 00000 n 0000004354 00000 n 0000005423 00000 n 0000006494 00000 n 0000007569 00000 n 0000007683 00000 n 0000007760 00000 n 0000007887 00000 n 0000008018 00000 n 0000008076 00000 n 0000008135 00000 n 0000008193 00000 n 0000008251 00000 n 0000008309 00000 n 0000008388 00000 n 0000011185 00000 n 0000011321 00000 n 0000011452 00000 n 0000011510 00000 n 0000011569 00000 n 0000011627 00000 n 0000011685 00000 n 0000011743 00000 n 0000011822 00000 n 0000014260 00000 n 0000014396 00000 n 0000014527 00000 n 0000014585 00000 n 0000014644 00000 n 0000014702 00000 n 0000014760 00000 n 0000014839 00000 n 0000017847 00000 n 0000017983 00000 n 0000018114 00000 n 0000018172 00000 n 0000018231 00000 n 0000018310 00000 n 0000021908 00000 n 0000022044 00000 n 0000022175 00000 n 0000022233 00000 n 0000022291 00000 n 0000022350 00000 n 0000022409 00000 n 0000022467 00000 n 0000022525 00000 n 0000022583 00000 n 0000022662 00000 n 0000022805 00000 n 0000022926 00000 n 0000023069 00000 n 0000023219 00000 n 0000023357 00000 n 0000023549 00000 n 0000023689 00000 n 0000023836 00000 n 0000023999 00000 n 0000024113 00000 n 0000027161 00000 n 0000027297 00000 n 0000027427 00000 n 0000027631 00000 n 0000027838 00000 n 0000028054 00000 n 0000028117 00000 n 0000028146 00000 n 0000028773 00000 n trailer << /Size 85 /Info 5 0 R /Root 84 0 R /ID[<ebee558180d5066419f25983d17ad558><7b950ef065ffb83dc9af06fbc1f5577d>] >> startxref 28902 %%EOF

1612
swigweb/Doc1.1/PDF/Extending.pdf
View file

File diff suppressed because one or more lines are too long

314
swigweb/Doc1.1/PDF/Index.pdf
View file

File diff suppressed because one or more lines are too long

655
swigweb/Doc1.1/PDF/Introduction.pdf
View file

File diff suppressed because one or more lines are too long

310
swigweb/Doc1.1/PDF/Library.pdf
View file

@ -1,310 +0,0 @@
%PDF-1.2 %âãÏÓ
1 0 obj << /Type /Page /Parent 21 0 R /Resources 14 0 R /Contents 13 0 R /CropBox [ 0 0 612 792 ] /B [ 12 0 R ] >> endobj 2 0 obj << /D [ 1 0 R /XYZ null 844 null ] >> endobj 3 0 obj << /D [ 1 0 R /XYZ null 640 null ] >> endobj 4 0 obj << /D [ 1 0 R /XYZ null 364 null ] >> endobj 5 0 obj << /CreationDate (D:19970623235242) /Producer (Acrobat Distiller 3.0 for Power Macintosh) /Author (Dave) /Title (SWIG Manual) /Creator (FrameMaker 5.1.1) /ModDate (D:19970624001617) >> endobj 6 0 obj << /D [ 1 0 R /XYZ null null null ] >> endobj 7 0 obj << /D [ 1 0 R /XYZ null null null ] >> endobj 8 0 obj << /D [ 1 0 R /XYZ null 625 null ] >> endobj 9 0 obj << /D [ 1 0 R /XYZ null 349 null ] >> endobj 10 0 obj << /D [ 1 0 R /XYZ null 696 null ] >> endobj 11 0 obj << /I << /Title (A)>> /F 12 0 R >> endobj 12 0 obj << /T 11 0 R /P 1 0 R /R [ 63 63 549 729 ] /V 66 0 R /N 34 0 R >> endobj 13 0 obj << /Length 3042 /Filter [ /ASCII85Decode /LZWDecode ] >> stream
J/gkM&HS[n!uqRi,>ku'5W=FR%Rs9/>X302OG\S9Go1-9Je\^@0n=jK,oFcJ,B:NG
5ZBXoA>XUn?pH@iPf?#l3Qs`W/-A<B!D-,;%3ig70ppa>59Z03ACW`&hKCgr%Rn8r
jM#+[Ra("O\a9<J,q9bo;Y.R-VH5%*`!')-PiY(RSP:Fu/JaC=#/HmnBLF77%#74o
d5\46R2dF\A.n`tSuF"R5p_]YKaNZ+Uf+Jfgm(2t;j9nM[>NLT5FiK%:8Yq&Uu6&E
L^_:o`;%2e1'eAENQo2s+>t-37jA>]o7#'E?uT4-`Y/`9ihB:@ZsknSVr]c2C66S&
S$-J9(^aW!SWf1\o([3rY-V?8lit@fJ@&u.Kuceg)hp#`?6UdaZKsT2,C&"*"i6!s
&.(_&gt]QhQsq%j+hQ<bUnTgeSV]t+eB*a8!_Oem!nb)IN/jA5)a*)PA/@!mLha#b
n[*8r!MZ'ZlS-OL*f.(]lUE*'mt+%*[/gE'))3RUd\4S:CYGZ-P&M?g1=CcULP?1'
@bA,+X)?^NMVr=-KFRg1iOGq?jQIk_C^M.*_P@_W3A+O)kHkX""RE;[b`M6IcM1ic
Z;2bi.6R1-@*c%D'cfgKcSVCe^_H9O*(Jn[@%E%gJ8n>=#n5)t9/Jbh758mo]e2E#
N?:rhJ[2IP9_?5t/\D_hG=`tBgiaS>_5$_rL&lD>5-:R3:a6G0OpX,V@usUS"Tp0i
]!rtuhD.!,B[SpP1Q-bp$ug1P16'1GkV8%#S^rCj_l2]YN$D``G2L1cbh9KnGX1BF
iPiYfNH]NR3\J<(_gDRhR,B`Y@nbSoL;OkFg;1Tr\ge"Z>kJBPM0olA>+n4H3+@,/
gGH@`^d4%+j!oInKGQMmhM&cJN4BE6otWMHbMIY,U>r3+0eU9BhD7)l&El1>=E^8l
BEKC61l]C45W)odUP(H5,FDc#AIa]1lnL>$)dBT\CJ?!8Le)@(4VYQ8@O&M6`P*gY
>'@!_!Q@h+g;9V@&-TTf`\n=-i'9%,3pjd=[^VjePgIW,kp+ck]U)m'-maro#:P"N
oh`$GEFX.6UG^#FiLQIj9)OlnkTdd!9[$LYo_mJln0i?TKE5atjM:$s.rKD9j^Zb:
40MR/4imA;??TV<3FM?)?cQ[]2K_%uZ9bC8htAVgUJnLeO#PAC]`1<9>9S,!6-u5W
(Gm#"n8Ac:\2U<S[*KW=A.FPI3\L]IkEhrYJkT1&VSq8-)CS107/<X5OP1O;CSLp'
Zl9),=S,E=egGAfQiP[<*0&t]>`9t_Q_;uM6O4eE$sYZE&C,0$6iDR16$TU\36;_Y
=(<qU-S;3KCt\DK>75+"LOd5\;ck.I:oWHNk@/"nLc@1cbq'b74psZFX$:OQ"9R3C
%1M31"TZ1OJcLaJ%ELS>E,g7,i6n2?Jt3*Bbs-e^Y0NaY@u.B0kQO4NopiAA2^+DF
YR$oVUcG*2dUDK&PB%Pd?uTt6N_i;M/d`Z3Q^#MT5Tn_h/#=MsF$YqNL)FnXV0oP3
6sML&5jl'J==t#&i`Jd?At*=5/d9&',g'$[$eQkJ"i6pH"#mZN*BDhF.Q,ti[rP(H
,(+d[?""epeN'6G@l;T[BG0mcrP=mFAg(F=+SH.]>9dp#XT[OTFhC`U65+%jJ3079
fXr?E,<%=\"u]M(*T]p5Jae'BY7TJ0!t/XUNL>=Dpn\.+EI81VWBA'6>4TKs#@!@>
U<W?BOf&i#1%Cd5`g:/m?UM4o7Qjb]ic\n5.uslj6l^h<@LU)9bYO;M1P6T^XPWL%
F\6NA".7[8hI=AWlQ+e4O?a5GI.T<-$"6;%9]FW22$ORl2O&IQ[$)C,Xu4Ij9:7Y;
k6lH\':$J\E^2ns8ZRi7[G*68i;4U;O0&dEB2q9/["3dk$BOGs6&.]D=.8V;nHoE&
JEBY+>T4/H=c>WNI"]?R+?4q*^/;=(DbumC";\p9LA&.WD/C7?_/L)FR$A"]4"5lF
]!P"qARAJo0j43f)Zkb`8t/po?)KRZS!EsjTBeULY[rBh")r1qi$i?GnTnA0Q"d2!
,e%T%h`:"TD:cs#:=M%S-P5SHiAn;V9F0h:O;fV*\I^?Z<5(A>\@<rV!]NYRc_09F
^=hJ\2qJP<"":b""-@DiXVJr2j<h]HZWN#AcJ#V93C+HpDLnl?gqeh.s"K-,60A]c
_Pp!3)%h".oa/1Bf25SM)gPQ(-,-+M.p+=(@XKdG?"Cth=cCI+W70>_3>X"KE;=ZC
p3,lWpI0Y(/E"V!k,m9)F^^Qg.4'-hoY),D5kBW?,RAS$-@4>7!].hY:AFjW+DUAF
JK[hT$'gdB@LI9<>;J/1=CrO??o))?S<c4Q^-s*,C'A%:g"H&L:h*FtG,NYoh`f_>
k<?&Lqm4WIIN3md)VuM>XiH9`K5bk:Zpp7V$OEj_noplf%Z7I<RnQb?1u8akO4;9L
FgroSi?&i`SJ@^kK*#;4ojsD/"V*/gJDf.A)^?K-W<Za+k/`0p^;\^^h)#;f`n,4H
_:G/o[Kes9)iAre,Xn!Rph5=Y-=$cl"U9_F6J@nB:W?,.Mm^,g]4eugAqp4Gj2T9U
:prEs.r71PrT;FG,A\a\P6bc6!=9pf-\i*@+%^]l[AX#s>="rC*1fC/an'=$fKFuo
5(mj@HT*jAjP7iOZQGV=?&S6-1$bqD)3Tot\[mPE]d+$Y6+YGe0.sm(kjnDXF.4f5
J25QZ5tb`fN4QQM4CSF7(mc0]%?$4T#(hY\J]E>&EV(KG^r>#eg@^=?V5STilZp,(
/:&e34D@@]#Qes`76G4Bp8DrCpXac!l"+Or,Z4_S;CY86`^Q=m@$<re5tQ@?nPd:s
nU[)\l^BT."-"?i3rCh+f2Vm(SKO=d5Y5_r4;e5$;/_YT'*J^>Oh%^e)l!+A$tg\A
gIaqgn_lZbi2$4$L"b'@Qu6,epc70OiUa5*5$VA2TWWOEBY1gcUC2S7EMbY77l\*B
!5O2B^r-R;aV'_RjBB`K%?J*4#UG"W-Jddr:I&Xu")Klu54<++?jS5Z!)ROo;G.GF,@U]~> endstream endobj 14 0 obj << /ProcSet [ /PDF /Text ] /Font << /F3 15 0 R /F5 16 0 R /F7 17 0 R /F9 18 0 R /F11 19 0 R >> /ExtGState << /GS2 20 0 R >> >> endobj 15 0 obj << /Type /Font /Subtype /Type1 /Name /F3 /FirstChar 32 /LastChar 255 /Widths [ 250 278 371 500 500 840 778 208 333 333 389 606 250 333 250 606 500 500 500 500 500 500 500 500 500 500 250 250 606 606 606 444 747 778 611 709 774 611 556 763 832 337 333 726 611 946 831 786 604 786 668 525 613 778 722 1000 667 667 667 333 606 333 606 500 333 500 553 444 611 479 333 556 582 291 234 556 291 883 582 546 601 560 395 424 326 603 565 834 516 556 500 333 606 333 606 0 778 778 709 611 831 786 778 500 500 500 500 500 500 444 479 479 479 479 287 287 287 287 582 546 546 546 546 546 603 603 603 603 500 400 500 500 500 606 628 556 747 747 979 333 333 0 944 833 0 606 0 0 500 603 0 0 0 0 0 333 333 0 758 556 444 278 606 0 500 0 0 500 500 1000 250 778 778 786 998 827 500 1000 500 500 278 278 606 0 556 667 167 500 331 331 605 608 500 250 278 500 1144 778 611 778 611 611 337 337 337 337 786 786 0 786 778 778 778 287 333 333 333 333 250 333 333 380 313 333 ] /Encoding /MacRomanEncoding /BaseFont /Palatino-Roman /FontDescriptor 88 0 R >> endobj 16 0 obj << /Type /Font /Subtype /Type1 /Name /F5 /FirstChar 32 /LastChar 255 /Widths [ 250 333 500 500 500 889 778 333 333 333 389 606 250 333 250 296 500 500 500 500 500 500 500 500 500 500 250 250 606 606 606 500 747 722 611 667 778 611 556 722 778 333 333 667 556 944 778 778 611 778 667 556 611 778 722 944 722 667 667 333 606 333 606 500 333 444 463 407 500 389 278 500 500 278 278 444 278 778 556 444 500 463 389 389 333 556 500 722 500 500 444 333 606 333 606 0 722 722 667 611 778 778 778 444 444 444 444 444 444 407 389 389 389 389 278 278 278 278 556 444 444 444 444 444 556 556 556 556 500 400 500 500 500 500 500 500 747 747 1000 333 333 0 941 778 0 606 0 0 500 556 0 0 0 0 0 333 333 0 638 444 500 333 606 0 500 0 0 500 500 1000 250 722 722 778 1028 669 500 1000 500 500 278 278 606 0 500 667 167 500 333 333 528 545 500 250 278 500 1000 722 611 722 611 611 333 333 333 333 778 778 0 778 778 778 778 278 333 333 333 333 333 333 333 333 333 333 ] /Encoding /MacRomanEncoding /BaseFont /Palatino-Italic /FontDescriptor 89 0 R >> endobj 17 0 obj << /Type /Font /Subtype /Type1 /Name /F7 /FirstChar 32 /LastChar 255 /Widths [ 250 333 500 500 500 889 833 250 333 333 444 606 250 389 250 315 500 500 500 500 500 500 500 500 500 500 250 250 606 606 606 444 833 722 667 685 778 611 556 778 778 389 389 722 611 944 778 833 667 833 722 556 611 778 667 1000 722 611 667 333 606 333 606 500 333 556 537 444 556 444 333 500 556 333 333 556 333 833 556 556 556 537 389 444 389 556 556 833 500 556 500 333 606 333 606 0 722 722 685 611 778 833 778 556 556 556 556 556 556 444 444 444 444 444 333 333 333 333 556 556 556 556 556 556 556 556 556 556 556 400 500 500 556 606 556 556 747 747 1000 333 333 0 944 833 0 606 0 0 500 556 0 0 0 0 0 333 333 0 738 556 444 333 606 0 500 0 0 500 500 1000 250 722 722 833 944 778 500 1000 500 500 278 278 606 0 556 611 167 500 333 333 611 611 556 250 250 500 1000 722 611 722 611 611 389 389 389 389 833 833 0 833 778 778 778 333 333 333 333 333 333 556 333 333 333 333 ] /Encoding /MacRomanEncoding /BaseFont /Palatino-BoldItalic /FontDescriptor 90 0 R >> endobj 18 0 obj << /Type /Font /Subtype /Type1 /Name /F9 /Encoding /MacRomanEncoding /BaseFont /Courier >> endobj 19 0 obj << /Type /Font /Subtype /Type1 /Name /F11 /Encoding /MacRomanEncoding /BaseFont /Helvetica >> endobj 20 0 obj << /Type /ExtGState /SA true /OP false /HT /Default >> endobj 21 0 obj << /Type /Pages /Kids [ 1 0 R 22 0 R 37 0 R 45 0 R 53 0 R 58 0 R ] /Count 6 /MediaBox [ 0 0 612 792 ] >> endobj 22 0 obj << /Type /Page /Parent 21 0 R /Resources 36 0 R /Contents 35 0 R /CropBox [ 0 0 612 792 ] /B [ 34 0 R ] >> endobj 23 0 obj << /D [ 22 0 R /XYZ null 740 null ] >> endobj 24 0 obj << /D [ 22 0 R /XYZ null 604 null ] >> endobj 25 0 obj << /D [ 22 0 R /XYZ null 424 null ] >> endobj 26 0 obj << /D [ 22 0 R /XYZ null null null ] >> endobj 27 0 obj << /D [ 22 0 R /XYZ null 725 null ] >> endobj 28 0 obj << /D [ 22 0 R /XYZ null 589 null ] >> endobj 29 0 obj << /D [ 22 0 R /XYZ null 589 null ] >> endobj 30 0 obj << /D [ 22 0 R /XYZ null 409 null ] >> endobj 31 0 obj << /D [ 22 0 R /XYZ null 357 null ] >> endobj 32 0 obj << /D [ 22 0 R /XYZ null 357 null ] >> endobj 33 0 obj << /D [ 22 0 R /XYZ null 357 null ] >> endobj 34 0 obj << /P 22 0 R /R [ 63 63 549 729 ] /V 12 0 R /N 42 0 R >> endobj 35 0 obj << /Length 4188 /Filter [ /ASCII85Decode /LZWDecode ] >> stream
J/gkM&HS[n!uqRi,>ku'5W=FR%Rs9/>X302OG\S9Go1-9Je\^@0n=jK,oFc/@sE7V
BHScD6*aEOA?[0mOih/W!M&9p,*i8(JH2LEC'Kf1AJiX/4!0R*jYCSI9Q*$4N<^Zd
ST\EsRSB[nWT<o,6B[TBF#eg.L/TUc8E']MbfXsuOj9hf+dS*YV#t+%82MM)+GN7X
&EoWb027H=L9_,>8l&HO%4%]oFaf*7UXEk%#jtH_,cXH_",u&N\R(ZMaer'Gd*ckk
)+4[=:?I"62]2`'6UpA"EY'0!-6nY+jE\N(YY[;1*+K;/`,TcFUfoJkaODuVN4hno
1ot>51es&8RGb"),[O0a+D7gYf44fbYih_rL4Q:.KS?,0@b8A(,).U#j-\7RNQD0*
(kmM@PWFfKct"$2Tnm_/L@8k8P)/%2GU4hl;^a`'#q25R$Y&Bn1-1@BClbV?OBfo)
6)q;I]b0"^#)[7?N#]Q'*0A@c%m),`-1>&'Ud,KY@Y-k=EZg$mOAK*t"i5_'.'6oC
`\n5MRXQG5j%/Ml\3\J,3"D\sPVIgm'[eamF%"Lh%rR7s(;Smo%%'=H7-QcB,8bOd
V=Ym96RS&^L)3c!r?FYUoWV.ULN+!)l`f_J*f.)(oSi<(Ek>52+G#>`c+Q]4f[.=^
>`sZ2O"(F9KE8@q(C%^]=P0`+>eh22E^6S4$Xl<!1^to/dPhYo\BHXcD:#eqL<[e)
4,rX&KJU06'8GM""),h8N(^d,$k.![+Q'[P!6?jSK*ui_"YR;]2iXL7r%Uug4OQ7,
UCc]O";$+94G3g:lkGAPTTll_:;&/29EBgb[]"'ihL`U)0L.XY"";/GgYnN91#J(?
+ubJ52>&lPmM6Np"k&kb-G3d#-6&rseVdqb3Y\_58JEM:@o3RM8huGCaQ,9Z9H14S
4&nYZa1_iPG?7kf!,EiP%/"MR1j^fVWE6+"#T8@hg/=8ldiF:F2E$NWJ7(`m]/<dP
4sQT[2[ITB2re<.2r^mBbh>!cGi^s5UL+[n@mF^3%BGp_6&p^;qUoM4[YX3."9T\N
2Soq@o9QST2=TQX]P-(WhSXK<#iF*$#TO!M4*3GdK36%Q"l0A@_!BN'_T$D0qOAcV
NBKi'Tco5.oZB&"Kj<uYlc8IoW(hiNU"g*RFp+R2g,O.UJB0SBiC7'hPC(_=:K6\J
VSlu9dG\p/e<DHuMG%;*T2\=omC+rtX4;:[Bat#NX(A/GNenciLWg_\2+WLaQnfp=
2#i2="qF1EKPs\dWe,u.ek<V[<s3CB2@'`b+@<YdcnSW8!,e"NX:g:r2@;^JLB\KN
bq"=km"78WB9N+""q"@D'M%ls?i"Y!93'-4",>n>3rCt?Cqd-KRd`oDAq-ln&3/-d
]%>j_%kEon+U,RgJZB=lk5gAD7joD'CTq"5)?Bol>RXH`Va0ToWj31JQQk\0AIW?j
Xk&(=6Z?XY6+ICW^rjUJ$<IB:<L#Fq\ATV\ib&Y$a0"I>*TJ8[%I?>6L<0W@8c!'.
V`5BUOAO;3q\43HQk0J!/ArQjD?[6M.KZ>VQpI,`MlZMdZaY>O)7'`\/o?e,5h[,D
3,"`jC+qE]+E4,4#!sJuC^2?_^g9F,@ZTk3:Ol7ZMnK%\N'QEi2eX'<TOjN!Z2m9<
G#m#$%Y[0Z.N(*+d".E-#2m<!;*$3:?`WpN/Telq<DO/@;f[G/5`c)(OT\m6dYXmA
-aoAu%)J`@=UBa"T=DKLkS!QI6knOaYj!.FF38Q<]Y$%5(/\2W)kkT'0I,U)TrHNm
1c4;).2oG=klY%';!GJ>2SQ/Ng8SnM<gC+^]*''okAE/_R^ZZj7T0=n-'\+ned(:X
,V5j65_=U?"q2FQAPZl7[Gs&Cm`HiOFdD.cW4F4Ve.gUMFYZrNRDqe)Ag7A9B*9uf
"=lEAeH;E:M2AF/dm$qL!/q:oG)#i)DJ39c>4RJ0#2:,ND=\GM2SnHN"m]])OaSU`
d(@G1KG]`'Q("k4OFngR(IPIQ60q_7S,ghT??s,ToH^'%i7teQUD+4#p;D]9_OK6,
nICOlJsY$d/Ao,9TM)E*S+sfYQNA$a7f_KPJDM=/Ut.+RCuX5#s#aAAAIOVhb.UD?
&#hSELbGU2OI*aR&I!,G:e`/uV-A_IBb)SAcl3acC_CYGC_!Z:UtI)+*SmbGG!WRo
09_WTBd0@KeYVWN-eAqFE&%V)rZor/d9SLj/6Do!Q.)I=(0M@*FeGD\L+ptp6V(uO
9W0,[0L-2c==\PG&3(W_"#5n>Kk?AXaZ2emRIQ]V3Cbdd0hCZkfS_1aR-u)d/:MK(
Z_+g-=;3Nh6BU"_4DtsH,pblU<tW'BdWP@RK$`24CHL.c<2V,oglOfF<_TA*asLY9
9hPdd<n/=CoN0WE=;`8M%H5.]Y\VF5K=tf/F?N^$Lf@%%DBgtf&Hel=:R)J.3*FIV
0W$U5R6_Z4`Ymdt4B%Pe:3jIrbSkW=IE$,jEe9HH9hqXK9$6U,M?T^$1V.jZ[6m23
+OViY/]nbGFT^3MqMqu%m%W3B;f'ReZC/.9lN;-'+9lNV.lt)':Enq*>&fWXLB-9Q
f&g<LJ^pldoueL`V@e*)aP-nTBQL:k((@?P`7r:T_h0p]EAPc#Qa#/&**$I>LcWT&
)>Q,UWe6IXD+cW!>jE/bZCk7GcQ"!"c;R/']FQDNZk0B[:l]nX!N/1d)=kr'CG0\4
RVnWdacB9A!6uCWK4"QFN/R*+%*`Mf(_TGu.]JV#J2LK)TPt@0\XH$*;'*dffL)XW
<GI)i+rLU4?%K2>:rKZ0+F<rZS.rZcp/M)@=LYm&U6`t.HX+`U(<`dqE3^BG&X=cH
<OJP+=fFlm,t`1d!QgPtV/RFO_M>l.Pb$_0#9gm28\qfa#bsA9o3t<l_r<9!KV6io
nL??6>SZ\@$c[KF3>1a.>8EK^:nNJ-hk2:FJoa5ZK!Uj<*IFpcW8Zp83Y_pS^gQae
;!EWI_/G@RWT*@4o$(uqG,lH?bC5sHk]Z(Ej/Ku4L*C0K2UCg&q2@#KN&H$!9I`_4
2/;QK0<!=!AAkQ1K*U0ZMXZNj6A*80YcbpjX]U@Yd.troVN).h`&=IWiqgnlDN(Cr
"buX7W(\bL=tJ`BN<$Y%LhBP%gaQiUld#2kLlX+L":QL:8`8\_HoOW&[]BDJ@rQ2i
2W(DBBHU2!?r.+Ok.rLM!%".nYO;kG`aYiR?cQ]^#f:baB"VW$6Ep$j.h6T9C^.lL
ro3F3k&Ul'^3Hg)Gp@EqL#?9/B))c2s/%]cAX3PB0IUk)&S$4S`Md$9*&K.BI:NKU
!XMh<-B\XLBL#`d5\ffO:DQK#F\$?M6Mgl3G,5ariR!&5$`r"k(C6(q#g];20gu66
4P&l-[E-.^9Ap8_^+RdLAHM5[O\Bc\:7$q)ASHmKXLuma<<J'r4Q<jT#\*%2<+I0i
f-RR0Ac!#@K^H!Y/gBHcXSgJBW"%):p!;:Bb9F0`apoWh]-D@)Opj9Cb9-ep"YijO
YO4G%V?IH?BMhr5U]^oUJ2%1K<6?gXn_@/358Nf^+sf@#XCBL1K[`WDJM;KJ0Ru[?
;T[)E)5o0i`r(u$5061r#uD%6/E7hk`k@MZ'!/`e.EGeRriu`-PY2S'mWNYCr%Fs+
;=@&R+EAib7ahm,=s1>d^hO$!#R1D!IUdK]^uVq:oX/E(?DfWk-UR&j1j)^@/J?Ra
+CG?QM(XS^0$3J,#$>HV?sEu^&kaDPTTWb9G\5=d5k<R]ieK)G!dZS'dKdEM8LR\N
mQiO+:lT#\0m76Z7Zt)3"TVj=D;kripEjb_-EUPkd"'RsP5;,CiM\<umNEiB5k.[8
"VWaF1HP6("sMB7U5E4lZ;@GGA5Y4PUZFTAjt%!-?4DYuQa=+\F'gg]Ar1JL-B*iY
nW*Jo9fI#jamsj>&$g%_#*9LQ9G!G-5e(372SU^CZq?^H8GO=sni%eHTX$'gVMk]b
Nca?)3bp]Bb'_B?Xp#q_#,"e;&dAIFLFMM=Zr7Ao"KhqX=$R;d$`SIb5fS`h9P%c#
6aH!=dghBc2+(,*3,pEn7Nh"I^:YeE#ps\W6nf%"=Fa<Aoe6_H0+bJJ:p@"OYnENH
%R`:Nm2F-"7LmKek8GuRkX)IA.hE9=FB$kkB1G_*%%pfZ0%=,/n:&a4?,a#V0g#KA
5h@Z"Q=^!UDHc/b2]r^M1Q'<t+9~> endstream endobj 36 0 obj << /ProcSet [ /PDF /Text ] /Font << /F3 15 0 R /F5 16 0 R /F7 17 0 R /F9 18 0 R >> /ExtGState << /GS2 20 0 R >> >> endobj 37 0 obj << /Type /Page /Parent 21 0 R /Resources 44 0 R /Contents 43 0 R /CropBox [ 0 0 612 792 ] /B [ 42 0 R ] >> endobj 38 0 obj << /D [ 37 0 R /XYZ null 808 null ] >> endobj 39 0 obj << /D [ 37 0 R /XYZ null 536 null ] >> endobj 40 0 obj << /D [ 37 0 R /XYZ null null null ] >> endobj 41 0 obj << /D [ 37 0 R /XYZ null 450 null ] >> endobj 42 0 obj << /P 37 0 R /R [ 63 63 549 729 ] /V 34 0 R /N 50 0 R >> endobj 43 0 obj << /Length 3457 /Filter [ /ASCII85Decode /LZWDecode ] >> stream
J/gkM&HS[n!uqRi,>ku'5W=FR%Rs9/>X302OG\S9Go1-9Je\^@0n=jK,oF`n6ZK1i
E&8+@%A;B'ShaCZ$cqEaOFYVt&.qP8d6N4[<&FbKZ*K=#2][t#A9+(q<i@sKNQ-U5
E6c-ORE]@8RG@Lc6(uCmL,l'JmmJUiaWtj,<9@aP:^H5_8W_+cUsd)`-mT]C$4oQJ
d0Ohh.i5*R#h%FkP,g!r%H0=HKZ]-@Uf+1[)"(:3;j5b.",SUE\R(?[K`ol(Yiod\
)[rGC0rK.Z0Un#Q"/2K6EOgl7L6E4j_K%cs1fu^W((N'P_W!PrPYs(MNF]%MI(#oN
1=f+)ZT9a4"\nL9,T]RURS#FTlYCXsrlAso3^IFm)MQ7'=rW2Lj'j2\K!Ol+N?`]'
O9NIV=:bd+W8-3`6(BPELEX`VpEOB#NWuDU;Q;T<A%FpgM4jpX/u56eWl#%^qQq+D
a_GE+X(Z`l*[RRh)C`7X_[sd1k_gGLZ6>)2o,s)^FI0';r(%%+#i)6!U^/0KLP@PA
C`<TLaC#eg!Q&"i/`PDZ/;57gA/#L5W'E)I+TU@\0*@C6h70T>fJh-9]HocNc6J8Z
3=DUJk.0Nn5VZ0[\EM\,_`]!qKd,`Z,r.d0k)gd'G\i`O_/O*I-88r`d&V`=AsS.Y
D-o6Q</A78#pL(l_E0;A[jO8]KAqqklC=`P9!bkS/CnVF7qK>U7)(2S!MF*Fc'FS+
1JJM+j:D`pE9oEA5teIF%E!&23WoPkShu//%7UPUTpTP5eA5r6lmJO(A2&s:cs:(a
maDt_1%,18,>B_jPk-%AOE-YnQD6`]98t8IB!D'I*hLUE>2)"bJn(223Yt'N0TE3W
rm7lM,aW#G[SA+<A<u&E&7\]u3n\$2S@bG'ep:1JAHAS?1X.K?>;_-9N8HUK!i6u0
\QO>1JuBK&hD1$7@+e0].$`R-"Tp122o5ZihjBDqBXeq76'1BDN6S:d2N?`AC,1fr
gcJ"72l-6UN(r1.1:V\=0"qdT+!XL`#UnIh0,o.5I+2.=W"i[.^gtaVK.t.snH!Z?
3mQc1;A^gpQpJ1/H%di`L1.E2$]d*fpHHG3Y1=/.<%<mUe@?]522<?/9Gl[Y.RR?Q
1L/_,i*OK9mAPRadPhSE@-YL@3R/RR@JT=9O]s_c_(WPSgp*YJH<]IZ?b$:DBDi15
0L-).5V?f0QkT`nf][r9@lETP&-m1&EE)`MAqo]c]=,SQ%YFOVJ@(T8:gcs6&etW[
'a>GJh?k;+_@3Tg,<'dVbo*`.#=h=F]lV8oNCp&PBmlbJ`fg]A+>k=hOT_fH3eJ?^
Cg4ir[K:tOi>aS`L@6R\P`eZG'm*A^^bn,9B@-LI@rm%cJ2m\j$jo:85[2$s(P;-A
&^G?)K.V[43VPT'<3.8EY+24V=*=r2cn,Eoq)t8s^4KSU/1?(64@[79)&(1"2dq@p
#!f^$AB\3c-sfRP=Yuu:,b[/)W%j"A;@_>g8n#h!q'?3KcrtHu";)']^UT7&?_k2^
/=aYU=;8;>nS0Y8?l0I;=Iat8'0)\]TLh[nnDLC;CsBcO^3A$%h`@?SdI9*7\Gk-K
M8aJ;mS8uO!r<U-DOo/,2OkG"D-Uo9OA\7W8LC\!$ZSQ?@"LS^^uk!Po8&TNFikZA
2$B#"nl"sF2m4\:F4[3.GbNVI3&_3'ggc@?Y!qIhF+tN(!ZQ0?;AqK8V'-jXXGi.X
RDm)s*R3?"JuT.(6/\]RP)q)?+FlJ,2$=m8U!!m[&2[*R6Ka!*D[hR(TEZOr"s.l<
LTa8j+>R.-6%TJ;7YOlq<]14,,2fOP`1fiF4U_?bYumtZmNhIi`8@NrQS7879@d(M
>#`=g$ZR>nn7kTrHEDa1H#q:-+JR-hPn)ceLH^Ja^=VX4"q'=?_ReD.WLWLLdqq2O
fJ?Q[1d4nFF;GRq56>13P->?$<l23QC_JC:"V_Z`7dB'[hhg0<Eo+X>1;(XRoj_MC
q.<l4T$[Rj4?k*>DhC'1eRC@cAh`Sue[$b;$EQPuDsG*UE+FMN4A13J[D(55UC#0/
CedT:4ejKg*3(f.Vm;UeK)iIg$8M[>^n;^"0L-2jRuNV>K)S33<,WqaBW=lh:;N)?
*6kF(T66l!?J*8fX)d$_B_2i;5fXiFM6I2/'*A@qdMikm*5M8Ka+ig^+VTrV%\_7B
"hX39T2E5=_06Rq%#jU.-m/j($.%WHkju$m)3@Y*=[*4,E2BlS@].S+Z=Ws!mju7W
H#7D0d]@'&kVHC@-7VqV&HjK,'kPaC9*AaPi\Ho@B2[$dZg.aB/)121lV7@7Ks+f0
'&60!"Kkk4_M(eO>R;q/V`'(fV4=q_c4ou3dEp_jd%/m7ja%e@G@mD0_m_%kq=OtH
k]<`hc41VP6o]_[:$Ke563[4GLJ'"I"%[$G6(-*.G<^i@9*DTeKS6YH;5f$K0fSYP
#q/Fp(nAPm,2ne'6d&C"O<q&r@,V0eqfNLm8j*A-V1.i!?aEaoFF>=V1gBnQ`%oM0
ck?jmVO39^X:<,*CN@.l#5J7n<S)ed'3YT]S/Y;<O\a&7i`SrAgNFbn?;;*"cVWC6
6TAX`>92o]-,<.t?(JE)3mfXp%$GCq4NeJpa_!l::JWl_XP+:oo)"j"L`\T+`Fh#[
)4Z%4ODNd>qj6KYXe0JPLq1sui0Bdq?k7^9>?V5?0s/QmSP!_^e-.j2rD;mP_j<=:
BasI]Tm)PDI=Y/tDS@L?Cs`:f#7LcS+]l^%\k_nSh*6:.8,pBm11T5?@mf^f[kRPZ
>]6U>YAgNZ;*tV.2^,"cd2.W/WDf(fQt+B'[bGOK;,cQ6_)1o<[COWk7"l\o^W&1C
qEjsCo2A*dan]6#l_fGLrZB1_bJop\]C#.'&c5[$L4N8FQ0]8ELX-cJJ/\)UVbT]I
=ccm?3DBCXoEJ-37fPGUaC_GE*XcCW_)[.3Y'(aS;FRQKnpK4ITqTbhmD.)>Dq(P[
dU(kq%k1b=9t^-A)S?,DLd\K;BT>;0'TOKT#7gI@`itCmWfYHkMa2ADNTLZ[R#B0J
]o-D(T_>5F:^$hgfHOc1@$h>[RKt%#$/hTei2d3WU^CLm$/h<V!."mE*WuI:"OLK[
+IWTZSHdG\#>f[N^d&.OKEdN;.#?Gn@)@<U576GB%,f,li5Yf^3X%cK$_Zken5;(l
#UlXM%?P-/+P`1M]*meF%RA;L`%EW\h"O(lpOMIma^GWT<knb`%Z37V+A`7S!=GJr
&$ZrS@*7_)\r^l3P)1`2`TWnt[&suB.59?d",,;])%,m*pFg\!c[,<SgmTYD%KJ`t
:Z)]h>n&MO&90C%!osXF^3oHL'X:an&R5K:!.1`mX/Ns`JdQEn<"&3o$Y]GJ;.Kha
JI"N?"ouCC5c"\3%[#+1OtFtp"1o,[j?dje"u3@ed5ikX^kpIQ"md9:bs$3i/e'/U
%3Y:qN+D%-+t*Fj"m!*7+9~> endstream endobj 44 0 obj << /ProcSet [ /PDF /Text ] /Font << /F3 15 0 R /F5 16 0 R /F7 17 0 R /F9 18 0 R >> /ExtGState << /GS2 20 0 R >> >> endobj 45 0 obj << /Type /Page /Parent 21 0 R /Resources 52 0 R /Contents 51 0 R /CropBox [ 0 0 612 792 ] /B [ 50 0 R ] >> endobj 46 0 obj << /D [ 45 0 R /XYZ null 299 null ] >> endobj 47 0 obj << /D [ 45 0 R /XYZ null null null ] >> endobj 48 0 obj << /D [ 45 0 R /XYZ null 518 null ] >> endobj 49 0 obj << /D [ 45 0 R /XYZ null 381 null ] >> endobj 50 0 obj << /P 45 0 R /R [ 63 63 549 729 ] /V 42 0 R /N 55 0 R >> endobj 51 0 obj << /Length 3815 /Filter [ /ASCII85Decode /LZWDecode ] >> stream
J/gkM&HS[n!uqRi,>ku'5W=FR%Rs9/>X302OG\S9Go1-9Je\^@0n=jK,oF`n@tDid
E&8+@%A;B'ShaCZ$cqEaOFYVt&.qP8d6N4[<&FbKZ*K=#2][t#A9+(q<i@sKNQ-U5
E6c-ORE]@8RG@Lc6(uCmL,l'JmmJUiaWtj,<9@aP:^H5_8W_+cUsd)`-mT]C$4oQJ
d0Ohh.i5*R#fBdJ`ht2b8r#9lI=d;FUf+1[)"(:u,c]!5",SUE\R(?@W.`X!Yiod\
)[rGC0rK.Z0Un#Q"/2K6EOgl7L6E4j_K%cs1fu^W((N'P_W!PrPYs(MNF]%LD+8!5
1E=UCq;%;PV1PT>C)L.jQSXI9lYCXss0QY\\j:"C)MQ7'>5u?sLkqc4bJ<6sNT5%E
(Bu$j5U?o8F*8E*E3NdkLEX:dNMN:.)P2dXW78tMklOI(KEBf;P)PF%$l^GVct!qJ
M3r%[U#Dejapil7VU>alCJL2%$#@m,V9+ADcm^,OB,u^^a?]o^aFY$S6"+G7(Bso9
Up_\M.*N51JO>MDMrR@`1ldc9j>nprJ@H;H!U+isLgjc+,)S^KSgdHQP"HLE+`M!_
VD)9'&3HY[l8_0tV#s$1ZoE7u96&b3.8j->-VIAP"U$30FSeEodBn4H0IVS>UacO?
+A5oq//&<UYqF`Sa#iiZ`qmkS1'ed&%-44P^")F<q'44[VLhrAH?pM7JZrAu#1A-7
[4RR_RrL%>fMEj1:+4P`$tBY5$TP9@au;6=OAbEK%G81o#0kL[0u>VhjuOmmI+C!)
&9utdi)h3$&.Cp6hD(!uEagk2p__nFNpZ>hMDoU>mQ"&Q(s"Pk=5_4UNe:a1K&6ZT
;D*iY;VOZ-J]27*X]J%jHD4KnEINpbX)EcH"1t'_%L^5.J2^</iKi]fGjN/i6T@=l
W#5u#i],#hatg0G*cIRS;H([7kGdZS);Flp,1"%Y+CL!uH_0PC;G1-E08MZCffDj7
9r.&9$pt_afP^:(C0:2A;NP%%e(87$**_F#g9!N$X''3,>TCcb"ED"X(DWV"6TKfB
2[.SN).7IPjb_+O&r/lH]ZKAN(qi^X?e]YgQ[J?.4p%gegL5[Rp5PgQfo$8IE7<QC
r,m\4nkTKVb+Npu8.^#dLGmI^/.JNIg>=P:bpT3`E#`f_oYiS(CN>4EK6f+`/O27]
G+*<d\\Vi)&3$uCjIHb7$t%r;J=Em@7pC!+#&6";RUC$"?aFs)TJ]1t6pQ<SN#r8n
Kj"P5WqG#Vg3\Pom23;VA)@mXIP-SD/?iYohD:^N^bt2F2amJ8kTGLsHlNamm/A#>
Sm>'P0S_nY(dfN^MWXC`U<qU36YLC!!.jEii5-Al!r%SgRFm,Bf$8h]O"6mO'K6fq
cp2@22XD0<!W]A19\TFK+Ma_U6Yac:CIATI^)/U@Qk#m<D13ofWfkkb94(k$5Tn;Q
72Y$8+1Wt(O6n^"Eek+>GT[:3pt^S$aRu.C10*`77k"^I#t*FU=!4.JV]`tu"03(?
OM4hOJ:0&8d_%"Y/Q!j.6jZ5RH"nZ$25-6U):6dK:@'eoLS2d+_kNf:MTQM9@,>6V
!%O@p>rJAO]f6;-@LjpG3N'8i;H:P$SC=,G&NO8]!CZfE@&Q$i5idWsFPhtl\p7(C
m4p'uk;Zn;M2#!a5c7<eEGp"=\Hfq\(,S+0%Unu32i?cA)=XFV*Vkd`Yt8@$;-[YM
[Rs&cs-HpV@uJ0K##m,oc.H\<+kd3cjmHFrYTOD_>W=uIG&klBcXpf*.^A4JaVsu!
3+:V&+f^><TK?b&%AGA-0ZFttR6V7@g0(c"Yg:H:7"XYLppsj@%S.dFIk\8[6:a"9
6'3`kaR5HF.Fo?k81B:22NGDI_b/cs,>1Ur*5ianqr-'V>;$O+1Xdb6XR.bo-r:d-
-A:^fF0^jWJ18\%G.WV5G:rua0\1EF"W.mn%>P'BLKMjD:(UuO2[+S-o6.cCP@.q+
=Q"t%gs.-rh?KY*T%<%Oh:GY30+AeJ]3CqMki0F5e9tf.8!^G%E@?')FXXuHqb"%K
41unjkX;A%*W\N&[pb9![RL,E.ml/.a!g'ij.Tr<_r!P_J]^k?>5Aj7R<\.Ga=N5q
98W!L>LnV!+\UH&)A#t[N!M-Bp;Xt#!,kcnJ22n1_Ac4p!BKmnj-LtSCkJ"[[a7bV
LGe:8R@Z3G^jnD2`:+$M=D#0rRdIEBnURBGWK2%djinYf5!_OG[aiY3Ouc9t&0+:m
O#2ru=Z2;VK>^DqU=*XWj"J<;BU2L*n@P'+H!c8oI-:uli@'A$i[^_.3'H7QjN9f"
j/d.ANA:TF6YXHP.Lh.B#dYkI(kZ$e:4](*YI(SB-2UETE*D_HLZ/`:Jlg0![LlTn
8rj"0PY0Vf).r)<5MjT<UN"ZO;=#*j/C&lP.sF21CYr_J2Ssk2;$&[>&.N_[Y)akF
8C`,4*43mue!E!-VRD:$1)!0;'8Gtr*&`m2[;`krm>'H[clD*2PR;u8YZtcY)DmSo
WGu'e^he76fqiK"Btj^L(rj4JjG[Qagn74@6`H5QQ]f/>f'HoKZR)a(#-'O62gItN
MciFO^q;\5&C)*WJ1n/&c(1mQCo"T`,n2u/P_VhZ$i.#Cc9/@=CWu0k*Tk2TfK:'=
]A"[:V@CjK-C="O)i#4V*I4rH[t9Q,^$<jQ:0=?=edQPYYPku5)#]K@rY\aEB3DFN
6+<uSF'[ZkS^D_Md&=n&%RJ+?5]uM4CQ<X/o<&FEE9Cd(4bqm?4qi`u"nG%'8@&Z_
+X,Z&]otFR[\C9LWdBC5DDRPr2fX?&Xh_#R,o^(I'jR#pY.>NjB*s3Q:g9k63bm>,
B7%Kl5YH?gV=c.[H/?-XSGU-)rfsd`8R&"b\`@1#/S=%:>m@+u+2n[*B_+g#dL;$J
L@$N/TT*Qc#X+'N<7Vo?_YoA$p-mO:S/>F]%cK9q.V[gNW#6Ls%'fNn+YV3^O4J$"
(^^?6%=i2V+Bn0QL6dls<f?I++NQI@I'noLdmpPblqBE)h@8j-lY>M>mojSq;BaA\
"p>Xdki-K53'bh`"QkH*lk"Ne`n0X1n?8F2i+iJA'$on%cS(BULjo!SE$0[A#-R%@
8>^)D`+<l8Aa7j^jKedN]PW?>KB,3]`--`d8;)]@<b@!k.'1]GnuDcG`6-0$LofEj
HFN#TC+K)"JB$NK$k4`h\HuRPD).(R1c`QFWY"<p#l4hJ`5R[?`WiG;5X5i2<0AP8
Nlaaq`6+t`&ml3qJZ#LWC5W(BjCDZ]%D^F&#fpNG5%"QRb&5YNMWu^F"u;2s7tMqg
KE=4<$@e^Q'rN+,Y#b<j_"a"'n8FhG7C(rh.]!T7Llm/V`3b_^)Dbh8euUe+ieTqK
'Fq.EdV3&%#e(JE?4ABIX5k<g0/<rh!skQ)9ZZN#VLX/WZm^Xg!p&S<N4K%m0_Qob
7qbrtcqsDs^9j]EqIi/:!)Vf19]ZAD"m2Qn?u"dur>/4TZ&O(7bS^Z3%0m%Zcc[sY
c]98`P)&/3"spb^!+c;Z.ca.uX/`J?YquoPUr>e&#c!.Gb?tGb]QS%=e7c#elqBCX
o^8YU>OFENMm!0%r/XW5o?TVVX+"k=`jnbJ%n_poC6f?%RXigu6859L;B!A+HMGO,
LLLlY_A<K^G9ZDU]],h>iiLJ'jTrp%,VL_6^f(NS:t#gKo+:i"95_eL,:bHYf?o!k
0Q)_#VNVK@kqXP=.S-Duk-0u@>g4$t:$0QpNe/sRMdYm3nE?;m\r,^W:5<G\.)%[<
4t$rqdd=:lXZ%mc!<^?ai0*Me@f-^ScoHj-b3=(:5k#8=C2m\a~> endstream endobj 52 0 obj << /ProcSet [ /PDF /Text ] /Font << /F3 15 0 R /F5 16 0 R /F7 17 0 R /F9 18 0 R >> /ExtGState << /GS2 20 0 R >> >> endobj 53 0 obj << /Type /Page /Parent 21 0 R /Resources 57 0 R /Contents 56 0 R /CropBox [ 0 0 612 792 ] /B [ 55 0 R ] >> endobj 54 0 obj << /D [ 53 0 R /XYZ null null null ] >> endobj 55 0 obj << /P 53 0 R /R [ 63 63 549 729 ] /V 50 0 R /N 66 0 R >> endobj 56 0 obj << /Length 3401 /Filter [ /ASCII85Decode /LZWDecode ] >> stream
J/gkM&HS[n!uqRi,>ku'5W=FR%Rs9/>X302OG\S9Go1-9Je\^@0n=jK,oF`nUG7uq
E&8+@%A;B'ShaCZ$cqEiBq4<.,*i8(JH2LEC'Kf1AJiX/4!0R*jYCSI9Q)L%N<^Zd
ST\L!Ra("O\a9<J1mjZt"[fs3VH5%*`!')-PiY+SSP:Fu/K0aD#/HmnBLF77%#74o
d5\46RiEX^A.olGSuX=YjG*7%r=4`UUsef'gm(?#<0Tu[&mEOt]-!G;aer'Gd*ckk
)+4[=:?I"62]2`'6Up@uE=a&u-6nY+jE\LRE%j7&*+K;/`,SX&UfoJkaAap`I'l^M
2j[2r1es&4RGb"(jBbNo*+u@T="E.=^I26D#,-&M(5Ce+o[jG,(p(=Z@n>H8,QVjn
('F\8l8LXfOCnn)+in[C]r9XW,Cuh-Pc>0dR-p%]U1ceDMlA,Gl7ddp5-0K)F!R0.
WmVq,7kBbS#)[;fY/;t"H6U?jbnuE31r5&QntiVW=O''GqYnl+&pr]=8ntB1X@c1M
[M0)-9C<KSUO_8ZNPd_@0Y&f?Rcf>*ijp'f+\90o#u6ZelnIkWQL;$+lbrUR-mQld
8$T_2RD"R^h'Z'7PoQfsMRYnj#9faF)[=VU@MX\!E*sMG95Mm!N55Mb2iaR3mog0\
'9kA`6_N=@9s^A]4gugj+Q>B(K&l#RNcUm`L*8r6#*#b#ndl5i8F9ru(.'W-NNLRb
=PL_%gc5Nj\55,E"-CqHcdW$C(;S5,=t2fe.bLGR,GTBn:A2?m):+WaNoG]o(u@01
Xp&r-%&%W*,7W[p5VeB:"*!'$:5V(PbM[8'b@D4N2+b.#n7We36)krO<*"T\"P"5`
B_<rC6nU<W!<@KY%V*#t3<c1.o&;so!8of](\$K%%5A9N6:ifbR7+$qp-V<W#mDFi
b3r=Z/NQ[VZV7$6g/1VAZ*7k<e?&'0[8f(f'7GQLK85+fGV7+!j<:DWX3)B08Q.o3
WfS!NC=m8=+IAu8\DIW7Q_pq>L8@2X'JgOn48V4N[;3uGD6U@Z<m+0YHLA9[U(nRi
:TM*]9UX,g.Xj;cj/%aK[mM"t3F*Ftau=O^+Of>*!C4d^f?Sfn7bU-1Nk&gj@+aP"
j*9.,pVWrghqQceSa"i^T[2Z$fBW5tclm/5e%HQn,TL.bcgSKr_*IFX6\0Dh+hYN4
7NBj/?ssIYon4h\kSs]*^.o1>KY072o:A2iGu.f0]bR.3(m%]+!Ml?ki5QZ;E+oe*
e_lqt5T#L-FY9Qu?S<,q'`h0IJ$?"2L+q0t(:t#WM[25V6YO!&L`fr<$1fO!qQXGd
B0"/3k(Z6N:Z>K#33[C*.n&P:'tA8nBtuNVk\QoN.G6F**6,Q'+I!BTAP.uMX>5Q1
V:+^L;2Ksj-8Q-Hh+0mmYkg+CW07ls'#Y3Pc-=7n$Q@guD0:\(dP]$LakIIX;TWq+
8Om%?,GV\b8uNSgjn>+Z$beOBKK5_kdfbO*1(9kDg)Mu"$/U$d:6@^c46W"+;mO\D
B*JCDB>Cd;oG!6=NB"bPQPCQ_csj5-BYkTV,9MFFLBQ")'!c!H6OVTWiS:'+2/=sV
/'8:D?#NBWPf9Lle69d_BEh;s]7VTf";8j\4h5eWi<Uk;+N\bXOC1p3`'.:%\d(X"
aMK2ikZUiTD6Kl6\fPT&HHR`tPOQd8k7lt[%!HHs"&-eYUEp,_,gFGt<!u!lokTRB
<.cZ:beS!O<K,k0ZaP2+g'^7N!4@M[2N6&qJ^-9Ljin\F9)Y`qq-T0o0\!rK6<3!]
TqRi60XrP(e#LZ=7Y5K`W)HLQC.F7T.S-Ac'^J_EKi1m\Z:Ba5*+Z.D#)\R@)]%Tq
!J(ZKi&*=--3#Z.FGa,=p$KX&&H[S6_LcQKiB0]t#%66ZRRuHG`Hi>0RM!JiJ^&-Q
T\X<\Qu%D+KJFPSZW#JVpnng.Ts9DE*=;LG"V=E\6dX2s6O@lZme.7:fLZ:/G\%85
V2632SrQnrl@2e$_:Vd#=<p8F\8M-Q#<D5`=7e=NmU/$ZCETk6+hhDO:%:'PKfO\a
BXNa)Ki.n9'FV8%%Uk?@#74CXSb2''p;-XV-L)#)1]:Bu7U&[#KfEB*c!<VIJP\nM
_Mt8+2]&"D>^Ii@kiEC[!255Pl,Kic.MuB+>5/>DJTu-MZ?uYXMF3kHRI>kI=#87a
?2=&/V0jq"n;oYsWLHHqPpSV8TTZTZ[2k__0I<Xq!7`!-:78Y,VmW(f1^8W\+:)us
L.\0jnCeq%h>Ih6\D1?SL4QY:Pm&%t1n/mDDAZ'"X"kRM<Q_t`Y/Q2X&oFVYfcYJa
Q#Dl:`#=8^4-UYIAiqre:(Zu"%+5<-//`+8?GtX<?1e0,'dP[B21K,9`XJQLL>pE;
OBo%H$b[#G)+[c?a+?)i1tCt6+94Y9'hV@L/gi'"'ES^E^1>k%8]Xh\:^LmT%]q<[
cY/3l?.<G20];'B-(Q8+lboFIi8(l5E^-E5bD/d1'$S"$TXL5HB?<Zi-3=BD%VqQ5
as=(i",9*8&2=`6m*WE+OJpHJL3fQ(df*lqfGc]cBPWmP:BMn1VMeSlVau!IJquj8
hTOY\X8-MQWG]<q@skObj'>.i7">R>qJeVR2/rO=a?d,,"q#4i]:"jo+LRP]1I$(L
lqm69fuU\q@^@d9oWf]$/TMMHQp50LD!n5MS^W>Dg=@kt/\J3tG83,CE63-12'ko;
7QqFjr!\_QWon`3_^f=KY#Eqk9gIJJ;<rhKY4B$$\2F</o5pN)BOOu*o6E3q(SuAW
"QKs@(`N_V'[qfBckqO(?)Msl-`u62cU.n1R_a8,M7T>M\_dTN?"9^rik@7$XXo2Y
1BSoT?;kd%Or+!.kN'%Clq*'hAh_5abcXu*_$j_ikmo1DM=Ga=O0N*2?Br`g$C"(9
]s]W0K5qDerJ3K>QidL?phX7MB!R05`u,`YT\a4?HL%536;G-D<FgcNjbe;kMTf^j
JBR54%Ze3"C5VjZAiHI\WQa3&bi3Ur'K:`'eLIq_/GosW^@R6#csi)#0-4tI/0k]"
h+IUg7d:4+poo9F#`".rUu8l,_LWqJ60'Gq$i$<kgc+F$HUp1``#snJg9X0gDkPC#
C$IZS'\#pY"9@dK`#OM$JDmR,N/RuBm]LT7!.cET%\U[eC&eA@o_F$[oW6:,:C\T,
b!g$mLu]rn87_CpoZr>X6OFfX$\\n$'^SAE%3Wn)A"oH'c@k5/$j[9/Mr5(QcrU=&
Z-KqON_Wc^(mnfdqra";6m2l9b[SBMbmm;3/<]C6ipEPa;o2H'O8(,;"ICfM64:)k
mV`4U8lNe"D?fP/Y:*`?q?\TY[4P'd5i)u])@T&lR4>Gl@sj[JIe.'2`(30&:R5%A
ncl)c@A<PIbK0<#Cq.NIedOOR#gP+*!W~> endstream endobj 57 0 obj << /ProcSet [ /PDF /Text ] /Font << /F3 15 0 R /F5 16 0 R /F7 17 0 R /F9 18 0 R >> /ExtGState << /GS2 20 0 R >> >> endobj 58 0 obj << /Type /Page /Parent 21 0 R /Resources 86 0 R /Contents 85 0 R /CropBox [ 0 0 612 792 ] /B [ 66 0 R ] >> endobj 59 0 obj << /D [ 58 0 R /XYZ null 575 null ] >> endobj 60 0 obj << /D [ 58 0 R /XYZ null 421 null ] >> endobj 61 0 obj << /D [ 58 0 R /XYZ null null null ] >> endobj 62 0 obj << /D [ 58 0 R /XYZ null null null ] >> endobj 63 0 obj << /D [ 58 0 R /XYZ null 560 null ] >> endobj 64 0 obj << /D [ 58 0 R /XYZ null 560 null ] >> endobj 65 0 obj << /D [ 58 0 R /XYZ null 393 null ] >> endobj 66 0 obj << /P 58 0 R /R [ 63 63 549 729 ] /V 55 0 R /N 12 0 R >> endobj 67 0 obj << /Title (Multiple files and the SWIG library) /Dest [ 1 0 R /XYZ null 864 null ] /Parent 91 0 R /First 68 0 R /Last 84 0 R /Count 10 >> endobj 68 0 obj << /Title (The %include directive) /Dest [ 1 0 R /XYZ null 652 null ] /Parent 67 0 R /Next 69 0 R >> endobj 69 0 obj << /Title (The %extern directive) /Dest [ 1 0 R /XYZ null 376 null ] /Parent 67 0 R /Prev 68 0 R /Next 70 0 R >> endobj 70 0 obj << /Title (The %import directive) /Dest [ 22 0 R /XYZ null 752 null ] /Parent 67 0 R /Prev 69 0 R /Next 71 0 R >> endobj 71 0 obj << /Title (Including files on the command line) /Dest [ 22 0 R /XYZ null 616 null ] /Parent 67 0 R /Prev 70 0 R /Next 72 0 R >> endobj 72 0 obj << /Title (The SWIG library) /Dest [ 22 0 R /XYZ null 436 null ] /Parent 67 0 R /Prev 71 0 R /Next 73 0 R >> endobj 73 0 obj << /Title (Library example) /Dest [ 37 0 R /XYZ null 820 null ] /Parent 67 0 R /Prev 72 0 R /Next 74 0 R >> endobj 74 0 obj << /Title (Creating Library Files) /Dest [ 37 0 R /XYZ null 548 null ] /Parent 67 0 R /Prev 73 0 R /Next 78 0 R /First 75 0 R /Last 77 0 R /Count -3 >> endobj 75 0 obj << /Title (tclsh.i) /Dest [ 37 0 R /XYZ null 468 null ] /Parent 74 0 R /Next 76 0 R >> endobj 76 0 obj << /Title (malloc.i) /Dest [ 45 0 R /XYZ null 758 null ] /Parent 74 0 R /Prev 75 0 R /Next 77 0 R >> endobj 77 0 obj << /Title (Placing the files in the library) /Dest [ 45 0 R /XYZ null 536 null ] /Parent 74 0 R /Prev 76 0 R >> endobj 78 0 obj << /Title (Working with library files) /Dest [ 45 0 R /XYZ null 311 null ] /Parent 67 0 R /Prev 74 0 R /Next 83 0 R /First 79 0 R /Last 82 0 R /Count -4 >> endobj 79 0 obj << /Title (Wrapping a library file) /Dest [ 53 0 R /XYZ null 864 null ] /Parent 78 0 R /Next 80 0 R >> endobj 80 0 obj << /Title (Checking out library files) /Dest [ 53 0 R /XYZ null 732 null ] /Parent 78 0 R /Prev 79 0 R /Next 81 0 R >> endobj 81 0 obj << /Title (The world\220s fastest way to write a Makefile) /Dest [ 53 0 R /XYZ null 406 null ] /Parent 78 0 R /Prev 80 0 R /Next 82 0 R >> endobj 82 0 obj << /Title (Checking in library files) /Dest [ 53 0 R /XYZ null 252 null ] /Parent 78 0 R /Prev 81 0 R >> endobj 83 0 obj << /Title (Static initialization of multiple modules) /Dest [ 58 0 R /XYZ null 587 null ] /Parent 67 0 R /Prev 78 0 R /Next 84 0 R >> endobj 84 0 obj << /Title (More about the SWIG library) /Dest [ 58 0 R /XYZ null 433 null ] /Parent 67 0 R /Prev 83 0 R >> endobj 85 0 obj << /Length 2267 /Filter [ /ASCII85Decode /LZWDecode ] >> stream
J.RTgd<QR@+;fnAL1"]5?m(6BiPGW*as](dMhZ5];7%8Q1P84eJH3?C;i;O=@KIuf
570-gb(jqLTVbd9Oi.E%R?Ze`,FqOU6R\b/C4[%PY_Z76*%i4!+[eo$2!Sm<)GULS
."KNUY"Hnbiuim9BWfVC+p28L`,[Q%O#1T>((U_*K19smGuCRh)iX38d:gmB:_4"(
iu$9drA?*$Nb4K#\e$J2MZa0XWOfYr)<QYuOiZDa7=i@ti7P:aUhZbIi=PQnJ@8a=
R3A:,8:VU:K8mm'+a#D"22k!!Pd=aSV]p\N@5/Te-7]cInHQm>]Q>&r'HU!3;$#Ro
CpMeiFjm%s60g:r";_Y@`,I-pfeZbeD/AdL%jQ\;*<dYNW$Nl9b*]iX:8ASZ.Nu$8
W/?E#=r7FZJ7oiJ$*-*DNr]6.&.W3[dPJ-Q)gW9["3Sp3KEE(J2iWB-d_W*5>+FiW
:6I#`4(4demCTU&A=178J8GcCBr]1YXQo#ZNJ>U65q.OSUi7PEl=_*R]9)%K^W'-H
D(Vp]n7No!&`Xr%9+"ot2@Y3;`3-.N#f\X$UJ!0eKE?g31e%f8`iR/^Gg*KG$Y%o$
/l/OD'Eu;QP=<,OW8ueE_kMN7:K!FV.h*_n$NmVhaCO6a/7\%)1$e+<'Fa"P4Le.]
Ketaul0C3#`[`&h3KA_#khZf6j4d$R[B4@W;9O:Fs,8C/bo.%DGj^j4MEDOm!O-=8
#DNeL<prBEbVp#c&H"m-`3DF&hM&db?S]X+]tGDh&_a%;3mn":29:gKq]oHF@VG6<
lU*6QL2s68YmsR1m]MLa5fWKCUN8:@g6er-'MegB6]TiA!6@"X=M52'Y!E,GL^))o
atZ-Q"]#7DZKh"?WWBVGWA3YCE$L;#@$2[-(BfC29tDOIn,rj!i\ZT='"OR;JXCF#
L@480<sKIlW?f*3<G&Rr2G!:OKEJ6#ZAb$tr=ghTe7AQ[)f$kFAenc?/a(2_AB"h)
SA_D(]?ZV:l*ojqVs6&W^(^\bYjI`ccbS<of%*Tt3GTP_U_F7p>'`4;JP@XfKG;_A
(5>,Z>gOpH)_nYgQ',l;1:)t'23$29au!tJ(9BD(WpLNj<4]69XOMlo56/B]D6H!)
>Ir&QARh8$s,A7t=)<hBo-tPqQNb<_gkpo&)PHXYdg\m*NS6<Z&JRcmO[(L)+e5uq
,6gNkcn^/I0GFT^j;`_tkZH2"[fZ=/(Z6`p$@o)d5K2L?;Y!"4M"p:g:gfY08k*4L
I11a+nA<",8T5*F'GNtoZIm60@qf4GYr.bmPQV.f"jH35&5]RV(a'9ia^i&7lrQQd
Uf5'[!='b$WD&b;:[0h]/N./&)&t\#W^\237_&R>,A)X[^_e>!?kJn8B6l8Y19FJ)
ArNe9;/-(j3^DF9S!6*?nD-RA`d5,qOr+EHbr6I.>)K!SGqk"Ab;DQA*#(])H7LU3
\^93qas$@EJY`:AB0aI0)Pmn>H'gZQ'FTj+(3`BahP$7Pg52hY=Gn$)L?A!QgrO_=
_7D2A7pd=\5s:Sk%UtU-4J*\k_cWr\0!c=,=BPIA=YHSo-['&B;mCCJcto+;"8I@s
!u4#^FoG%l5i,jW#%rK(m^XS/^W8]<3pn9+&`RW39#tL@O-Qd^d.I1)!fMnH@'*%/
hVCg5O^HIpJ:[c7\PaCr,KV8k'36$RRu*?"ddDXai7o7*\bcj(J@64Ic5f7Z[>@jF
X2F1HnYfSn.qNf\dmCr/B(CDDM\n:+WM$Y,e/W\JU$\tI[KmZ5F\@e,Hp80-%*Vlm
C+n6cY-=l(JLs$Z$/n#O\mcONct*\D_G%XN5T.aqE")iD1"P?u<t(dk%#qVJRA2kb
%kr#5AnjT9<P8GD+ra+-rHbG>R`l-'6k!n!\5psB@q^u67uRHjeSo(,&hP%iW?`H?
1n&XjU5c6ReOM/ZJn:(-SI?tDGK^5\:Rc1I[<2C-f/RF]&RfYhMblAJ]'2N`R["4G
PVX!;U6K.KX`ncah];d8EFGZ0FI)'TbN`M0V*p]]dLK+g7>b1oJOBuVNRCCQrWjQm
Ea$l?3[psf)/"i*+LBW1a[CJ>LpF&cokJrdHQO7=Qsr0n,sXDSUCcK@#$_^r*mn1U
OI.RK6SI"LQ#u<\!uQ0&(<T>/S/1%eFObblXZorBl;8Dd.$t%Zn\[ch(Y0h,$piH<
](7JO'K@XZPEMcJT\kQF*<<eA6nmZD<o9NAF?fKUb0:-1D+Vj<%e\)*QH8>/$!VG\
l86g\,Y8iBrKpg/TE^Jh~> endstream endobj 86 0 obj << /ProcSet [ /PDF /Text ] /Font << /F3 15 0 R /F5 16 0 R /F7 17 0 R /F9 18 0 R >> /ExtGState << /GS2 20 0 R >> >> endobj 87 0 obj << /Type /Halftone /HalftoneType 1 /HalftoneName (Default) /Frequency 60 /Angle 45 /SpotFunction /Round >> endobj 88 0 obj << /Type /FontDescriptor /Ascent 733 /CapHeight 692 /Descent -281 /Flags 34 /FontBBox [ -166 -283 1021 927 ] /FontName /Palatino-Roman /ItalicAngle 0 /StemV 84 /XHeight 469 >> endobj 89 0 obj << /Type /FontDescriptor /Ascent 733 /CapHeight 692 /Descent -276 /Flags 98 /FontBBox [ -170 -276 1010 918 ] /FontName /Palatino-Italic /ItalicAngle -10 /StemV 84 /XHeight 482 >> endobj 90 0 obj << /Type /FontDescriptor /Ascent 726 /CapHeight 681 /Descent -271 /Flags 262242 /FontBBox [ -170 -271 1073 926 ] /FontName /Palatino-BoldItalic /ItalicAngle -10 /StemV 122 /XHeight 469 >> endobj 91 0 obj << /Count 11 /First 67 0 R /Last 67 0 R >> endobj 92 0 obj [ 11 0 R ] endobj 93 0 obj << /F.Library 7 0 R /G996747 2 0 R /G997817 3 0 R /G997888 4 0 R /G997929 25 0 R /G997969 38 0 R /G998135 23 0 R /G998146 24 0 R /G998234 46 0 R /G998285 39 0 R /G998361 60 0 R /G998363 59 0 R /I1.998157 8 0 R /I1.998162 9 0 R /I1.998163 27 0 R /I1.998164 28 0 R /I1.998165 29 0 R /I1.998166 10 0 R /I1.998167 65 0 R /I1.998168 30 0 R /I1.998169 31 0 R /I1.998170 32 0 R /I1.998171 33 0 R /I1.998172 41 0 R /I1.998173 48 0 R /I1.998174 49 0 R /I1.998364 63 0 R /I1.998365 64 0 R /L.Library 62 0 R /P.68 6 0 R /P.69 26 0 R /P.70 40 0 R /P.71 47 0 R /P.72 54 0 R /P.73 61 0 R >> endobj 94 0 obj << /Type /Catalog /Pages 21 0 R /Outlines 91 0 R /Threads 92 0 R /Dests 93 0 R /PageMode /UseOutlines >> endobj xref 0 95 0000000000 65535 f 0000000016 00000 n 0000000146 00000 n 0000000202 00000 n 0000000258 00000 n 0000000314 00000 n 0000000516 00000 n 0000000573 00000 n 0000000630 00000 n 0000000686 00000 n 0000000742 00000 n 0000000799 00000 n 0000000854 00000 n 0000000943 00000 n 0000004077 00000 n 0000004225 00000 n 0000005294 00000 n 0000006365 00000 n 0000007440 00000 n 0000007554 00000 n 0000007671 00000 n 0000007748 00000 n 0000007875 00000 n 0000008006 00000 n 0000008064 00000 n 0000008122 00000 n 0000008180 00000 n 0000008239 00000 n 0000008297 00000 n 0000008355 00000 n 0000008413 00000 n 0000008471 00000 n 0000008529 00000 n 0000008587 00000 n 0000008645 00000 n 0000008724 00000 n 0000013004 00000 n 0000013140 00000 n 0000013271 00000 n 0000013329 00000 n 0000013387 00000 n 0000013446 00000 n 0000013504 00000 n 0000013583 00000 n 0000017132 00000 n 0000017268 00000 n 0000017399 00000 n 0000017457 00000 n 0000017516 00000 n 0000017574 00000 n 0000017632 00000 n 0000017711 00000 n 0000021618 00000 n 0000021754 00000 n 0000021885 00000 n 0000021944 00000 n 0000022023 00000 n 0000025516 00000 n 0000025652 00000 n 0000025783 00000 n 0000025841 00000 n 0000025899 00000 n 0000025958 00000 n 0000026017 00000 n 0000026075 00000 n 0000026133 00000 n 0000026191 00000 n 0000026270 00000 n 0000026431 00000 n 0000026553 00000 n 0000026688 00000 n 0000026824 00000 n 0000026974 00000 n 0000027105 00000 n 0000027235 00000 n 0000027412 00000 n 0000027520 00000 n 0000027643 00000 n 0000027776 00000 n 0000027957 00000 n 0000028081 00000 n 0000028222 00000 n 0000028383 00000 n 0000028509 00000 n 0000028665 00000 n 0000028793 00000 n 0000031152 00000 n 0000031288 00000 n 0000031418 00000 n 0000031622 00000 n 0000031829 00000 n 0000032045 00000 n 0000032109 00000 n 0000032138 00000 n 0000032768 00000 n trailer << /Size 95 /Info 5 0 R /Root 94 0 R /ID[<4ef5976beed810d833324057dd2a0a27><390ffeb92a5b573ed995ec630e988c34>] >> startxref 32897 %%EOF

2226
swigweb/Doc1.1/PDF/Perl5.pdf
View file

File diff suppressed because one or more lines are too long

166
swigweb/Doc1.1/PDF/Preface.pdf
View file

@ -1,166 +0,0 @@
%PDF-1.2 %âãÏÓ
1 0 obj << /Type /Page /Parent 20 0 R /Resources 14 0 R /Contents 13 0 R /CropBox [ 0 0 612 792 ] /B [ 12 0 R ] >> endobj 2 0 obj << /D [ 1 0 R /XYZ null 844 null ] >> endobj 3 0 obj << /D [ 1 0 R /XYZ null 799 null ] >> endobj 4 0 obj << /D [ 1 0 R /XYZ null 403 null ] >> endobj 5 0 obj << /CreationDate (D:19970623234914) /Producer (Acrobat Distiller 3.0 for Power Macintosh) /Author (Dave) /Title (SWIG Manual) /Creator (FrameMaker 5.1.1) /ModDate (D:19970624001357) >> endobj 6 0 obj << /D [ 1 0 R /XYZ null null null ] >> endobj 7 0 obj << /D [ 1 0 R /XYZ null null null ] >> endobj 8 0 obj << /D [ 1 0 R /XYZ null 388 null ] >> endobj 9 0 obj << /D [ 1 0 R /XYZ null 340 null ] >> endobj 10 0 obj << /D [ 1 0 R /XYZ null 264 null ] >> endobj 11 0 obj << /I << /Title (A)>> /F 12 0 R >> endobj 12 0 obj << /T 11 0 R /P 1 0 R /R [ 63 63 549 729 ] /V 36 0 R /N 25 0 R >> endobj 13 0 obj << /Length 3412 /Filter [ /ASCII85Decode /LZWDecode ] >> stream
J/gkM&HS[n!uqRi,>ku'5W=FR%Rs9/>X302OG\S9Go1-9Je\^@0n=jK,oFcJ,B:NG
5ZBXoA>XUn?pH@iPf?#l3Qs`W/-A<B!D-,;%3ig70ppa>59Z03ACW`&hKCgr%Rn8r
jM#+[Ra("O\a9<J,q9bo;Y.R-VH5%*`!')-PiY(RSP:Fu/JaC=#/HmnBLF77%#74o
d5\46R2dF\A.n`tSuF"R5p_]YKaNZ+Uf+Jfgm(2t;j9nM[>NLT5FiK&,%b<kNr,Kb
@%a`DN$]>Q`C-G_BZ+[0:WdDBeKL0,2dXg;Zln(0)P*(SEjGI[SkE3jY3ZAk+_]5>
>7_03iu\K<M*`^uNb4K#\j.kbMZa0XWOU(^3Npe=*/?0dE/gZf3#\?E8sn,MNp-U;
-A2HQ\rr#.)g2F?c>[G7"jE-=)QP9657iJM?lCJu/1Z1fU+Bf1d>5WNY`XZVZ:c1Q
$qa^e-uP4KlD_%iD?e.?[!8VpiI]FDMf":2'Xsc$b1\bi8@g8W:7DCD0^]'QiN^Za
HIO2G9"O2o%/TtN9ZTkmQ)A&pC<89;Lls\,P+8O2N.\(K3^/1<[4Y,"FMeqMF!HSe
\IQ\iJiRKeAsLF.CkXiH&j7U!;t=H\&-ftXD*3L[HK'OS_[&Lg%HD]c&.HI$j:DfD
OR+f`_`0n@:VjhC2iL+3au58gFUp+#Tklt3L<S]7(5;j/?l5eNU>%)Q[BuoA5NA-h
15o^6\?6%R(rA0?K?U;dKb)^5\ICE5E&<QLKoK0b24\MeN(_OM109b6GWIJ%XU%!Q
iZ%M5Kje3Y>6G"P`&1ee=NVD8Fo?r$N8p#;A6E\M>4sn`bMR'2.!;m$as4FE3Xl)i
`]&mPC[546A!#+u:mLBF0\<(u_D@.MnE3)LUC)Au?/^T90o_7@TY"s4#)G#;!eBm2
5,!-L1M4OLlFW"Yeod%gpV>`l%[nO)G3V#H8h(!9Q)kj7f%j66?C/'.=]Uo_g+\M2
-p`mG(B-U^B095Ha$8T4gbfQ$aMVK%qVFBUB*3U8?O_Vnoj2>]n@00GJHo,s:mYMW
]]F^56ba&I.)J#]r1LP6lrT`[MtC$E_Dr*W!8k))UOF)Aj?3M2qc>!rkWAS;Vd3X%
$b$kjchPH`rH5g1&UaC3J3e^F3$2eH"r";qQj"5GgMlR%<lpmAeWsec"%ZpCl2?^L
0\YNVZFaW0ebc8a-EZ/RFF<HVIQ1@lD4Pao%k#m,^8BO'g%,Jtje9FA[:]![G\@MZ
V-C9Hp]qmBBah,$(E`A'*D<HJCe="t0Ve:?:\4F:/LCtC"aWss5[e)_A@k%0b2o)@
*^5[>G:>GGZBEqc4Y&[/P4hqaJV)QncO&qOj_Pi&3kU-^j:E-I(`NR'j(jPC+d2V"
\!!\$:lD;UK`KI@:RGW>_%8H(Zf]QhfH:KO]Uo7j/d_XfV.W3k-Te^C]&ZeZ"g!u$
Z@Ho:T7AnEn'P?$[;?j!qs.W`&YUn!m$8P`'m-WEs1!4`c^.j.>cq6=2T"bQ;Q+);
Vp%&S=%].sWBL_eXe@$uKR[<*p1B$P/:c=@quMYXDnukYTB-9N5laV;Yo*M/-C21"
]/U9$em!`hYR2Q/dXVJs"N&2E)k^kd5=+*)cc4WK9s\):9[Yu9"ba,r1<=rANGAW<
nDAl0[W*l+J[82"*Ekg6B1MST7V9^Z*S=db9\k)Na9(eI.pR&b$.K2=a;^T.2\!UJ
\>R="c([kdBMd6a8EGL96_+WhoKE$U3Hh#2XW=$Hr;TZ`;\WTO_J"kW2Sj*,qdj7A
:Q-W=`4?B;fbltcOsVrqi:*@DU\CYRkW-Z%@8N"ho*#]a['j+rf)o8R%M'Hd;-(jJ
lPmsI[*"gr.W8:cctB3BEInB[gpt7_20gbsjMsih#Tgp#KbI/E9m*JD_9;FB/[A&M
q@Kpt'M5Mtg$MJB'Wsf5$k/,QE@]&n'pjoI5N/U^==3-.hc5aB6&p+Y<dGTMKodPI
HAI>!f/-qV,IB_1dORCQk9s;dV`)gq7C'B=6DRtQBgaJe"nrlQF38.CUc1cQg)4CJ
EN/N+UI-Mm\^lE8\I7\db_g"]R@#+R1F[?#LH83NZO+4god\(oX!^]]T8UtX(nt&;
PZrEU?]Gc7]K9BFX/'f#cF$t7f-o+<:j.*Qa?!J$aQT<s/Y,hF`F$2M]!(UE"e`:b
-%P5I!K)*4CT^7AQAF/P1;47n`U,Y+(BId"XXD9\4"I=/n8L3NZM</Qc3]$202<Mo
1i"3935kat$eV*@UCr<slO30^Y[#AGr<E`+NYF&t";2TI;IK/DO/_uO%E'tXk)t1O
X9YUp"[TCYL(HZpqJD2V&PZIl[Bha>0!rqCdg4]+=n;Z&%<5i@.QZ46-1D>J^c5,[
"aXcc:fn/J><if.IBRG!D4'_G]=\uj,",$fqSbg9B5"]V"=4J1nZG'K_m8Ct;las7
dD.dRFqnkn%'d,RQWn/K*_i,X6q\2raOnbm,r?+*RE%3Z#8<hc1;V*X97m4_2P6^l
%6BBEYst#sg-mitiJKNH4!4u(olMhRLalrVo;g"'rd"C(4PoI^'Q+TgVAC`VT.nSJ
K6SMFFUDs@4CJn=*:c>QS2\QG;2MfceQ(>KDo^,)=>GcJE,*]/Z[2'RJHd:Kmj`%f
%.0%l%eE?">SL\5P_%4sB1:lE0ppK4A.c)D9^0b4"%-+d8W#h!#nsBhjQ';SU&YCo
BdXN+^NA<H^22/%Up<p>U5VTA;8$*N.2&AO$D@S,LO66G*lm/;pOFOoBUt[BcDa?,
W8XZQjgaXG\jK/YNZ$fH_N*X;-9Y.jc[&8<<_>l!$)Y'V>0qmj0P<HSDF8rb;PRW'
LJMe$>)QK$)8al1"%3b3!9b5NnF,n`FFj\FYV:f^>tRJ_0+ZM`dk"nt$i(l@9BI2+
S.oM%<:=#\7"Bjk;k;lo&oTh&,Om5o(n*b2Zj,AW\!E*pmaf!uI[i9AYBCInV"b?E
GhY]B@1$\oA)s-h`.&#nbss0H:)#(kc7_NZZ#+Acm:p9GfF7,\"U_Q#6@&fn\n(.O
PRBYZX2Y;S#&Ya>ci`XGl4VE54Di4RFq@nYk'RSFelaEf5OUr>kFRdqm/^d;H"X;_
V`N;Hf^p<-\kF^[%k^u'>+b&"j=$8n7nRi]p@BW<L]I"@@XNLEp5q"'#gZC/030Q<
6HDRIp*6@;TNh^%E3pk>4b=gI-)S$;H6r$0$r;Z_nAP,KP510/q>aim@)N6;W"2\*
qZd+"DPBf8]'?)'3l4#L0AH[1D!UOtnB]VNK<G0L.O!ep;IrDuA"YCTe?e5($/i)m
+E@ZTL(:(sI%]+n-#a?e`2LpIK<@PHkCdg;g2T_Z!:C+o#;$&>>^kVn%VC`nVuD^R
&?P)'beRb'EHYusp6p[H_?NoTBLjO:k%6m(j+l.t!Wi~> endstream endobj 14 0 obj << /ProcSet [ /PDF /Text ] /Font << /F3 15 0 R /F5 16 0 R /F7 17 0 R /F9 18 0 R >> /ExtGState << /GS2 19 0 R >> >> endobj 15 0 obj << /Type /Font /Subtype /Type1 /Name /F3 /FirstChar 32 /LastChar 255 /Widths [ 250 278 371 500 500 840 778 208 333 333 389 606 250 333 250 606 500 500 500 500 500 500 500 500 500 500 250 250 606 606 606 444 747 778 611 709 774 611 556 763 832 337 333 726 611 946 831 786 604 786 668 525 613 778 722 1000 667 667 667 333 606 333 606 500 333 500 553 444 611 479 333 556 582 291 234 556 291 883 582 546 601 560 395 424 326 603 565 834 516 556 500 333 606 333 606 0 778 778 709 611 831 786 778 500 500 500 500 500 500 444 479 479 479 479 287 287 287 287 582 546 546 546 546 546 603 603 603 603 500 400 500 500 500 606 628 556 747 747 979 333 333 0 944 833 0 606 0 0 500 603 0 0 0 0 0 333 333 0 758 556 444 278 606 0 500 0 0 500 500 1000 250 778 778 786 998 827 500 1000 500 500 278 278 606 0 556 667 167 500 331 331 605 608 500 250 278 500 1144 778 611 778 611 611 337 337 337 337 786 786 0 786 778 778 778 287 333 333 333 333 250 333 333 380 313 333 ] /Encoding /MacRomanEncoding /BaseFont /Palatino-Roman /FontDescriptor 51 0 R >> endobj 16 0 obj << /Type /Font /Subtype /Type1 /Name /F5 /FirstChar 32 /LastChar 255 /Widths [ 250 333 500 500 500 889 778 333 333 333 389 606 250 333 250 296 500 500 500 500 500 500 500 500 500 500 250 250 606 606 606 500 747 722 611 667 778 611 556 722 778 333 333 667 556 944 778 778 611 778 667 556 611 778 722 944 722 667 667 333 606 333 606 500 333 444 463 407 500 389 278 500 500 278 278 444 278 778 556 444 500 463 389 389 333 556 500 722 500 500 444 333 606 333 606 0 722 722 667 611 778 778 778 444 444 444 444 444 444 407 389 389 389 389 278 278 278 278 556 444 444 444 444 444 556 556 556 556 500 400 500 500 500 500 500 500 747 747 1000 333 333 0 941 778 0 606 0 0 500 556 0 0 0 0 0 333 333 0 638 444 500 333 606 0 500 0 0 500 500 1000 250 722 722 778 1028 669 500 1000 500 500 278 278 606 0 500 667 167 500 333 333 528 545 500 250 278 500 1000 722 611 722 611 611 333 333 333 333 778 778 0 778 778 778 778 278 333 333 333 333 333 333 333 333 333 333 ] /Encoding /MacRomanEncoding /BaseFont /Palatino-Italic /FontDescriptor 52 0 R >> endobj 17 0 obj << /Type /Font /Subtype /Type1 /Name /F7 /FirstChar 32 /LastChar 255 /Widths [ 250 333 500 500 500 889 833 250 333 333 444 606 250 389 250 315 500 500 500 500 500 500 500 500 500 500 250 250 606 606 606 444 833 722 667 685 778 611 556 778 778 389 389 722 611 944 778 833 667 833 722 556 611 778 667 1000 722 611 667 333 606 333 606 500 333 556 537 444 556 444 333 500 556 333 333 556 333 833 556 556 556 537 389 444 389 556 556 833 500 556 500 333 606 333 606 0 722 722 685 611 778 833 778 556 556 556 556 556 556 444 444 444 444 444 333 333 333 333 556 556 556 556 556 556 556 556 556 556 556 400 500 500 556 606 556 556 747 747 1000 333 333 0 944 833 0 606 0 0 500 556 0 0 0 0 0 333 333 0 738 556 444 333 606 0 500 0 0 500 500 1000 250 722 722 833 944 778 500 1000 500 500 278 278 606 0 556 611 167 500 333 333 611 611 556 250 250 500 1000 722 611 722 611 611 389 389 389 389 833 833 0 833 778 778 778 333 333 333 333 333 333 556 333 333 333 333 ] /Encoding /MacRomanEncoding /BaseFont /Palatino-BoldItalic /FontDescriptor 53 0 R >> endobj 18 0 obj << /Type /Font /Subtype /Type1 /Name /F9 /Encoding /MacRomanEncoding /BaseFont /Courier >> endobj 19 0 obj << /Type /ExtGState /SA true /OP false /HT /Default >> endobj 20 0 obj << /Type /Pages /Kids [ 1 0 R 21 0 R 28 0 R ] /Count 3 /MediaBox [ 0 0 612 792 ] >> endobj 21 0 obj << /Type /Page /Parent 20 0 R /Resources 27 0 R /Contents 26 0 R /CropBox [ 0 0 612 792 ] /B [ 25 0 R ] >> endobj 22 0 obj << /D [ 21 0 R /XYZ null 784 null ] >> endobj 23 0 obj << /D [ 21 0 R /XYZ null 305 null ] >> endobj 24 0 obj << /D [ 21 0 R /XYZ null null null ] >> endobj 25 0 obj << /P 21 0 R /R [ 63 63 549 729 ] /V 12 0 R /N 36 0 R >> endobj 26 0 obj << /Length 3764 /Filter [ /ASCII85Decode /LZWDecode ] >> stream
J/gkM&HS[n!uqRi,>ku'5W=FR%Rs9/>X302OG\S9Go1-9Je\^@0n=jK,oF`ndIFa)
BHScD6*aEOA?[0mOih/W!M&9p,*i8(JH2LEC'Kf1AJiX/4!0R*jYCSI9Q*$4N<^Zd
ST\EsRSB[nWT<o,6B[TBF#eg.L/TUc8E']MbfXsuOj9hf+dS*YV#t+%82MM)+GN7X
&EoWb027H=L9_,>8l&HP@\qWO*>X]-V;rl33fK6$.$P2e[@5op5;Ajr,%b<kNr>Tc
i8ChZN$]>Q`PeL5BZ+[2:s/%.oeEg#>;+W+0DYZc1Q>2Q8@_l^5gLgZY#i1ZNgR1e
2Qd;hUN)?M?::KPY3.T4]\O\H$q5aL;:OAVKE70HrIuK:EZ;T+$;)OoWSj#@%8<G_
O<gQ65V7nn.*-tK?tr_tL4PFkaehA([1G`"R+MV#D%MXG]."_-bJk'%*mM8InrObS
+c6QuKueiY.R!lH?l'"JUS,#K"),P/%HEPk2iXSWJ2*'mE9]Im,=#KhN.\2ENNd9k
&E"``CP`if%b,mTU^/2r*%"FEE6u2[oO<BENa1Y:3MF5n)[=-j34,f.3+*S"_P5g;
K`[pp!(k(!fJJT*3'g2tA"Z(GN5M=2qi$.ujtVmkRd?Z,Ehi_4"9YJI&5&^Z;Vm*=
"[k))")u[CN$D^q0TKXnat\p5rF!,f<Z'Kd;a\(D=WjJYbp^]MBMpI?Jl:5:]rgRF
+t]$u)b:I"X6q[#6[Z<R$puSUM,rTSE]+?7+Ng=8,B1^8%+<eo>?;@9mjO0(Fgl8"
P:I-]U%:p3a3QRu9&@i1_HRtj'<H<@3m)E$M`Ec7QKM'FU=2/Z2f7GT<7RiA3nQ5-
"N*1b<[>^F\J3bs:TCE#*$pfD4.Bb54SLe\aF+%*L@cJo6cZ6BLIl)5E8?sb6UciV
%(-p;4-!@47/PF6!8oPk<XnS->#qJ2!&(+Ob@ch;D+@B)CPq;"fG.'[,_R*/7<f9$
W7L3jJPp(r##HqS86r"0pL2sq#72i=_Vf#D#.4%U28Br$0hkZU#k,3.[EW4!+K>.o
2p*@QndnE97eAW=6QfX$%3!N)@+\tc6oL&@9k$'?G4urrL&m_`F&ED5:U8h8FbO:,
ejYfZ";YJ0Ic'0Nh[/"F"b?LI4;IiV%H.Io2K%*J7=njth:#'b?bfJW_\2_RWFQPC
6gX!,"/9*s]Y?&=SE#i10f!ZD'H]U4J/(/I@%`$4Y2f6NT2PW(!.[%q[gp,>S%!hH
J\aG;OSQdEG#lRm'HaR!)r[!Y=D;V%"r5Q'hb\5EV"ITOG^R)i!`=692<VdiL82RO
f3iLS1koXH)2l,/Df<]O[TAY&S4]2]JXsu\a%3rI'BrNuPWT0V_\(5$^P!-"gclWJ
[*Se]?icPb434_D<9pH=EA]!D@R=:M6SMFarE2MLBGs5tBN)aW2lYuGX&Sk'%`d+!
^F/%"+#:iYni=7e-FWFhTQ="HrDpD(2^BZ3T0DXVgStJr";3s[JoO)eQY0bI_lETX
l:FT12msYN_0-;_fmYTqLk"/o_LKCf/57hRD4SQ@MkR")^WC/ehZMkh!7[WqQ]Sos
e..=s6-5qRpDb,=WgG(0/cpe6i1OVXCQO\m+:4n__lJV(:>&eUP3a+i0O+c4.Wl\r
E1,D,N+-VqaKe4h:C^Mi#6nn&Zuk_Y;0<X(<+)_kJp:=YJZr#Vat6=ImX5f]F,>!!
N&-bE7%*%NBl+!;1c/spPHfX6%/QO"Pl:phTK#*7&Or&gndO#a:hp44X\Z?]0H8N#
FqAaVX?!0VU\jjcWI\fm2Tl$Kd[5LGeTAQ&LAtOmD[c$A!P+!C<nDGGQO5<a`<O!R
A9.HIMKqe0V<ktIK@^PeIJu\S!#T2iX:D9#@?^2ZXjQVd$t6C=K`L\FO0SS0J:K$a
E7jWq9i(uo";HJbC/GB(>Z0+629A,O^&oWkS/(;/K+Mj@-/t,TegeZgWuW&4].oJ+
HC#GYVSC[kTFS7s:J0Y\)cX%UD2V-CRpb>oK67<)mWHje(CIsqUV@,]13G_ON043u
YDN@sZDA*u)\t5@<-)KXL5"Pl_d]HlQ+f.7F6J%JA+>na!oqrAP#(LZBt<02$3h53
?/F!+AeUE$LNa2G&j1qSi1^c@kKZlgj3*IemJ%sjIbTM"Qj+\-(IJI=$=TY*F)T(!
LKRn-<;%cFcFR_k6gVE5-.fa]ZM)nZV]me\q4A#2)n_)@?4YbV%F1.g=(Z"-*:qTc
$F*9!KU`t>e\nQsD1:.7Fb*O6#7]=+>J1C@LuiH#FpceP6lF:RiUp`DVqnX13-?:<
TQ3WI$Fenbj'9J-D$1O'ke:i1J$*#HOp_(?K4iaU-mj=L[dqZh8DP45;[T;d3h%*'
eAW:?+s:uhPS:iQS>lZ50J+Q1lQB]>#mDXY%nIS6J7(o@"RQNapbT,#dN5<>i-"Jq
;hiG,R4*Cne^R?b0m\)75l`nkk<.$h(.#E40&KCb?X\RPC=K8!coJG@@VIU/%?&)p
M[3$`"rEGMp6HYi:D)ne\$H>Z9OsS&'%,q)E=NB;Gs:`U]?.SY[$I7<ae1Qdm!M3s
('A?3.U@/?-\4LVdZmn[o7$0!nQ3'_Fcs<BpoIJU)Kb=2KGZW',uhdLo(GG'%GiUT
]L/7c!VX/4JmjCf;L[W,**q@:%D$3J#U*;Z^^L.f=pE@rK9<N!_9Dl;R8]OVJJ+7U
H55KL5`u/78@)$;QY#PFk!N%G;p2Fi.Hk5Hm/+VKR&'cR5XB6o3%5(Tb8NPUhp`HH
o$/DFZLpD7]bi@ULlWGp"$Aj!TD3H+*"HL[;sYBE<C1<ieqd7GKhbaN9@t0_E2[Wp
N`njpp.T+-"!n8Y[RMKqkY;kI&F:@ZkEp`BLB/j'93#,s%GMr1D)8QMSlto;W5qfc
l^r7l.P"6LJBF\V"$!(X9AmcA)jGW?S*<!X4cD1+;Ca^<%"_-bJ'eVFY*]]?i]b9!
I_WsAGC[P/$(Tmi1n<V,NK#.3mPJ@/#^RrRZtW.lM5"*;i-6Q><NnC$,^dULRU:"P
%hKfG&.6&RL1S=dQU"0s:At`!!f'PWCa\(g0+\W]hFT8i`+W2D#K4"X<!Y$-oLsd"
A*BHGDP%5-kCC\YY&"MaE8Kf/jeqMojf\5IVOFHjRdX)6kJD/YW"*Oj!_f,\.<p1B
[YY0>P74I3m%TP5"Egbe<2l`t"JV3[_#_n"X%=:/^tA*Fg2Q6!pkRj$AS;P73q25b
%#;RHM%h>\:t9Eg9aYk9m:'d=&nL&OBW=,Kc$&hN0,%fpAHG,Yc[brO:^Cj.j"7G,
ABanT0%L5kgX!;S05UO.51bJ\(=0oHMrIQ%#Y8^#8Lo=+kCUUK&8Yq5^aIValbK0Q
14(B\<Cs]-#0'h`/FA.'QiQ&fCVJLo^0&2-eE;:"L(9k&rcD^nH%S<_?tcPk7WD(;
[gR;bVsXZfQqDnM9<1#T!/,3cre9Gd?`60Q^sot]5RU:;5@Buj-LN8>Pk&5;ZpumW
lWaT"bQIp+0'9NHAN_,S,(]+ISY1RS,cW6MS=TtA$'+fmE:Si=7)['?S'fr,7L#4`
FVu[eiS`3fme1]UZ>9egPc["(-s2m*ZF>]lLW7IF@+HY8'F"P6THMo4kDGlSW`R8P
V@`APKXee=J.1`fGH(/m..gO?_M=(T=6Spn8`'Kbmbq!c,_Zs#00k?AjEKOH%HVn`
-$[$%aXAJ7$#@n"+G=)%b0,sRPd7_,1:k)WU^FEE<[[O@Nr#@ont9W61+X"0,H)_-~> endstream endobj 27 0 obj << /ProcSet [ /PDF /Text ] /Font << /F3 15 0 R /F5 16 0 R /F7 17 0 R /F9 18 0 R >> /ExtGState << /GS2 19 0 R >> >> endobj 28 0 obj << /Type /Page /Parent 20 0 R /Resources 49 0 R /Contents 48 0 R /CropBox [ 0 0 612 792 ] /B [ 36 0 R ] >> endobj 29 0 obj << /D [ 28 0 R /XYZ null 730 null ] >> endobj 30 0 obj << /D [ 28 0 R /XYZ null 438 null ] >> endobj 31 0 obj << /D [ 28 0 R /XYZ null 315 null ] >> endobj 32 0 obj << /D [ 28 0 R /XYZ null null null ] >> endobj 33 0 obj << /D [ 28 0 R /XYZ null null null ] >> endobj 34 0 obj << /D [ 28 0 R /XYZ null 742 null ] >> endobj 35 0 obj << /D [ 28 0 R /XYZ null 450 null ] >> endobj 36 0 obj << /P 28 0 R /R [ 63 63 549 729 ] /V 25 0 R /N 12 0 R >> endobj 37 0 obj << /Title (Preface) /Dest [ 1 0 R /XYZ null 864 null ] /Parent 54 0 R /First 38 0 R /Last 47 0 R /Count 7 >> endobj 38 0 obj << /Title (Introduction) /Dest [ 1 0 R /XYZ null 811 null ] /Parent 37 0 R /Next 39 0 R >> endobj 39 0 obj << /Title (SWIG resources) /Dest [ 1 0 R /XYZ null 415 null ] /Parent 37 0 R /Prev 38 0 R /Next 40 0 R >> endobj 40 0 obj << /Title (About this manual) /Dest [ 21 0 R /XYZ null 796 null ] /Parent 37 0 R /Prev 39 0 R /Next 44 0 R /First 41 0 R /Last 43 0 R /Count -3 >> endobj 41 0 obj << /Title (Prerequisites) /Dest [ 21 0 R /XYZ null 651 null ] /Parent 40 0 R /Next 42 0 R >> endobj 42 0 obj << /Title (Organization of this manual) /Dest [ 21 0 R /XYZ null 515 null ] /Parent 40 0 R /Prev 41 0 R /Next 43 0 R >> endobj 43 0 obj << /Title (How to avoid reading the manual) /Dest [ 21 0 R /XYZ null 418 null ] /Parent 40 0 R /Prev 42 0 R >> endobj 44 0 obj << /Title (Credits) /Dest [ 21 0 R /XYZ null 317 null ] /Parent 37 0 R /Prev 40 0 R /Next 45 0 R >> endobj 45 0 obj << /Title (What\220s new?) /Dest [ 28 0 R /XYZ null 742 null ] /Parent 37 0 R /Prev 44 0 R /Next 46 0 R >> endobj 46 0 obj << /Title (Bug reports) /Dest [ 28 0 R /XYZ null 450 null ] /Parent 37 0 R /Prev 45 0 R /Next 47 0 R >> endobj 47 0 obj << /Title (SWIG is free) /Dest [ 28 0 R /XYZ null 327 null ] /Parent 37 0 R /Prev 46 0 R >> endobj 48 0 obj << /Length 3584 /Filter [ /ASCII85Decode /LZWDecode ] >> stream
J/gkM&HS[n!uqRi,>ku'5W=FR%Rs9/>X302OG\S9Go1-9Je\^@0n=jK,oFcN0_)s*
5ZBXoA>XUn?pH@iPf?#l3Qs`W/-A<B!D-,;%3ig70ppa>59Z03jRNU*hKCgr%Rn8r
jM#+[Ra("O\a9<J,q9bo;Y.R-VH5%*`!')-PiY(RSP:Fu/JaC=#/HmnBLF77%#74o
d5\46R2dF\A.n`u:/NL%NTIS5'bZKsV.8Pr.YNsZVj332'jAk"].fom,%b<kNr,Ha
@%a`P<Z;V]LuT],Lt4nbPg`V),93"a?*L$[ZiJfe(7gYOEci!lW6^s8Y"/<jSrg<m
2Q_c=UN)=+`'g:6Y/`=i]\O\H$q5aL;:OAVKE70HrIuK:EZ;S`!_O\gWS!HaND,`-
WWWB:5V7nn.*-tK?taB#L4PFkaX/12ZA6@Q(dKt[U725$TkK>uM'@s!*Z1Q1;@+<d
/os#9[g`_'*&QnX*ik#M&8W9im,27f"qL4V#)cnTOqWe*!5^W(@sh<6NGnm^0/fS-
gc(8R@*155n,S2"%RWj9,n8m"h(HG%#i.%lK1#\gN+5E$2\(I2\?6%R(dK7(j(R@3
d%bR+/PfdTOuA7D37CG%!]]6T[6[(73fXj"kS/rLTTlj<YA7+.MN<F^)$V`,gFCOR
!3.se,I?MhNe>D<2iPqIkV.ts!6dB^5m;9cfqTMR8<1#Y5WR>HKpXn)cfFBgLdS,\
2:DYKp*L1mOQBmX_+8;ZK`akD(^1WP6G?^SUp;HR+in4l?=?+R<)l1sW"gXWJ8-(H
Eif<u%eAE*Ar[\3ED[4hh5i\2A#R7!9h6\g7uilSmp(M[3+a*^q(=34%'rdI\u4$,
Z8Bt^Gi+J/R74JC=Q9t@2HU_0L_)0(Lg>U4GWl`W.bJE2+q-HTZ6N(2TZ99"\[=M@
fKqj[2IrRPWrQV:"tuP-;TQ_HA`G2VP-:&)LLS_X-;9$S4'"(1dX"HF6\[n,HmgVb
?u)WIfL2;J40kF;7nl?f#@l,a[CRXQJZdf]9A1Z/B1p_?oJM:'=Nd9=(C98^fiDKG
1ep=@3&Y:""9H0`(XPH^:m6^S83X5kN\J%JG9<bu6G;3";e%*"T*`B-6(cn_!0'_4
6d7n:"V9Cl/G)jTa`5Pr9\22G6X\TZg!fFU3j,Nn5War<p<?qI!taPHe)U"19X$O_
:s9eE]8V#,5TH17W3+[PIV(1RRQK^+J--?o:i)!jWV.qb>dB$#b&(pL:sPP<.tE*-
Kjc;^5c,P@Jq`MG#qVkLkoZ=9IOXMS5c5U_SQU,SMIfMaA[EH'UUk/R"W*ZX@U`(>
2)3-R,:(`1Dba.98L7?\SHCu]dLf32VdQHbR'Mju3&i)$_((.^bT.\e.0a28'GKO+
*PqW32^lJZUF;jH:*a:.k@Gh^U-R[/@F$8L!\bW^6q=!q"%O]2Ji+*SLV\"(8[5K6
"\7XZhf<Ca8'j&ma9EL1e-9eVcoSWOC>;@m#\6]`?_:it$s[6.6f^3BU*`o^c[o.)
JB/Wg[9AerTMo&FD:kr?JfFkBQjs8o/cpdajdOnL:-l=#]D(NV_e<`p:oV87^f&V2
8uj5;[/>Q1@5'u8_jI*o@tQZ&'18g2%3`QLWOB=@'@F7Z$l,[6.>]d99_N40PhJop
kR5:QE-!25].TEI);t[a%Wi/WY_ilPkGn/o!Qi;4G0KT?Qt$Sac'hMM)O2\0#G./+
H8!3U$pd<3#73^7L.Urd-EHbIV"p6P710&DZf%`S$o%sZar&e]Rgt/)g)FbN9;jEs
U_M/i";C4beq=YFM[DOt#G`4#bT`cs>Wff)UK/f9>+lTP'ElEpYSOOs%M*#dTDI?/
@-B%log2]q.Q7m;K^u9f-mqY1hc"9:-!?*367lr9:+9*cWaX&ML0EPFBpBhF"k"P1
a9I.BaCPkdg5.pnB$HbgP-ae0`NMoQKYo*E<&R0Oe2b,F6`$8Fn+j1S>5'g"W$PAc
`%msh95:Q]pUNmVD9co/D(2#t$2-]a>L6ObmPEM(Fis'tWKhJW"Pn@H]m-HaV@-_2
^'U[fW<VkS)D<+g]W9C+#4UhPRQTP&lS[Y#3!LEUoI`dF[ehg^K"BFsJ>L`#?(S$C
%Aj5'6nM#,4'(@bU"/m:@BhB"Qhm+PM_>Klq.V8>jr.OSpK.eMWDu<$:_Z62-craq
^\Xgn<a*b&8$s^r#/hOuCQ+g!\p"e[A<[+Oc[lur'U=Hk$e*TWG)Ah_6$Ie2P`jUN
N1q0m0NJP',]g#[5U<IR]H$'cJSrUm3CIug>RQj0bniZ3T0qrblp5;:TV+BE)hS@c
$2>d>h4_RSrjAGC-Gc#1!N*An,>8[UM<=lX`@1k!,-f4I#,3[O,^U><>[KO)<\\>,
#oU,rBEg`_)C5Ak84e\=>UiIX]o<%R:7dk4dJH\[#p1;4N0?fTe>qke3eCiJ`f`(m
8o#[)-:+mC2@2L1`jd02RMl1BlNt,P2&t:PS,It0h+SX+E==Y6EIY3[(5?G]F&j,f
Po9FU537KL8bS*ka_>lF.m-JVlMh=`k`+p\2N5oq;^6WfAYgZ#(Uf!W8:)bH8Q'`j
C"c577=SMlC14;X@rK/\m(0/r0[SduABu-%Tu*[`!ECjBfE?>O)H%Oa!Os`dj>/0"
o0*RY60BAGS"TC62LHaPN""YF1"!BOZ2nu]%_QG08(aN?;7'<U&kO;;dQe6JG8Jdl
B3&jtYK%8"+kE==*0L4d[Q,3lF(a8jW\p7,U-b:*(n$e`:hGN7Jfd-Y13]sp%g/JZ
E2i+?6n#1d&`QDt5AG)$#?u5H-E(W\Tn^7f8PniQ1&ETIlbCq'kMUu\q[S\bgBJqH
2&D=KGOX&:en@;g1^['s%7iGHWES(E-`QiUWl$EapBmM0`P;itR;XWlB/."Ia!_"_
#"/+9ZHIWB&uFom,Am)>5V7!>$)r>Njc9eUF'@96dS0n>)p@92<83ju6]#(D`;!#d
#/HrYJk^VWB80rug6Do%%Ec]f7TL$/jsR84E_f)$^d(T3cq?XB<+\a(+PP92JrbP5
iXJ#4m9GUQau?Dr8ZpS,aVsQ@3s?i9N96i=/Zo9eDDR"ek%AGca<WF@J<+B6lchCY
NK!3uVX=S1#,s**aV`QFNsTc+j3Gs2/[@scnchZDJd>n1VV]:kp^F1#!UtWKB$a5T
"G^S]n"Arik]j$tB)Esta0=2!&DY8umdjiAo<1=dmt(`J(kLs[dVgOFBi(O6pA"jP
p2",]KC&Ks.h5*@`MY7um,WTWdSqmh>YG'#WB<EJm/cHW&^.bOa_Y&\I1hNgTSFLO
+CNqp+EYV.JkL-:Yo]WXVLC,V/l9LA-(;bDnk1Q\B1dP0d<K@8Am.IX%j^-Ci6Z#1
c;:d-b[gYM0@o4&Wio3m;i8l&-STeM5^l.th9Y$"`N0J:KSE;?h,"HfEGlH9'$Nc7
%E4#2U?p$qBE\RN$/jV6/\5[gY4mZ'D$/oa`pF[]nH/48F/Sg1Z'=*9>i#nEEm,_+
KqrNt`,hit9F&fD!,PQ;4GIJ.!jN$"coQBIJBcI0!GHa&Lh+"'KUSdNL!O(%T]Q[1
mT<*.:+P[EWikA+!W~> endstream endobj 49 0 obj << /ProcSet [ /PDF /Text ] /Font << /F3 15 0 R /F5 16 0 R /F7 17 0 R /F9 18 0 R >> /ExtGState << /GS2 19 0 R >> >> endobj 50 0 obj << /Type /Halftone /HalftoneType 1 /HalftoneName (Default) /Frequency 60 /Angle 45 /SpotFunction /Round >> endobj 51 0 obj << /Type /FontDescriptor /Ascent 733 /CapHeight 692 /Descent -281 /Flags 34 /FontBBox [ -166 -283 1021 927 ] /FontName /Palatino-Roman /ItalicAngle 0 /StemV 84 /XHeight 469 >> endobj 52 0 obj << /Type /FontDescriptor /Ascent 733 /CapHeight 692 /Descent -276 /Flags 98 /FontBBox [ -170 -276 1010 918 ] /FontName /Palatino-Italic /ItalicAngle -10 /StemV 84 /XHeight 482 >> endobj 53 0 obj << /Type /FontDescriptor /Ascent 726 /CapHeight 681 /Descent -271 /Flags 262242 /FontBBox [ -170 -271 1073 926 ] /FontName /Palatino-BoldItalic /ItalicAngle -10 /StemV 122 /XHeight 469 >> endobj 54 0 obj << /Count 8 /First 37 0 R /Last 37 0 R >> endobj 55 0 obj [ 11 0 R ] endobj 56 0 obj << /F.Preface 7 0 R /G996747 2 0 R /G997894 3 0 R /G998106 29 0 R /G998112 4 0 R /G998137 22 0 R /G998181 23 0 R /G998240 30 0 R /G998348 31 0 R /I1.998289 8 0 R /I1.998290 9 0 R /I1.998291 10 0 R /I1.998292 34 0 R /I1.998293 35 0 R /L.Preface 33 0 R /P.7 6 0 R /P.8 24 0 R /P.9 32 0 R >> endobj 57 0 obj << /Type /Catalog /Pages 20 0 R /Outlines 54 0 R /Threads 55 0 R /Dests 56 0 R /PageMode /UseOutlines >> endobj xref 0 58 0000000000 65535 f 0000000016 00000 n 0000000146 00000 n 0000000202 00000 n 0000000258 00000 n 0000000314 00000 n 0000000516 00000 n 0000000573 00000 n 0000000630 00000 n 0000000686 00000 n 0000000742 00000 n 0000000799 00000 n 0000000854 00000 n 0000000943 00000 n 0000004447 00000 n 0000004583 00000 n 0000005652 00000 n 0000006723 00000 n 0000007798 00000 n 0000007912 00000 n 0000007989 00000 n 0000008095 00000 n 0000008226 00000 n 0000008284 00000 n 0000008342 00000 n 0000008401 00000 n 0000008480 00000 n 0000012336 00000 n 0000012472 00000 n 0000012603 00000 n 0000012661 00000 n 0000012719 00000 n 0000012777 00000 n 0000012836 00000 n 0000012895 00000 n 0000012953 00000 n 0000013011 00000 n 0000013090 00000 n 0000013222 00000 n 0000013334 00000 n 0000013462 00000 n 0000013634 00000 n 0000013748 00000 n 0000013890 00000 n 0000014022 00000 n 0000014144 00000 n 0000014273 00000 n 0000014399 00000 n 0000014512 00000 n 0000018188 00000 n 0000018324 00000 n 0000018454 00000 n 0000018658 00000 n 0000018865 00000 n 0000019081 00000 n 0000019144 00000 n 0000019173 00000 n 0000019498 00000 n trailer << /Size 58 /Info 5 0 R /Root 57 0 R /ID[<131825006751d97ca8310dd68f934311><42318955ee355d848ff1c8081c0e3cc6>] >> startxref 19627 %%EOF

3429
swigweb/Doc1.1/PDF/Python.pdf
View file

File diff suppressed because one or more lines are too long

838
swigweb/Doc1.1/PDF/Reference.pdf
View file

File diff suppressed because one or more lines are too long

1608
swigweb/Doc1.1/PDF/SWIG.pdf
View file

File diff suppressed because one or more lines are too long

14954
swigweb/Doc1.1/PDF/SWIGManual.pdf
View file

File diff suppressed because one or more lines are too long

415
swigweb/Doc1.1/PDF/Scripting.pdf
View file

File diff suppressed because one or more lines are too long

2033
swigweb/Doc1.1/PDF/Tcl.pdf
View file

File diff suppressed because one or more lines are too long

190
swigweb/Doc1.1/PDF/Title.pdf
View file

File diff suppressed because one or more lines are too long

847
swigweb/Doc1.1/PDF/Typemaps.pdf
View file

File diff suppressed because one or more lines are too long

217
swigweb/INSTALL
View file

@ -1,217 +0,0 @@
Installation: SWIG 1.1
June 24, 1997
Installation (Unix)
-------------------
To compile and use SWIG, you will need the following on your machine:
A C++ compiler (ie. g++)
An ANSI C compiler (ie. gcc)
yacc or bison (only needed to rebuild the SWIG parser).
To compile and install SWIG, type the following :
./configure
make
make install
The configuration script will attempt to locate various packages on
your machine, including Tcl, Perl5, and Python. Don't panic if
you get 'not found' messages--SWIG does not need these packages
to compile or run. The configure script is actually looking for
these packages so that you can try out the SWIG examples contained
in the 'Examples' directory. See the Examples section below for
more details.
The 'make runtime' option is an optional step that can be used to
build the SWIG runtime libraries. These libraries are only used with
larger packages and are not necessary for learning SWIG or trying
the examples (please refer to the "Advanced topics" section of the
SWIG Users manual for more details).
Typing 'make test' will run a rather extensive series of tests
and can be run before running 'make install' (if you are paranoid).
There are a number of configuration options that you can give to
'configure' :
--prefix=/usr/local
Set the installation prefix. SWIG installs into
/usr/local by default.
--exec_prefix=/usr/local
Set the prefix used to install platform specific
files (binaries and libraries). Use this if the
location is different than that given with --prefix.
--with-lang={TCL,TCL8,PYTHON,PERL5,PERL4,GUILE}
This lets you choose the default SWIG target language.
By default, SWIG chooses TCL, but you can select
another as shown :
./configure --with-lang=PYTHON
--with-doc={ASCII,LATEX,HTML,NODOC}
This lets you choose the default SWIG documentation
method. By default, SWIG chooses ASCII.
To test the SWIG parser after compilation, type 'make test'.
Site specific installation
--------------------------
While not required for compiling SWIG, the configuration script looks
for various packages in order to create a makefile for compiling the
examples. This makefile is also installed with the SWIG package.
The following configuration options can be used to set the location
of various packages.
--with-tcl=pathname - Set root directory of Tcl installation.
SWIG will use $pathname/include and
$pathname/lib.
--with-tclincl=pathname - Set exact location of Tcl include files
--with-tcllib=pathname - Set exact location of Tcl library files
--with-itcl=pathname - Same as above but for [incr Tcl]
--with-itclincl=pathname - Location of [incr Tcl] include files
--with-itcllib=pathname - Location of [incr Tcl] libraries
--with-py=pathname - Set package location of Python. This is usually
something like /usr/local. configure will attempt
to locate the appropriate include and library files.
--with-pyincl=pathname - Set location of Python include files
(for example, /usr/local/include)
--with-pylib=pathname - Set location of Python library files
(for example, /usr/local/lib)
--with-perl5=executable - Specify your perl5 executable. SWIG will figure
out where files are by running this version of
Perl and grabbing its configuration data.
Other options :
--without-yacc - Try to compile SWIG using a pregenerated YACC
file generated by Berkeley YACC (byacc). Only recommended
if you get compiler errors when trying to compile parser.y
or parser.cxx.
How to use a different C++ compiler (IMPORTANT)
------------------------------------------------
Normally, the configure script will probably use g++ as the
C++ compiler. If you want to use a different compiler, do
the following before running configure.
setenv CXX CC # Set CXX to your C++ compiler
./configure
make
Changing the Makefiles to use a different C++ compiler after
configuration is not recommended! If you need to do this,
do this :
rm config.cache
setenv CXX CC
./configure
make
To change the C compiler (for compiling examples), follow the
same procedure above, change the symbol 'CC' instead of 'CXX'.
Testing :
---------
There are several tests that can be done after compilation :
make test - Tests the SWIG parser and performs regression tests
make testbuild - Tests SWIG ability to build various modules
(see below)
make testall - Test both of the above
The testing process requires the use of the 'bash' shell and Perl.
If you don't have these, don't expect the tests to work.
*** Warning : Full testing requires about 20 Mbytes of disk space
and creates a collection of regression testing files. After
performing the tests, you can do a 'make testclean' to clean up
the test directories to their initial distribution state.
The SWIG Makefiles
------------------
SWIG creates a Makefile with rules on how to build all kinds of
modules for different languages. This makefile is called
'Makefile.template' in the top level directory and is installed with
the SWIG library as 'swig_lib/Makefile'.
Prior to installation, it is highly recommended that you run a
'make testbuild' to test this Makefile. This test will report
which kinds of extensions can be built. It is normal that
some tests will fail (depending on your system and installation),
but if the tests fail for a language you want to use, you will
want to edit the file 'Makefile.template' by hand. In this
process, you can repeatedly try 'make testbuild' until you
are satisfied.
In addition to the 'Makefile.template' SWIG 1.1 attempts to configure
more advanced makefiles for each scripting language. These are
located in 'swig_lib/tcl/Makefile', 'swig_lib/perl5/Makefile', and
'swig_lib/python/Makefile'. Prior to installation, you may want
to examine these Makefiles to make sure they accurately reflect
your local setup.
If you're happy with the setup, proceed to installation.
Installation
------------
Type 'make install' to install SWIG. This will install the following :
- The SWIG Library (containing interface files)
- swig.h (Headers for building SWIG extensions)
- libswig.a (SWIG library for building SWIG extensions)
- swig.1 (man page)
- swig_lib/Makefile Makefile for building extensions
- Runtime libraries (if built earlier).
Troubleshooting
--------------
See the file TROUBLESHOOTING for solutions to several problems.
While I have access to a large number of machines, it's impossible for
me to test everything. If you can't get SWIG to build successfully,
please send me email at beazley@cs.utah.edu.
Installation for Windows 95 and NT
----------------------------------
The Win directory contains makefiles for Microsoft Visual C++ 4.x.
See the README file in the Win directory for specific build
instructions.
Installation for Macintosh
--------------------------
The Mac directory contains information about building SWIG on
the Macintosh. At this time, the Macintosh version is
distributed separately as a binary release. Source is also
available, but is non-trivial to build due to dependencies
on other packages.

12
swigweb/Makefile
View file

@ -1,12 +0,0 @@
# Simple makefile to create the web pages and update/synchronise to the real web server
USERNAME=wsfulton
all: makeweb rsync
makeweb:
python makeweb.py
rsync:
rsync -r --cvs-exclude --rsh="ssh" . $(USERNAME)@shell.sf.net:/home/groups/s/sw/swig/swigweb

275
swigweb/article_cpp.ht
View file

@ -1,275 +0,0 @@
Thoughts on the Insanity C++ Parsing
<h2>Thoughts on the Insanity of C++ Parsing</h2>
<center>
<em>
"Parsing C++ is simply too complex to do correctly." -- Anonymous
</em>
</center>
<p>
Author: David Beazley (beazley@cs.uchicago.edu)
<p>
August 12, 2002
<p>
A central goal of the SWIG project is to generate extension modules by
parsing the contents of C++ header files. It's not too hard to come up
with reasons why this might be useful---after all, if you've got
several hundred class definitions, do you really want to go off and
write a bunch of hand-crafted wrappers? No, of course not---you're
busy and like everyone else, you've got better things to do with
your time.
<p>
Okay, so there are many reasons why parsing C++ would be nice.
However, parsing C++ is also a nightmare. In fact, C++ would
probably the last language that any normal person would choose to
serve as an interface specification language. It's hard to parse,
hard to analyze, and it involves all sorts
of nasty little problems related to scoping, typenames, templates,
access, and so forth. Because of this, most of the tools that claim
to "parse" C++ don't. Instead, they parse a subset of the language
that happens to match the C++ programming style used by the tool's
creator (believe me, I know---this is how SWIG started). Not
surprisingly, these tools tend to break down when presented with code
that starts to challenge the capabilities of the C++ compiler.
Needless to say, critics see this as opportunity to make bold claims
such as "writing a C++ parser is folly" or "this whole approach is too
hard to ever work correctly."
<p>
Well, one does have to give the critics a little credit---writing a
C++ parser certainly <em>is</em> hard and writing a parser that
actually works correctly is even harder. However, these tasks are
certainly not "impossible." After all, there would be no working C++
compiler if such claims were true! Therefore, the question of whether
or not a wrapper generator can parse C++ is clearly the wrong question
to ask. Instead, the real question is whether or not a wrapper
generation tool that parses C++ can actually do anything useful.
<h3>The problem with using C++ as an interface definition language</h3>
If you cut through all of the low-level details of parsing, the primary
problem of using C++ as an module specification language is that of
ambiguity. Consider a declaration like this:
<blockquote>
<pre>
void foo(double *x, int n);
</pre>
</blockquote>
If you look at this declaration, you can ask yourself the question,
what is "x"? Is it a single input value? Is it an output value
(modified by the function)? Is it an array? Is "n" somehow related?
Perhaps the real problem in this example is that of expressing the
programmer's intent. Yes, the function clearly accepts a pointer to
some object and an integer, but the declaration does not contain
enough additional information to determine the purpose of these
parameters--information that could be useful in generating a suitable
set of a wrappers.
<p>
IDL compilers associated with popular component frameworks (e.g.,
CORBA, COM, etc.) get around this problem by requiring interfaces to
be precisely specified--input and output values are clearly indicated
as such. Thus, one might adopt a similar approach and extend C++
syntax with some special modifiers or qualifiers. For example:
<blockquote>
<pre>
void foo(%output double *x, int n);
</pre>
</blockquote>
The problem with this approach is that it breaks from C++ syntax and
it requires the user to annotate their input files (a task that C++
wrapper generators are supposed to eliminate). Meanwhile, critics sit
back and say "Ha! I told you C++ parsing would never work."
<p>
Another problem with using C++ as an input language is that interface
building often involves more than just blindly wrapping declarations. For instance,
users might want to rename declarations, specify exception handling procedures,
add customized code, and so forth. This suggests that a
wrapper generator really needs to do
more than just parse C++---it must give users the freedom to customize
various aspects of the wrapper generation process. Again, things aren't
looking too good for C++.
<h3>The SWIG approach: pattern matching</h3>
SWIG takes a different approach to the C++ wrapping problem.
Instead of trying to modify C++ with all sorts of little modifiers and
add-ons, wrapping is largely controlled by a pattern matching mechanism that is
built into the underlying C++ type system.
<p>
One part of the pattern matcher is programmed to look for specific sequences of
datatypes and argument names. These patterns, known as typemaps, are
responsible for all aspects of data conversion. They work by simply attaching
bits of C conversion code to specific datatypes and argument names in the
input file. For example, a typemap might be used like this:
<blockquote>
<pre>
%typemap(in) <b>double *items</b> {
// Get an array from the input
...
}
...
void foo(<b>double *items</b>, int n);
</pre>
</blockquote>
With this approach, type and argument names are used as
a basis for specifying customized wrapping behavior. For example, if a program
always used an argument of <tt>double *items</tt> to refer to an
array, SWIG can latch onto that and use it to provide customized
processing. It is even possible to write pattern matching rules for
sequences of arguments. For example, you could write the following:
<blockquote>
<pre>
%typemap(in) (<b>double *items, int n</b>) {
// Get an array of items. Set n to number of items
...
}
...
void foo(<b>double *items, int n</b>);
</pre>
</blockquote>
The precise details of typemaps are not so important (in fact, most of
this pattern matching is hidden from SWIG users). What is important
is that pattern matching allows customized data handling to be
specified without breaking C++ syntax--instead, a user merely has to
define a few patterns that get applied across the declarations that
appear in C++ header files. In some sense, you might view this
approach as providing customization through naming conventions rather than
having to annotate arguments with extra qualifiers.
<p>
The other pattern matching mechanism used by SWIG is a declaration annotator
that is used to attach properties to specific declarations. A simple example of declaration
annotation might be renaming. For example:
<blockquote>
<pre>
%rename(cprint) print; // Rename all occurrences of 'print' to 'cprint'
</pre>
</blockquote>
A more advanced form of declaration matching would be exception handling.
For example:
<blockquote>
<pre>
%exception Foo::getitem(int) {
try {
$action
} catch (std::out_of_range&amp; e) {
SWIG_exception(SWIG_IndexError,const_cast&lt;char*&gt;(e.what()));
}
}
...
template&lt;class T&gt; class Foo {
public:
...
T &amp;getitem(int index); // Exception handling code attached
...
};
</pre>
</blockquote>
Like typemaps, declaration matching does not break from C++ syntax.
Instead, a user merely specifies special processing rules in advance.
These rules are then attached to any matching C++
declaration that appears later in the input. This means that raw C++
header files can often be parsed and customized with few, if any,
modifications.
<h3>The SWIG difference</h3>
Pattern based approaches to wrapper code generation are not unique to SWIG.
However, most prior efforts have based their pattern matching engines on simple
regular-expression matching. The key difference between SWIG and these systems
is that SWIG's customization features are fully integrated into the
underlying C++ type system. This means that SWIG is able to deal with very
complicated types of C/C++ code---especially code that makes heavy use of
<tt>typedef</tt>, namespaces, aliases, class hierarchies, and more. To
illustrate, consider some code like this:
<blockquote>
<pre>
// A simple SWIG typemap
%typemap(in) int {
$1 = PyInt_AsLong($input);
}
...
// Some raw C++ code (included later)
namespace X {
typedef int Integer;
class _FooImpl {
public:
typedef Integer value_type;
};
typedef _FooImpl Foo;
}
namespace Y = X;
using Y::Foo;
class Bar : public Foo {
};
void spam(Bar::value_type x);
</pre>
</blockquote>
If you trace your way through this example, you will find that the
<tt>Bar::value_type</tt> argument to function <tt>spam()</tt> is
really an integer. What's more, if you take a close look at the SWIG
generated wrappers, you will find that the typemap pattern defined for
<tt>int</tt> is applied to it--in other words, SWIG does exactly the right thing despite
our efforts to make the code confusing.
<p>
Similarly, declaration annotation is integrated into the type system
and can be used to define properties that span inheritance hierarchies
and more (in fact, there are many similarities between the operation of
SWIG and tools developed for Aspect Oriented Programming).
<h3>What does this mean?</h3>
Pattern-based approaches allow wrapper generation tools to parse C++
declarations and to provide a wide variety of high-level customization
features. Although this approach is quite different than that found
in a typical IDL, the use of patterns makes it possible to work from
existing header files without having to make many (if any) changes to
those files. Moreover, when the underlying pattern matching mechanism
is integrated with the C++ type system, it is possible to build
reliable wrappers to real software---even if that software is filled
with namespaces, templates, classes, <tt>typedef</tt> declarations,
pointers, and other bits of nastiness.
<h3>The bottom line</h3>
Not only is it possible to generate extension modules by parsing C++,
it is possible to do so with real software and with a high degree of
reliability. Don't believe me? Download SWIG-1.3.14 and try it for
yourself.

BIN
swigweb/blank.jpg
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 404 B

21
swigweb/bugs.ht
View file

@ -1,21 +0,0 @@
SWIG Bug Tracking
<p><img src="images/bugs.png" alt="Bugs">
<p>A <a href="http://sourceforge.net/tracker/?group_id=1645">bug-tracking system</a> for SWIG
is located on <a href="http://sourceforge.net">SourceForge</a>.
Note that you need to log on to SourceForge before submitting a bug.
<p>
Users who have found a bug and fixed it themselves can submit a
<a href="http://sourceforge.net/patch/?group_id=1645">patch</a>.
Please give the SWIG version or CVS snapshot date that the patch is against.
Again, please log on to SourceForge before submitting patches.
<p>
Please note that due to time constraints, bug reports may not
receive an immediate response.
If you have an urgent problem, you may want to
post a message to the <a href="mail.html">swig</a> mailing list
instead.

115
swigweb/cgi-bin/surveyresponse.pl
View file

@ -1,115 +0,0 @@
#!/usr/bin/perl
# This is a CGI script which takes the input from the simple survey submitted in
# survey.html. The user's intended languages and operating systems are stored in
# simple comma separated value files.
use CGI;
$q = new CGI;
# Start the response web page
print "Content-type:text/html\n\n";
print <<EndHTML;
<html><head><title>SWIG Survey Submission</title></head>
<body>
<p/>
<table> <tr>
<td bgcolor="#000000" align=center><font color="#ffffff"><b>SWIG Survey Submission</b></font></td>
</tr> </table>
EndHTML
# Extract all the variables out of the response
$remoteHost = $ENV{'REMOTE_HOST'};
$remoteAddr = $ENV{'REMOTE_ADDR'};
$ipAddress = ($remoteHost == '') ? $remoteAddr : $remoteHost;
$langChicken = $q->param('langChicken');
$langCSharp = $q->param('langCSharp');
$langGuile = $q->param('langGuile');
$langJava = $q->param('langJava');
$langMzscheme = $q->param('langMzscheme');
$langOcaml = $q->param('langOcaml');
$langPerl = $q->param('langPerl');
$langPhp = $q->param('langPhp');
$langPike = $q->param('langPike');
$langPython = $q->param('langPython');
$langRuby = $q->param('langRuby');
$langSexp = $q->param('langSexp');
$langTcl = $q->param('langTcl');
$langXml = $q->param('langXml');
$langSpareLang1 = $q->param('langSpareLang1');
$langSpareLang2 = $q->param('langSpareLang2');
$langSpareLang3 = $q->param('langSpareLang3');
$langOtherLang = $q->param('langOtherLang');
$namedLanguage = $q->param('namedLanguage');
$osBSD = $q->param('osBSD');
$osHPUX = $q->param('osHPUX');
$osLinux = $q->param('osLinux');
$osMacOSX = $q->param('osMacOSX');
$osSolaris = $q->param('osSolaris');
$osWindows = $q->param('osWindows');
$osOtherOS = $q->param('osOtherOS');
$namedOS = $q->param('namedOS');
# Get log date
($seconds, $minutes, $hours, $day_of_month, $month, $year, $wday, $yday, $isdst) = gmtime;
$logDate = sprintf("%04d/%02d/%02d %02d:%02d", $year+1900, $month+1, $day_of_month, $hours, $minutes);
# Create new file each month
$fileName = sprintf("../survey/swigsurvey-%04d-%02d.csv", $year+1900, $month+1);
if (!-e $fileName) {
create_file($fileName);
}
# Open file for appending and lock it to prevent concurrent access
open(fileOUT, ">>$fileName") or construct_thankyou_page_and_exit(); # We can't log the info if we can't open the file, quietly give up.
flock(fileOUT, 2);
seek(fileOUT, 0, 2);
# Dump all the surveyed data to file in comma separated value (CSV) format
print fileOUT "$logDate,$ipAddress,";
print fileOUT "$langChicken,$langCSharp,$langGuile,$langJava,$langMzscheme,$langOcaml,$langPerl,$langPhp,$langPike,$langPython,$langRuby,$langSexp,$langTcl,$langXml,$langSpareLang1,$langSpareLang2,$langSpareLang3,$langOtherLang,$namedLanguage,";
print fileOUT "$osBSD,$osHPUX,$osLinux,$osMacOSX,$osSolaris,$osWindows,$osSpareOS1,$osSpareOS2,$osSpareOS3,$osOtherOS,$namedOS";
print fileOUT "\n";
close(fileOUT);
# Create html page response
construct_thankyou_page_and_exit();
sub create_file($)
{
my($fileToCreate) = @_;
open(fileOUT, ">$fileToCreate") or construct_thankyou_page_and_exit(); # We can't log the info if we can't create the file, quietly give up.
# Generate field heading names
print fileOUT "LogDate,IPAddress,";
print fileOUT "Chicken,CSharp,Guile,Java,Mzscheme,Ocaml,Perl,Php,Pike,Python,Ruby,Sexp,Tcl,Xml,SpareLang1,SpareLang2,SpareLang3,OtherLang,NamedLanguage,";
print fileOUT "BSD,HPUX,Linux,MacOSX,Solaris,Windows,SpareOS1,SpareOS2,SpareOS3,OtherOS,NamedOS";
print fileOUT "\n";
}
sub construct_thankyou_page_and_exit
{
print <<EndHTML;
Thank you for taking the time to fill out the survey. Please continue to the
<a href="../download.html">Download area</a> or return to the <a href="../index.html">SWIG home</a> page.
</body></html>
EndHTML
exit;
}

111
swigweb/compare.ht
View file

@ -1,111 +0,0 @@
SWIG Features
<h2>SWIG Features</h2>
<p>
This information is based on the SWIG-1.3.22 release.
<h3>Code Generation</h3>
SWIG current generates wrapper code for thirteen different target languages:
<ul>
<li>Allegro CL
<li>C#
<li>Chicken
<li>Guile
<li>Java
<li>Modula-3
<li>Mzscheme
<li>OCAML
<li>Perl
<li>PHP
<li>Python
<li>Ruby
<li>Tcl
</ul>
In addition to this, an XML output module is also available and work
is in progress on a Pike module.
<h3>ANSI C</h3>
SWIG is capable of wrapping all of ANSI C. Features include:
<ul>
<li>Handling of <em>all</em> ANSI C datatypes.
<li>Global functions, global variables, and constants.
<Li>Structures and unions.
<li>Pointers.
<li>Arrays and multidimensional arrays.
<li>Pointers to functions.
<li>Variable length arguments.
<li>Typedef.
<li>Enums.
</ul>
<h3>ANSI C++</h3>
SWIG provides wrapping support for almost all of ANSI C++.
<ul>
<Li>All C++ datatypes.
<Li>References.
<li>Pointers to members.
<li>Classes.
<li>Inheritance and multiple inheritance.
<li>Overloaded functions and methods (using dynamic dispatch).
<li>Overloaded operators.
<li>Static members.
<li>Namespaces (including using declarations, aliases, nesting, etc.)
<li>Templates
<li>Member templates
<li>Template specialization and partial specialization.
<li>Smart pointers
<li>Library support for strings, STL vectors, and more.
</ul>
The only major C++ feature not currently supported by SWIG is the
wrapping of nested classes--a problem we're working on. SWIG also
does not allow C++ virtual methods to be implemented in certain
target languages (a subtle feature that might be useful in projects that
rely heavily on the use of callback functions).
<p>
C++ users who rely on advanced template programming techniques
(e.g., template meta-programming) should also be aware that SWIG
currently requires manual instantiation of all template classes.
Therefore, if your application somehow involves the instantiation of 50000
template classes, your mileage might vary.
<h3>Preprocessing</h3>
SWIG provides a full C preprocessor with the following features:
<ul>
<li>Macro expansion.
<li>Automatic wrapping of #define statements as constants (when applicable).
<li>Support for C99 (variadic macro expansion).
</ul>
<h3>Customization features</h3>
SWIG provides control over most aspects of wrapper generation. Most
of these customization options are fully integrated into the C++ type
system--making it easy to apply customizations across inheritance
hierarchies, template instantiations, and more. Features include:
<ul>
<li>Customizated type conversion/marshaling.
<Li>Exception handling.
<li>Class/structure extension.
<li>Memory management.
<li>Ambiguity resolution.
<li>Template instantiation.
<li>File import and cross-module linking.
<li>Code inclusion, helper function support.
<li>Extensive diagnostics (error/warning messages).
<li>Extended SWIG macro handling.
</ul>

101
swigweb/compat.ht
View file

@ -1,101 +0,0 @@
SWIG Compatibility
<p>
<img src="images/compat.png" alt="Compatibility">
<p>
SWIG is known to work on the following platforms :
<ul>
<li> Unix
<blockquote>
SWIG is configured and built using an autoconf script so it is
relatively easy to install on almost any flavor of Unix. However, most of
SWIG's development has taken place under Linux and Solaris.
While the configuration script tries to determine the proper settings
for your machine, some tweaking may be required to compile the
examples included in the distribution (especially if you are using a
version of Unix such as AIX or HPUX).
</blockquote>
<li> Microsoft Windows
<blockquote>
SWIG works on 32 bit versions of Windows such as Windows 95/98/NT/2000/XP.
Currently the Windows version of SWIG 1.3 is compiled and tested under
Visual Studio compilers, <a href="http://www.cygwin.com">Cygwin</a> and
<a href="http://www.mingw.org">Mingw</a> using gcc, but should be
compilable by any other Windows C++ compiler.
SWIG 1.1 can be compiled with Visual C++ 4.x/5.x/6.x or with the Borland C++ 5.x
compiler. However, SWIG 1.1 has only been officially tested using the
Visual C++ compiler. You may also need to determine which compiler
has been used to compile the various scripting languages that you will
be using. In general, using SWIG with a different C++ compiler than
the one that was used to compile the target scripting language may
not work (for example, trying to create a Tcl/Tk module using the
Borland compiler when Tcl/Tk has been compiled with Visual C++).
</blockquote>
<li> Macintosh
<blockquote>
A highly experimental version of SWIG has been compiled using
Metrowerks Code Warrior 10. Given the limited availability and
experience with the Macintosh, this version of SWIG should only
be used by exceptionally brave users. SWIG has not been fully tested with Python or
Perl on the Macintosh although some users have reported success.
<p>
<b>Note:</b>SWIG-1.3.12 does support OS-X/Darwin. Simply download the Unix
sources, configure, and build from the command terminal.
</blockquote>
</ul>
<h3><a name="SupportedLanguages"></a> Supported Languages </h3>
The following scripting languages were supported in the final SWIG 1.1 release.
<ul>
<li> Tcl 8.0 and newer versions.
<li> Python 1.5 and newer.
<li> Perl 5.003 or newer.
<li> Guile 1.3.4 and newer.
</ul>
The following languages are also supported in SWIG 1.3.6 onwards.
<ul>
<li> Java JDK 1.1 and newer.
<li> Ruby.
<li> Mzscheme.
</ul>
PHP support was added in SWIG 1.3.11.<br>
Objective Caml (Ocaml) and Pike support was added in SWIG 1.3.14.<br>
Support for C# and the Chicken scheme compiler was added in SWIG 1.3.18.<br>
Support for Allegro CL and Modula-3 was added in SWIG-1.3.22.<br>
Support for Lua, CLISP and Common Lisp with UFFI was added in SWIG-1.3.26.<br>
Support for Common Lisp with CFFI was added in SWIG-1.3.28.<br>
Support for R was added in SWIG-1.3.30.<br>
<p>
Any newer versions of these languages should be assumed to be
supported unless otherwise indicated.
There is also <a href="http://www.ultravioletconsulting.com/projects/swigjs">SwigJS</a>, a JavaScript module for SWIG,
<a href="http://www.dsource.org/projects/swig4d">swig4d</a> for the D programming language
and <a href="http://efsa.sourceforge.net/archive/cozzi/swigeiffel.htm">SWIGEiffel</a> for Eiffel.
<h3> Compilation Requirements </h3>
SWIG is implemented in C and C++ and is distributed in source form.
You will need a working C++ compiler (e.g. g++) to build SWIG and at
least one of the supported scripting languages to use it (or else it
isn't going to be very useful). SWIG does not depend upon any of the
supported scripting languages for its own compilation. Finally,
although SWIG is partly written in C++, a C++ compiler is not required to use
SWIG--it works just fine with both ANSI C and C++.

14
swigweb/copyfun.ht
View file

@ -1,14 +0,0 @@
Proposed SWIG Copyright
<p>
<img src="images/copyright.png" alt="Copyright">
<pre>
Simplified Wrapper and Interface Generator (SWIG)
Copyright (C) 1995-2003
The University of Chicago
All Rights Reserved
It's free.
</pre>

75
swigweb/copyright.ht
View file

@ -1,75 +0,0 @@
SWIG Copyright
<p>
<img src="images/copyright.png" alt="Copyright">
<pre>
Simplified Wrapper and Interface Generator (SWIG)
SWIG is distributed under the following terms:
=================================================
I.
This software includes contributions that are Copyright (c) 1998-2002
University of Chicago.
All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are
met:
Redistributions of source code must retain the above copyright notice,
this list of conditions and the following disclaimer. Redistributions
in binary form must reproduce the above copyright notice, this list of
conditions and the following disclaimer in the documentation and/or
other materials provided with the distribution. Neither the name of
the University of Chicago nor the names of its contributors may be
used to endorse or promote products derived from this software without
specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE UNIVERSITY OF CHICAGO AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE UNIVERSITY OF
CHICAGO OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED
TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
II.
Copyright (c) 1995-1998
The University of Utah and the Regents of the University of California
All Rights Reserved
Permission is hereby granted, without written agreement and without
license or royalty fees, to use, copy, modify, and distribute this
software and its documentation for any purpose, provided that
(1) The above copyright notice and the following two paragraphs
appear in all copies of the source code and (2) redistributions
including binaries reproduces these notices in the supporting
documentation. Substantial modifications to this software may be
copyrighted by their authors and need not follow the licensing terms
described here, provided that the new terms are clearly indicated in
all files where they apply.
IN NO EVENT SHALL THE AUTHOR, THE UNIVERSITY OF CALIFORNIA, THE
UNIVERSITY OF UTAH OR DISTRIBUTORS OF THIS SOFTWARE BE LIABLE TO ANY
PARTY FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL
DAMAGES ARISING OUT OF THE USE OF THIS SOFTWARE AND ITS DOCUMENTATION,
EVEN IF THE AUTHORS OR ANY OF THE ABOVE PARTIES HAVE BEEN ADVISED OF
THE POSSIBILITY OF SUCH DAMAGE.
THE AUTHOR, THE UNIVERSITY OF CALIFORNIA, AND THE UNIVERSITY OF UTAH
SPECIFICALLY DISCLAIM ANY WARRANTIES,INCLUDING, BUT NOT LIMITED TO,
THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE. THE SOFTWARE PROVIDED HEREUNDER IS ON AN "AS IS" BASIS, AND
THE AUTHORS AND DISTRIBUTORS HAVE NO OBLIGATION TO PROVIDE MAINTENANCE,
SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS.
</pre>

168
swigweb/cpp.ht
View file

@ -1,168 +0,0 @@
New C++ Features
<h2>Dave's Most Desired C++ Features</h2>
In writing SWIG, I have developed a whole new appreciation for the
language that is C++. However, I have also come to discover a number
of serious limitations in the language. Therefore, in the interest of
public service, I now present my semi-official list of C++ features
I would most like to see implemented:
<ul>
<li><b>The slightly ambiguous reference.</b> This would be a variation
on the ever-so-useful C++ reference (&amp;) used to denote a quantity
that refers to either the object itself (by value) to a reference to
an object. The preferred syntax for this is to enclose the variable
name in brackets and use the ampersand like this
<tt>&lt;&amp;foo&gt;</tt>.
<blockquote>
<pre>
void foo(Bar <&amp;b>) {
b.frag(3); // Call some method
...
}
</pre>
</blockquote>
In this case, <tt>foo</tt> would either be passed a copy of a
<tt>Bar</tt> type (pass by value) or a reference to an existing
<tt>Bar</tt>. The precise choice, of course, would be up to the
implementation. Obviously, the compiler would pick the best
option--making it a good choice for programmers too stupid to know whether
they should use a pointer or not.
<p>
Obviously, there are a few complicated cases such as:
<blockquote>
<pre>
void foo(const Bar *const *<&amp;b>);
</pre>
</blockquote>
The interpretation of this is left as an exercise to the reader (hey,
it's good to be a professor).
<li><p><b>Circular shift operators.</b> Sure, one doesn't really need to
do a circular bit shift very often, but they are sometimes useful in
cryptographic algorithms and for general-purpose bit-twiddling. I
propose the inclusion of the triple angle bracket operators
(<tt>&lt;&lt;&lt;</tt> and <tt>&gt;&gt;&gt;</tt>) for this purpose. Of
course, these operators could also be overloaded just like the normal
shift operators. It's not that I really need these operators, but it
is yet another opportunity to include more angle brackets into the
language.
<li><p><b>The survival cast.</b> I'm not really sure where I got this idea,
but basically it works like this: given an object, you can cast it using
a <tt>survival_cast</tt> like this
<blockquote>
<pre>
Bar *x = survival_cast&lt;Bar *&gt;(y);
</pre>
</blockquote>
Afterwards, the object that <tt>x</tt> points to is guaranteed to be
undeletable--even if a program repeatedly calls <tt>delete</tt> or
<tt>free()</tt> on it. This effect applies to the object itself, not
the pointer (thus, the cast implicitly applies to all other pointers referring to
the same object). Furthermore, the cast remains in effect until the
program terminates--making this a particularly good way to avoid those
pesky memory management problems such as calling delete too many times
by accident.
<p>
The survival cast can be applied to the individual elements of an array
or container. However, in this case, the implementation must ensure
that deletion of the array or container only deletes those members for
which the survival cast has not been applied.
<p>
When too many objects have been cast using the survival cast, they may
decide to spontaneously delete themselves along with an unspecified
number of non-survival objects. This is a feature. However, the
precise mechanism and scope of destruction is implementation specific
and may depend on the type of objects to which the survival cast has
been applied.
<li><p><b>The non-castable function pointer</b>. Since function pointers are
too confusing for everyone, it should be impossible to cast them into any
other type. Oh wait, this is already a C++ feature.
<li><p><b>The identifier length cast</b>. Since we're on the subject of casting.... I would
also like to propose the identifier length cast. This is a cast that only works
if the identifier names of the two types are exactly the same length in
characters. For example:
<blockquote>
<pre>
Bar *x = identifier_length_cast&lt;Foo *&gt;(y); // Ok
FooBar *x = identifier_length_cast&lt;Foo *&gt;(y); // Error
</pre>
</blockquote>
In addition, there should be an <tt>identifier_case_cast</tt> that works similarly, but
which looks at the case of the type names. I'm not really sure what purpose these casts
would serve, but that doesn't really distinguish them from any of the other casts.
<li><p><b>The instance goto</b>. In a nutshell, I really want to be able to do
this:
<blockquote>
<pre>
class Foo {
public:
...
bar:
printf("Hello world\n");
... some code here ...
break;
};
int main() {
Foo *f = new Foo;
goto f.bar;
...
}
</pre>
</blockquote>
Obviously, the benefits of this feature are self-evident. However,
there are still a few tricky points. First, the goto should work with
inheritance when the goto label happens to appear in a base-class. Second,
the goto should certainly take advantage of dynamic binding much like virtual
member functions. Finally, I believe that there would be many interesting
possibilities of combining template classes with goto. For example:
<blockquote>
<pre>
template class Foo&lt;x&gt; {
public:
x:
... some code here ...
break;
...
};
</pre>
</blockquote>
Clearly, the number of applications is endless.
<li><p><b>MP3 player</b>. Since compiling a C++ application takes so long, I think
it would be useful to modify the C++ compiler to go out and search the net for an
appropriate symphony or sonata to download and play while it is working. Ahhhh. Yes.
Of course, if you have a DVD player handy, I have personally found that watching "Apocalypse Now"
is a relaxing way to pass the time.
</ul>
Have a further feature suggestion? Please let me know.

136
swigweb/cvs.ht
View file

@ -1,136 +0,0 @@
SWIG CVS
<p>
<img src="images/cvs.png" alt="CVS">
<p>
Development versions of SWIG are available through the CVS server located at SourceForge.
<h3> Disclaimer </h3>
The CVS release represents work in progress and is not guaranteed to compile on your machine or be functional in any
manner.
<h3> Required Tools </h3>
To compile SWIG from its CVS repository, you will need the following tools:
<ul>
<li> Autoconf 2.58 or higher
<li> Automake 1.7.2 or higher
<li> A working C++ compiler.
<li> yacc or bison (to compile the SWIG parser).
</ul>
<p>
It is important to note that the CVS repository does not include the C++ code
generated by yacc nor the files produced by Autoconf or Automake (these
are however included in a normal release). Thus, you will have
to install these tools on your machine for everything to work.
<h3>To check out the latest version </h3>
There are
<a href="http://sourceforge.net/cvs/?group_id=1645">generic CVS instructions</a>
available on the SourceForge site, but the steps below should be all you need.
The instructions below are for those who have read only access for cvs, developers should
consult the generic CVS instructions above.
<ol>
<li><p> Set the location of CVSROOT, for csh this would be:
<pre>
% setenv CVSROOT :pserver:anonymous@swig.cvs.sourceforge.net:/cvsroot/swig </pre>
<p>
If you are using bash, you would use:
</p>
<pre>
% export CVSROOT=:pserver:anonymous@swig.cvs.sourceforge.net:/cvsroot/swig </pre>
<p>
(Alternatively, you can use the -d option to CVS)
</p>
<li><p> Log into the cvs server by issuing the following command:
<pre>
% cvs login
CVS password: &lt;press enter here&gt;
</pre>
<li><p>The latest development version of SWIG can be retrieved using
<pre>
% cvs checkout SWIG
</pre>
<li><p>To build the system, follow these steps
<pre>
% cd SWIG
% ./autogen.sh
% ./configure --prefix=/some/directory
% make
% make install
</pre>
<li><p>To check the build, run the tests:
<pre>
% make -k check </pre>
This could take up to an hour or longer. If you are interested in a particular language,
just check the examples and test-suite for that language. For example, the Python tests:
<pre>
% make check-python-examples
% make check-python-test-suite
</pre>
</ol>
<b>Note:</b> The CVS repository is read-only so the system will not
accept code modifications unless you are a developer.
<h3> Build Issues </h3>
Here are some guidelines should you be experiencing problems building SWIG from CVS.
<ol>
<li>Check that you have a complete update from the SWIG CVS repository.
A fresh checkout from CVS often solves build problems.
</li>
<li>
Make sure you have run <tt>./autogen.sh</tt> and <tt>./configure</tt>.
Both these steps will be necessary if you have a fresh CVS checkout or if the build files in the repository have changed since a previous update.
</li>
<li>
Check that the appropriate versions of your autotools (Autoconf and Automake) are installed properly.
The autotools are in a state of flux and there are backward compatibility issues which are solved in different ways on different operating systems.
</li>
<li>
Check that all the autotool bootstrap programs which are executed when running <tt>./autogen.sh</tt> are up to date and match your installed autotool versions.
For example <tt>aclocal --version</tt> should report a matching version of Automake or Autoconf, something like "aclocal (GNU automake) 1.7.6".
</li>
</ol>
If you are still having problems, send an email to <a href="mail.html">swig-devel</a> mailing list.
<h3>Developer Access</h3>
We are always looking for people to help out with various projects.
<ul>
<li><p> Send email to to the <a href="mail.html">swig-devel</a> mailing list.
if you are interested in doing developer work and gaining write access to the CVS repository.
<li><p> The <a href="mail.html">swig-devel</a> mailing list is the developer mailing list
and should be used to discuss coding issues, bugs, patches, and so forth.
Subscription information and archives of recent activity can be found on the <a href="mail.html">mailing lists</a> page.
</ul>

Some files were not shown because too many files have changed in this diff Show more