gmane.comp.programming.swig.devel

[ swig-Bugs-2080497 ] [python] type checking inpystdcommon.swg

SourceForge.net — 2008-11-29T18:31:25

Bugs item #2080497, was opened at 2008-08-28 13:12 Message generated for change (Comment added) made by wsfulton 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 Priority: 5 Private: No Submitted By: Romain Boman (r_boman) Summary: [python] 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: fro

[ swig-Bugs-2174783 ] Error when compiling SWIG code,argv[0] may be uninitialized

SourceForge.net — 2008-11-29T17:56:06

Bugs item #2174783, was opened at 2008-10-17 13:31 Message generated for change (Comment added) made by wsfulton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101645&aid=2174783&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: Ilmar Wilbers (ilmarw) Assigned to: Nobody/Anonymous (nobody) Summary: Error when compiling SWIG code, argv[0] may be uninitialized Initial Comment: We are compiling the SWIG wrapper with -Werror. With gcc > 4.3, the builds are exiting with the following message: dolfin/swig/dolfin_wrap.cc: In function 'PyObject* _wrap_new_Mesh(PyObject*, PyObject*)': dolfin/swig/dolfin_wrap.cc:69695: error: 'argv[0]' may be used uninitialized in this function If we substitute 'Type v;' with 'Type v=0;' the compilation is successfull. This seem

[ swig-Bugs-2359417 ] Type system broken for pointersand the STL

SourceForge.net — 2008-11-29T17:51:10

Bugs item #2359417, was opened at 2008-11-29 17:51 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=2359417&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: William Fulton (wsfulton) Assigned to: Nobody/Anonymous (nobody) Summary: Type system broken for pointers and the STL Initial Comment: The type system is broken when using the STL and pointers. Testcase below (li_std_vector_ptr.i - checked into svn): %module li_std_vector_ptr %include "std_vector.i" %template(IntPtrVector) std::vector; %inline %{ #include using namespace std; int* makeIntPtr(int v) { return new int(v); } double* makeDoublePtr(double v) { return new double(v); } #if 1 int

[Lua] Check unsigned arguments to be positive

Jérôme Pouiller — 2008-11-28T11:09:44

In Lua binding, number arguments are directly casted to target type, like this: $1 = ($type)lua_tonumber(L, $input); There is no check for unsigned numbers. So, for exemple: Lua> getElementInMyVector(-1) ... crash ... I suggest to use patch in attachment to correct this behaviour. Nevertheless, I am not familiar with Swig macros, so it may exist better way to correct this. Cheers,

[Patch] Fix parsing of nested structures with comments

Kalyanov Dmitry — 2008-11-27T22:16:23

------------------------------------------------------------------------- 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=/

[Lua] Check unsigned arguments to be positive

Jérôme Pouiller — 2008-11-27T08:38:44

[ swig-Patches-2340105 ] little fix for wrongformatting in perl code

SourceForge.net — 2008-11-24T21:09:49

Patches item #2340105, was opened at 2008-11-24 22:09 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=2340105&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: Arkadiusz Miskiewicz (arekm) Assigned to: Nobody/Anonymous (nobody) Summary: little fix for wrong formatting in perl code Initial Comment: Patch speaks for itself. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=301645&aid=2340105&group_id=1645 ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the cooles

Re: php4 removal

Olly Betts — 2008-11-24T15:11:44

Not *ALL* I think - uses in user-visible stuff should ideal have compatibility aliases - e.g. %pragma(php4) should probably continue to work but %pragma(php) should be added and be the preferred way to write that. Anything purely internal can (and should) be updated. I just haven't had much spare time recently, and have been trying to focus on getting more of the test suite working. I don't know if anything should be php5 instead of just php - I've not looked at php6 development at all - but "php" is certainly better than "php4" at this point even if we have to change it again later. Cheers, Olly ------------------------------------------------------------------------- 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=/

php4 removal

William S Fulton — 2008-11-23T22:43:48

For Olly mostly... Is it okay to finish tidying up the php4 removal, ie can I change all the references to php from php4 ? For example the Examples/Makefile and SWIG_Php4_GetModule() and SWIG_Php4_SetModule ? William ------------------------------------------------------------------------- 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-2263850 ] [ruby] Fix compilation withruby-1.9.1

SourceForge.net — 2008-11-23T22:28:09

Patches item #2263850, was opened at 2008-11-11 18:21 Message generated for change (Settings changed) made by wsfulton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=301645&aid=2263850&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: Alex (bro_ken_toy) Summary: [ruby] Fix compilation with ruby-1.9.1 Initial Comment: Currently, SWIG-generated code will not compile against the latest version of ruby, 1.9.1-preview. This is because SWIG's code includes the header "rubyio.h" which has been removed in the latest versions of Ruby. The attached patch checks for this and correctly includes the header for both ruby 1.8 and ruby 1.9. I hope this can be applied and released soon please, as Ruby 1.9 is due to become the stable version next month. Currently, no SWIG code will work. ---------

