diff options
Diffstat (limited to 'CHANGES')
| -rw-r--r-- | CHANGES | 2140 |
1 files changed, 2140 insertions, 0 deletions
@@ -2,6 +2,2146 @@ SWIG (Simplified Wrapper and Interface Generator) See CHANGES.current for current version. +Version 1.3.28 (February 12, 2006) +================================== + +02/11/2006: mmatus + Fix many issues with line counting and error reports. + +02/11/2006: mmatus + [Python] Better static data member support, if you have + + struct Foo { + static int bar; + }; + + then now is valid to access the static data member, ie: + + f = Foo() + f.bar = 3 + + just as in C++. + + +02/11/2006: wsfulton + [Perl] + Fixed code generation to work again with old versions of Perl + (5.004 and later tested) + +02/04/2006: mmatus + [Python] Add the %extend_smart_pointer() directive to extend + SWIG smart pointer support in python. + + For example, if you have a smart pointer as: + + template <class Type> class RCPtr { + public: + ... + RCPtr(Type *p); + Type * operator->() const; + ... + }; + + you use the %extend_smart_pointer directive as: + + %extend_smart_pointer(RCPtr<A>); + %template(RCPtr_A) RCPtr<A>; + + then, if you have something like: + + RCPtr<A> make_ptr(); + int foo(A *); + + you can do the following: + + a = make_ptr(); + b = foo(a); + + ie, swig will accept a RCPtr<A> object where a 'A *' is + expected. + + Also, when using vectors + + %extend_smart_pointer(RCPtr<A>); + %template(RCPtr_A) RCPtr<A>; + %template(vector_A) std::vector<RCPtr<A> >; + + you can type + + a = A(); + v = vector_A(2) + v[0] = a + + ie, an 'A *' object is accepted, via implicit conversion, + where a RCPtr<A> object is expected. Additionally + + x = v[0] + + returns (and sets 'x' as) a copy of v[0], making reference + counting possible and consistent. + + %extend_smart_pointer is just a collections of new/old + tricks, including %typemaps and the new %implicitconv + directive. + +02/02/2006: mgossage + bugfix #1356577, changed double=>lua_number in a few places. + added the std::pair wrapping + +01/30/2006: wsfulton + std::string and std::wstring member variables and global variables now use + %naturalvar by default, meaning they will now be wrapped as expected in all languages. + Previously these were wrapped as a pointer rather than a target language string. + It is no longer necessary to add the following workaround to wrap these as strings: + + %apply const std::string & { std::string *} + + *** POTENTIAL INCOMPATIBILITY *** + +01/28/2006: mkoeppe + [Guile -scm] + Add typemaps for handling of member function pointers. + +01/24/2006: mmatus + - Better support for the %naturalvar directive, now it + works with the scripting languages as well as + Java/C#. + + Now, it can also be applied to class types: + + %naturalvar std::string; + %include <std_string.i> + + that will tell swig to use the the 'natural' wrapping + mechanism to all std::string global and member + variables. + + - Add support for the %allowexcept feature along the + scripting languages, which allows the %exception feature + to be applied to the variable access methods. Also, add + the %exceptionvar directive to specify a distintic + exception mechanism only for variables. + + + - Add more docs for the %delobject directive to mark a method as a + destructor, 'disowning' the first argument. For example: + + %newobject create_foo; + %delobject destroy_foo; + + Foo *create_foo() { return new Foo(); } + void destroy_foo(Foo *foo) { delete foo; } + + or in a member method as: + + %delobject Foo::destroy; + + class Foo { + public: + void destroy() { delete this;} + + private: + ~Foo(); + }; + + +01/24/2006: mgossage + [Lua] + - Removed the type swig_lua_command_info & replace with luaL_reg + (which then broke the code), fixed this + - added an additional cast in the typemaps for enum's + due to the issue that VC.Net will not allow casting of + a double to an enum directly. Therefore cast to int then to enum + (thanks to Jason Rego for this observation) + +01/16/2006: mmatus (Change disabled... will be back in CVS soon) + Add initial support for regexp via the external library + RxSpencer. SWIG doesn't require this library to compile + and/or run. But if you specify --with-rxspencer, and the + library is found during installation, then swig will use + it in three places: + + - In %renames rules, via the new rxsmatch rules, for example: + + %rename("%(lowercase)",rxsmatch$name="GSL_.*") ""; + %rename("%(lowercase)",rxsmatch$nodeType="enum GSL_.*") ""; + + rxsmatch is similar to the match rule, it just uses + the RxSpencer regexp library to decide if there is a + match with the provided regexp. As with the match + rule, you can also use the negate rule notrxsmatch. + + - In the %rename target name via the rxstarget option, for example: + + %rename("%(lowercase)",rxstarget=1) "GSL_.*"; + + where the target name "GSL.*" is now understood as a + regexp to be matched. + + - In the new encoder "rxspencer", which looks like: + + %(rxspencer:[regexp][replace])s + + where "regexp" is the regular expression and "replace" + is a string used as a replacement, where the @0,@1,...,@9 + pseudo arguments are used to represent the + corresponding matching items in the reg expression. + + For example: + + %(rxspencer:[GSL.*][@0])s <- Hello -> + %(rxspencer:[GSL.*][@0])s <- GSLHello -> GSLHello + %(rxspencer:[GSL(.*)][@1])s <- GSLHello -> Hello + %(rxspencer:[GSL(.*)][gsl@1])s <- GSLHello -> gslHello + + Another example could be: + + %rename("%(lowercase)s",sourcefmt="%(rxspencer:[GSL_(.*)][@1])s",%$isfunction) ""; + + which take out the prefix "GSL_" and returns all the + function names in lower cases, as following: + + void GSL_Hello(); -> hello(); + void GSL_Hi(); -> hi(); + const int GSL_MAX; -> GSL_MAX; // no change, is not a function + + We use the RxSpencer as an initial test bed to + implemention while we decide which library will be + finally added to swig. + + You can obtain the RxSpencer library from + + http://arglist.com/regex (Unix) + + or + + http://gnuwin32.sourceforge.net/packages.html (Windows) + + Once installed, use "man rxspencer" to get more info + about the regexp format, or just google rxspencer. + + Since now you can enable the rxsmatch rules (see above), + the simple or '|' support for the match rules + (01/12/2006: mmatus) is disabled. Still, if you have + problems with the rxspencer library, you can re-enable + the simple 'match or' support using + -DSWIG_USE_SIMPLE_MATCHOR. + + +01/16/2006: mmatus + Change the %rename predicates to use the prefix '%$', as in: + + %rename("%(utitle)s",%$isfunction,%$ismember) ""; + + to avoid clashings with other swig macros/directives. + +01/14/2006: cfisavage + [Ruby] + Added support for Ruby bang! methods via a new %bang feature. + Bang methods end in exclamation points and indicate that the + object being processed will be modified in-place as + opposed to being copied. + +01/12/2006: cfisavage + [Ruby] + Updated the Ruby module to automatically convert + method names to lower_case_with_underscores using the + new %rename functionality. + +01/12/2006: mmatus + - Add aliases for 'case' encoders used with %rename/%namewarn + + %(uppercase)s hello_world -> HELLO_WORLD + %(lowercase)s HelloWorld -> helloworld + %(camelcase)s hello_world -> HelloWorld + %(undercase)s HelloWorld -> hello_world + + +01/12/2006: mmatus + - Add the -dump_parse_module and -dump_parse_top options, + which are similar to -dump_module and -dump_top, but they + dump the node trees just after parsing, showing only the + attributes visible at the parsing stage, and not the added + later in typemap.cxx, allocate.cxx, lang.cxx or elsewhere. + + Besides debugging porpuses, these options are very useful + if you plan to use %rename in an "advance way", since it + shows only and all the node's attributes you can use + inside the match rules. + + +01/12/2006: mmatus + - Add predicates to %rename, so, you don't need to + remember, for example, how to match a member function. + + Now it is easy, for example to use the 'utitle' encoder + in all the member methods, you type: + + %rename("%(utitle)s",%isfunction,%ismember) ""; + + or to ignore all the enumitems in a given class: + + %rename("$ignore", %isenumitem, %classname="MyClass") ""; + + Available predicates are (see swig.swg): + + %isenum + %isenumitem + %isaccess + %isclass + %isextend + %isextend + %isconstructor + %isdestructor + %isnamespace + %istemplate + %isconstant + + %isunion + %isfunction + %isvariable + %isimmutable + + %isstatic + %isfriend + %istypedef + %isvirtual + %isexplicit + %isextern + + %ismember + %isglobal + %innamespace + + %ispublic + %isprotected + %isprivate + + %classname + + These predicates correspond to specific 'match' + declarations, which sometimes are not as evident as the + predicates names. + + + - Add the or '|' operation in %rename match, for + example to capitalize all the constants (%constant or + const cdecl): + + %rename("%(upper)s",match="cdecl|constant",%isimmutable) ""; + + + +01/12/2006: mgossage + - Partial fixed of errors under C89, bug #1356574 + (converted C++ style comments to C style) + - Added patches from neomantra@users.sf.net #1379988 and #1388343 + missing a 'return' statement for error conditions + also updated the %init block bug #1356586 + +01/10/2006: mmatus + - Add the 'utitle' encoder, as an example of how to add + your own encoder. I added the encoder method in misc.c + but developers can add others, the same way, inside any + target language. + + Well, 'utitle' is the reverse of 'ctitle', ie: + + %rename("%(ctitle)s") camel_case; -> CamelCase; + %rename("%(utitle)s") CamelCase; -> camel_case; + + +01/10/2006: cfisavage + [Ruby] + Updated Ruby Exception handling. Classes that are specified in throws clauses, + or are marked as %exceptionclass, are now inherited from rb_eRuntimeError. + This allows instances of these classes to be returned to Ruby as exceptions. + Thus if a C++ method throws an instance of MyException, the calling Ruby + method will get back a MyException object. To see an example, + look at ruby/examples/exception_class. + +01/10/2006: mmatus + + - Add the %catches directive, which complements the %exception + directive in a more automatic way. For example, if you have + + int foo() throw(E1); + + swig generates the proper try/catch code to dispatch E1. + + But if you have: + + + int barfoo(int i) { + if (i == 1) { + throw E1(); + } else { + throw E2(); + } + return 0; + } + + ie, where there is no explicit exception specification in the decl, you + end up doing: + + %exception barfoo { + try { + $action + } catch(E1) { ... } + } catch(E2) { ... } + } + + which is very tedious. Well, the %catches directive defines + the list of exceptions to catch, and from swig: + + %catches(E1,E2) barfoo(int i); + int barfoo(int i); + + is equivalent to + + int barfoo(int i) throw(E1,E2); + + Note, however, that the %catches list doesn't have to + correspond to the C++ exception specification. For example, if you + have: + + struct E {}; + struct E1 : E {}; + struct E2 : E {}; + + int barfoo(int i) throw(E1,E2); + + you can define + + %catches(E) barfoo(int i); + + and swig will generate an action code equivalent to + + try { + $action + } catch(E &_e) { + <raise _e>; + } + + Of course, you still have to satisfy the C++ restrictions, + and the catches list must be compatible (not the same) + as the original list of types in the exception specification. + + Also, you can now specify that you want to catch the + unknown exception '...', for example: + + %catches(E1,E2,...) barfoo(int); + + In any case, the %catches directive will emit the + code to convert into the target language error/exception + using the 'throws' typemap. + + For the '...' case to work, you need to + write the proper typemap in your target language. In the + UTL, this looks like: + + %typemap(throws) (...) { + SWIG_exception(SWIG_RuntimeError,"unknown exception"); + } + + +01/05/2006: wsfulton + [Java] Fix unsigned long long and const unsigned long long & typemaps + - Bug #1398394 with patch from Dries Decock + +01/06/2006: mmatus + Add 'named' warning codes, now in addition to: + + %warnfilter(813); + + you can use + + %warnfilter(SWIGWARN_JAVA_MULTIPLE_INHERITANCE); + + just use the same code name found in Source/Include/swigwarn.h + plus the 'SWIG' prefix. + + If a developer adds a new warning code, the Lib/swigwarn.swg file + will be generated when running the top level make. + +01/05/2006: cfisavage + [Ruby] + Reimplemented object tracking for Ruby. The new implementation works + by expanding the swig_class structure for Ruby by adding a trackObjects + field. This field can be set/unset via %trackobjects as explained + in the Ruby documentation. The new implementation is more robust + and takes less code to implement. + +01/05/2006: wsfulton + Fix for %extend and static const integral types, eg: + + class Foo { + public: + %extend { + static const int bar = 42; + } + }; + +12/30/2005: mmatus + + - Add info for old and new debug options: + + -dump_top - Print information of the entire node tree, including system nodes + -dump_module - Print information of the module node tree, avoiding system nodes + -dump_classes - Print information about the classes found in the interface + -dump_typedef - Print information about the types and typedefs found in the interface + -dump_tags - Print information about the tags found in the interface + -debug_typemap - Print information for debugging typemaps + -debug_template - Print information for debugging templates + + - Add the fakeversion. If you have a project that uses + configure/setup.py, or another automatic building system + and requires a specific swig version, let say 1.3.22 + you can use: + + SWIG_FEATURES="-fakeversion 1.3.22" + + or + + swig -fakeversion 1.3.22 + + and then swig -version will report 1.3.22 instead of the + current version. + + Typical use would be + + SWIG_FEATURES="-fakeversion 1.3.22" ./configure + +12/30/2005: mmatus + + - Add option/format support to %rename and %namewarn. + Now %namewarn can force renaming, for example: + + %namewarn("314: import is a keyword",rename="_%s") "import"; + + and rename can also support format forms: + + %rename("swig_%s") import; + + Now, since the format is processed via swig Printf, you + can use encoders as follows: + + %rename("%(title)s") import; -> Import + %rename("%(upper)s") import; -> IMPORT + %rename("%(lower)s") Import; -> import + %rename("%(ctitle)s") camel_case; -> CamelCase + + This will allow us to add more encoders, as the + expected one for regular expressions. + + - Add the above 'ctitle' encoder, which does the camel case: + + camel_case -> CamelCase + + - Also, while we get the regexp support, add the 'command' encoder, + you can use it as follows + + %rename("%(command:sed -e 's/\([a-z]\)/\U\\1/' <<< )s") import; + + then swig will popen the command + + "sed -e 's/\([a-z]\)/\U\\1/' <<< import" + + see below for anonymous renames for better examples. + + - The rename directive now also allows: + + - simple match: only apply the rename if a type match + happen, for example + + %rename(%(title)s,match="enumitem") hello; + + enum Hello { + hi, hello -> hi, Hello + }; + int hello() -> hello; + + - extended match: only apply the rename if the 'extended attribute' match + occurred, for example: + + // same as simple match + %rename(%(title)s,match$nodeType="enumitem") hello; + + enum Hello { + hi, hello -> hi, Hello + }; + + Note that the symbol '$' is used to define the attribute name in + a 'recursive' way, for example: + + // match only hello in 'enum Hello' + %rename(%(title)s,match$parentNode$type="enum Hello") hello; + + enum Hello { + hi, hello -> hi, Hello // match + }; + + enum Hi { + hi, hello -> hi, hello // no match + }; + + here, for Hello::hi, the "parentNode" is "Hello", and its "type" + is "enum Hello". + + + - Anonymous renames: you can use 'anonymous' rename directives, for example: + + // rename all the enum items in Hello + %rename(%(title)s,match$parentNode$type="enum Hello") ""; + + enum Hello { + hi, hello -> Hi, Hello // match both + }; + + enum Hi { + hi, hello -> hi, hello // no match + }; + + // rename all the enum items + %rename(%(title)s,match$nodeType="enumitem") ""; + + // rename all the items in given command (sloooow, but...) + %rename(%(command:<my external cmd>)s) ""; + + + Anonymous renames with commands can be very powerful, since you + can 'outsource' all the renaming mechanism (or part of it) to an + external program: + + // Uppercase all (and only) the names that start with 'i' + %rename("%(command:awk '/^i/{print toupper($1)}' <<<)s") ""; + + int imported() -> IMPORTED; + int hello() -> hello + + Note that if the 'command' encoder returns an empty string, swig + understands that no rename is necessary. + + Also note that %rename 'passes' the matched name. For example, in + this case + + namespace ns1 { + int foo(); + } + + namespace ns2 { + int bar(); + } + + the external program only receives "foo" and "bar". If needed, + however, you can request the 'fullname' + + %rename("%(command:awk 'awk '/ns1::/{l=split($1,a,"::"); print toupper(a[l])}'' <<<)s",fullname=1) ""; + + ns1::foo -> FOO + ns2::bar -> bar + + - Mixing encoders and matching: of course, you can do mix commands + and match fields, for example: + + %rename("%(<my encoder for fncs>)",match="cdecl") ""; + %rename("%(<my encoder for enums>)",match="enumitem") ""; + %rename("%(<my encoder for enums inside a class>)",match="enumitem", + match$parentNode$parentNode$nodeType="class") ""; + + Use "swig -dump_parse_module" to see the attribute names you can use to + match a specific case. + + - 'sourcefmt' and 'targetfmt': sometimes you need to + process the 'source' name before comparing, for example + + %namewarn("314: empty is a keyword",sourcefmt="%(lower)s") "empty"; + + then if you have + + int Empty(); // "Empty" is the source + + you will get the keyword warning since 'Empty' will be + lower cased, via the sourcefmt="%(lower)s" option, + before been compared to the 'target' "empty". + + There is an additional 'targetfmt' option to process the + 'target' before comparing. + + - complementing 'match': you can use 'notmatch', for example + + %namewarn("314: empty is a keyword",sourcefmt="%(lower)s",notmatch="namespace") "empty"; + + here, the name warning will be applied to all the symbols except namespaces. + + +12/30/2005: mmatus + + - Add initial support for gcj and Java -> <target language> mechanism. + + See examples in: + + Examples/python/java + Examples/ruby/java + Examples/tcl/java + + to see how to use gcj+swig to export java classes into + python/ruby/tcl. + + The idea is to put all the common code for gcj inside + + Lib/gcj + + and localize specific types such as jstring, as can be found + in + + Lib/python/jstring.i + Lib/ruby/jstring.i + Lib/tcl/jstring.i + + Using the UTL, this is very easy, and the perl version for + jstring.i will be next. + + +12/29/2005: mmatus + - Add the copyctor feature/directive/option to enable the automatic + generation of copy constructors. Use as in: + + %copyctor A; + + struct A { + + }; + + then this will work + + a1 = A(); + a2 = A(a1); + + Also, since it is a feature, if you just type + + %copyctor; + + that will enable the automatic generation for all the + classes. It is also equivalent to + + swig -copyctor -c++ ... + + Notes: + + 1.- The feature only works in C++ mode. + + 2.- The automatic creation of the copy constructor will + usually produce overloading. Hence, if the target + language doesn't support overloading, a special name + will be used (A_copy). + + 3.- For the overloading reasons above, it is probably not + a good idea to use the flag when, for example, you are + using keywords in Python. + + 4.- The copyctor automatic mechanism follows more or less + the same rules as the default constructor mechanism, + i.e., a copy constructor will not be added if the + class is abstract or if there is a pertinent non-public + copy ctor in the class or its hierarchy. + + Hence, it might be necessary for you to complete the + class declaration with the proper non-public copy ctor + to avoid a wrong constructor addition. + + - Fix features/rename for templates ctor/dtor and other + things around while adding the copyctor mechanism. + + +12/27/2005: mmatus + - Add the 'match' option to typemaps. Assume you have: + + %typemap(in) SWIGTYPE * (int res) {..} + %typemap(freearg) SWIGTYPE * { if (res$argnum) ...} + + then if you do + + %typemap(in) A * {...} + + swig will 'overload the 'in' typemap, but the 'freearg' + typemap will be also applied, even when this is wrong. The old + solutions is to write: + + %typemap(in) A * {...} + %typemap(freeag) A * ""; + + overload 'freearg' with an empty definition. + + The problem is, however, there is no way to know you need + to do that until you start getting broken C++ code, or + worse, broken runtime code. + + The same applies to the infamous 'typecheck' typemap, + which always confuses people, since the first thing you do + is to just write the 'in' typemap. + + The 'match' option solves the problem, and if instead you write: + + %typemap(in) SWIGTYPE * (int res) {..} + %typemap(freearg,match="in") SWIGTYPE * { if (res$argnum) ...} + %typemap(typecheck,match="in",precedence...) SWIGTYPE * {...} + + it will tell swig to apply the 'freearg/typecheck' + typemaps only if they 'match' the type of the 'in' + typemap. The same can be done with other typemaps as: + + %typemap(directorout) SWIGTYPE * {...} + %typemap(directorfree,match="directorout") SWIGTYPE * {...} + + +12/27/2005: mmatus + - Add the 'naturalvar' option/mode/feature to treat member + variables in a more natural way, ie, similar to the global + variable behavior. + + You can use it in a global way via the command line + + swig -naturalvar ... + + or the module mode option + + %module(naturalvar=1) + + both forms make swig treat all the member variables in the + same way it treats global variables. + + Also, you can use it in a case by case approach for + specific member variables using the directive form: + + %naturalvar Bar::s; + + Then, in the following case for example: + + std::string s; + struct Bar { + std::string s; + }; + + you can do: + + b = Bar() + b.s ="hello" + cvar.s = "hello" + + if (b.s != cvar.s): + raise RuntimeError + + + This is valid for all the languages, and the + implementation is based on forcing the use of the + const SWIGTYPE& (C++)/SWIGTYPE (C) typemaps for the + get/set methods instead of the SWIGTYPE * typemaps. + Hence, for 'naturalvar' to work, each target language + must implement 'typemap(in/out) const Type&' properly. + + The 'naturalvar' option replaces or makes workarounds such as: + + %apply const std::string & { std::string *} + + unnecessary. + + Note1: If your interface has other kinds of workarounds to + deal with the old 'unnatural' way to deal with member + variables (returning/expecting pointers), the + 'naturalvar' option could break them. + + Note2: the option has no effect on unnamed types, such + as unnamed nested unions. + + +12/27/2005: mmatus + - Add more 'expressive' result states for the typemap + libraries. + + In the past, for scripting languages, you would do checking something like: + + if (ConvertPtr(obj,&vptr,ty,flags) != -1) { + // success + } else { + // error + } + + Now the result state can carry more information, + including: + + - Error state: like the old -1/0, but with error codes from swigerrors.swg. + + int res = ConvertPtr(obj,&vptr,ty,flags); + if (SWIG_IsOK(res)) { + // success code + } else { + SWIG_Error(res); // res carries the error code + } + + - Cast rank: when returning a simple successful + conversion, you just return SWIG_OK, but if you need + to do a 'cast', you can add the casting rank, ie: + + if (PyFloat_Check(obj)) { + value = PyFloat_AsDouble(obj); + return SWIG_OK; + } else if (PyInt_Check(obj)) { + value = (double) PyInt_AsLong(obj); + return SWIG_AddCast(SWIG_OK); + } + + later, the casting rank is used to properly dispatch + the overloaded function, for example. This of course + requires your language to support and use the new + dispatch cast/rank mechanism (Now mainly supported in + perl and python, and easily expandable to ruby and tcl). + + - [UTL] Add support for the new 'expressive' result states. + +12/27/2005: mmatus + - Add support for the C++ implicit conversion mechanism, which + required some modifications in parser.y (to recognize + 'explicit') and overload.cxx (to replace $implicitconv as + needed). + + Still, real support in each target language requires each + target language to be modified. Python provides an example, + see below. + + + - Add support for native C++ implicit conversions, ie, if you + have + + %implicitconv A; + + struct A { + int ii; + A() {ii = 1;} + A(int) {ii = 2;} + A(double) {ii = 3;} + explicit A(char *s) {ii = 4;} + }; + + int get(const A& a) {return a.ii;} + + you can call: + + a = A() + ai = A(1) + ad = A(1.0) + as = A("hello") + + # old forms + get(a) -> 1 + get(ai) -> 2 + get(ad) -> 3 + get(as) -> 4 + + #implicit conversions + get(1) -> 2 + get(1.0) -> 3 + get("hello") -> Error, explicit constructor + + Also, as in C++, now implicit conversions are supported in + variable assigments, and if you have: + + A ga; + struct Bar { + A a; + }; + + you can do: + + cvar.ga = A(1) + cvar.ga = 1 + cvar.ga = 1.0 + cvar.ga = A("hello") + cvar.ga = "hello" -> error, explicit constructor + + b = Bar() + b.a = A("hello") + b.a = 1 + b.a = 1.0 + b.a = "hello" -> error, explicit constructor + + Note that the last case, assigning a member var directly, + also requires the 'naturalvar' option. + + This support now makes the old '%implicit' macro, which + was found in 'implicit.i' and it was fragile in many ways, + obsolete, and you should use the new '%implicitconv' + directive instead. + + Note that we follow the C++ conventions, ie, in the + following the implicit conversion is allowed: + + int get(A a) {return a.ii;} + int get(const A& a) {return a.ii;} + + but not in these cases: + + int get(A *a) {return a->ii;} + int get(A& a) {return a.ii;} + + Also, it works for director methods that return a by value + result, ie, the following will work: + + virtual A get_a() = 0; + + def get_a(self): + return 1 + + but not in this case: + + virtual const A& get_a() = 0; + virtual A& get_a() = 0; + virtual A* get_a() = 0; + + Notes: + + - the implicitconv mechanism is implemented by directly + calling/dispatching the python constructor, triggering a + call to the __init__method. Hence, if you expanded the + __init__ method, like in: + + class A: + def __init__(self,args): + <swig code> + <my code here> + + then 'my code' will also be executed. + + - Since the %implicitconv directive is a SWIG feature, if you type: + + %implicitconv; + + that will enable implicit conversion for all the classes in + your module. + + But if you are worried about performance, maybe that will be + too much, especially if you have overloaded methods, since + to resolve the dispatching problem, python will efectively + try to call all the implicit constructors as needed. + + - For the same reason, it is highly recommended that you use + the new 'castmode' when mixing implicit conversion and + overloading. + + - [python] The %implicit directive is declared obsolete, and + you should use %implicitconv instead. If you include + the implicit.i file, a warning will remind you of this. + + Note: Since %implicit is fragile, just replacing it by + %implicitconv could lead to different behavior. Hence, we + don't automatically switch from to the other, and the user + must migrate to the new %implicitconv directive manually. + + +12/26/2005: wsfulton + [C#] + Modify std::vector wrappers to use std::vector::value_type as this is + closer to the real STL declarations for some methods, eg for push_back(). + Fixes some compilation errors for some compilers eg when the templated + type is a pointer. + + [Java] + std::vector improvements - a few more methods are wrapped and specializations are + no longer required. The specialize_std_vector macro is no longer needed (a + warning is issued if an attempt is made to use it). + +12/26/2005: wsfulton + [Java, C#] + Add in pointer reference typemaps. This also enables one to easily wrap + std::vector<T> where T is a pointer. + +12/24/2005: efuzzyone + [CFFI] The cffi module for SWIG: + - Fully supports C, but provides limited supports for C++, in + particular C++ support for templates and overloading needs to + be worked upon. + +12/23/2005: mmatus + [python] Add the castmode that allows the python + type casting to occur. + + For example, if you have 'int foo(int)', now + + class Ai(): + def __init__(self,x): + self.x = x + def __int__(self): + return self.x + + foo(1) // Ok + foo(1.0) // Ok + foo(1.3) // Error + a = Ai(4) + foo(ai) // Ok + + The castmode, which can be enabled either with the + '-castmode' option or the %module("castmode") option, uses + the new cast/rank dispatch mechanism. Hence, now if you + have 'int foo(int); int foo(double);', the following works + as expected: + + foo(1) -> foo(int) + foo(1.0) -> foo(double) + ai = Ai(4) + foo(ai) -> foo(int) + + Note1: the 'castmode' could disrupt some specialized + typemaps. In particular, the "implicit.i" library seems to + have problem with the castmode. But besides that one, the + entire test-suite compiles fine with and without the + castmode. + + Note2: the cast mode can't be combined with the fast + dispatch mode, ie, the -fastdispatch option has no effect + when the cast mode is selected. The penalties, however, + are minimum since the cast dispatch code is already based + on the same fast dispatch mechanism. + + See the file overload_dispatch_cast_runme.py file for + new cases and examples. + +12/22/2005: mmatus + Add the cast and rank mechanism to dispatch overloading + functions. The UTF supports it now, but for each language + it must be decided how to implement and/or when to use it. + + [perl] Now perl uses the new cast and rank dispatch + mechanism, which solves all the past problems known + in perl, such as the old '+ 1' problem: + + int foo(int); + + $n = 1 + $n = $n + 1 + $r = foo(n) + + also works: + + foo(1); + foo("1"); + foo(1.0); + foo("1.0"); + + but fails + + foo("l"); + + and when overloading foo(int) and foo(double); + + foo(1) -> foo(int) + foo(1.0) -> foo(double) + foo("1") -> foo(int) + foo("1.0") -> foo(double) + foo("l") -> error + foo($n) -> foo(int) for good perl versions + foo($n) -> foo(double) for old bad perl versions + + when overloading foo(int), foo(char*) and foo(double): + + foo(1) -> foo(int) + foo(1.0) -> foo(double) + foo("1") -> foo(char*) + foo("1.0") -> foo(char*) + foo("l") -> foo(char*) + + Note: In perl the old dispatch mechanism was broken, + so, we don't provide an option to enable the old one + since, again, it was really really broken. + + See 'overload_simple_runme.pl' for more cases and tests. + + PS: all the old known issues are declared resolved, any + new "problem" that could be discovered is declared, + a priori, as "features" of the new dispatch mechanism + (until we find another solution at least). + + + *** POTENTIAL INCOMPATIBILITY *** + + As with the introduction of the UTF, some things could + now start to work as expected, and people used to deal or + workaround previous bugs related to the dispatch + mechanism, could see now a difference in perl behavior. + +12/21/2005: mmatus + - The '-nodefault' flag (pragma and feature) now generates + a warning, and recommends to use the explicit + -nodefaultctor and -nodefaultdtor options. + + The reason to split the 'nodefault' behavior is that, in + general, ignoring the default destructor generates memory + leaks in the target language. Hence, is too risky just to + disable both the default constructor and destructor + at the same time. + + If you need to disable the default destructor, it is + also recommended you use the directive form: + + %nodefaultdtor MyVerySpecialClass; + + for specific classes, and always avoid using the global + -nodefault and -nodefaultdtor options. + +12/21/2005: wsfulton + [Java, C#] + Fix incorrect code generation when the intermediary classname is changed + in the module directive from its default. For example: + + %module(jniclassname="myimclassnewname") "mymodule" // Java + %module(imclassname="myimclassnewname") "mymodule" // C# + + Add in new special variable $imclassname. See docs. + +12/17/2005: mmatus + [Python] + - Add the -aliasobj0/-noaliasobj0 options to use with + -fastunpack and/or -O and old typemaps that use 'obj0' + directly. + + So, if you compile your code using -O and get errors about + the undeclared 'obj0' variable, run again using + + swig -O -aliasobj0 -python .... + + For new typemaps, never use 'obj0' directly, if needed, + use the '$self' name that will be properly expanded to + 'obj0' (nofastunpack) or 'swig_obj[0]' (fastunpack). + + If you have no idea what I am talking about, better, that + means you have no typemap with this problem. + + +12/14/2005: mmatus + [Python] + - Add the -fastunpack/-nofastunpack options to enable/disable + the use of the internal UnpackTuple method, instead of + calling the one from the python C API. + + The option -O now also implies -fastunpack. + + +12/11/2005: mmatus + [Python] + - Add the -proxydel/-noproxydel options to enable/disable + the generation of proxy/shadow __del__ methods, even + when now they are redundant, since they are empty. + However, old interfaces could rely on calling them. + + The default behavior is to generate the __del__ methods + as in 1.3.27 or older swig versions. + + The option -O now also implies -noproxydel. + +12/10/2005: mmatus + [UTF] + - Fix unneccessary calls to SWIG_TypeQuery for 'char *' + and 'wchar_t *', problem found by Clay Culver while + profiling the PyOgre project. + + + [Python] + - Add the -dirvtable/-nodirvtable to enable/disable + a pseudo virtual table used for directors, avoiding + the need to resolve the python method at each call. + + - Add the -safecstrings/-nosafecstrings options to + enable/disable the use of safe conversions from PyString + to char *. Python requires you to never change the internal + buffer directly, and hence 'safectrings' warranties that + but returning a copy of the internal python string buffer. + + The default, as in previous releases, is to return a + pointer to the buffer (nosafecstrings), so, it is the user's + responsibility to avoid its modification. + + - Add the -O option to enable all the optimization options + at once, initially equivalent to + + -modern -fastdispatch -dirvtable -nosafecstrings -fvirtual + +12/08/2005: mmatus + + - Add the -fastdispatch option (fastdispatch feature). This + enables the "fast dispatch" mechanism for overloaded + methods provided by Salvador Fandi~no Garc'ia (#930586). + + The resulting code is smaller and faster since less type + checking is performed. However, the error messages you + get when the overloading is not resolved could be + different from what the traditional method returns. + + With the old method you always get an error such as + + "No matching function for overloaded ..." + + with the new method you can also get errors such as + + "Type error in argument 1 of type ..." + + See bug report #930586 for more details. + + So, this optimization must be explicitly enabled by users. + + The new mechanism can be used as: + + swig -fastdispatch + + or using the feature form + + %feature("fastdispatch") method; + or + %fastdispatch method; + + +12/06/2005: mmatus + + - Several memory and speed improvements, specially for + templates. Now swig is up to 20 faster than before for + large template interfaces, such as the std_containers.i + and template_matrix.i files in the python test-suite. + + Memory footprint is also reduced in consideration of small + pcs/architectures. + + - add commandline options -cpperraswarn and -nocpperraswarn" to force + the swig preprocessor to treat the #error directive as a #warning. + + the pragmas + + #pragma SWIG cpperraswarn=1 + #pragma SWIG cpperraswarn=0 + + are equivalent to the command line options, respectively. + + +12/06/2005: mmatus + [Python] The generated code is now more portable, especially + for Windows. Following + + http://www.python.org/doc/faq/windows.html + + Py_None is never accessed as a structure, plus other + tricks mentioned there. + +12/06/2005: mmatus + [Python] Added initial support for threads based in the + proposal by Joseph Winston. + + The user interface is as follows: + + 1.- the module thread support is enable via the "threads" module + option, i.e. + + %module("threads"=1) + + 2.- Equivalent to that, is the new '-threads' swig option + + swig -threads -python ... + + 3.- You can partially disable thread support for a given + method using: + + %feature("nothread") method; + or + %nothread method; + + also, you can disable sections of the thread support, + for example + + %feature("nothreadblock") method; + or + %nothreadblock method; + + %feature("nothreadallow") method; + or + %nothreadallow method; + + the first disables the C++/python thread protection, and the + second disables the python/C++ thread protection. + + 4.- The current thread support is based in the PyGIL + extension present in python version 2.3 or later, but + you can provide the thread code for older versions by + defining the macros in pythreads.swg. + + If you get a working implementation for older versions, + please send us a patch. + + For the curious about performance, here are some numbers + for the profiletest.i test, which is used to check the speed + of the wrapped code: + + nothread 9.6s (no thread code) + nothreadblock 12.2s (only 'allow' code) + nothreadallow 13.6s (only 'block' code) + full thread 15.5s ('allow' + 'block' code) + + i.e., full thread code decreases the wrapping performance by + around 60%. If that is important to your application, you + can tune each method using the different 'nothread', + 'nothreadblock' or 'nothreadallow' features as + needed. Note that for some methods deactivating the + 'thread block' or 'thread allow' code is not an option, + so, be careful. + + +11/26/2005: wsfulton + SWIG library files use system angle brackets everywhere for %include, eg + %include "std_common.i" + becomes + %include <std_common.i> + +11/26/2005: wsfulton + [Java, C#] + Typesafe enums and proper enums have an extra constructor so that enum item values that + are initialised by another enum item value can be wrapped without having to use %javaconstvalue/ + %csconstvalue for when using %javaconst(1)/%csconst(1). Suggestion by + Bob Marinier/Douglas Pearson. + For example: + + typedef enum + { + xyz, + last = xyz + } repeat; + +11/21/2005: mmatus + [ruby + python] + + Fixes for directors + pointers. This is an ugly problem without an easy + solution. Before we identified this case as problematic: + + virtual const MyClass& my_method(); + + but it turns out that all the cases where a pointer, array or + reference is returned, are problematic, even for + primitive types (as int, double, char*, etc). + + To try to fix the issue, a new typemap was added, + 'directorfree', which is used to 'free' the resources + allocated during the 'directorout' phase. At the same + time, a primitive garbage collector engine was added to + deal with orphaned addresses, when needed. + + The situation is much better now, but still it is possible to have + memory exhaustation if recursion is used. + + So, still you need to avoid returning pointers, arrays or + references when using director methods. + + - Added stdint.i - typemaps for latest C99 integral types found in stdint.h. + +11/14/2005: wsfulton + More types added to windows.i, eg UINT8, WORD, BYTE etc. + Including windows.i will also enable SWIG to parse the __declspec Microsoft + extension, eg __declspec(dllimport). Also other Windows calling conventions + such as __stdcall. + +11/10/2005: wsfulton + New library file for Windows - windows.i. This file will contain useful type + information for users who include windows.h. Initial support is for the + non ISO integral types: __int8, __int16, __int32, __int64 and unsigned versions. + The unsigned versions previously could not be parsed by SWIG. SF #872013. + +11/09/2005: wsfulton + [Java, C#] Portability warning for files which will overwrite each other on case + insensitive file systems such as FAT32/NTFS. This will occur, for example, when two + class names are the same barring case. The warning is issued on all platforms and + can be suppressed with the usual warning suppression techniques. SF bug #1084507. + +11/09/2005: wsfulton + ./configure --with-python --with-ruby --with-perl5 etc enable these languages, + ie the --with-xxxx options, where no path is specified, work the same as if + the option was not specified at all. Based on patches #1335042 #1329048 #1329047. + +11/09/2005: dancy + + [Allegrocl] + Add C++ support to the Allegrocl module. Further + enhances the C support as well. Some of the + features: + + - MUCH better generation of foreign types based on + the C/C++ types for use in defining the FFI on + the lisp side. We don't pass everything as a (* :void) + any longer. + + - Uses typemaps for better control of type conversions + and code generation in the generated lisp and c++ wrapper + code. + + - CLOS wrapping of pointers returned from foreign space + makes it easier to differentiate pointers in user code. + The wrapping objects can be passed directly to FF calls. + + - Defun wrapping of FF calls, allowing for more lispy + interface. Conversion, GCing, of lisp objects to + foreign objects can be done in the wrapping defun via + the use of typemaps. + + - overload dispatching implemented on the lisp side + using generic functions. + + - Templates and synonymous types supported. + +11/07/2005: mmatus + + [Python] Adding proper support for multi-inheritance in + the python side, ie, if you have two C++ wrapped class, Foo + and Bar, now: + + class MyPythonClass(Foo,Bar): + .... + + will properly work, even with directors, and the + deallocation of Foo.this and Bar.this will follow + correctly. Before, a class could only have one 'this' + instance (unlike C++), only the last base class was + properly deleted, or detected with directors. + + Now 'self.this' can be a list, which will contain the C++ + instance pointers for all the base classes. + + Also, swig.this is responsible for deallocating the C++ + instance(s), and the __del__ method is not emitted unless + the user preppend/append some code to it. + + - Swig can now detect memory leaks, ie, if you still + don't use proxy/shadow classes, and type something like + + import _example + f = _example.new_Foo() + + and forget to call _example.delete_Foo(f), then swig will + tell you that there is a memory leak. + + Otherwise, if you always use the proxy classes, you probably + you will never ever see this warning unless there is + something wrong inside the swig wrapping code. + + + *** POTENTIAL INCOMPATIBILITY *** + + If you overloaded the __del__ method, and call the base + one without a try block, as in + + class MyClass(SwigClass): + + def __del__(self): + <your code here> + SwigClass.__del__(self) + + python could complain that the method SwigClass.__del__ is + undefined. Try to use instead: + + def __del__(self): + <your code here> + try: SwigClass.__del__(self) + except: pass + + or simply + + def __del__(self): + <your code here> + +11/02/2005: mmatus + + [Python] Adding more fun to STL/STD containers, now you + can do + + %template(pyset) std::set<PyObject *>; + %template(pyvector) std::vector<PyObject *>; + %template() std::pair<PyObject *,PyObject *>; + %template(pyvector) std::map<PyObject *,PyObject *>; + .... + + The same applies to std::list, std::deque, std::multiset, etc. + + Then, at the python side you can do now: + + # C++ std::vector as native python sequence + v = pyvector([1,"hello",(1,2)]) + print v[1] + >> 'hello' + print v[2] + >> (1,2) + + # C++ std::set as native python sequence + s = pyset() + s.insert((1,2)) + s.insert(1) + s.insert("hello") + sum=() + for i in s: + sum +=(i,) + print sum + >>> (1, 'hello', (1, 2)) + + # C++ std::map as native python sequence + m = pymap() + m["foo"] = "hello" + m[1] = (1,2) + pm = {} + for k in m: + pm[k] = m[k] + print pm + >>> {1: (1, 2), 'foo': 'hello'} + + ie, the STD/STL containers work as real native python + container, with arbitrary item types and so. + + But since normal C++ containers do not properly ref/unref + their items, you should use the safer versions: + + %template(pyset) std::set<swig::PyObject_ptr>; + %template(pyvector) std::vector<swig::PyObject_ptr>; + %template() std::pair<swig::PyObject_ptr, swig::PyObject_ptr>; + %template(pyvector) std::map<swig::PyObject_ptr,swig::PyObject_ptr>; + .... + + where swig::PyObject_ptr is a PyObject * envelope class provided + to safely incref/decref the python object. + + So, now you can use all the STL/STD containers as native + Python containers. + + Note 1: std::map, std::set and the other 'ordered' + containers will properly use PyObject_Compare for sorting, + when needed. + + Note 2: all the STL/STD containers have a limit size of + SIZE_MAX, ie, you can have manage containers larger than + INT_MAX, the python limit. + + +11/02/2005: mmatus + + [Python] + - add 'iterator()' method for all sequences and additionally + 'key_iterator()' for maps. + + 'iterator()' will always return the native C++ iterator. + Additionally, in maps, 'key_iterator()' will return a python + iterator using only the map keys. + + In general the sequence method __iter__ will call + 'iterator()', returning the native C++ iterator, but in + maps it will call 'key_iterator()', maintaining + backward compatibility. + + Hence, for std::maps, you can play then with the native + C++ iterator, which value is a (key, value) pair, by + calling map.iterator(), as with map.begin(), map.end(), etc. + + The difference is that map.iterator() returns a safe + 'closed' iterator, while map.begin() and map.end() are + 'open' iterators. + + A 'closed' iterator knows the begin and the end of the + sequence, and it never can seg. fault. An 'open' + iterator, as in C++, can seg. fault at the C++ side. + + # a closed iterator is safe in the following example. + # the next() method will throw a StopIteration + # exception as needed + + i = seq.iterator() + try: + while True: + sum += i.next() + except: pass + + # an open iterator always need to be checked, + # or it will crash at the C++ side + + current = seq.begin() + end = seq.end() + while (current != end): + sum += current.next() + + + [Python] + - Finally, when we call + + f = Foo() + + the construction is 'one-way'. Before construction was done + something like + + Foo() (python) -> _new_Foo() (C++) + new_Foo() (C++) -> FooPtr() (python) + FooPtr() (python) -> Foo() (python) + + and returning a pointer was done like + + NewPointerObj() (C++) -> FooPtr() (python) + FooPtr(python) -> Foo() (python) + + + ie, we when going back and forward between the C++ and + python side. + + Now since there is no FooPtr the construction process is + + Foo() (python) -> _new_Foo() (C++) + _new_Foo() (C++) -> NewPointerObj() (C++) (no shadow class) + + and returning a pointer is done + + NewPointerObj() (C++) (with shadow class) -> NewInstaceObj() (C++) + + where NewInstanceObj creates a new instance without + calling __init__ and it doesn't go 'back' to python, is + 'pure' C API. + + - With this change, and the other ones in the + PySwigObject type, which now carries the thisown and + swig_type_info pointer, the generated code should be as + fast as boost::Python and/or the other python wrappers + based in pure Python/C API calls. + + As a reference, the profiletest_runme.py example, which + does a simple call function many times, such as this code: + + import profiletest + + a = profiletest.A() + b = profiletest.B() + for i in range(0,1000000) + a = b.fn(a) + + + where fn is defined as 'A* B::fn(A *a) {return a;}', + produces the following times + + nomodern modern + swig-1.3.26 19.70s 5.98s + swig-CVS 0.99s 0.98s + + + Clearly, there is a large improvement for the python + 'nomodern' mode. Still, the 'modern' mode is around + 6 times faster than before. For the same test, but + using the non-shadow version of the module, we get + + _profiletest (non-shadow) + swig-1.3.26 0.80s + swig-CVS 0.60s + + Hence, now for practical purposes, the proxy overhead + is insignificant. + + Note that the performance numbers we are showing is for + a simple module (two types) and a simple function (one + argument). For real situations, for modules with many + more types and/or functions with many more parameters, + you will see even better results. + + +10/31/2005: mmatus + [Python] + + - Finally, no more ClassPtr proxy classes. You will see + only a clean Class proxy class in the .py file. + + - No more 'real' thisown attribute either, the PySwigObject now + carries the ownership info. + + You can also do something like + + print self.this.own() + >>> True + + self.this.disown() + self.this.own(0) + print self.this.own() + >>> False + + self.this.acquire() + self.this.own(1) + print self.this.own() + >>> True + + Still the old way, + + print self.thisown + >>> True + + self.thisown = 0 + print self.thisown + >>> False + + self.thisown = 1 + print self.thisown + >>> True + + is supported, and python dispatches the proper method + calls as needed. + + + - Support for iterators in STL/STD containers, for example, if you have + + %template<set_string> std::set<std::string>; + + you can use the C++ iterators as: + + s = set_string() + + s.append("c") + s.append("a") + s.append("b") + + b = s.begin() + e = s.end() + sum = "" + while (b != e): + sum += b.next() + print sum + + >>> "abc" + + advance the iterator as in C++ + + current = s.begin() + current += 1 + print current.value() + >>> "b" + + now using the reverse operators + + b = s.rbegin() + e = s.rend() + sum = "" + while (b != e): + sum += b.next() + print sum + + >>> "cba" + + or the 'previous' method + + b = s.begin() + e = s.end() + sum = "" + while (b != e): + sum += e.previous() + print sum + + >>> "cba" + + or just as in a python fashion + + for i in s: + sum += i + + Note 1: Iterators in C++ are very powerful, but + dangerous too. And in python you can shoot yourself in the foot + just like in C++, so, be careful. + + Note 2: the iterators are 'light', ie, they do not + convert sequence elements until you request to do so, via + next(), value() or previous(). If you just increment/decrement one + no conversion is performed, for example: + + + b = s.begin() + b += 1 + b.incr() + b.incr(2) + b.decr(2) + b.decr() + b -= 1 + + only the iterator is modified, and not value wrapper + is generated. Other typical C++ operations are also + available, such as: + + print s.end() - s.begin() + >>> 3 + f = s.begin() + 1 + print f.value() + >>> "b" + l = s.end() - 1 + print l.value() + >>> "c" + + etc. Of course, the 'find', 'insert', 'erase', and + so on methods also supports iterators now, ie: + + i = s.begin() + i += 1 + s.erase(i) + for i in s: + sum += i + print sum + >>> "ac" + + *** POTENTIAL INCOMPATIBILITY *** + + There is no more 'thisown' attribute. If you use it, python + will translate the following code as follows: + + if (self.thisown): ==> if (self.this.own()): + self.thisown = 1 ==> self.this.own(1) + self.thisown = 0 ==> self.this.own(0) + + Still, maybe in some unusual cases the translation will not be + 100% correct, so if you have a problem, please report it + and/or use the new 'self.this.own()' accessor. + + + *** POTENTIAL INCOMPATIBILITY *** + + There is no more ClassPtr classes in the python code. Hence, + if in the past you needed to resort to some kind of trickery + with them, or overcome their presence, it is no longer + required, but the extra code you added could now break + things. + + If needed, you can use the option -classptr, i.e., + + swig -classptr -python ... + + to generate the old ClassPtr classes. + + +10/30/2005: mkoeppe + [Guile] Make declared and defined linkage of SWIG_init consistent. + Reported by Steven G. Johnson (SF patch 1315498). + +10/26/2005: mmatus + + - Added the attribute.i file to the global library director. + Now it can be used from other languages that do not use + the unified typemap library as well. + + So, if you have something like: + + %include attribute.i + + %attribute(A, int, a, get_a, set_a); + + struct A + { + int get_a() const; + void set_a(int aa); + }; + + %attribute_ref(B, int, c); + + struct B + { + int& c(); + }; + + then in the target language the 'A.a' and 'B.c' attributes will + be visible, ie, you can access them as plain variables: + + f = A() + f.a = 3 + g = B() + g.c = 3 + + h = f.a + g.c + + and the proper get/set methods will be dispatched. See + attribute.i for more info. + + - More cleanups around and adding more test-cases. The + DISOWN typemap now is tested and working in all the + languages that use the unified typemap library, ie, tcl, + ruby, perl and python. + + +10/25/2005: mmatus + + - Perl, complete the DISOWN typemap. + + - added the attribute.i file to the unified typemap + library (before was only usable from python). + + - unify the names for the setter and getter methods in + perl,tcl,ruby and python, so, the attribute.i library + can work across them. + + - see the li_attribute.i test-case or the library file + + Lib/typemaps/attribute.swg + + for more info about how to use it. + + + + +10/24/2005: mmatus + + - Perl now uses the unified typemap library. + + - Changes in ruby to use the $track option in typemaps. + + - Changes in the unified typemap library to follow the + convention that all macros that are not used in the + C/C++ side starts with %, such as + + %delete + %new_array + + etc. + + - Documenting fragments, see fragments.swg. + + - Cleaner way to use the unified typemap library, include + just <typemaps/swigtypes.swg>. + + Check some of the supported languages: perl, tcl, ruby, + python. + + Always start with the head file, such as + + python/python.swg + tcl/tcl8.swg + ruby/ruby.swg + perl5/perl5.swg + + and the principal file that invokes the unified library, such as + + python/pytypemaps.swg + tcl/tcltypemaps.swg + ruby/rubytypemaps.swg + perl/perltypemaps.swg + + The file that provide the specialization for each + language are the one that provides the basic types: + + python/pyprimtypes.swg + ruby/rubyprimtypes.swg + tcl/tclprimtypes.swg + perl5/perlprimtypes.swg + + and the string manipulation: + + python/pystrings.swg + ruby/rubystrings.swg + tcl/tclstrings.swg + perl5/perlstrings.swg + + + The rest of the files, such as carray.i, are mostly one + line files that include the proper typemap library + version. + + *** POTENTIAL INCOMPATIBILITY in Perl *** + + Some missing/wrong typemaps could start working properly, + and change the old expected behavior in Perl. + +10/23/2005: wuzzeb + Chicken: + + pointers to member functions finally work properly + + add test of member function pointers to cpp_basic.i + +10/20/2005: dancy + [allegrocl] Added C++ support. Large update, many changes. See + newly added Allegro Common Lisp section in lisp.html + +10/20/2005: mmatus + Ruby, Tcl, Python: + + - Uniform way to fail (label fail:), now finally + SWIG_exception works across the three languages and all + the typemaps. + + - Add proper cleanup code to ruby + + - More valgrind fixes + + - Simplify the inline use, it seems a small interface of + 20,000 lines (plus many many templates) can break + gcc -O3 easily. + + - Finalize the typemaps library. All the old *.i files + (carray.i, cpointer.i, exception.i) had been implemented + in the new typemaps library. + + +10/19/2005: wuzzeb + Update the Runtime Typemap documentation in Typemaps.html + +10/18/2005: wuzzeb + Chicken: + - Correctly handle %ignored classes + - Correctly convert long, long long, unsigned long, etc + to chicken primitives. (Thanks to Felix Winkelmann) + - Using argout parameters when the return value was a + wrapped pointer caused a memory corruption. The chicken + garbage collector moved a pointer out from under us. + This is now fixed by running all the proxy creation + functions as continuations after the wrapper function + returns. As part of this, we no longer need the + chickenfastproxy flag on output typemaps. + - using -proxy and -nocollection together works now + Before, it was not exporting the destructor in the proxy + wrapper. + +10/18/2005: mmatus + + Added the Unified Typemap Library (UTL). It unifies the typemaps for + + python, ruby, tcl + + and in the process, fixes several problems in each of the three + languages to work in a "canonical" way now established in + the typemap library + + SWIG/Lib/typempas + + The current status of the unification is that everything + compiles and runs inside the test-suite and examples + directories. And for the first time we have three + languages than pass the primitive_types.i case. + + Also, we have a uniform way to treat the errors, for example + if you do something like + + >>> from primitive_types import * + >>> print val_uchar(10) + 10 + >>> print val_uchar(1000) + Traceback (most recent call last): + File "<stdin>", line 1, in ? + OverflowError: in argument 1 of type 'unsigned char' + + you get the same exception in all the three languages. + + And well, many more good things will come from this + unification, for example, proper support of the STL/STD classes + for all the languages, and hopefully, we can keep + adding other languages. + + The hardest part, writing a common typemap library + that suites the three different languages, is done, + and adding another language should now be easy. + + Still the global unification is not complete, the STL/STD + part is next, and probably as well as adding one or two more + languages. + + If you are curious, look at the python, ruby and/or tcl + directories to see what is needed to support the new + common typemaps library. Still, the final way to + integrate a new language could change as we move to + integrate the STD/STL. + + *** POTENTIAL INCOMPATIBILITY in Ruby/Tcl *** + + Some missing/wrong typemaps could start working properly, + and change the old behavior, specially in ruby and tcl. + Version 1.3.27 (October 15, 2005) ================================= |