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

update to 1.3.13

Browse source 
git-svn-id: https://swig.svn.sourceforge.net/svnroot/swig/trunk@2979 626c5289-ae23-0410-ae9c-e8d60b6d4f22
This commit is contained in:
Dave Beazley 2002-06-17 20:28:59 +00:00
commit 3f3189026c
5 changed files with 447 additions and 76 deletions
Download patch file Download diff file Expand all files Collapse all files

208
SWIG/CHANGES
View file

@ -14,6 +14,214 @@ http://www.math.uni-magdeburg.de/~mkoeppe/imo-debian
Eventually this branch will be merged back to the trunk of the CVS
tree (maybe).
Version 1.3.13 (June 17, 2002)
==============================
06/16/2002: beazley
Fixed a bug with __FILE__ expansion in the preprocessor. On Windows,
the backslash (\) is now converted to (\\) in the string literal
used for __FILE__. Reported by Steve Glaser.
06/14/2002: beazley
Fixed warning message about 'name private in this context'. The
warning is only generated for public methods. Reported by
Scott Michel.
06/14/2002: beazley
Fixed some problems related to template instantiation
and namespaces. When SWIG expands a template, it does
so with fully resolved types. For example, if you have this:
template<class T> class foo { };
typedef double Double;
%template(foo_d) foo<Double>;
then, it is handled as foo<double> in the typesystem.
This fixes a number of subtle problems with inheritance
and templates.
06/14/2002: ljohnson (Lyle Johnson)
[Ruby] Added missing bool typemaps for INPUT, OUTPUT and
INOUT in Lib/ruby/typemaps.i.
05/29/2002: cheetah (William Fulton)
[Java] Fix for a couple of broken pragmas.
05/29/2002: cheetah (William Fulton)
Fix for unnecessary cast when wrapping global variable where
the type is not parsed by SWIG - Java variables example
failure as reported by Larry Virden.
06/10/2002: beazley
Modified %template to allow for empty instantiations.
%template() foo<int,int>;
This registers foo<int,int> with the type system, but
doesn't wrap it (same as %ignore). This may only be a
temporary measure. SWIG might be able to automatically
instantiate templates in certain cases.
06/10/2002: beazley
Fixed function prototype problems with Tcl 8.4
06/09/2002: beazley
Fixed problem with templates and location of base classes.
This one is a little mind-bending, but here is an example
that illustrates:
template <class ArgType, class ResType>
struct traits
{
typedef ArgType arg_type;
typedef ResType res_type;
};
template <class ArgType, class ResType>
struct Function
{
};
template <class AF, class AG>
struct Class : Function<typename traits<AF, AG>::arg_type,
typename traits<AF, AG>::res_type>
{
};
%template(traits_dd) traits <double, double>;
%template(Function_dd) Function <double, double>;
%template(Class_dd) Class <double, double>;
In this example, the base class of 'Class' is determined from
the Function template, but the types are obtained through typedefs.
Because of this, SWIG could not locate the wrapped base class
(Function<double,double>). Should be fixed in 1.3.13 even
though I can think of a million other things that might
also be broken.
06/07/2002: beazley
Fixed a problem with conversion operators. If you had an
operator like this,
operator double() const;
SWIG was ommitting the "const" qualifier. This affected
%rename and other directives. Reported by Zhong Ren.
06/07/2002: beazley
Lessened the strictness of abstract class checking. If
you have code like this:
class Foo {
public:
virtual int method() = 0;
};
class Bar : public Foo {
public:
Bar();
~Bar();
};
SWIG will go ahead and generate constructor/destructors
for Bar. However, it will also generate a warning message
that "Bar" might be abstract (since method() isn't defined).
In SWIG-1.3.12, SWIG refused to generate a constructor at all.
06/07/2002: beazley
Change to %template directive. If you specify something like this:
%template(vi) std::vector<int>;
It is *exactly* the same as this:
namespace std {
%template(vi) vector<int>;
}
SWIG-1.3.12 tried to instantiate the template outside of the namespace
using some trick. However, this was extremely problematic and full
holes. This version is safer.
06/07/2002: beazley
Fixed bug with scope qualification and templates. For example:
A<B::C>::DD
Before, this was separated as scopes A<B, C>, and DD. Fixed now.
06/06/2002: beazley
Allow the following syntax:
class A { };
struct B : A { ... };
A base class without a specifier is assumed to be public for a struct.
06/06/2002: beazley
Fixed syntax error with template constructor initializers.
Reported by Marcelo Matus.
06/06/2002: beazley
Fixed bug with default template arguments.
Reported by Marcelo Matus.
06/05/2002: beazley
Fixed subtle problems with %rename directive and template
expansion.
Code like this should now work:
%rename(blah) foo<double>::method;
...
template<class T> class foo {
public:
void method();
};
%template(whatever) foo<double>;
06/05/2002: beazley
Resolved some tricky issues of multi-pass compilation and
and inheritance. The following situation now generates
an error:
class Foo : public Bar {
...
};
class Bar {
...
};
The following code generates a warning about incomplete classes.
class Bar;
class Foo : public Bar { };
The following code generates a warning about an undefined class.
class Foo : public Bar { }; // Bar undefined
This fixes a failed assertion bug reported by Jason Stewart.
06/05/2002: ljohnson
[Ruby] Added a warning message for the Ruby module about the lack
of support for multiple inheritance. Only the first base class
listed is used and the others are ignored. (Reported by Craig
Files).
06/03/2002: beazley
Fixed a bug with struct declarations and typedef. For example:
typedef struct Foo Foo;
struct Foo {
...
};
A few other subtle struct related typing problems were
also resolved.
Version 1.3.12 (June 2, 2002)
=============================

19
SWIG/README
View file

@ -1,6 +1,6 @@
SWIG (Simplified Wrapper and Interface Generator)
Version: 1.3.12 (June 2, 2002)
Version: 1.3.13 (June 17, 2002)
$Header$
@ -23,7 +23,7 @@ working on this are:
Loic Dachary (loic@ceic.com) (Perl5)
Jason Stewart (jason@openinformatics.com) (Perl5)
Thien-Thi Nguyen (ttn@glug.org) (Testing/Misc)
Lyle Johnson (ljohnson@resgen.com) (Ruby)
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)
@ -153,7 +153,6 @@ To build and install SWIG, simply type the following:
% ./configure
% make
% make runtime # Optional (See note 4 below)
% make -k check # This step is optional (see note 3 below)
% make install
@ -163,7 +162,6 @@ to ./configure. For example:
% ./configure --prefix=/home/yourname/projects
% make
% make runtime
% make -k check
% make install
@ -209,13 +207,6 @@ Notes:
does not support member templates). These errors are harmless if you
don't intend to use these features in your own programs.
(4) The 'make runtime' target builds the SWIG runtime libraries. These
are needed if you plan to build applications that might involve more
than one SWIG generated module. This step requires that shared libraries
be properly configured on your machine and it may not work on all
platforms. If this step fails, SWIG will still work, but multi-module
support will be broken. Please let us know if this fails on your platform.
Examples
========
The Examples directory contains a variety of examples of using SWIG
@ -268,9 +259,9 @@ 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
!! file Doc/Manual/SWIG.html.
There is some technical documentation available in the Doc/Devel
subdirectory. This is not necessarily up-to-date, but it has some
information on SWIG internals.
There is some technical developer documentation available in the
Doc/Devel subdirectory. This is not necessarily up-to-date, but it
has some information on SWIG internals.
Participate!
============

