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

update to 1.3.15

Browse source 
git-svn-id: https://swig.svn.sourceforge.net/svnroot/swig/trunk/SWIG@3837 626c5289-ae23-0410-ae9c-e8d60b6d4f22
This commit is contained in:
Dave Beazley 2002-09-10 20:01:45 +00:00
commit 8eb3766522
3 changed files with 332 additions and 158 deletions
Download patch file Download diff file Expand all files Collapse all files

55
LICENSE
View file

@ -1,37 +1,37 @@
SWIG is distributed under the following terms:
I.
I.
Copyright (C) 1998-2000
The University of Chicago
This software includes contributions that are Copyright (c) 1998-2002
University of Chicago.
All rights reserved.
Permission is hereby granted, without written agreement and without
license or royalty fees, to use, copy, modify, and distribute this
software and its documentation for any purpose, provided that
(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.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are
met:
IN NO EVENT SHALL THE AUTHOR, THE UNIVERSITY OF CHICAGO, OR
DISTRIBUTORS OF THIS SOFTWARE BE LIABLE TO ANY PARTY FOR DIRECT,
INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES ARISING OUT OF
THE USE OF THIS SOFTWARE AND ITS DOCUMENTATION, EVEN IF THE AUTHORS OR
ANY OF THE ABOVE PARTIES HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH
DAMAGE.
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.
THE AUTHOR AND THE UNIVERSITY OF CHICAGO SPECIFICALLY DISCLAIM ANY
WARRANTIES,INCLUDING, BUT NOT LIMITED TO, 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.
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.
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.

134
README
View file

@ -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
Kovuk, Gary Holt, David Fletcher, Oleg Tolmatcev, Harco de Hilster.
(See CHANGES for a more complete list).
Clark McGrew, Dustin Mitchell, Ian Cooke, Catalin Dumitrescu, Baran
Kovuk, Gary Holt, David Fletcher, Oleg Tolmatcev, Harco de Hilster.
(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
and by the Python module.
- Improved support for pointers to functions and callbacks.
- SWIG now has a full C preprocessor with macro expansion.
- A full C preprocessor with macro expansion.
Includes C99 variadic macro support.
- Code generation for the Tcl and Python modules has been
substantially improved both in terms of size and runtime
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.
- Java, Ruby, MzScheme, PHP4, OCAML, Pike, and XML modules added.
Guile module improved.
- 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
as 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 these changes are needed in order to fix a number of annoying
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
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
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
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.
Testing
=======
If you want to test SWIG before installation, type the following:
(3) 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.
% make -k check
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.
'make -k check' requires at least one of the target languages to be
installed. If it fails, it may mean that you have an uninstalled
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 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.

301
TODO
View file

@ -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
of the very high-level API. Issues:
[DONE] Refinement of the overloading dispatch rules. If you have two
classes like this:
- Language modules should be created by a factory function
with C linkage. For example:
class Foo {
};
Language *PYTHON_init() {
return new PYTHON();
}
class Bar : public Foo {
};
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.
and two overloaded methods:
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.
void spam(Foo *f);
void spam(Bar *b);
- 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.
SWIG should make sure that the derived class version is checked
first.
- Does anyone inherit from existing modules?
[DONE] Refinement of using directives. For example:
*** 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.
namespace foo {
int blah(int);
}
*** 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:
namespace bar {
double blah(double);
}
class FooProxy {
...
Foo *operator->();
...
};
using foo::blah;
using bar::blah;
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:
Currently, SWIG reports an error (redefined symbol). Instead, it should be
silent.
FooProxy *arg1; // Object pointer (to proxy)
(*arg1)->bar();
^
extra "*" added here.
It's not entirely clear what should happen in terms of overloading. Currently,
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).
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
requiring the use of a special directive.
[DONE] Modify exception handling code not to apply to attribute access. Should
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
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.
* Consider using typemaps for proxy class code generation. [partially
implemented]
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.