update to 1.3.15

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

SWIG/LICENSE

@@ -1,37 +1,37 @@
 SWIG is distributed under the following terms:
 
-I.
+I. 
 
-Copyright (C) 1998-2000
+This software includes contributions that are Copyright (c) 1998-2002
-The University of Chicago
+University of Chicago.
+All rights reserved.
 
-Permission is hereby granted, without written agreement and without
+Redistribution and use in source and binary forms, with or without
-license or royalty fees, to use, copy, modify, and distribute this
+modification, are permitted provided that the following conditions are
-software and its documentation for any purpose, provided that 
+met:
-(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 CHICAGO, OR
+Redistributions of source code must retain the above copyright notice,
-DISTRIBUTORS OF THIS SOFTWARE BE LIABLE TO ANY PARTY FOR DIRECT,
+this list of conditions and the following disclaimer.  Redistributions
-INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES ARISING OUT OF
+in binary form must reproduce the above copyright notice, this list of
-THE USE OF THIS SOFTWARE AND ITS DOCUMENTATION, EVEN IF THE AUTHORS OR
+conditions and the following disclaimer in the documentation and/or
-ANY OF THE ABOVE PARTIES HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH
+other materials provided with the distribution.  Neither the name of
-DAMAGE.
+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.
 
-THE AUTHOR AND THE UNIVERSITY OF CHICAGO SPECIFICALLY DISCLAIM ANY
+THIS SOFTWARE IS PROVIDED BY THE UNIVERSITY OF CHICAGO AND CONTRIBUTORS
-WARRANTIES,INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
-MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE SOFTWARE
+LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
-PROVIDED HEREUNDER IS ON AN "AS IS" BASIS, AND THE AUTHORS AND
+PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE UNIVERSITY OF
-DISTRIBUTORS HAVE NO OBLIGATION TO PROVIDE MAINTENANCE, SUPPORT,
+CHICAGO OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
-UPDATES, ENHANCEMENTS, OR MODIFICATIONS.
+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.  
-II.
 
 Copyright (c) 1995-1998
 The University of Utah and the Regents of the University of California
@@ -63,3 +63,4 @@ THE AUTHORS AND DISTRIBUTORS HAVE NO OBLIGATION TO PROVIDE MAINTENANCE,
 SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS.
 
 
+

SWIG/README

@@ -1,12 +1,12 @@
 SWIG (Simplified Wrapper and Interface Generator)
 
-Version: 1.3.13 (June 17, 2002)
+Version: 1.3.15 (September 9, 2002)
 
 $Header$
 
 Tagline: SWIG is a compiler that integrates C and C++ with
          languages including Perl, Python, Tcl, Guile, Mzscheme,
-         Java, Ruby, and PHP.
+         Java, Ruby, PHP, and Ocaml.
 
 SWIG reads annotated C/C++ header files and creates wrapper code (glue
 code) in order to make the corresponding C/C++ libraries available to
@@ -18,22 +18,26 @@ aiming to replace versions 1.1p5 and 1.1-883. The guilty parties
 working on this are:
 
  Dave Beazley (beazley@cs.uchicago.edu)                 (SWIG core, Python, Tcl, Perl)
- William Fulton (wsf@fultondesigns.co.uk)               (Java)
+ William Fulton (wsf@fultondesigns.co.uk)               (Java, Cygwin)
  Matthias Köppe (mkoeppe@mail.math.uni-magdeburg.de)    (Guile/MzScheme)
- Loic Dachary (loic@ceic.com)                           (Perl5)
  Jason Stewart (jason@openinformatics.com)              (Perl5)
- Thien-Thi Nguyen (ttn@glug.org)                        (Testing/Misc)
  Lyle Johnson (lyle@users.sourceforge.net)              (Ruby)
- Masaki Fukushima (fukusima@goto.info.waseda.ac.jp)     (Ruby)
  Richard Palmer (richard@magicality.org)                (PHP)
- Luigi Ballabio (ballabio@mac.com)                      (Macintosh port)
+ Luigi Ballabio (luigi.ballabio@fastwebnet.it)          (Macintosh, STL wrapping)
  Sam Liddicott (saml@liddicott.com)                     (PHP)
+ Art Yerkes (ayerkes@speakeasy.net)                     (Ocaml)
+
+Major contributors include:
+ Shibukawa Yoshiki                                      (Japanese Translation)
+ Marcelo Matus                                          (Evil C++ testing)
+ Loic Dachary                                           (Perl5)
+ Masaki Fukushima                                       (Ruby)
+ Thien-Thi Nguyen                                       (Testing/Misc)
 
 Past contributors include:
-
+ Clark McGrew, Dustin Mitchell, Ian Cooke, Catalin Dumitrescu, Baran
-Clark McGrew, Dustin Mitchell, Ian Cooke, Catalin Dumitrescu, Baran
+ Kovuk, Gary Holt, David Fletcher, Oleg Tolmatcev, Harco de Hilster.
-Kovuk, Gary Holt, David Fletcher, Oleg Tolmatcev, Harco de Hilster.
+ (See CHANGES for a more complete list).
-(See CHANGES for a more complete list).
 
 Up-to-date SWIG related information can be found at
 
@@ -42,7 +46,11 @@ Up-to-date SWIG related information can be found at
 A SWIG FAQ and other hints can be found on the SWIG Wiki:
 
        http://swig.cs.uchicago.edu/cgi-bin/wiki.pl
- 
+
+Information about SWIG is also available in Japanese translation at
+
+       http://swig-jp.dyndns.org
+
 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
 !!!!!!!                      IMPORTANT                         !!!!!!!
 !!!!!!!                                                        !!!!!!!
@@ -57,6 +65,10 @@ What's New?
 ===========
 The most notable changes since SWIG1.1 include the following:
 
+   - Support for C++ overloaded functions and methods.
+
+   - Support for C++ smart pointers.
+
    - Support for C++ namespaces
 
    - Support for C++ overloaded operators.
@@ -64,30 +76,13 @@ The most notable changes since SWIG1.1 include the following:
    - Support for C++ templates including member templates,
      specialization, and partial specialization.
 
-   - Improved support for overloaded functions/methods.
-
    - Parsing support for almost all C/C++ datatypes.
 
-   - Pointers to members are now supported in the parser
+   - A full C preprocessor with macro expansion. 
-     and by the Python module.
-
-   - Improved support for pointers to functions and callbacks.
-
-   - SWIG now has a full C preprocessor with macro expansion. 
      Includes C99 variadic macro support.
 
-   - Code generation for the Tcl and Python modules has been
+   - Java, Ruby, MzScheme, PHP4, OCAML, Pike, and XML modules added.
-     substantially improved both in terms of size and runtime
+     Guile module improved.
-     efficiency (Perl5 is coming along too).
-
-   - The Guile module is stable. It represents C pointers as smobs and
-     supports the Guile module system and exceptions.
-
-   - Java, Ruby, MzScheme, PHP4 modules added.
-
-   - Redesigned implementation of typemaps.  Typemaps can now be defined
-     for groups of consecutive function arguments.  This has been a long
-     requested feature that now works.
 
    - Better code generation.   SWIG is better able to make optimizations
      in order to generate less code.
@@ -98,7 +93,7 @@ The most notable changes since SWIG1.1 include the following:
 
    - Better Windows support.
 
-Here are a few missing features:
+If you used SWIG-1.1, a number of old features are missing from SWIG-1.3.
 
    - The SWIG1.1 documentation system is gone and hasn't been
      replaced yet.  This is on the long-term to-do list.
@@ -106,10 +101,6 @@ Here are a few missing features:
    - The Tcl7.x and Perl4 modules are deprecated and no longer
      included.
 
-   - The Perl5 module is need in some repair and may not work
-     with ActivePerl.  We are looking for volunteers to help us
-     with this.
-
    - A wide variety of old SWIG command-line options and
      obscure features are gone.
 
@@ -122,11 +113,11 @@ Here are a few missing features:
 
 Although we are making some attempt to preserve backwards
 compatibility with interfaces written for SWIG1.1, SWIG1.3
-incorporates a number of very substantial modifications to things such
+incorporates a number of very substantial modifications to type
-as type handling, typemaps, and wrapper code generation.  Therefore,
+handling, typemaps, and wrapper code generation.  Therefore, if you
-if you are making extensive use of advanced SWIG features, interfaces
+are making extensive use of advanced SWIG features, interfaces written
-written for SWIG1.1 may not work.  We apologize for the inconvenience,
+for SWIG1.1 may not work.  We apologize for the inconvenience, but
-but these changes are needed in order to fix a number of annoying
+these changes are needed in order to fix a number of annoying
 "features" in SWIG1.1.  Hopefully the list of new features will
 provide enough incentive for you to upgrade (and that the
 modifications to your interfaces will only be minor).
@@ -153,7 +144,6 @@ To build and install SWIG, simply type the following:
 
      % ./configure
      % make
-     % make -k check	# This step is optional (see note 3 below)
      % make install
 
 By default SWIG installs itself in /usr/local.  If you need to install SWIG in
@@ -162,7 +152,6 @@ to ./configure.  For example:
 
      % ./configure --prefix=/home/yourname/projects
      % make
-     % make -k check
      % make install
 
 Note: the directory given to --prefix must be an absolute pathname.  Do *NOT* use
@@ -186,26 +175,35 @@ Notes:
     before typing 'configure'.    In addition, a full build of SWIG requires
     the use of bison.
 
-(2) 'make -k check' is a new feature that requires at least one of the target
+Testing
-    languages to be installed and which performs compile/link level testing
+=======
-    of the examples.  If it fails, it may mean that you have an uninstalled
+If you want to test SWIG before installation, type the following:
-    language module or that the file 'Examples/Makefile' has been
-    incorrectly configured.  It may also fail due to compiler issues 
-    such as broken C++ compiler.  Even if 'make -k check' fails, there is a 
-    pretty good chance SWIG still works correctly---you will just have
-    to mess around with one of the examples and some makefiles first.
 
-(3) The testing suite executed by 'make -k check' is designed to stress-test
+    % make -k check
-    many parts of the implementation including obscure corner cases. If some
-    of these tests fail or generate warning messages, there is no reason for
-    alarm---the test may be related to some new SWIG feature or a difficult bug
-    that we're trying to resolve.  Chances are that SWIG will work just fine
-    for you.  
 
-    Note: SWIG's support for C++ is sufficiently advanced that certain
+'make -k check' requires at least one of the target languages to be
-    tests may fail on older C++ compilers (for instance if your compiler
+installed.  If it fails, it may mean that you have an uninstalled
-    does not support member templates).   These errors are harmless if you 
+language module or that the file 'Examples/Makefile' has been
-    don't intend to use these features in your own programs.
+incorrectly configured.  It may also fail due to compiler issues such
+as broken C++ compiler.  Even if 'make -k check' fails, there is a
+pretty good chance SWIG still works correctly---you will just have to
+mess around with one of the examples and some makefiles to get it to work.
+
+The testing suite executed by 'make -k check' is designed to stress-test
+many parts of the implementation including obscure corner cases. If some
+of these tests fail or generate warning messages, there is no reason for
+alarm---the test may be related to some new SWIG feature or a difficult bug
+that we're trying to resolve.  Chances are that SWIG will work just fine
+for you.  
+
+Note: SWIG's support for C++ is sufficiently advanced that certain
+tests may fail on older C++ compilers (for instance if your compiler
+does not support member templates).   These errors are harmless if you 
+don't intend to use these features in your own programs.
+
+Note: The test-suite currently contains more than 170 tests.  If you
+have many different target languages installed and a slow machine, it
+might take more than an hour to run the test-suite. 
 
 Examples
 ========
@@ -216,6 +214,15 @@ the file "Example/index.html".
 The Examples directory now includes Visual C++ project (.dsp) files for
 building some of the examples on Windows (new in SWIG1.3.7).
 
+Known Issues
+============
+The SWIG-1.3.15 release includes a number of substantial changes to existing
+language modules.  These changes include modifications to the build environment
+and the wrapper code itself.  Certain examples may not compile or may need
+minor changes to work.
+
+Please see the CHANGES file for a detailed list of changes.
+
 Troubleshooting
 ===============
 In order to operate correctly, SWIG relies upon a set of library
@@ -228,7 +235,7 @@ files.  If after building SWIG, you get error messages like this,
 it means that SWIG has either been incorrectly configured or
 installed.  To fix this:
 
-    1.  Make sure you remembed to do a 'make install' and that
+    1.  Make sure you remembered to do a 'make install' and that
         the installation actually worked.  Make sure you have
         write permission on the install directory.
 
@@ -265,7 +272,6 @@ has some information on SWIG internals.
 
 Participate!
 ============
-
 Please report any errors and submit patches (if possible)!  We only
 have access to a limited variety of hardware (Linux, Solaris, OS-X,
 and Windows). All contributions help.

SWIG/TODO

@@ -1,6 +1,6 @@
 SWIG TO-DO    
 
-Release: SWIG-1.3.14    (Late July, 2002)
+Release: SWIG-1.3.15    (Late August, 2002)
 -----------------------------------------------------------------------------
 
 ****    = High Priority
@@ -8,10 +8,12 @@ Release: SWIG-1.3.14    (Late July, 2002)
 **      = Will implement if time. 
 *       = Implement if bored (or deemed necessary).
 
+defer   = Implement in 1.3.16
+
 CORE:
 
 ****   Add support for nested classes.   The type system should be
-       ready to go.  The primary obstacle lies in the target language
+defer  ready to go.  The primary obstacle lies in the target language
        modules (which were never programmed with nested classes in
        mind).  There are also issues with nested C structures.  For
        example:
@@ -25,64 +27,70 @@ CORE:
        This is one of the last remaining "hard" problems in the SWIG
        core, but it is important that we solve it.  
 
-****   Better modularization of language modules and a minor redesign
+[DONE] Refinement of the overloading dispatch rules.  If you have two
-       of the very high-level API.   Issues:
+       classes like this:
 
-        -  Language modules should be created by a factory function
+           class Foo {
-           with C linkage.  For example:
+           };
 
-              Language *PYTHON_init() {
+           class Bar : public Foo {
-                  return new PYTHON();
+           };
-              }
 
-           swigmain.cxx should then be modified to only use the factory
+       and two overloaded methods:
-           functions when bringing a module into existence.  This
-           decouples main() from the implementation of each language
-           module---and eliminates the need to have header files
-           for each module. 
 
-           Placing C linkage on the initialization function provides
+           void spam(Foo *f);
-           support for eventual dynamic loading of SWIG modules--it 
+           void spam(Bar *b);
-           establishes a well-known symbol name that can be used in
-           conjunction with the dynamic loader.
 
-        -  Perhaps the module system would be simplified by having
+       SWIG should make sure that the derived class version is checked
-           all code located in a single file instead of a separate
+       first. 
-           header file and a separate implementation file.
 
-        -  Does anyone inherit from existing modules?
+[DONE] Refinement of using directives.  For example:
 
-***    Support for overloaded functions.   It is probably possible to
+          namespace foo {
-       add some kind of support for this.  Overloading has been supported
+             int blah(int);
-       internally for quite some time---the warning messages are there
+          }
-       simply as a stop-gap measure (since no language modules support
-       overloading).    We would keep the the existing %rename support.
 
-***    Support for smart-pointers and proxies.  This is primarily to
+          namespace bar {
-       support classes that implement the -> operator and which are used
+             double blah(double);
-       to dispatch on another class.   I think it would be cool if
+          }
-       SWIG could automatically detect and handle this case.   For example, 
-       if you had this:
 
-            class FooProxy {
+          using foo::blah;
-               ...
+          using bar::blah;
-               Foo *operator->();
-               ...
-            };
 
-       Perhaps SWIG could automagically locate Foo and arrange for its
+       Currently, SWIG reports an error (redefined symbol).  Instead, it should be
-       methods to be associated with FooProxy.  This is really not too
+       silent.   
-       bad.   The proxy methods could be wrapped normally with only
-       one minor modification in the wrapper code.   If the class Foo had
-       a method "bar" it would be invoked as this, through the proxy:
 
-            FooProxy *arg1;     // Object pointer (to proxy)
+       It's not entirely clear what should happen in terms of overloading.  Currently,
-            (*arg1)->bar();  
+       the two functions can't be combined into an overloaded method (they are
-             ^
+       in separate namespaces and the functions don't quite combine like that).
-            extra "*" added here.
+       
+       One could generate wrappers for the using declarations.  However, this
+       could generate a conflict (if both the namespace and non-namespace version
+       are wrapped).
 
-       I think automatic wrapping of methods would be much nicer than
+[DONE] Modify exception handling code not to apply to attribute access.  Should
-       requiring the use of a special directive.
+       reduce the amount of wrapper code substantially when a global exception
+       handler is used.
+
+****   Typemap environments.  Stay tuned.
+
+[DONE] Implement option to print dependencies.
+
+****   Implement "throw" typemaps for all of the target languages.
+
+[DONE] If a wrapper can't be generated to a function/method for some
+       reason, provide a flag that prevents that function/method from
+       appearing the dispatch function.
+
+       If a language module sets the "error" attribute of a node, it is
+       not included in the dispatch function.
+ 
+[DONE] Investigate the enhancement of exception handling to match against exceptions
+       specified with throw specifiers.
+
+***    Add attributes to the %feature directive. Something like:
+
+       %feature("except", throws="OutOfMemoryException") 
 
 ***    Rewrite declaration annotation to better unify %rename and related
        directives.  Add a selector mechanism that allows specific parse tree
@@ -90,6 +98,13 @@ CORE:
 
              %feature("foo", nodetype="class") Foo { ... some code ... };
 
+       Also desirable for the Java module to specify the classes to go in the
+       throw clause:
+
+             %feature("except", throws="OutOfMemoryException") Foo { 
+                ... code which throws the OutOfMemoryException ... 
+             };
+
        Consider use of wildcards.   Namespace/nested scope support in
        %feature is currently weak.  It works, but is fragile.  Consider
        an implementation that is better integrated with symbol table
@@ -102,6 +117,37 @@ CORE:
        objects when they are assigned to pointer variables and structure
        members as well as stored in a container (i.e., an array of pointers).
 
+       [ Partially finished for Tcl/Python. ]
+
+
+***    Modify smart pointer handling to properly handle inheritance.  For
+       example:
+
+            class Foo {
+            public:
+                Blah *operator->();
+            };
+  
+            class Bar : public Foo {
+            }
+
+       Bar should still allow access to Blah * through operator->().
+
+**     Virtual function optimization.  If you have two classes like this:
+
+          class Foo {
+          public:
+                virtual int blah(int);
+          };
+
+          class Bar : public Foo {
+          public:
+                virtual int blah(int);
+          };
+
+       Then SWIG ought to be able to reuse the wrapper for Foo::blah as
+       Bar::blah.   This should result in much smaller extension modules.
+
 **     Restoration of the documentation system.
 
 **     Restoration of Objective-C support.
@@ -111,11 +157,37 @@ CORE:
        both.  The existence of two symbol management systems is mostly
        historical. 
 
+**     Add a warning for uninstantiated templates.  For example, if a function
+       using a template type, but that type hasn't been instantiated using
+       %template.
+
+[DONE] Fix build problems on 64-bit platforms.   We need to replace
+       NULL by (char *) NULL in most modules.
+
+       Defined NIL as (char *) NULL.  Used that in most modules--especially
+       with functions like Printv().
+
 *      Fix template partial specialization matching rules.   SWIG does not
        implement the proper C++ type deduction rules, but it does handle
        the most common cases.   This is likely to be hard and implementing
-       it is really only for completeness.
+       it would really only be for completeness.
 
+Build
+-----
+[DONE] Fix Python Windows examples.
+
+****   Upgrade libtool to a more recent version.  Might fix linking on OS-X
+       but should definitely help on Cygwin.
+
+****   Make sure there are tests for *ALL* library files in the test-suite.
+       A number of files appear to be broken in SWIG-1.3.13.
+
+***    Move the Source/Modules1.1 directory into the Source/Modules directory and
+       deprecate Modules1.1.
+
+*      Upgrade autoconf? This will definitely help for Windows. The later the
+       version the better.
+ 
 Library
 -------
 
@@ -124,11 +196,14 @@ Library
 
 ****   Continue to expand the set of recognized typemaps.
 
+All language modules
+--------------------
+[DONE] Convert use of char * to String *.   Suggest using Replaceall()
+       instead of Replace(..., DOH_REPLACE_ANY);
+
 Python
 ------
 
-****   Support for Python-2.2 style classes.
-
 ****   Ability to wrap certain classes as Python built-in types.
 
 Perl
@@ -152,32 +227,107 @@ Ruby
        to be changed for the wrapper code generated by SWIG. For background
        see ruby-talk messages 23358 and 38856 (and related threads).
 
+
+**     In a post to the SWIG users' mailing list (June 5: "Multiple Inheritance
+       and Ruby"), Brett Williams suggested a workaround for supporting
+       multiple inheritance in the Ruby module. I'm quoting it here since
+       the idea may be best implemented at the core level for reuse by other
+       language modules that have limited support for MI:
+
+       """
+       While it makes for longer generated wrapper code, you can easily
+       generate wrappers as Ruby methods on the derived class in these cases,
+       i.e.:
+
+	   class Base1;
+	   class Base2;
+	   class Derived : public Base1, public Base2;
+	   class OtherDerived : public Base2;
+
+       This would mean that for class Derived, the methods for Base2 would be
+       generated as methods on class Derived as opposed to a superclass. For
+       class OtherDerived, things work as normal, and any other derived class
+       from Base2 would still work as they currently are, unless other derived
+       classes also use MI. The exception and extra wrapper generation would
+       only kick in with the use of multiple inheritance where the base class
+       information is available to SWIG. 
+
+       The feature could be turned on and off, and doesn't have to be default
+       if necessary. 
+
+       I was under the impression that the Tcl module, until a few releases ago,
+       did all inheritance this way (generating wrappers for superclass methods
+       in all derived classes). It does bloat the wrapper code, but in this case
+       it would only be causing more bloat in cases where the alternative is
+       no support.
+
+       What is missing with this? Hmmmm... if Base2 implements a method that is
+       overridden by Derived, then you could not get at Base2::Method() via the
+       super keyword... what else am I missing? Again, the alternative is no
+       support for MI at all unless you want to get fancy with mixins. I'm not
+       sure how good of an idea that is or even if it is workable.
+       """
+       
+       Another problem (which we can't really get around anyways) is that
+       basic inheritance relationships wouldn't be true at the Ruby level,
+       e.g. Derived#is_a?(Base1) would return true but Derived#is_a?(Base2)
+       would return false.
+       
+**     A related suggestion from Brett Williams (and perhaps an alternative
+       to the previously described workaround for MI) is to provide a
+       variant of the %extend directive that allows you to pretend that these
+       functions should be treated as if they were in the class definition,
+       i.e.:
+
+	   %define ADD_ART_PROP_METHODS(classname)
+	   %extend classname {
+	     void AddArtProperty(const String &key, const String &val);
+	     String GetArtProperty(const String &key) const;
+	     const PropertyVector *GetArtProperties() const;
+	   };
+	   %enddef
+
+       As written, SWIG would expect you to have provided functions with
+       names classname_AddArtProperty(), etc. somewhere else in the wrapper
+       code. We'd prefer that it somehow knew to call the function directly.
+       
 *      Consider adding a switch to define everything in the global (Kernel)
        module instead of nested in a user-defined module, but only if
        it comes up.
 
 Java
 ----
-****   Improved pointer handling to take advantage of Java's static type
-       checking. Currently all pointers are a Java long and these could
-       be changed to use a Java class wrapper.
 
-****   Better support for global variables and functions when using proxy 
+*      Consider using typemaps for proxy class code generation. [partially
-       classes. They could be put into a global proxy class to improve on 
+       implemented]
-       current syntax:
-       A a = new A(module.global_function(b.getCPtrB()), true);
-       to use something like:
-       A a = Globals.global_function(b);
-
-***    Implement function overloading.
-
-***    Implement replacements for the deprecation of the %pragma directive.
-
-*      Consider using typemaps for proxy class code generation.
 
 PHP
 ---
 
+**     When returning wrapped objects via alternate constructors if that
+       pointer value already exists "out there" as a resource we should
+       use the same resource, we can't have multiple ref-counted resources
+       mapping to the same object in case it gets twice destroyed.  And check
+       if ref count destroying is even working, see smart_pointer_rename
+
+*      Work out how classes without even inherited constructors should
+       interact with the php "new <class>" notation.
+       See: abstract_inherit_wrap.cpptest
+
+[DONE] Work out when we can but shouldn't dispose of objects because the
+       creator will.  See %newobject in the docs.  Works automatically for
+       constructors and return-by-value.
+
+[DONE] Got class properties to work, and global vars to work both ways 
+       with _set and _get accessors
+
+**     Look at pass by point and passby ref,
+       Make sometype** to be auto allocated
+       Make sometype& and sometype* to be autoallocated IF THEY ARE NOT
+       ALREADY swigtype wrapped.
+
+*      Overloading, callbacks, really review to see what else is missed
+
 Guile
 -----
 
@@ -219,7 +369,8 @@ Guile
 	   void free_foo(struct foo *FREED);
 
 **     Make SWIG's types first-class by using a separate smob type for
-       SWIG type descriptors; enable reflection on types.
+       SWIG type descriptors; enable reflection on types.  (Maybe
+       GOOPS metaclasses?)
 
 **     Maybe communicate the type system between object modules via Scheme
        variables, rather than a shared object.
@@ -227,6 +378,18 @@ Guile
 Mzscheme
 --------
 
+Pike
+----
+
+*      Decide how to handle global variables (probably using something
+       like the Python module's cvar). Affects Examples/pike/simple.
+
+*      Decide how to handle static class member functions and member
+       variables.
+
+*      Should investigate the possibility of generating .cmod files
+       in addition to straight C/C++ code for extensions.
+
 Documentation
 -------------
 
@@ -242,3 +405,7 @@ Other
 -----
 
 ****   Bring Tiger's .NET/CLR module online.
+
+****   Learn more wicked Jazz chords.
+
+

swigweb/compare.ht

@@ -75,10 +75,17 @@ SWIG provides wrapping support for almost all of ANSI C++.
 </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
+wrapping of nested classes--a problem we're working on. SWIG also
 does not allow C++ virtual methods to be implemented in the
 target language (a subtle feature that might be useful in certain projects).
 
+<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:

swigweb/compat.ht

@@ -56,7 +56,7 @@ The following scripting languages were supported in the final SWIG 1.1 release.
 
 <ul>
 <li> Tcl 8.0 and newer versions.
-<li> Python 1.3 and newer.
+<li> Python 1.5 and newer.
 <li> Perl 5.003 or newer.
 </ul>
 

swigweb/copyright.ht

@@ -5,17 +5,42 @@ SWIG Copyright
 
 <pre>
 Simplified Wrapper and Interface Generator  (SWIG)
- 
-David Beazley
-Department of Computer Science        
-University of Chicago
-1100 E 58th Street
-Chicago, IL  60637
-beazley@cs.uchicago.edu
 
-SWIG 1.1 is distributed under the following license:
+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
@@ -45,4 +70,3 @@ 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>

swigweb/download.ht

@@ -35,13 +35,13 @@ Note : If you received SWIG on CD-ROM, you may want to upgrade to the latest rel
 
 <p>
 <a
-href="http://prdownloads.sourceforge.net/swig/swig-1.3.14.tar.gz">SWIG
+href="http://prdownloads.sourceforge.net/swig/swig-1.3.15.tar.gz">SWIG
-1.3.14</a> is the latest development release (2002/08/12). View the <a
+1.3.15</a> is the latest development release (2002/08/12). View the <a
 href="release.html">release notes</a>.  Windows users should download
 <a
-href="http://prdownloads.sourceforge.net/swig/swigwin-1.3.14.zip">swigwin-1.3.14</a>
+href="http://prdownloads.sourceforge.net/swig/swigwin-1.3.15.zip">swigwin-1.3.15</a>
 which includes a prebuilt executable. A Macintosh port
-(macswig-1.3.14) also may be available from the SourceForge <a
+(macswig-1.3.15) also may be available from the SourceForge <a
 href="http://sourceforge.net/project/showfiles.php?group_id=1645">releases</a>
 area.
 

swigweb/index.ht

@@ -40,6 +40,12 @@ development work.
 <p>
 <h3>News</h3>
 
+<p>
+<b>2002/09/10</b>
+<a href="http://prdownloads.sourceforge.net/swig/swig-1.3.15.tar.gz">SWIG-1.3.15</a> has been
+released.  This is mostly a bug-fix release for 1.3.14 that resolves a number
+of issues with template and namespace support.  Improvements to exception handling and overloading are also included.
+
 <p>
 <b>2002/08/12</b>
 <a href="http://prdownloads.sourceforge.net/swig/swig-1.3.14.tar.gz">SWIG-1.3.14</a> has been
@@ -48,6 +54,7 @@ full support for overloaded methods and functions, C++ smart pointers, and more.
 includes new language modules for Ocaml and XML as well as a variety of enhancements to
 existing modules.
 
+
 <p>
 <b>2002/07/19</b>
 Shibukawa Yoshiki is working on a Japanese translation of the SWIG documentation.  Check out