headers
SourceForge.net | 1 Sep 2007 02:36
Picon
Favicon

[ swig-Bugs-1785770 ] vector of enums isn't passed correctly

Bugs item #1785770, was opened at 2007-08-31 15:42
Message generated for change (Comment added) made by gga73
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=1785770&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: dsomerfield (dsomerfield)
Assigned to: Gonzalo Garramuno (gga73)
Summary: vector of enums isn't passed correctly

Initial Comment:
I have defined an enum Test::NUMBER and a method with a parameter of type vector<Test::NUMBER>. I have
added an include in the swig file for "std_vector.i" and added a %template directive that should handle
the vector. 

Instead, I get a segfault coming from _wrap_Test_test_enum_vector in the wrapper file. It seems to fail
when calling push_back() on the instance of std::vector<Test::NUMBER > (line 3045). 

The method is called fine if the parameter is std::vector<int> or just Test::Number.

Incidentally, the included code is a stripped-down a larger project wherein I originally saw the bug.
However, since I was calling the method in a different context, the segfault was not occuring, rather the
(Continue reading)

Permalink | Reply | 0 comments |
headers
SourceForge.net | 1 Sep 2007 19:31
Picon
Favicon

[ swig-Bugs-1760125 ] [php] Ref count...

Bugs item #1760125, was opened at 2007-07-25 09:13
Message generated for change (Comment added) made by olly
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=1760125&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: php
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Etienne (evaillant)
Assigned to: kruland (kruland)
Summary: [php] Ref count...

Initial Comment:
Consider the following example:

t01.i:
%module t01
%{
# include <iostream>
# include "t01.hh"
# define TRACE(arg) std::cout << __FILE__ << "(" << __LINE__ << ") : " 
<< arg << std::endl
%}
(Continue reading)

Permalink | Reply | 2 comments |
headers
William S Fulton | 3 Sep 2007 21:40
Picon
Favicon
Gravatar

Ruby C wrappers

Gonzalez, I'm getting lots of these errros when the test-suite runs the 
C tests:

Checking testcase function_typedef under ruby
function_typedef_wrap.c: In function ‘SWIG_Ruby_isCallable’:
function_typedef_wrap.c:1651: error: initializer element is not constant
function_typedef_wrap.c: In function ‘SWIG_Ruby_arity’:
function_typedef_wrap.c:1665: error: initializer element is not constant
make[2]: *** [ruby] Error 1
make[1]: *** [function_typedef.ctest] Error 2

A static variable is being initialised by a function call instead of a 
constant. Have you got a moment to fix please? Maybe these static vars 
can be global and be initialised in the Init_xxxx function instead.

William

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
Permalink | Reply | 0 comments |
headers
mark gossage | 4 Sep 2007 04:01

Re: [Swig-user] swig_type() gives incomplete type name for templates

Hello All,

I just tried this on my copy, it gets real interesting.

===========
%module templ

