1.3.22 update

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

ANNOUNCE

@@ -1,11 +1,11 @@
-*** ANNOUNCE: SWIG 1.3.20 ***
+*** ANNOUNCE: SWIG 1.3.22 ***
 
 http://www.swig.org
 
-December 17, 2003
+September 1, 2004
 
-We're pleased to announce SWIG 1.3.20, the latest installment in the
+We're pleased to announce SWIG-1.3.22, the latest installment in the
-SWIG development effort.  SWIG-1.3.20 includes a number of bug fixes
+SWIG development effort.  SWIG-1.3.22 includes a number of bug fixes
 and large number of enhancements throughout.
 
 What is SWIG?
@@ -22,15 +22,15 @@ Availability:
 -------------
 The release is available for download on Sourceforge at
 
-     http://prdownloads.sourceforge.net/swig/swig-1.3.20.tar.gz
+     http://prdownloads.sourceforge.net/swig/swig-1.3.22.tar.gz
 
 Within the next day, a Windows version will also be made available at
 
-     http://prdownloads.sourceforge.net/swig/swigwin-1.3.20.zip
+     http://prdownloads.sourceforge.net/swig/swigwin-1.3.22.zip
 
 Release numbers
 ---------------
-With SWIG1.3, we are adopting an odd/even version numbering scheme for
+With SWIG-1.3, we are adopting an odd/even version numbering scheme for
 SWIG.  Odd version numbers (1.3, 1.5, 1.7, etc...) are considered to
 be development releases.  Even numbers (1.4,1.6,1.8) are stable
 releases.  The current 1.3 effort is working to produce a stable 2.0
@@ -40,14 +40,14 @@ continue to make periodic 1.3.x releases.
 
 We need your help!
 ------------------
-Even if you are perfectly happy with SWIG1.1, we can still use your
+Even if you are perfectly happy with SWIG-1.1, we can still use your
 feedback.  First, we like to know about compilation problems and other
-issues concerning the building of SWIG.  Second, if SWIG1.3 is unable
+issues concerning the building of SWIG.  Second, if SWIG-1.3 is unable
 to compile your old interface files, we would like to get information
 about the features you are using.  This information will help us find
-bugs in the SWIG1.3 release, develop techniques for supporting
+bugs in the SWIG-1.3 release, develop techniques for supporting
 backwards compatibility, and write documentation that addresses
-specific issues related to migrating from SWIG1.1 to SWIG1.3.
+specific issues related to migrating from SWIG-1.1 to SWIG-1.3.
 
 We are also looking for volunteers who would like to work on various
 aspects of SWIG development.  SWIG is an unfunded project that would
@@ -55,21 +55,11 @@ not exist without volunteers.  We are also looking for the developers
 of other SWIG language modules.  If you have developed a SWIG module
 and would like to see it incorporated into the new release, please
 contact us to obtain SWIG-CVS access.  We are also more than willing
-to help port your module from SWIG1.1 to SWIG1.3.  Please send email
+to help port your module from SWIG-1.1 to SWIG-1.3.  Please send email
 to beazley@cs.uchicago.edu for further information.
 
-Please report problems with this release to swig-dev@cs.uchicago.edu.
+Please report problems with this release to the swig-dev mailing list,
+details at http://www.swig.org/mail.html.
 
 --- The SWIG Developers
 
-
-
-
-
-
-
-
-
-
-
-

CHANGES

@@ -1,5 +1,7 @@
 SWIG (Simplified Wrapper and Interface Generator)
 
+See CHANGES.current for current version.
+
 Version 1.3.21 (January 11, 2004)
 ==================================
 01/10/2004: cheetah (William Fulton)

CHANGES.current

@@ -1,4 +1,4 @@
-Version 1.3.22 (in progress)
+Version 1.3.22 (September 1, 2004)
 ==================================
 
 08/26/2004: wsfulton

FUTURE

@@ -320,7 +320,7 @@ we need your help.
    not as bad as one might imagine.
 
 -  We are always looking for developers.  Subscribe to
