gmane.comp.programming.swig.devel

JAVA_ARRAYSOFCLASSES again

Jean-Yves Lionel Lawson — 2008-08-29T10:21:11

Hi, I've already posted this request to the swig-user list but couldn't get any answers. Maybe I sent it to the wrong mailing list, so I'm reposting here hoping I'll get any clues. I'm having troubles using the JAVA_ARRAYSOFCLASSES macro with an array of classes declared in c++ like "MyClass** list;". I've read other posts talking about it and succeeded in having simple examples(no double pointers **) working. However the following configuration does fail: ->My MyClassTest.i file contains -------MyClassTest.i------------ %module MyClassTest %include "typemaps.i" %include "arrays_java.i" %include "various.i" JAVA_ARRAYSOFCLASSES(MyClass) %apply MyClass[] { MyClass** list} %include "MyClassDef.h" ------------------------------ ->MyClassDef.h contains ------MyClassDef.h ----------- MyClass{ public: int i; int j; int foobar(); bool barfoo(); }; class MyClasses{ public: void bar(int i); void foo(); MyClass** list; }; -------------------------------- ->The generated MyClassTest_wrap.cxx is wrong(but compiles) and contains the following code for accessing the MyClass Array: -----MyClassTest_wrap.cxx--------------------- SWIGEXPORT jlongArray JNICALL Java_myPackage_MyClassTestJNI_MyClasses_1list_1get(JNIEnv *jenv, jclass jcls, jlong jarg1, jobject jarg1_) { jlongArray jresult = 0 ; MyClasses *arg1 = (MyClasses*) 0 ; MyClasses **result = 0 ; (void)jenv; (void)jcls; (void)jarg1_; arg1 = *(MyClasses **)&jarg1; result = (MyClass **) ((arg1)->list); *(MyClass ***)&jresult = result; return jresult; } --------------------------------------------------- ->The generated Java wrapper is also wrong(and do not compile) as MyClasses.java contains the following accessor code: ----------------MyClasses.java----------------- public SWIGTYPE_p_p_MyClass[] getList() { return SWIGTYPE_p_p_MyClass.cArrayWrap(MyClassTestJNI.MyClasses_list_get(swigCPtr, this), false); } ---------------------------------------------- I'm using "swig -c++" (1.3.35) under windows with MinGW Do you have any clues why the correct code is not generated when I'm trying to use JAVA_ARRAYSOFCLASSES with an array of classes declared like "MyClass** list"? Many Thanks. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

[ swig-Patches-2081967 ] [mzscheme] Make SWIG buildwith recent PLT versions

SourceForge.net — 2008-08-29T07:50:01

Patches item #2081967, was opened at 2008-08-29 11:49 Message generated for change (Settings changed) made by ddzhus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=301645&aid=2081967&group_id=1645 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Dmitry Dzhus (ddzhus) Assigned to: Nobody/Anonymous (nobody) Initial Comment: Current SWIG version (1.3.36 and SVN) fails to build with any recent PLT version. I've attached a patch to fix it. Probably more patching needed for MzScheme module as it seems to be unmaintained. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=301645&aid=2081967&group_id=1645 ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

[ swig-Patches-2081967 ] [mzscheme]

SourceForge.net — 2008-08-29T07:49:17

Patches item #2081967, was opened at 2008-08-29 11:49 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=301645&aid=2081967&group_id=1645 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Dmitry Dzhus (ddzhus) Assigned to: Nobody/Anonymous (nobody) Summary: [mzscheme] Initial Comment: Current SWIG version (1.3.36 and SVN) fails to build with any recent PLT version. I've attached a patch to fix it. Probably more patching needed for MzScheme module as it seems to be unmaintained. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=301645&aid=2081967&group_id=1645 ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

[ swig-Bugs-2080497 ] type checking in pystdcommon.swg

SourceForge.net — 2008-08-28T13:12:49

Bugs item #2080497, was opened at 2008-08-28 15:12 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101645&aid=2080497&group_id=1645 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: python Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Romain Boman (r_boman) Assigned to: Nobody/Anonymous (nobody) Summary: type checking in pystdcommon.swg Initial Comment: I have just found a problem concerning type checking when using a std::vector as input argument. Here is a small module containing 2 new classes A and B %module castswig %{ #include %} %include "std_vector.i" %inline { class A { public: A() { std::cout << "A constructor\n"; } }; } %template() std::vector; %inline { class B { public: B(const std::vector &listA) { std::cout << "B constructor\n"; } }; } And my python file showing the bug: from castswig import * a1=A() a2=A() b1 = B( [a1,a2] ) # <= OK b2 = B( [1,2] ) # <= should fail The problem is the last statement does not fail athough the input list contains integers instead of A objects! I think the bug is located in "Lib/python/pystdcommon.swg" (line 49) template struct traits_asptr { static int asptr(PyObject *obj, Type **val) { Type *p; int res = (SWIG_ConvertPtr(obj, (void**)&p, type_info(), 0) == SWIG_OK) ? SWIG_OLDOBJ : 0; if (SWIG_IsOK(res)) { if (val) *val = p; } return res; } }; The "res" variable is always 0(SWIG_OLDOBJ=0) after the call of SWIG_ConvertPtr. That's why "SWIG_IsOK(res)" is always true and the cast is always done. I have replaced this line by: int res = SWIG_ConvertPtr(obj, (void**)&p, type_info(), 0); and it seems to work. An exception is thrown as expected and "b2 = B([1,2])" fails as it should. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101645&aid=2080497&group_id=1645 ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