%inline %{
	
typedef int s32;

template<class T> class Dim {
public:
Dim( T w_, T h_ )
: w(w_), h(h_)
{}
virtual ~Dim() {}
T w, h;
};

template<class T> class Point {
public:
Point( T x_, T y_ )
: x(x_), y(y_)
{}
Point<T> operator+( const Dim<T>& other ) const
{
return Point<T>( x + other.w, y + other.h );
}
virtual ~Point() {}
(Continue reading)

Permalink | Reply | 2 comments |
headers
SourceForge.net | 4 Sep 2007 21:16
Picon
Favicon

[ swig-Bugs-1785770 ] vector of enums isn't passed correctly

Bugs item #1785770, was opened at 2007-08-31 11:42
Message generated for change (Comment added) made by dsomerfield
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=1785770&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: dsomerfield (dsomerfield)
Assigned to: Gonzalo Garramuno (gga73)
Summary: vector of enums isn't passed correctly

Initial Comment:
I have defined an enum Test::NUMBER and a method with a parameter of type vector<Test::NUMBER>. I have
added an include in the swig file for "std_vector.i" and added a %template directive that should handle
the vector. 

Instead, I get a segfault coming from _wrap_Test_test_enum_vector in the wrapper file. It seems to fail
when calling push_back() on the instance of std::vector<Test::NUMBER > (line 3045). 

The method is called fine if the parameter is std::vector<int> or just Test::Number.

Incidentally, the included code is a stripped-down a larger project wherein I originally saw the bug.
However, since I was calling the method in a different context, the segfault was not occuring, rather the
(Continue reading)

Permalink | Reply | 0 comments |
headers
SourceForge.net | 4 Sep 2007 23:52
Picon
Favicon

[ swig-Bugs-1785770 ] vector of enums isn't passed correctly

Bugs item #1785770, was opened at 2007-08-31 11:42
Message generated for change (Comment added) made by dsomerfield
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=1785770&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: dsomerfield (dsomerfield)
Assigned to: Gonzalo Garramuno (gga73)
Summary: vector of enums isn't passed correctly

Initial Comment:
I have defined an enum Test::NUMBER and a method with a parameter of type vector<Test::NUMBER>. I have
added an include in the swig file for "std_vector.i" and added a %template directive that should handle
the vector. 

Instead, I get a segfault coming from _wrap_Test_test_enum_vector in the wrapper file. It seems to fail
when calling push_back() on the instance of std::vector<Test::NUMBER > (line 3045). 

The method is called fine if the parameter is std::vector<int> or just Test::Number.

Incidentally, the included code is a stripped-down a larger project wherein I originally saw the bug.
However, since I was calling the method in a different context, the segfault was not occuring, rather the
(Continue reading)

Permalink | Reply | 0 comments |
headers
William S Fulton | 5 Sep 2007 00:24
Picon
Favicon
Gravatar

Re: %apply CONSTANT warning

Valery Sigalov wrote:
> Hello,
> 
> I am upgrading from version 1.3.19 to 1.3.31. The following code is 
> working fine with the old version:
> 
>  
> 
> #ifdef SWIG
> 
> %{
> 
> #include "test.h"
> 
> %}
> 
> %include "tclsh.i"
> 
> %module test
> 
> %apply int CONSTANT { int x };
> 
> #endif
> 
>  
> 
> #include <stdio.h>
> 
>  
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
SourceForge.net | 5 Sep 2007 01:06
Picon
Favicon

[ swig-Feature Requests-1788111 ] SAL annonations

Feature Requests item #1788111, was opened at 2007-09-05 09:06
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=351645&aid=1788111&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
Priority: 5
Private: No
Submitted By: Glenn Watson (deepdene)
Assigned to: Nobody/Anonymous (nobody)
Summary: SAL annonations

Initial Comment:
Get SAL annontations to work within SWIG. SAL stands for Standard Annotation Language (SAL) and its a
microsoft standard of documenting the code about what a particular parameter of a function will be doing,
if its input or output parameter. This then can be used by microsoft visual studio 2005 for example to
automatically analyse the input/output of a parameter and provide some error checking to assure the
parameters are correct.

Two documentation points for SAL are :
http://blogs.msdn.com/michael_howard/archive/2006/05/19/602077.aspx
http://msdn2.microsoft.com/en-us/library/ms235402(VS.80).aspx 

Also in Visual Studio 2005 the actual SAL annontations are defined within sal.h header file. They are
turned off for non-analysing builds.
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Lenz | 5 Sep 2007 07:46
Picon
Favicon

Re: [Swig-user] swig_type() gives incomplete type name for templates

On 09/03/2007 09:01 PM, mark gossage wrote:
> Hello All,
> 
> I just tried this on my copy, it gets real interesting.
> 
> ===========
> %module templ
> 
> %inline %{
> 	
> typedef int s32;
> 
> template<class T> class Dim {
> public:
> Dim( T w_, T h_ )
> : w(w_), h(h_)
> {}
> virtual ~Dim() {}
> T w, h;
> };
> 
> template<class T> class Point {
> public:
> Point( T x_, T y_ )
> : x(x_), y(y_)
> {}
> Point<T> operator+( const Dim<T>& other ) const
> {
> return Point<T>( x + other.w, y + other.h );
> }
(Continue reading)

Permalink | Reply | 1 comment |
headers
mark gossage | 5 Sep 2007 12:01

Re: [Swig-user] swig_type() gives incomplete type name for templates

John Lenz <jlenz2 <at> math.uiuc.edu> wrote :

> Ok, I have attempted a fix I just committed in revision 9933.  Reading
> through the code again, I remember why there is that nasty warning in
> typesys.c not to modify the code...
> 
> Please test with all the different modules that exposed this bug... I have
> just tested with the above simple templ module.  See if that fixed it.
> 
> The issue was the types in r_ltype were getting overwritten when multiple
> different ltypes mapped to the same mangled type.  The entry that was
> added in r_ltype was dependent on the order that SwigType_remember was
> called.
> 
> So the reason changing the order mattered, is because when building
> Point<s32>, it called SwigType_remember when it reached the Dim<T>
> in the
> operator+ function definition (which is also why removing the operator+
> changes things too... you could have used any function in which Dim<T>
> appeared as a parameter... because when parsing Point<> it wasn't
> calling
> SwigType_remember on Dim<T>... thus changing the order).
> 
> Each call to SwigType_remember overwrote the value in r_ltype so whatever
> parameters happened to be the last call to SwigType_remember is what got
> stored in r_ltype.  This seems to only be a problem in the case of
> typemaps where the inner type is typedefed... normally calls to
> SwigType_remember have the same type so it normally doesn't matter that we
> overwrite r_ltype.
>
(Continue reading)

Permalink | Reply | 3 comments |

Gmane