Version 1.3.26 (in progress) ============================ 08/16/2005: wsfulton [Perl] Bug #1254494 - Fix for global namespace pollution by perl header files (bool define) prevented STL headers from being used on some systems, eg Windows with Visual Studio. 08/16/2005: wsfulton [Java] Bug #1240937 - Redefinition of __int64 typedef for Intel compilers. 08/15/2005: wsfulton [Xml] Bug #1251832 - C++ template may generate invalid XML file 08/15/2005: wsfulton [Lua] Support added for Lua. Patch #1242772 from Mark Gossage. It supports most C/C++ features (functions, struct, classes, arrays, pointers, exceptions), as well as lots of documentation and a few test cases & examples. 08/14/2005: wsfulton [Xml] Fix incorrect xml escaping in base class name when base class is a template. 08/13/2005: efuzzyone [CLISP] Added support for handling enums. Does not adds the return type declaration to the function definition, if a function returns void. 08/09/2005: mkoeppe New language module, Common Lisp with UFFI, from Utz-Uwe Haus. 08/09/2005: mkoeppe Fix the Lisp s-expression output module; it no longer complains about "unknown targets". 07/27/2005: wsfulton Modifications to STL wrappers so that it is possible for a user's %exception directive to be applied to the STL wrapper methods. Previously the following global %exception directive would not be used on the wrapper methods: %exception { try { $action } catch (...) { // handle uncaught exceptions } } This has been implemented by replacing %exception directives for specific STL wrapper methods with an exception specification declared on the wrapper methods. throws typemaps are now supplied for handling the STL exception specification. These can also be easily overridden, for example the std::out_of_range exception, which is used a lot in the STL wrappers, can be customised easily: %include "std_vector.i" %typemap(throws) std::out_of_range { // custom exception handler } %template(VectInt) std::vector; 07/22/2005: efuzzyone [CLISP] The clisp module for SWIG: - It can only handle C, clisp currently does not supports ffi bindings to C++. - It has two options, (a) -extern-all this will generate wrappers for all functions and variablestions, (b) -generate-typedef this will generate wrappers "def-c-type" wrappers for typedefs - Can handle pointers to functions, complex types such as n-dimensional arrays of pointers of depth d - Generates wrappers for constants as well as variables - Correctly distinguishes between the declaration of variables in structures and functions - Creates a defpackage "declaration" with the module name as the package name, the created package exports both functions and variables - tries to guess when should a pointer variable be declared as c-ptr or c-pointer 07/22/2005: wsfulton [C#] Changes to support C# structs returned by value. The changes required are: - Using an optional 'null' attribute in the out typemap. If this attribute is specified, then it is used for the $null special variable substitution. - The ctype used in the C/C++ wrappers is no longer initialised to 0 on declaration. Both of these changes fix the situations where an attempt was made to assign 0 to the returned struct. Marshalling structs as value types still requires user defined typemaps. See documentation for an example. 07/22/2005: wsfulton [C#, Java] Fix SWIG_exception usage to work with compilers that don't support empty macro arguments. Unfortunately this fix will stop usage of SWIG_exception being used within typemaps that use "" or %{ %} delimeters, but continues to work with typemaps using {} delimeters. Please use the SWIG_CSharpSetPendingExceptionArgument or SWIG_JavaThrowException methods instead as SWIG_exception is really intended as a platform independent macro for the SWIG library writers. 07/16/2005: mkoeppe [Allegro CL] Use specific foreign types rather than (* :void). Use *swig-identifier-converter*. 06/27/2005: wsfulton Functions declared as 'extern' no longer have an additional function declaration added to the wrapper files. There are some cases where SWIG does not get this right, eg bug #1205859 (extern functions with default arguments declared in a namespace). Also SWIG cannot get non-standard calling conventions correct, eg Windows calling conventions are usually handled like this: %{ #define DLLIMPORT __declspec(dllimport) #define STDCALL __stdcall %} #define DLLIMPORT #define STDCALL %inline %{ DLLIMPORT extern STDCALL void function(int); %} SWIG incorrectly generates: extern void function(int); To which there is no solution as SWIG doesn't handle non-standard calling conventions. The extra 'extern' function that SWIG generates is superfluous unless a user has forgotten to add the function declaration into the wrappers. The -noextern commandline argument is now redundant and a new commandline argument -addextern can be used to obtain the original behaviour. This shouldn't be necessary unless the header file containing the function declaration was inadvertently not added to the wrappers. To fix this add the function declaration into your wrappers, For example, replace: extern void foo(int); with: %inline %{ extern void foo(int); %} *** POTENTIAL INCOMPATIBILITY *** 06/22/2005: wsfulton [C#, Java, Modula3, Ocaml] The intermediary function names have been changed when wrapping variables to match the other language modules so that %extend for a member variable works uniformly across all language modules, eg: %extend ExtendMe { Var; }; %{ void ExtendMe_Var_set(ExtendMe *, double) {...} double ExtendMe_Var_get(ExtendMe *) {...} %} The methods implementing the get/set used to be: %{ void set_ExtendMe_Var(ExtendMe *, double) {...} double get_ExtendMe_Var(ExtendMe *) {...} %} This also changes the name of variable wrapper functions when using -noproxy. The original names can be generated with the -oldvarnames commandline option. *** POTENTIAL INCOMPATIBILITY ***