274
SWIG/TODO
View file

@ -1,78 +1,244 @@
-*- outline -*-
SWIG TO-DO
* for release 1.3.8 (or 1.4.0?)
Release: SWIG-1.3.14 (Late July, 2002)
-----------------------------------------------------------------------------
** Revive the documentation
**** = High Priority
*** = Implement if possible.
** = Will implement if time.
* = Implement if bored (or deemed necessary).
** Maybe port Wrapper DOH-ification from CVS head
CORE:
** Fix all the bugs on SourceForge
**** Add support for nested classes. The type system should be
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:
** Add facilities to attach documentation strings to procedures.
There is a patch by twburton on SF for the Python language module,
but it needs to be done for all language modules.
struct Foo {
struct {
int x,y;
} z;
};
** Add support for type annotations, see mkoeppe's message:
http://mailman.cs.uchicago.edu/pipermail/swig/2001-June/002652.html
This is one of the last remaining "hard" problems in the SWIG
core, but it is important that we solve it.
* for the unstable 1.5 series
**** Better modularization of language modules and a minor redesign
of the very high-level API. Issues:
** Maybe use libtool rather than all the home-grown compile/link stuff
- Language modules should be created by a factory function
with C linkage. For example:
** The behavior of SWIG with respect to call/return-by-value needs
to be verified for all language modules. Previously, the
parser automatically performed the conversion of pass-by-value
to pass-by-reference. Unfortunately, this confused typemap
handling and other aspects of the system. I have removed
this behavior. However, in doing so, the handling of user
defined types is passed on to the language modules.
Language *PYTHON_init() {
return new PYTHON();
}
** All of the SWIG 1.1p5 examples need to be verified. Changes
in type handling and internal data structures may have broken
a variety of things.
swigmain.cxx should then be modified to only use the factory
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.
** [Guile] Rename slot setters from CLASS-SLOT-set to CLASS-SLOT-set!
Placing C linkage on the initialization function provides
support for eventual dynamic loading of SWIG modules--it
establishes a well-known symbol name that can be used in
conjunction with the dynamic loader.
** [Guile] Maybe support keyword args
- Perhaps the module system would be simplified by having
all code located in a single file instead of a separate
header file and a separate implementation file.
** [Guile] Maybe support GOOPS shadow classes
- Does anyone inherit from existing modules?
** [Guile] Support garbage collection.
*** Support for overloaded functions. It is probably possible to
add some kind of support for this. Overloading has been supported
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.
*** %new annotation decides whether a pointer smob can be gc'ed.
*** Support for smart-pointers and proxies. This is primarily to
support classes that implement the -> operator and which are used
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:
*** New smob type `swig-gc'; instances created with
SWIG_Guile_MakeCollectablePtr. %new versions of the pointer
typemaps use this function rather than SWIG_Guile_MakePtr.
class FooProxy {
...
Foo *operator->();
...
};
*** New typemaps "destructor", "gcmarker". Their values are taken as
identifiers for functions taking one argument: a pointer to the
object to be destroyed, or whose SCM-valued subobjects are to be
marked. After creating the pointer equivalence table, we iterate
again over the remembered pointer types, emitting code that puts
the functions into our type table. No additional functions are
generated.
Perhaps SWIG could automagically locate Foo and arrange for its
methods to be associated with FooProxy. This is really not too
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:
*** The default for all pointer types would be:
%typemap(destructor) SWIGPOINTER * "free";
FooProxy *arg1; // Object pointer (to proxy)
(*arg1)->bar();
^
extra "*" added here.
*** A special annotation, e.g. FREED, can be attached to the arguments
of destructor functions, so that explicitly freed structs won't be
collected by the GC again. Like this:
I think automatic wrapping of methods would be much nicer than
requiring the use of a special directive.
%typemap(argout) SWIGPOINTER *FREED {
smob-tag($source) = swig; /* non-gc */
smob-data($source) = NULL;
}
void free_foo(struct foo *FREED);
** Make a tricky header file defining annotations invisible to the C compiler.
The idea is to prepare one file that serves both as a C header file
and a SWIG interface file.
*** Rewrite declaration annotation to better unify %rename and related
directives. Add a selector mechanism that allows specific parse tree
nodes to be identified. For example:
void add(SWIG_OUTPUT(int) *z, int x, int y)
%feature("foo", nodetype="class") Foo { ... some code ... };
** Unify Guile and MzScheme support, add support for more Scheme systems.
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
management. Continue to consolidate SWIG directives to %feature.
** [Guile]: Make SWIG's types first class.
*** Bring Aquinas' contract/assertion checking code online.
*** Add more intelligent information related to object ownership.
SWIG should be able to automatically strip ownership from
objects when they are assigned to pointer variables and structure
members as well as stored in a container (i.e., an array of pointers).
** Restoration of the documentation system.
** Restoration of Objective-C support.
** Unification of symbol tables and type system scopes. In a sense
they capture the same information so it is not necessary to have
both. The existence of two symbol management systems is mostly
historical.
* 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.
Library
-------
**** Add more support for the C++ standard library. std::complex and other
core datatypes. Refine support for STL vector. Add more STL objects.
**** Continue to expand the set of recognized typemaps.
Python
------
**** Support for Python-2.2 style classes.
**** Ability to wrap certain classes as Python built-in types.
Perl
----
**** Rewrite runtime pointer type checking to better integrate
shadow classes. Creation of shadow classes should be done
in C instead of Perl. This will fix a number of problems
related to typemaps and reduce the amount of Perl wrapper code.
**** Create tests for existing support for operator overloading
Tcl
---
Ruby
----
**** 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).
* 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
classes. They could be put into a global proxy class to improve on
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
---
Guile
-----
** Rename slot setters from CLASS-SLOT-set to CLASS-SLOT-set!
to match Scheme convention for naming of mutators.
** Support keyword args.
** Support GOOPS shadow classes.
** Support garbage collection. Here is a possible design:
-- %new annotation decides whether a pointer smob can be gc'ed.
-- New smob type `swig-gc'; instances created with
SWIG_Guile_MakeCollectablePtr. %new versions of the pointer
typemaps use this function rather than SWIG_Guile_MakePtr.
-- New typemaps "destructor", "gcmarker". Their values are taken
as identifiers for functions taking one argument: a pointer to
the object to be destroyed, or whose SCM-valued subobjects are
to be marked. After creating the pointer equivalence table,
we iterate again over the remembered pointer types, emitting
code that puts the functions into our type table. No
additional functions are generated.
-- The default for all pointer types would be:
%typemap(destructor) SWIGPOINTER * "free";
(or "delete" for C++)
-- A special annotation, e.g. FREED, can be attached to the
arguments of destructor functions, so that explicitly freed
structs won't be collected by the GC again. Like this:
%typemap(argout) SWIGPOINTER *FREED {
smob-tag($source) = swig; /* non-gc */
smob-data($source) = NULL;
}
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.
** Maybe communicate the type system between object modules via Scheme
variables, rather than a shared object.
Mzscheme
--------
Documentation
-------------
**** Extending SWIG (and internals).
*** Perl, Python, Tcl modules.
*** add section for Perl module support for operator overloading
** Add section on WAD.
Other
-----
**** Bring Tiger's .NET/CLR module online.

