diff --git a/LICENSE b/LICENSE index a22145a46..d74e17762 100644 --- a/LICENSE +++ b/LICENSE @@ -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. + diff --git a/README b/README index 20a3b0f86..a4fc5314c 100644 --- a/README +++ b/README @@ -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. diff --git a/TODO b/TODO index fde6502d2..f4e783b0f 100644 --- a/TODO +++ b/TODO @@ -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 " 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. + +