bumped version

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

1 files changed, 318 insertions, 0 deletions

diff --git a/CHANGES b/CHANGES
index 0765ef5b9..29f48a430 100644
--- a/CHANGES
+++ b/CHANGES
@@ -2,6 +2,324 @@ SWIG (Simplified Wrapper and Interface Generator)
 
 See CHANGES.current for current version.
 
+Version 1.3.24 (December 14, 2004)
+==================================
+
+12/12/2004: wuzzeb (John Lenz)
+            [Chicken] Fix a bunch of bugs relating to -proxy support
+	      + non-class variables now export properly using -proxy
+	      + static member functions now export properly using -proxy
+	      + member class variables now export properly using -proxy
+	      + added a -nounit argument, which does not export the (declare (unit ...))
+	      + correctly install swigclosprefix.scm
+	      + constants (enums, defines) now correcly export when using -proxy
+
+12/11/2004: wsfulton
+            configure fix for when more than one version of jni_md.h is found
+            in the Java include directory (was generating lots of sed error
+            messages).
+
+12/08/2004: wsfulton
+            [Java] Fixes to arrays_java.i so that one can apply the array
+            typemaps to functions taking pointers as input, eg
+
+                %include "arrays_java.i"
+                %apply int[] {int*};
+                void foo(int *a);
+
+12/05/2004: wsfulton
+            [Java] Director mods contributed by Scott Michel. New typemaps
+            directordisconnect and directordisconnect_derived for the 
+            swigDirectorDisconnect() method. Also fix to get the javapackage
+            typemap working again.
+
+12/05/2004: mmatus
+	    - Finishing the fixes for templates + default template
+	      args + specializations.
+
+            - [Python] Now we use the new templates + default template
+	      args in the std/STL library. That means the internal
+	      swig files are getting uglier since we now support the
+	      original declarations:
+
+	        template<class _Tp, class _Alloc = std::allocator< _Tp > >
+		class vector {
+		....
+		};
+	      	     
+                template<class _Key, class _Tp, class _Compare = std::less<_Key >,
+	        class _Alloc = std::allocator<std::pair<const _Key, _Tp > > >
+                class map {
+		....
+		};
+ 
+              and the user can use the %template directive as
+
+	        %template() std::vector<int>;
+	        %template() std::vector<int, std::allocator<int> >;
+	        %template() std::vector<int, MyAllocator<int> >;
+
+              Now we are closer to the cleaning/rewriting of the
+	      python std/STL support, such that we recover support for
+	      MSVC++ 6.0, and we can add support for other languages
+	      too.
+
+
+12/02/2004: wsfulton
+            [Java] Fix for directors when wrapping methods using a member enum
+            and typesafe/proper enums enabled.
+
+12/01/2004: mmatus
+	    - Fix typemaps to work with templates and default template
+	      args, ie
+
+	       template <class A, class B = int>
+               struct Foo {
+	       };
+
+	       %typemap(in) Foo<int> *{...}
+	       %typemap(out) Foo<int,int> *{...}
+
+	       Foo<int> * foo( Foo<int> *f1, Foo<int,int> *f2);
+
+	      now 'f1', 'f2' and the return value resolve the provided
+	      typemaps properly.
+
+	      This is highly needed for proper STL support, see new 
+	      std_basic_string.i, std_sstream.i, etc.
+
+	    - Added std_sstream.i, and fix std_basic_string.i to use
+	      the new typemaps + template def. arg mechanism. Also,
+	      added the needed std_alloc.i. Now, all the containers
+	      can be modified to support std::allocator, like in:
+	      
+	        template<class T, class A = std::allocator<T > >
+		class vector {
+		public:
+		....
+		};
+	      
+	      This change is only completed by now for basic_string.
+
+	    - Fix for smart pointers + members + extensions:
+
+	      %extend Foo {
+	        int extension(int i, int j) { return i; }
+		int extension() { return 1; }
+	      }
+
+	      %inline %{
+
+	      class Foo {
+	      public:
+		int y;
+		static const int z;
+	      };
+  
+	      class Bar {
+	        Foo *f;
+	      public:
+	        Bar(Foo *f) : f(f) { }
+		Foo *operator->() {
+		  return f;
+		}
+	      };
+
+	      now you can 
+	     
+	      f = Foo()
+	      f.y = 3
+	      a = f.z
+	      f->extension()
+ 
+	      b = Bar(f)
+	      b.y = 3
+	      a = b.z
+	      b->extension()
+
+	    - Other small errors fixes, mostly python.
+
+11/25/2004: wsfulton
+            [Java] Numerous director bug fixes so that the correct java types
+            and canonicalized types in the JNI code are emitted. Use of the
+            $javaclassname special variables in the director typemaps now
+            consistent with the non-director typemaps. The types used for 
+            typemap lookups are also corrected in a few places. If you 
+            previously had your own director typemaps, ensure they are using the
+            correct C++ type.
+
+            *** POTENTIAL INCOMPATIBILITY FOR JAVA DIRECTORS ***
+
+11/25/2004: wsfulton
+            const enum SWIGTYPE & typemaps added. These wrap const enum references
+            as if they were passed by value. Const enum references thus work the
+            same as const reference primitive types such as const double &, 
+            const int & etc. Typemaps added for Java, C#, Ruby, Tcl, Perl and Pike.
+
+11/25/2004: wsfulton
+            [Java, C#] New special variable: $*javaclassname, similar to $javaclassname
+            and $&javaclassname. The new one removes a pointer from the C type before
+            obtaining the Java class name. One or more of $javaclassname,
+            $&javaclassname or $*javaclassname may now appear in a typemap. Likewise for
+            C# using csclassname instead of javaclassname.
+
+11/25/2004: wsfulton
+            The last vestiges of enums being handled as integers removed from the
+            internals. The wrapper methods use the enum type rather than an int
+            now. The net result is added type safety for enums when handled as
+            pointers, references etc. Previously in situations such as a method
+            taking a pointer to an enum, a pointer to an int or a pointer to an
+            enum of some other type could inadvertantly be passed to the method.
+            This is now fixed as the descriptor for an enum is no longer based on
+            an int, but the enum type instead. Anonymous enums are still handled
+            as integers.
+
+            The consequence for scripting language users in correct usage of enums
+            should not be noticeable. There is no change for any of the languages
+            where enums are passed by value - most of the scripting languages will
+            still accept an integer for an enum value and the strongly typed
+            languages still use either typesafe enums, integers or proper enums
+            depending on what the user configures. For Java and C# users a change
+            in the typewrapper class name has occurred (for enum pointers,
+            references etc). For example:
+
+              enum Numbers { one=1, two };
+              enum Numbers* number();
+
+            In Java and C# this must now be coded as
+
+              SWIGTYPE_p_Numbers n = modulename.number();
+
+            rather than
+
+              SWIGTYPE_p_int n = modulename.number();
+
+            *** POTENTIAL INCOMPATIBILITY ***
+
+11/21/2004: wsfulton/mmatus
+            Added missing deprecated warning for %name and remove remaining %name
+            usage in the SWIG libraries.
+
+11/21/04: mmatus
+	    - [Python] Adding the PySwigObject to be used for carrying
+	      the instance C/C++ pointers. This is used instead of
+	      string and PyCObjects.
+
+	      The new PySwigObject is even safer than PyCObject, and
+	      more friendly than plain strings:
+
+	      now you can do
+
+	        print a.this
+		<Swig Object at _00691608_p_A>
+
+		print str(a.this)
+		_00691608_p_A
+
+		print long(a.this)
+		135686400
+
+		print "%s 0x%x" % (a.this, a.this)
+		_00691608_p_A 0x8166900
+
+	      the last one is very useful when debugging the C/C++
+	      side, since is the pointer value you will usually get
+	      from the debugger.
+
+	      Also, if you have some old code that uses the string
+	      representation "_00691608_p_A", you can use it now again
+	      using 'str(ptr)', or by calling 'str = PyObject_Str(obj)'
+	      in the C/C++ side.
+ 
+	      This change is mainly for nostalgic swig users that miss
+	      the string representation, but also allows to say again
+
+	        if a.this == b.this:
+		  return "a is b"
+
+	      and well, since the change were really simple, maybe in
+	      the future we will be able to do
+   
+		next = a.this + 1
+
+	      or add native python iteration over native C/C++ arrays,
+	      ie, no need to create/copy new tuples when returning and
+	      array or vector.
+
+	      Also, a PySwigPacked object was adding to carry a member
+	      method pointer, but this is probably a temporal solution
+	      until a more general object for methods is added.
+
+	      Be aware that to simplify maintaining and compatibility
+	      with other tools, the old string and PyCObjects
+	      representation could disappear very soon, and the
+	      SWIG_COBJECTS_TYPES or SWIG_NO_OBJECT_TYPES macros will
+	      have no effect at compilation time. Still, the three
+	      mechanisms are present in the code just for testing,
+	      debugging and comparison purposes.
+	      
+11/21/04: mmatus
+
+	    - [Python] Adding back support for using the swig runtime code
+	      inside the user code. We just allow the user to include
+	      the minimal code needed to implement the runtime
+	      mechanism statically, just as in done in the swig
+	      modules.
+	      
+	      To use the swig runtime code, for example with python,
+	      the user needs include the following:
+ 
+               #include <Python.h>         // or using your favorite language
+               #include <swigrun.swg>
+               #include <python/pyrun.swg> // or using your favorite language
+               #include <runtime.swg>
+
+	      the files swigrun.swg, pyrun.swg and runtime.swg can 
+	      be checked out by using swig -co, or they can simply 
+	      be found by adding the swig lib directory to the
+	      compiler include directory list, for example
+
+	       SWIGLIB=`swig -swiglib`
+	       c++ -I${SWIGLIB} ..
+
+	      of better, using the CPPFLAGS, but that depends on your
+	      environment.
+	       
+	      This change can be ported to the other languages too,
+	      you just need to isolate the needed runtime code in
+	      a single file like 'pyrun.swg', and provide the 
+	      SWIG_Runtime_GetTypeList() method. Look at the
+	      Lib/python/pyrun.swg file and the Examples/python/swigrun
+	      example.
+
+11/15/04: mmatus
+	    - Fix mixed_types.i + gcc-3.4, ie, arrays + references +
+	      typedefs
+
+	    - Fix multidim arrays + typedefs,ie
+
+	       typedef char character[1];
+	       typedef character word[64];
+
+	    - Process protected/private bases in the same way before
+	      we process protected/private members, ie, we check
+	      for constructors, operator new, virtual members, etc.
+   
+	    - Fix Ruby/Java to work (or ignore) multi-inheritance +
+              directors. Allow other languages to define if it is
+              supported or not.
+	    
+	    - Now you can run
+
+                SWIG_FEATURES="-directors -dirprot" 
+                make check-ruby-test-suite
+                make check-python-test-suite
+                make check-java-test-suite
+                make check-ocaml-test-suite
+
+	      and you will get only 'real' errors. ruby and python
+	      compile with no errors, java shows some problems.	
+
 Version 1.3.23 (November 11, 2004)
 =================================