-   swig-dev@cs.uchicago.edu (http://mailman.cs.uchicago.edu/listinfo/swig-dev)
+   the swig-dev mailing list, details at http://www.swig.org/mail.html,
    or send me email to get involved.
 
 Acknowledgements

README

@@ -1,8 +1,6 @@
 SWIG (Simplified Wrapper and Interface Generator)
 
-Version: 1.3.21 (January 11, 2004)
+Version: 1.3.22 (September 1, 2004)
-
-$Header$
 
 Tagline: SWIG is a compiler that integrates C and C++ with
          languages including Perl, Python, Tcl, Guile, Mzscheme,
@@ -63,7 +61,7 @@ Information about SWIG is also available in Japanese translation at
 !!!!!!!                      IMPORTANT                         !!!!!!!
 !!!!!!!                                                        !!!!!!!
 !!!!!!! Previous SWIG users should read the documentation      !!!!!!!
-!!!!!!! file Doc/Manual/SWIG.html before trying to use SWIG1.3 !!!!!!!
+!!!!!!! file Doc/Manual/SWIG.html before trying to use SWIG-1.3!!!!!!!
 !!!!!!! on existing SWIG interfaces.  This is the most current !!!!!!!
 !!!!!!! documentation that describes new 1.3 features and      !!!!!!!
 !!!!!!! incompatibilities.                                     !!!!!!!
@@ -72,8 +70,30 @@ Information about SWIG is also available in Japanese translation at
 What's New?
 ===========
 
-SWIG-1.3.x offers a huge number of improvements over older SWIG-1.1 releases.
+SWIG-1.3.22 summary:
-These improvements include:
+- Improved exception handling and translation of C errors or C++
+  exceptions into target language exceptions.
+- Improved enum support, mapping to built-in Java 1.5 enums and C#
+  enums or the typesafe enum pattern for these two languages.
+- Python - much better STL suppport and support for std::wstring,
+  wchar_t and FILE *.
+- SWIG also supports Allegro CL now.
+- 64 bit TCL support.
+- Java and C#'s proxy classes are now nearly 100% generated from
+  typemaps and/or features for finer control on the generated code.
+- SWIG runtime library support deprecation.
+- Improved documentation. SWIG now additionally provides documentation
+  in the form of a single HTML page as well as a pdf document.
+- Enhanced C++ friend declaration support.
+- Better support for reference counted classes.
+- Various %fragment improvements.
+- RPM fixes.
+- Various minor improvements and bug fixes for C#, Chicken, Guile, Java, 
+  MzScheme, Perl, Php, Ruby and XML.
+
+
+The SWIG-1.3.x development releases offer a huge number of improvements
+over older SWIG-1.1 releases. These improvements include:
 
    - Support for C++ overloaded functions and methods.
    - Support for C++ smart pointers.
@@ -98,7 +118,7 @@ These improvements include:
 
 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
+   - The SWIG-1.1 documentation system is gone and hasn't been
      replaced yet.  This is on the long-term to-do list.
 
    - The Tcl7.x and Perl4 modules are deprecated and no longer
@@ -115,24 +135,33 @@ If you used SWIG-1.1, a number of old features are missing from SWIG-1.3.
      when it will return.
 
 Although we are making some attempt to preserve backwards
-compatibility with interfaces written for SWIG1.1, SWIG1.3
+compatibility with interfaces written for SWIG-1.1, SWIG-1.3
 incorporates a number of very substantial modifications to type
 handling, typemaps, and wrapper code generation.  Therefore, if you
 are making extensive use of advanced SWIG features, interfaces written
-for SWIG1.1 may not work.  We apologize for the inconvenience, but
+for SWIG-1.1 may not work.  We apologize for the inconvenience, but
 these changes are needed in order to fix a number of annoying
-"features" in SWIG1.1.  Hopefully the list of new features will
+"features" in SWIG-1.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).
 
-In addition, SWIG1.3 makes no attempt to be compatible with SWIG1.1 at
+In addition, SWIG-1.3 makes no attempt to be compatible with SWIG-1.1 at
-the C++ API level so language modules written for SWIG1.1 will most
+the C++ API level so language modules written for SWIG-1.1 will most
 definitely not work with this release.
 
+See the documentation for details of the SWIG_VERSION preprocessor
+symbol if you have backward compatibility issues and need to use more
+than one version of SWIG.
+
 The files NEW and CHANGES describe in some detail all of the important
 changes that have been made to the system.  Experienced users would be
 well advised to read this.
 