[ swig-Patches-2263850 ] [ruby] Fix compilation withruby-1.9.1

SourceForge.net — 2008-11-23T22:27:45

Patches item #2263850, was opened at 2008-11-11 18:21 Message generated for change (Comment added) made by wsfulton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=301645&aid=2263850&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: Alex (bro_ken_toy) Assigned to: Nobody/Anonymous (nobody) Summary: [ruby] Fix compilation with ruby-1.9.1 Initial Comment: Currently, SWIG-generated code will not compile against the latest version of ruby, 1.9.1-preview. This is because SWIG's code includes the header "rubyio.h" which has been removed in the latest versions of Ruby. The attached patch checks for this and correctly includes the header for both ruby 1.8 and ruby 1.9. I hope this can be applied and released soon please, as Ruby 1.9 is due to become the stable

[ swig-Bugs-2319790 ] std::tr1::shared_ptr does notwork properly

SourceForge.net — 2008-11-23T22:00:00

Bugs item #2319790, was opened at 2008-11-21 07:59 Message generated for change (Settings changed) made by wsfulton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101645&aid=2319790&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: code generation (general) Group: None Priority: 5 Private: No Submitted By: Johan (johanhake) Assigned to: Nobody/Anonymous (nobody) Summary: std::tr1::shared_ptr does not work properly Initial Comment: In the macro SWIG_SHARED_PTR_DERIVED in the file shared_ptr.i there is a bug that appear when trying to wrapp c++ code that uses std::tr1::shared_ptr. Setting: #define SWIG_SHARED_PTR_NAMESPACE std #define SWIG_SHARED_PTR_SUBNAMESPACE tr1 will not produce the right code from the macro. The macro refer to SWIG_SHARED_PTR_NAMESPACE instead of SWIG_SHARED_PTR_QNAMESPACE. A patch that resolves the bug is p

[ swig-Bugs-2319790 ] std::tr1::shared_ptr does notwork properly

SourceForge.net — 2008-11-23T21:59:46

Bugs item #2319790, was opened at 2008-11-21 07:59 Message generated for change (Comment added) made by wsfulton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101645&aid=2319790&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: code generation (general) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Johan (johanhake) Assigned to: Nobody/Anonymous (nobody) Summary: std::tr1::shared_ptr does not work properly Initial Comment: In the macro SWIG_SHARED_PTR_DERIVED in the file shared_ptr.i there is a bug that appear when trying to wrapp c++ code that uses std::tr1::shared_ptr. Setting: #define SWIG_SHARED_PTR_NAMESPACE std #define SWIG_SHARED_PTR_SUBNAMESPACE tr1 will not produce the right code from the macro. The macro refer to SWIG_SHARED_PTR_NAMESPACE instead of SWIG_SHARED_PTR_QNAMESPACE. A patch

[ swig-Bugs-2277850 ] test suite does not compile

SourceForge.net — 2008-11-23T21:48:40

Bugs item #2277850, was opened at 2008-11-13 18:32 Message generated for change (Settings changed) made by wsfulton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101645&aid=2277850&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: csharp Group: None Priority: 5 Private: No Submitted By: Mathieu Malaterre (malat) Assigned to: William Fulton (wsfulton) Summary: test suite does not compile Initial Comment: checking testcase li_boost_shared_ptr (with run test) under csharp In file included from /usr/include/c++/4.3/x86_64-linux-gnu/bits/gthr.h:132, from /usr/include/c++/4.3/ext/atomicity.h:39, from /usr/include/c++/4.3/bits/basic_string.h:46, from /usr/include/c++/4.3/string:58, from li_boost_shared_ptr_wrap.cxx:294: /usr/include/c++/4.3/x86_64-linux-gnu/bits/gthr-default.h:

[ swig-Bugs-2277850 ] test suite does not compile

SourceForge.net — 2008-11-23T21:48:32

Bugs item #2277850, was opened at 2008-11-13 18:32 Message generated for change (Comment added) made by wsfulton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101645&aid=2277850&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: csharp Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mathieu Malaterre (malat) Assigned to: William Fulton (wsfulton) Summary: test suite does not compile Initial Comment: checking testcase li_boost_shared_ptr (with run test) under csharp In file included from /usr/include/c++/4.3/x86_64-linux-gnu/bits/gthr.h:132, from /usr/include/c++/4.3/ext/atomicity.h:39, from /usr/include/c++/4.3/bits/basic_string.h:46, from /usr/include/c++/4.3/string:58, from li_boost_shared_ptr_wrap.cxx:294: /usr/include/c++/4.3/x86_64-lin