[ swig-Patches-2079381 ] [cffi] constant exprs putinto no-eval context in DEFCENUM

SourceForge.net — 2008-08-27T23:16:21

Patches item #2079381, was opened at 2008-08-28 03:16 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=301645&aid=2079381&group_id=1645 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Boris Smilga (agrostis) Assigned to: Nobody/Anonymous (nobody) Summary: [cffi] constant exprs put into no-eval context in DEFCENUM Initial Comment: The CFFI front end translates C enumerations to DEFCENUM forms. If, in the C source, an enumerator is encountered which has a constant expression for value (cf. C99, sec. 6.7.2.2 (1), second clause of the production), the constant expression is translated into Lisp and written within the DEFCENUM form. However, the macro use (CFFI:DEFCENUM ... ( ) ... ) when expanded, inserts these expressions as ... (CFFI::MAKE-FOREIGN-ENUM (QUOTE ) (QUOTE :INT) (QUOTE ( ... ( ) ... ))) ... This means that s are not evaluated. That's perfectly OK for a self-evaluating , such as an integer literal, but integer expressions with one or more operators (e.g. shifts or bit arithmetics which are quite common in such contexts) translate to Lisp forms, i.e. lists. Unless evaluated, these cannot serve as integer values. One solution is to use the sharpsign-dot notation with every , thus making them evaluate at read time (cf. Common Lisp HyperSpec, sec. 2.4.8.6). The patch is outrageously simple (duplicated in attachment): --- Source/Modules/cffi.cxx~ 2008-05-22 02:15:52.000000000 +0400 +++ Source/Modules/cffi.cxx 2008-08-28 01:14:22.000000000 +0400 < at >< at > -630,7 +630,7 < at >< at > else { String *type = Getattr(c, "type"); String *converted_value = convert_literal(value, type); - Printf(f_cl, "\n\t(%s %s)", slot_name, converted_value); + Printf(f_cl, "\n\t(%s #.%s)", slot_name, converted_value); Delete(converted_value); } Delete(value); ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=301645&aid=2079381&group_id=1645 ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

GSoC Python 3.0 Support - Final Report

Haoyu Bai — 2008-08-26T13:10:38

