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

bumped version

Browse source 
git-svn-id: https://swig.svn.sourceforge.net/svnroot/swig/trunk@6886 626c5289-ae23-0410-ae9c-e8d60b6d4f22
This commit is contained in:
William S Fulton 2004-12-15 00:13:07 +00:00
commit 2cde33a9ab
4 changed files with 322 additions and 318 deletions
Download patch file Download diff file Expand all files Collapse all files

318
SWIG/CHANGES
View file

@ -2,6 +2,324 @@ SWIG (Simplified Wrapper and Interface Generator)
See CHANGES.current for current version. 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) Version 1.3.23 (November 11, 2004)
================================= =================================

318
SWIG/CHANGES.current
View file

@ -1,317 +1,3 @@
Version 1.3.24 (December 14, 2004) Version 1.3.25 (In progress)
================================== ============================
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.

2
SWIG/Doc/Manual/Sections.html
View file

@ -6,7 +6,7 @@
<body bgcolor="#ffffff"> <body bgcolor="#ffffff">
<H1><a name="Sections"></a>SWIG-1.3 Development Documentation</H1> <H1><a name="Sections"></a>SWIG-1.3 Development Documentation</H1>
Last update : SWIG-1.3.24 (December 14, 2004) Last update : SWIG-1.3.25 (?????? ??, 2004)
<H2>Sections</H2> <H2>Sections</H2>

2
SWIG/configure.in
View file

@ -2,7 +2,7 @@ dnl Process this file with autoconf to produce a configure script.
dnl The macros which aren't shipped with the autotools are stored in the dnl The macros which aren't shipped with the autotools are stored in the
dnl Tools/config directory in .m4 files. dnl Tools/config directory in .m4 files.
AC_INIT([swig],[1.3.24],[http://www.swig.org]) AC_INIT([swig],[1.3.25],[http://www.swig.org])
AC_PREREQ(2.54) AC_PREREQ(2.54)
AC_CONFIG_SRCDIR([Source/Swig/swig.h]) AC_CONFIG_SRCDIR([Source/Swig/swig.h])
AC_CONFIG_AUX_DIR([Tools/config]) AC_CONFIG_AUX_DIR([Tools/config])