Patch: Problem with %module(package="x.y.z")

anders musikka — 2008-11-23T18:58:30

Hello list! I've had some problems with swig-1.3.36. Namely, the %module(package="x.y.z") feature doesn't appear to work. After reading the code, I can see why it doesn't. It is supposed to write full package names to the .py proxy file, when needed. However, those full package names are only written to a string that isn't used. At least that's what it looks like to me. The following patch: diff --git a/Source/Modules/python.cxx b/Source/Modules/python.cxx index aa124a4..9b27dec 100644 --- a/Source/Modules/python.cxx +++ b/Source/Modules/python.cxx < at >< at > -862,8 +862,8 < at >< at > public: if (!options || (!Getattr(options, "noshadow") && !Getattr(options, "noproxy"))) { Printf(import, "_%s\n", modname); if (!Strstr(f_shadow_imports, import)) { - Printf(f_shadow, "import %s\n", modname); - Printv(f_shadow_imports, import, NULL); + //Printf(f_shadow, "import %s\n", modname); + Printv(f_shadow, import, NULL); } }

SWIG fails to parse some combination of struct's andcomments

Kalyanov Dmitry — 2008-11-21T13:50:20

When given the following input: ---begin comments.i--- %module "comments" struct A { struct { /*struct*/ struct { int b; }c; }d; }; --end comments.i--- and compiled as /usr/bin/swig -python comments.i the following error is given: :10: Error: p��comments.i:10: Error: Syntax error in input(3). or :10: Error: p.comments.i:10: Error: Syntax error in input(3). or :10: Error: p��comments.i:10: Error: Syntax error in input(3). (there are some random characters between 'Error: ' and 'comments.i'. They are different for every run) If I remove the comment (/*struct*/) no error is given and output files are produced. If I edit the comment to something other that does not include 'struct', 'class', 'union' as a substring then no error is given and output files are produced. This particular pattern occurs, for example, in gtk+ (in file gtk/gtktypeutils, struct _GtkArg). ------------------------------------------------------------------------- This SF.Net email is sponsored by the Mo

[ swig-Bugs-2319790 ] std::tr1::shared_ptr does notwork properly

SourceForge.net — 2008-11-21T07:59:27

Bugs item #2319790, was opened at 2008-11-21 07:59 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=2319790&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: code generation (general) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Johan (johanhake) Assigned to: Nobody/Anonymous (nobody) Summary: std::tr1::shared_ptr does not work properly Initial Comment: In the macro SWIG_SHARED_PTR_DERIVED in the file shared_ptr.i there is a bug that appear when trying to wrapp c++ code that uses std::tr1::shared_ptr. Setting: #define SWIG_SHARED_PTR_NAMESPACE std #define SWIG_SHARED_PTR_SUBNAMESPACE tr1 will not produce the right code from the macro. The macro refer to SWIG_SHARED_PTR_NAMESPACE instead of SWIG_SHARED_PTR_QNAMES

Bug with version 1.3.36 Ruby directors module

Sam Hendley — 2008-11-19T22:34:00

[ swig-Bugs-2313212 ] Multi-argument typemaps withoutvariable names do not work

SourceForge.net — 2008-11-19T04:35:12

Bugs item #2313212, was opened at 2008-11-18 18:52 Message generated for change (Comment added) made by jamesm17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101645&aid=2313212&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: code generation (general) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: James Masters (jamesm17) Assigned to: Nobody/Anonymous (nobody) Summary: Multi-argument typemaps without variable names do not work Initial Comment: I want to create a typemap for two sequential argument types but I don't want to specify the variable names. The documentation states that this should be possible, but multi-argument typemaps only seem to work when variable names are given: ----------------------------- %module multi_test; /* // Does not work %typemap(default) (int &, int &) { // FOUND } */

[ swig-Bugs-2313691 ] Multi-argument typemaps withoutvariable names do not work

SourceForge.net — 2008-11-19T04:34:23

Bugs item #2313691, was opened at 2008-11-18 20:32 Message generated for change (Settings changed) made by jamesm17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101645&aid=2313691&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: code generation (general) Group: None Status: Open Priority: 5 Private: No Submitted By: James Masters (jamesm17) Assigned to: Nobody/Anonymous (nobody) Summary: Multi-argument typemaps without variable names do not work Initial Comment: I want to create a typemap for two sequential argument types but I don't want to specify the variable names. The documentation states that this should be possible, but multi-argument typemaps only seem to work when variable names are given: ----------------------------- %module multi_test; /* // Does not work %typemap(default) (int &, int &) { // FOUND } */ // Works %type