+Release Notes
+=============
+Please see the CHANGES files for a detailed list of bug fixes and
+new features. The ANNOUNCE file has a summary of the changes.
+
 Windows Installation
 ====================
 Please see the Doc/Manual/Windows.html file for instructions on installing
@@ -169,26 +198,18 @@ The file INSTALL details more about using configure. Also try
 
      % ./configure --help.
 
-The configure script will attempt to locate various packages on your
+The configure script will attempt to locate various packages on your machine
-machine, including Tcl, Perl5, Python and other target languages that SWIG
+including Tcl, Perl5, Python and all the other target languages that SWIG
 uses.  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 without having to hack Makefiles.
 
-SWIG includes an optional set of runtime libraries that are sometimes used
+SWIG used to include a set of runtime libraries for some languages for working
-when working with multiple modules.  By default, these aren't built due to
+with multiple modules. These are no longer built during the installation stage.
-the wide variety of target languages, compilers, compiler flags, and other
+However, users can build them just like any wrapper module as described in
-configuration information that impacts the way that they have to be built.
+the documentation, Doc/Manual/Modules.html. The CHANGES file also lists some
-However, if you want to build the runtime libraries in their "default" 
+examples which build the runtime library.
-configuration, type this:
-
-     % make -k runtime
-     % make install-runtime
-
-The libraries aren't needed to use SWIG or to run most of the
-examples.  Therefore, you may want to skip this step until you've read
-the documentation located in Doc/Manual/Modules.html.
 
 Notes:
 
@@ -258,17 +279,13 @@ The Examples directory contains a variety of examples of using SWIG
 and it has some browsable documentation.  Simply point your browser to
 the file "Example/index.html".
 
-The Examples directory now includes Visual C++ project (.dsp) files for
+The Examples directory also includes Visual C++ project (.dsp) files for
-building some of the examples on Windows (new in SWIG1.3.7).
+building some of the examples on Windows.
 
 Known Issues
 ============
-The SWIG-1.3.15 release includes a number of substantial changes to existing
+There are minor bugs, details of which are in the bug tracker, see
-language modules.  These changes include modifications to the build environment
+http://www.swig.org/bugs.html.
-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
 ===============
@@ -305,12 +322,16 @@ http://www.signal6.com/cgi-bin/wiki.pl.
 Documentation
 =============
 The Doc/Manual directory contains the most recent set of updated
-documentation for this release.  As this is a development release, the
+documentation for this release.  The documentation is available in
-documentation is not entirely up to date and is being worked on.  We
+a single page html format, multiple page html format or pdf format,
-are working on it, but there is a lot of old documentation and it is going
+see Doc/Manual/index.html.
-to take time to complete. Please be patient or volunteer to help.
 
-!! The most up-to-date information concerning new features in SWIG1.3 is the
+This is a development release and the documentation is largely, but 
+not entirely up to date.  We are working on it, but there
+was a lot of old documentation and it is taking some time to
+update and complete. Please be patient or volunteer to help.
+
+!! The most up-to-date information concerning new features in SWIG-1.3 is the
 !! file Doc/Manual/SWIG.html.
 
 There is some technical developer documentation available in the
@@ -324,7 +345,8 @@ have access to a limited variety of hardware (Linux, Solaris, OS-X,
 and Windows). All contributions help.
 
 If you would like to join the SWIG development team or contribute a
-language module to the distribution, please contact swig-dev@cs.uchicago.edu.
+language module to the distribution, please contact the swig-dev
+mailing list, details at http://www.swig.org/mail.html.
 
  -- The SWIG Maintainers
 

TODO

@@ -1,6 +1,6 @@
 SWIG TO-DO
 
-Release: SWIG-1.3.20
+Release: SWIG-1.3.22
 
 $Header$
 -----------------------------------------------------------------------------
@@ -31,36 +31,7 @@ defer  ready to go.  The primary obstacle lies in the target language
 
 ****   Typemap environments.  Stay tuned.
 