16
swigweb/download.ht
View file

@ -33,19 +33,15 @@ Note : If you received SWIG on CD-ROM, you may want to upgrade to the latest rel
<h3> The Latest Release </h3>
<b>Note (2000/01/18) </b>SWIG1.1p5 has a number of compilation issues
with ANSI C++ compilers and will probably generate a lot of compiler
warnings. Sorry.
<p>
<a
href="http://prdownloads.sourceforge.net/swig/swig-1.3.12.tar.gz">SWIG
1.3.12</a> is the latest development release (2002/06/02). View the <a
href="http://prdownloads.sourceforge.net/swig/swig-1.3.13.tar.gz">SWIG
1.3.13</a> is the latest development release (2002/06/17). View the <a
href="release.html">release notes</a>. Windows users should download
<a
href="http://prdownloads.sourceforge.net/swig/swigwin-1.3.12.zip">swigwin-1.3.12</a>
href="http://prdownloads.sourceforge.net/swig/swigwin-1.3.13.zip">swigwin-1.3.13</a>
which includes a prebuilt executable. A Macintosh port
(macswig-1.3.12) also may be available from the SourceForge <a
(macswig-1.3.13) also may be available from the SourceForge <a
href="http://sourceforge.net/project/showfiles.php?group_id=1645">releases</a>
area.
@ -53,6 +49,10 @@ area.
<a href="http://prdownloads.sourceforge.net/swig/swig1.1p5.tar.gz">SWIG 1.1p5</a>
is the latest stable release (1998/02/05).
<b>Note (2000/01/18) </b>SWIG1.1p5 has a number of compilation issues
with ANSI C++ compilers and will probably generate a lot of compiler
warnings. Sorry.
<p>
<a href="http://prdownloads.sourceforge.net/swig/swig1.1-883.tar.gz">SWIG1.1-883</a> is the last maintenance version of SWIG1.1 (December 1999). This isn't really a
"release", but the last nightly build that was completed before

6
swigweb/index.ht
View file

@ -37,6 +37,12 @@ an abundance of spare time.
<p>
<h3>News</h3>
<p>
<b>2002/06/17</b>
<a href="http://prdownloads.sourceforge.net/swig/swig-1.3.13.tar.gz">SWIG-1.3.13</a>
has been released. This is a more stable version of SWIG-1.3.12. If you downloaded
SWIG-1.3.12, you should upgrade.
<p>
<b>2002/06/02</b>
<a href="Doc1.3/index.html">Updated documentation</a> for SWIG-1.3.12 is online.