Hello, The Google Summer of Code 2008 is finished. I think the final status of my project is mostly meet my project proposal (http://www.dabeaz.com/cgi-bin/wiki.pl?GSoCPython3Proposal). Even more, at some point it is better than the proposal, for example, we can have only one proxy .py file and one _wrap.c/cxx file generated for both 2.x and 3.0. Python 3 released the last beta, and when I'm writing this, the SWIG Python test suite can run successfully with Python 3. However, Python 3 still not be released so the C API is possible to be changed in future, so I will continue to maintain the Python backend. My project also includes three new features: function annotation support, buffer interface support and abstract base class support. Especially, the latter two features are done after the GSoC mid-term, so let me introduce them: Buffer interface support: when cooperating with Python 3 (and 2.6)'s new mutable bytearray data type, the buffer interface support allow you to treat the 'output pointer' in a more C-like style. For example, if you have a function writes something into a string buffer: vood write_into(char *str); Then in Python side you can do: s = bytearray(256) write_into(s) It could be more intuitive and faster. ABC support: now the proxies of STL classes able to have an proper abstract base class. For example, collections.MutableSequence for std::list and collections.MutableMap for std::map. I also appended a new section called "Python 3 Support" in the "SWIG and Python" chapter of SWIG document. So you can read it for these new features. I have learnt many things by doing this project. Thanks for the help of Richard Boulton, William Fulton, and Olly Betts! :) I'm very enjoy to work with you, also, I'd like to continue maintain and improve the Python backend after Summer of Code. Thanks!

COM status report

Jan Jezabek — 2008-08-19T17:09:59

Hi, Here is the COM module status report for the last week. As always feel free to respond with any comments/suggestions that you have. I have been somewhat busy with university work lately and therefore have not been able to do as much as I would like to. I have concentrated mostly on improving the test coverage and finishing the documentation. Below is a list of things I have been working on: - Support for running the test suite under Cygwin has been added, using GCC (MinGW/Cygwin), MSVC or Digital Mars C++ (to ensure good compatibility of the generated code), - The build system now supports run-tests written in VBScript in addition to C, which makes writing tests much easier. This requires that Windows Script Host is installed - it works out of the box on Windows/Cygwin and also on Linux/Wine with a lot of tweaking, - I set up a Wiki page with instructions for testing, available here: http://www.dabeaz.com/cgi-bin/wiki.pl?DeveloperInfo/COMTesting - I added two examples ('simple' and 'class') and 6 new VBScript run tests; this uncovered a regression in the class factory code and imperfect detection of non-instantiable classes - both issues have been fixed, - I finished the module documentation with the exception of smart pointers; I haven't looked at them yet and don't know how they should work, - Bug fixes and minor additions: added checking for NULL arguments where necessary, added typemaps for char *& and wchar_t *&, removed unused fragments of the code. The overall state of my module is pretty good in my opinion - there is a reasonably small number of failing tests (29 out of 349 on Cygwin/MSVC), all major features except for smart pointers and directors are implemented, there are no known bugs where the generated code compiles but fails to work correctly. There are still some things that I would like to work on before I would like the module to be considered for inclusion in mainline SWIG - e.g. better handling of opaque types, more consistent naming of generated functions, preventing potential name clashes in the generated code, more complete INPUT, OUTPUT, INOUT typemaps, better error reporting using SetErrorInfo, support for DCOM (I am still not sure how much is needed for it to work), better compatibility with VB (e.g. using VT_BOOL for booleans). Thanks, Jan Jezabek

COM status report

Jan Jezabek — 2008-08-12T21:52:47

Hi Ian (and list), It's been a long time since the last status report - sorry for that. I haven't been sitting idle though. Here is what I have been working on in the last two weeks: - support for constants which are wrapped as read-only properties in the module class, - support for enums (type unsafe for now). COM has a very obscure enum feature, which is rather useless. Therefore enum values are currently just constants in the appropriate scope (e.g. if a class defines an enum then the constants are not in the module class which corresponds to global scope), - added of typemaps for char *, std::string, std::wstring (all mapped to the OLE BSTR type, using character set conversion if necessary), - added INPUT, OUTPUT, INOUT typemaps for all primitive types, - changed wrapped function declarations to return HRESULT, converting the real return value to a [ retval, out ] parameter. This is required for OLE Automation and for DCOM, - added stub exception handlers, simply returning E_ABORT, - various bugfixes which brought the number of non-compiling tests from 117 down to 25, - made some changes to allocate.cxx to enable detecting overloading of functions which are inherited from base classes and the corresponding changes to the COM module, - added a feature that I call 'class objects' (suggestions for a better name are welcome) used to work around the lack of static functions in COM. In short this is meant to be used if you need to call a static method of a class but you do not have an instance of that class. This is probably best shown by an example: ----- /* example.i */ %module example class MyClass { public: virtual void something() = 0; // abstract static char *sayHello() { return "Hello world!"; } }; ----- In VBScript you can now use it as follows: ----- Rem test.vbs Dim example Rem Create the module class object Set example = CreateObject("example.example") WScript.Echo example.MyClass.sayHello() ----- This works also for static variables. Below the surface MyClass is a read-only property of the module class which returns an object implementing an interface containing all static functions and variables from MyClass. Static functions and variables can still be accessed from a normal instance of MyClass for convenience. - I created documentation for the COM module, which is not yet complete, - I have also added some typemaps for std classes, taken mostly from Java with some minor changes to work around the lack of function overloading in COM. I have a question about the typemaps for std::* - I have seen lots of different typemaps for std_map, std_deque, std_vector, etc. in std/, java/, csharp/, python/. Are there any guidelines of what should be in these typemaps? I have seen that these files are radically different from each other which is a little confusing. For this week I plan to finish the documentation, add more run-tests and some examples and perform some code cleanup afterwards. I have a (rather large) backlog of small things that I would still like to improve, but I probably will not be able to do much work on them this week. As always suggestions and comments are very welcome. Thanks, Jan Jezabek ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

[ swig-Bugs-2021598 ] segfault on inclusion ofstd_vector.i [ruby]

SourceForge.net — 2008-08-12T14:53:34

Bugs item #2021598, was opened at 2008-07-18 11:23 Message generated for change (Comment added) made by neomantra You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101645&aid=2021598&group_id=1645 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: ruby Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alex Norman (alexnorman) Assigned to: Nobody/Anonymous (nobody) Summary: segfault on inclusion of std_vector.i [ruby] Initial Comment: I have tested this with the most recent version of swig (1.3.36) as well as the ubuntu package. If I include std_vector.i in my swig wrapper and make a ruby wrapper, I get a segfault right when I start my app. I am not building the swig wrapper into a library, I am building it directly into my application and calling Foo_init(); I have attached a small example which works fine with out std_vector.i but segfaults when starting the app if I include std_vector.i. By the way, I am building under ubuntu/linux hardy (8.04LTS). when I include std_vector.i i also get these errors while building: swig -Wall -c++ -ruby foo.i /usr/local/share/swig/1.3.36/ruby/rubycontainer_extended.swg:136: Warning(322): Redundant redeclaration of 'map_bang', /usr/local/share/swig/1.3.36/ruby/rubycontainer_extended.swg:136: Warning(322): previous declaration of 'map_bang'. /usr/local/share/swig/1.3.36/ruby/rubycontainer_extended.swg:136: Warning(322): Redundant redeclaration of '__delete__', /usr/local/share/swig/1.3.36/ruby/rubycontainer_extended.swg:136: Warning(322): previous declaration of '__delete__'. /usr/local/share/swig/1.3.36/ruby/rubycontainer_extended.swg:137: Warning(322): Redundant redeclaration of 'map_bang', /usr/local/share/swig/1.3.36/ruby/rubycontainer_extended.swg:137: Warning(322): previous declaration of 'map_bang'. /usr/local/share/swig/1.3.36/ruby/rubycontainer_extended.swg:137: Warning(322): Redundant redeclaration of '__delete__', /usr/local/share/swig/1.3.36/ruby/rubycontainer_extended.swg:137: Warning(322): previous declaration of '__delete__'. /usr/local/share/swig/1.3.36/ruby/rubycontainer_extended.swg:138: Warning(322): Redundant redeclaration of 'map_bang', /usr/local/share/swig/1.3.36/ruby/rubycontainer_extended.swg:138: Warning(322): previous declaration of 'map_bang'. /usr/local/share/swig/1.3.36/ruby/rubycontainer_extended.swg:138: Warning(322): Redundant redeclaration of '__delete__', /usr/local/share/swig/1.3.36/ruby/rubycontainer_extended.swg:138: Warning(322): previous declaration of '__delete__'. g++ -g foo.cpp main.cpp foo_wrap.cxx -o foo_test -I/usr/lib/ruby/1.8/i486-linux/ -lruby1.8 here is the backtrace from gdb: 09:16:46 $ gdb ./foo_test GNU gdb 6.8-debian Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i486-linux-gnu"... (gdb) run Starting program: /home/alex/projects/swig_vector_segfault/foo_test [Thread debugging using libthread_db enabled] [New Thread 0xb7c026c0 (LWP 30045)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb7c026c0 (LWP 30045)] 0xb7f570de in st_lookup () from /usr/lib/libruby1.8.so.1.8 (gdb) bt #0 0xb7f570de in st_lookup () from /usr/lib/libruby1.8.so.1.8 #1 0xb7f2b312 in rb_intern () from /usr/lib/libruby1.8.so.1.8 #2 0x0804a623 in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) at foo_wrap.cxx:2067 #3 0x0804a776 in global constructors keyed to _ZN4swig8GC_VALUE7hash_idE () at foo_wrap.cxx:4163 #4 0x080504b5 in __do_global_ctors_aux () #5 0x08049654 in _init () #6 0x08050459 in __libc_csu_init () #7 0xb7c683f1 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6 #8 0x08049b51 in _start () (gdb) ---------------------------------------------------------------------- Comment By: Evan Wies (neomantra) Date: 2008-08-12 09:53 Message: Logged In: YES user_id=774353 Originator: NO you might want to see my bug #2048064, which is related to stl and ruby... i discovered it while migrating from Dapper to Hardy. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101645&aid=2021598&group_id=1645 ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

[ swig-Bugs-2048064 ] [ruby] aliases broken with-minherit

SourceForge.net — 2008-08-12T14:51:50

Bugs item #2048064, was opened at 2008-08-12 09:50 Message generated for change (Comment added) made by neomantra You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101645&aid=2048064&group_id=1645 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: ruby Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Evan Wies (neomantra) Assigned to: Gonzalo Garramuno (gga73) Summary: [ruby] aliases broken with -minherit Initial Comment: It appears that %alias is broken with the -minherit flag. I discovered it when binding a vector. One way that this elicits itself is that the STL vector bindings use %alias. It will segfault in registration with a NameError relating to reject! AFACS, this stl binding broke on Ruby between 1.3.29 and 1.3.33, since the newer binding uses some ruby aliases. (I use Ubuntu and one version is Dapper's and the other is Hardy's) The fix is pretty simple (this is against 1.3.36, but is equally applicable to other versions): --- Source/Modules/ruby.cxx.old 2008-08-12 10:49:03.000000000 -0400 +++ Source/Modules/ruby.cxx 2008-08-12 10:20:40.000000000 -0400 < at >< at > -1234,7 +1234,11 < at >< at > Iterator alias = First(aliases); while (alias.item) { if (Len(alias.item) > 0) { - Printv(klass->init, tab4, "rb_define_alias(", klass->vname, ", \"", alias.item, "\", \"", iname, "\");\n", NIL); + if (multipleInheritance) { + Printv(klass->init, tab4, "rb_define_alias(", klass->mImpl, ", \"", alias.item, "\", \"", iname, "\");\n", NIL); + } else { + Printv(klass->init, tab4, "rb_define_alias(", klass->vname, ", \"", alias.item, "\", \"", iname, "\");\n", NIL); + } } alias = Next(alias); } ---------------------------------------------------------------------- Date: 2008-08-12 09:51 Message: Logged In: YES user_id=774353 Originator: YES the attached file works fine without -minherit, but segfaults on load with that flag enabled File Added: inherit_test.i ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101645&aid=2048064&group_id=1645 ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

[ swig-Bugs-2048064 ] [ruby] aliases broken with-minherit

SourceForge.net — 2008-08-12T14:50:34

Bugs item #2048064, was opened at 2008-08-12 09:50 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101645&aid=2048064&group_id=1645 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: ruby Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Evan Wies (neomantra) Assigned to: Gonzalo Garramuno (gga73) Summary: [ruby] aliases broken with -minherit Initial Comment: It appears that %alias is broken with the -minherit flag. I discovered it when binding a vector. One way that this elicits itself is that the STL vector bindings use %alias. It will segfault in registration with a NameError relating to reject! AFACS, this stl binding broke on Ruby between 1.3.29 and 1.3.33, since the newer binding uses some ruby aliases. (I use Ubuntu and one version is Dapper's and the other is Hardy's) The fix is pretty simple (this is against 1.3.36, but is equally applicable to other versions): --- Source/Modules/ruby.cxx.old 2008-08-12 10:49:03.000000000 -0400 +++ Source/Modules/ruby.cxx 2008-08-12 10:20:40.000000000 -0400 < at >< at > -1234,7 +1234,11 < at >< at > Iterator alias = First(aliases); while (alias.item) { if (Len(alias.item) > 0) { - Printv(klass->init, tab4, "rb_define_alias(", klass->vname, ", \"", alias.item, "\", \"", iname, "\");\n", NIL); + if (multipleInheritance) { + Printv(klass->init, tab4, "rb_define_alias(", klass->mImpl, ", \"", alias.item, "\", \"", iname, "\");\n", NIL); + } else { + Printv(klass->init, tab4, "rb_define_alias(", klass->vname, ", \"", alias.item, "\", \"", iname, "\");\n", NIL); + } } alias = Next(alias); } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101645&aid=2048064&group_id=1645 ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

GSoC Python 3.0 Support Weekly Status Report #16

Haoyu Bai — 2008-08-12T04:34:33

Hello, Last week I did bug fixes and code clean up, also I have followed up the Python 3's new API change: the removal of PyUnicode_AsString. I have defined a series of SWIG API, SWIG_Python_str_*, to uniform some string APIs of Python 2 and 3, and then a lot of code like #if PY_VERSION_HEX >= 0x03000000 get eliminated. This week is the final week of GSoC, so I'll continue to hunt and fix bugs, and write documentation. Thanks!

Python 1.x and -apply support

Haoyu Bai — 2008-08-11T15:22:43

Hi, I just found my implementation of the Python backend accidentally dropped the '-apply' feature. Should we continue to support the -apply? As I know, the apply() is only useful in Python 1.x, since 2.0 introduced the extended call syntax, eg. the foo(*arg, **kw) calling style. However, Python 1.x is so old, could we drop it? Thanks.

Some problems with function hiding (C# new)

Jan Jezabek — 2008-08-07T11:45:12

Hi, I ran across a bug (?) in Allocate::function_is_defined_in_bases shown by this example: %module bbase %rename (aaa2) B::aaa(); %rename (bbb) B::bbb2(); %inline %{ class A { public: int aaa(); int bbb(); int ccc; }; class B : public A { public: int aaa(); int bbb2(); void ccc(int); }; %} The problem is the incorrect generation of the "hides" attribute - B::aaa2 has this attribute set while B::bbb has it cleared. Thus B::aaa2 is declared as "new" in C# and B::bbb is not, leading to complaints from the compiler in both cases. A somewhat related problem arises with ccc - here mcs (version 0.96) also complains that the "new" keyword is needed; the parameters of B::ccc do not matter. I am unable to test under MS .NET, but I believe that mcs is right. Regarding the first problem - it seems that marking methods as "hides" should be done in case of the same "sym:name", while marking them as "overrides" needs to be done based on "name". Am I right here? I will try to come up with a patch shortly to show what I have in mind. I have not yet really looked at the second problem. I am planning to do a small change to Allocate::function_is_defined_in_bases for the COM module - I need to check whether a function is overloading a name which was defined in a superclass, e.g.: class X { public: void aaa(); }; class Y : public X { public: void aaa(int); }; COM cannot handle overloading and thus I need to ignore aaa(int). Therefore I plan to add an "overloads_base" attribute for this case. This situation is very similar to the situation when "hides" is set so I decided that Allocate::function_is_defined_in_bases is the right place to detect this case. I will send the relevant code as a separate patch. Thanks, Jan Jezabek

GSoC Python 3.0 Support Weekly Status Report #15

Haoyu Bai — 2008-08-05T09:00:31

Hello, Last week I finished the Python 3.0's abstract base class support. (See PEP 3119 -- Introducing Abstract Base Classes for detail of the ABC: http://www.python.org/dev/peps/pep-3119/) If you have ever used SWIG to wrap STL classes, now you can try to add an include line in your interface file: %include Then your std::list, std::vector, std::set, std::map and other STL containers will automatically gain an ABC base class. For example, you can try: issubclass(IntSet, collections.MutableSet) #True issubclass(IntVector, collections.MutableSequence) #also True At this point, almost all the proposed Python 3 related features are implemented. Though there still codes need to review and polish, also some documentation works. Hopefully we can merge the code back to trunk at the end of GSoC.

[ swig-Patches-2019314 ] Allegro List fixes & smallChicken Scheme fix

SourceForge.net — 2008-08-02T08:30:41

Patches item #2019314, was opened at 2008-07-16 03:53 Message generated for change (Comment added) made by wuzzeb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=301645&aid=2019314&group_id=1645 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Priority: 5 Private: No Submitted By: Lorenz Msenlechner (moesenle) Assigned to: Nobody/Anonymous (nobody) Summary: Allegro List fixes & small Chicken Scheme fix Initial Comment: The generator module for Chicken Scheme seems to have a small bug. On our Debian etch system, it is necessary to add #include by hand to the c++ file generated by SWIG. The problem can be easily solved by adding the include line to chicken.swg. The generator module for Allegro Lisp seems to be quite broken, especially for c++. First of all, it is not possible to specify absolute path names for the input file because the path for the common lisp output file is generated wrong, based on the input file path. Further, when generating bindings from a c++ library, the resulting c++ binding file cannot be compiled due to a missing condition for methods with no return value in the generator module. In the try-block, a return expression is still created. The lispification-function in allegrocl.swg also behaves strange. It inserts a '-' whenever a change from lowercase to uppercase is detected in a symbol name, but also when a change from uppercase to lowercase is detected. This is wrong and leads to e.g. the following symbol names: The method 'open' of class Bottle is transformed to bottle_open without lispification and with lispification to b-ottle-open. Apart from these issues, the generated lisp file cannot be compiled in some cases, when some type synonyms cannot be resolved, which leads to empty lines in the lisp code. Further, template classes are causing problems because of the class renaming done in these cases. This can be fixed by changing the lisp-function full-name to take into account type synonyms. Attached, you find a patch to fix all of these issues. It was made against SVN revision 10659. Best regards, Lorenz ---------------------------------------------------------------------- Date: 2008-08-02 03:30 Message: Logged In: YES user_id=153408 Originator: NO Ok, I committed this patch in 10726. I am not really familiar with allegro cl and had no way to test it, but looking at the changes they look ok. Also, I notice now that the chicken test suite spits out a whole bunch of warnings... the output of make check-chicken-test-suite used to be so clean :( Will have to clean up the warnings. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=301645&aid=2019314&group_id=1645 ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

[ swig-Bugs-1604332 ] Swig ca't determine architecturecorrectly

SourceForge.net — 2008-07-31T20:38:14

Bugs item #1604332, was opened at 2006-11-28 09:03 Message generated for change (Comment added) made by wsfulton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101645&aid=1604332&group_id=1645 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: preprocessor Group: None Status: Open Resolution: None Priority: 1 Private: No Submitted By: Adam Tkac (atkac) Assigned to: David M. Beazley (beazley) Summary: Swig ca't determine architecture correctly Initial Comment: 64bit machines swig can't include correctly files. I've created patch for this problem ---Steps to Reproduce--- %module test # Make __NR_syscall names available %include /usr/include/asm/unistd.h:9: Warning(204): CPP #warning, This machine appears to be neither x86_64 nor i386. ---------------------------------------------------------------------- Date: 2008-07-31 20:38 Message: Logged In: YES user_id=242951 Originator: NO The recommended approach is to write an interface file that has the needed methods from the C headers. SWIG provides platform neutral interface files for the C++ STL and you could model your approach on this. If you really want to %include a C library header and you want it to work in a platform specific way (not recommended), then create the macros. Use the info you provided: cpp -dM /dev/null > cppmacros.i then add a %include "cppmacros.i" into your interface file. ---------------------------------------------------------------------- Comment By: Adam Tkac (atkac) Date: 2008-07-28 17:21 Message: Logged In: YES user_id=1655665 Originator: YES I have to reopen this bug because problem is far more generic. When you wrapping something around C source and that source includes some standard header (stdio.h, stdlib.h and others) you have to have macros from C preprocessor. If you don't have it you can use incorrect structures/functions etc. It causes real problems - look into headers, everything is #ifdef-ined One possible solution will be define platform-specific macros directly in swig - this solution was rejected. Other solution will be get macros directly from C preprocessor - at least with GNU C preprocessor you can execute cpp -dM /dev/null and you can use output in swig. What is your status? I will write proposed patch (get macros from cpp on systems which has GNU cpp) if you are interested. If not, would it be possible propose another solution for this problem, please? Regards, Adam ---------------------------------------------------------------------- Comment By: David M. Beazley (beazley) Date: 2006-11-28 13:02 Message: Logged In: YES user_id=7557 Originator: NO Won't fix. SWIG is not a low-level compiler. Moreover, the machine on which SWIG is run is often not the same on which wrapper code is compiled. If you need to do this, use the -D option. swig -python -D__i386__ whatever.i ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101645&aid=1604332&group_id=1645 ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

[ swig-Bugs-2034216 ] SWIG's generated tracking codeerrors with Ruby 1.8.7 / 1.9

SourceForge.net — 2008-07-31T18:37:42

Bugs item #2034216, was opened at 2008-07-31 19:37 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101645&aid=2034216&group_id=1645 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: ruby Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alex (bro_ken_toy) Assigned to: Gonzalo Garramuno (gga73) Summary: SWIG's generated tracking code errors with Ruby 1.8.7 / 1.9 Initial Comment: SWIG's generated tracking code is not compatible with the latest ruby versions : 1.8.7 and 1.9 Specifically, during ruby's garbage collection phase, the function SWIG_RubyRemoveTracking may be called, which in turn calls SWIG_RubyPtrToReference. This converts a void* (ptr to the C++ object) to a ruby numeric corresponding to the pointer address, which is then used as a ruby hash key. The pointer address may convert into a Ruby BigNum, which is a new object allocation. As of Ruby 1.8.7 / Ruby 1.9 object allocation during GC phase is a bug and will crash out with an error message. For the time being we (wxRuby) have worked round this be re-implementing the tracking code using a HashMap class from wxWidgets, but this isn't a general solution. This problem will affect any SWIG/Ruby project that uses the tracking code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101645&aid=2034216&group_id=1645 ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

GSoC Python 3.0 Support Weekly Status Report #14

Haoyu Bai — 2008-07-30T05:32:42

Hi, In last week I finished the Python buffer typemap. After digging into the Python buffer interface, I found it is hard for SWIG wrapped class to expose a buffer interface, because SWIG wrapped C++ class as plain Python object but not a 'type' object implemented in C extension module - the Python buffer interface hooks can only be implemented in C extension module! So, SWIG can only provide some buffer typemap, which can be used as 'consumer' of the protocol. Then, for function annotation, there's a lot of discussion about providing an __annotation__ attribute for built-in and C extension functions: http://bugs.python.org/issue3208 I'd like to work out a patch for it. But now I still thinking about the feasibility of implementing it. Finally, I started a Python wiki page by summarizing my experience of SWIG's Python 3 migration. You can see it here: http://wiki.python.org/moin/Py3kExtensionModules Thanks!

COM progress report

Jan Jezabek — 2008-07-28T21:22:38

Hi, I've noticed that other GSoC-ers are posting their updates to the list, so if nobody opposes I will do the same. My previous reports are available on my blog. I will be grateful for any suggestions regarding the director stuff mentioned in the second half of the report. Thanks, Jan Jezabek ----- This week I have been working mostly on smaller enhancements to the COM, with no major new features. These enhancements are: - ability to specify CLSIDs and IIDs by the user on a per-class basis, as shown by the following example: %feature ("iid", "11111111-1111-1111-1111-111111111111") A; %feature ("clsid", "22222222-2222-2222-2222-222222222222") A; class A { ... }; GUIDs can also be specified for the module class and also for the type library, - I have implemented a GUID generation algorithm (as specified in RFC 4122, variant 5). It uses SHA-1 hashing for generating the GUIDs. The user can (and should) specify one global GUID which can be thought of as a random seed (it is called 'name space ID' in RFC 4122); this GUID in binary form is prepended to the class name and afterwards the hash of this string is used as a source of bits for the CLSID and IID. This should practically guarantee uniqueness and determinism, and also save the user some work, - DllRegisterServer now creates IDispatch names and writes them to the registry. By default the names have the form . (or . in the case of the module class). This can be changed using a command line switch, - I have made the proxy objects aggregatable, - I have improved the way covariant virtual functions work, e.g. if you have the following code: class A { public: virtual A * method() { ... } }; class B : public A { public: virtual B * method() { ... } /* other methods */ }; the COM version of B::method is still declared as returning A*; but now the object returned by B::method is wrapped by a proxy of type B, which means that a call to QueryInterface is enough to be able to access all of B's methods. Before a custom method would be required for downcasting from A* to B*. Other minor fixes include: - memory management bugfixes, noticed after reference counting was redone last week, - IDL generation fixes, which make the generated file more compatible with WIDL and get rid of conditional compilation directives, - test suite infrastructure is now mostly complete; a test case has been imported (virtual_poly), which tests inheritance (including covariant method overriding - see above), static methods and some template features. I have been thinking about what would be needed to support directors. I'm seeing at least two different use cases. Let's say that we have class A with some virtual methods and a function that takes a pointer to A: class A { ... }; void func(A *); In COM this will be transformed to a function taking a pointer to an interface (say IA): void func(IA *); Now we need to deal with two cases: 1. the user creates an object which aggregates our coclass A 2. the user supplies his/her own, totally independent implementation of IA In the first case we can follow the same strategy as in Java - we can create a C++ class which inherits from A and whose virtual methods are upcalls to methods of the wrapping object. If the user has provided his/her own implementation of some part of A's public interface, then the C++ object will call it. The second - broader - case is more tricky, as we have no underlying C++ object associated with the user's implementation of IA. In this case a possible approach would be to create another C++ subclass of A, and wrap the parameter to func in this way: void _wrap_func(IA *arg1) { if (/* case 2. applies */) { SwigDirector_A jarg1(arg1); // SwigDirector_A overrides A's virtual methods to call arg1 func(&jarg1); } } There are some problems with this approach, e.g. a different jarg1 is created for each call; for this reason this form of directors really makes sense if A is a class with only virtual functions and no member variables (because changes to their values are not preserved). An even bigger problem arises when func stores &jarg1 for future use. I'm not really sure how to handle this case. As usual I will be grateful for comments and suggestions :).

[ swig-Bugs-1604332 ] Swig ca't determine architecturecorrectly

SourceForge.net — 2008-07-28T17:21:08

Bugs item #1604332, was opened at 2006-11-28 10:03 Message generated for change (Comment added) made by atkac You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101645&aid=1604332&group_id=1645 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: preprocessor Group: None Priority: 1 Private: No Submitted By: Adam Tkac (atkac) Assigned to: David M. Beazley (beazley) Summary: Swig ca't determine architecture correctly Initial Comment: 64bit machines swig can't include correctly files. I've created patch for this problem ---Steps to Reproduce--- %module test # Make __NR_syscall names available %include /usr/include/asm/unistd.h:9: Warning(204): CPP #warning, This machine appears to be neither x86_64 nor i386. ---------------------------------------------------------------------- Date: 2008-07-28 19:21 Message: Logged In: YES user_id=1655665 Originator: YES I have to reopen this bug because problem is far more generic. When you wrapping something around C source and that source includes some standard header (stdio.h, stdlib.h and others) you have to have macros from C preprocessor. If you don't have it you can use incorrect structures/functions etc. It causes real problems - look into headers, everything is #ifdef-ined One possible solution will be define platform-specific macros directly in swig - this solution was rejected. Other solution will be get macros directly from C preprocessor - at least with GNU C preprocessor you can execute cpp -dM /dev/null and you can use output in swig. What is your status? I will write proposed patch (get macros from cpp on systems which has GNU cpp) if you are interested. If not, would it be possible propose another solution for this problem, please? Regards, Adam ---------------------------------------------------------------------- Comment By: David M. Beazley (beazley) Date: 2006-11-28 14:02 Message: Logged In: YES user_id=7557 Originator: NO Won't fix. SWIG is not a low-level compiler. Moreover, the machine on which SWIG is run is often not the same on which wrapper code is compiled. If you need to do this, use the -D option. swig -python -D__i386__ whatever.i ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101645&aid=1604332&group_id=1645 ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/