-[DONE] Merge "in" and "ignore" typemaps into a single "in" typemap.
+[DONE] Implement "throws" typemaps for all of the target languages.
-       This would solve a variety of subtle problems with multiple
-       argument typemaps and other typemap code.   I propose to merge
-       the typemaps by making "ignore" a typemap attribute.
-       For example:
-
-           %typemap(in,ignore="1") int *OUTPUT (int temp) {
-                $1 = &temp;
-           }
-
-       This merging makes a lot of sense because "in" and "ignore"
-       typemaps both deal with input argument handling and they are
-       meant to be mutually exclusive of each other.   By unifying
-       into a single typemap, you fix the mutual exclusion problem
-       (since there is only one typemap).  I also think it makes
-       more sense to think of an "ignored" argument as a input value
-       property.
-
-       Update: Matthias proposes a generalization in which the
-       number of input arguments could be specified.  For example:
-
-           %typemap(in,numinputs="0") int *OUTPUT (int temp) {
-                $1 = &temp;
-           }
-
-       This seems to be a better solution.
-
-
-****   Implement "throws" typemaps for all of the target languages.
-       Partly implemented for Tcl, Perl, Python, Ruby, Java.
 
 ***    "Nested" typemaps. The basic idea is similar to allowing one to 
        use $descriptor(T) for any T, rather than just $descriptor
@@ -167,38 +138,6 @@ defer  ready to go.  The primary obstacle lies in the target language
 
        [ Partially finished for Tcl/Python. ]
 
-[DONE] Modify smart pointer handling to properly handle inheritance.  For
-       example:
-
-            %ignore Foo;
-
-            class Foo {
-            public:
-                Blah *operator->();
-            };
-
-            class Bar : public Foo {
-            }
-
-       Bar should still allow access to Blah * through operator->().
-
-[DONE] 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.
-
-       This feature is now enabled using the -fvirtual option.
-
 **     Restoration of the documentation system.
 
 **     Restoration of Objective-C support.
@@ -223,9 +162,6 @@ Build
 ****   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.
 
-[DONE] Move the Source/Modules1.1 directory into the Source/Modules directory
-       and deprecate Modules1.1.
-
 Library
 -------
 
@@ -237,9 +173,6 @@ Library
 Windows
 -------
 
-[DONE] Visual C++ Project files / Makefiles for building the runtime libraries.
-       Will require libtool mods to work under Cygwin.
-
 All language modules
 --------------------
 
@@ -272,68 +205,11 @@ Ruby
        acquire() methods to change this ownership status. Need to
        address this for Ruby as well.
 
-[DONE] Investigate the new object allocation framework that has been
-       implemented for Ruby 1.8 and determine what (if anything) needs
-       to be changed for the wrapper code generated by SWIG. For background
-       see ruby-talk messages 23358 and 38856 (and related threads).
-
 ***    Add support for keyword arguments (by collecting them in a hash?).
 
-[DONE] Add support for defining nested modules. This should work like it does
-       for the SWIG Perl module.
-
-[DONE] 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.
-
 *      Add some special directives to automatically rename declarations to
        or from CamelCase.
 
-[DONE] 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
 ----
 
@@ -341,28 +217,19 @@ Java
        at present. An overridden method for each default argument could be 
        generated thereby enabling one to call methods with default arguments.
 
-[DONE] Implement idea from Dave Dribin email to the swig mailing list, 2 April 2003, 
-       where the global enums and constants are placed in an interface so that they 
-       can be implemented by other Java classes. This will allow improved syntax when
-       referring to the enums/constants:
-         int foo = enumname;
-       instead of
-         int foo = ModuleName.enumname;
-
 C#
 --
 
-[DONE] Need a way to throw a C# exception from the PINVOKE C/C++ code.
-
-[DONE] The correct override/virtual keywords not always emitted for polymorphic
-       methods. It currently works with 'virtual' is specified in a derived 
-       C++ class function. A polymorphic method need not specify 'virtual' in C++.
-
 [DONE] Wrap C/C++ enums with C# enums, currently they are wrapped with a C# int.
 
 ****   Implement director support for C# so that virtual methods work seemlessly
        when mixing C# and C++ code.
 
+****   Fix exception handling. Currently memory leaks occur when a C# exception
+       is thrown from C/C++.
+
+****   Default argument support - see Java above.
+
 PHP
 ---