SWIG

Am 28.12.2006, 20:11 Uhr, schrieb Bo Peng <ben.bob@...>:

> Dear list,
>
> I need to use uint16_t (or __int16 for msvc) for my python module. I
> have two problems to process my header files with swig 1.3.31.
>
> 1. In my header file, I have something like
>
>   #ifdef _MSC_VER
>     typedef __int16 INT16;
>   #else
>     typedef int16_t INT16;
>   #endif
>
> However, swig does not know _MSC_VER so I have to pass -D_MSC_VER
> explicitly from command line when msvc is used. (This is of course not
> swig's fault).
>
> 2. When I use %include "stdint.i", stdint.h is always included in the
> generated _wrap file. Because msvc does not define this header file. I
> have to use
>   #ifndef _MSC_VER
>   %include "stdint.i"
>   #endif
> to get around this.
>
> The problem is that the generated _wrap files are different
> with/without -D_MSC_VER so I can not distribute a single _wrap file
> with my source distribution (so that users do not have to install swig
> to compile the python module). Is there any trick I can use to fix
> this? I guess I can accept something like
>   %ifndef _WIN32
>   %include "stdint.i"
>   %endif
> by forcing users to use msvc under windows.
>
> Many thanks in advance
> Bo

You could just copy the contents of stdint.i (can be found somewhere in  
your swig library) and paste/%include them in your wrapper file. Then  
modify them as necessary (for example doing #ifndef _WIN32 %{ #include  
"stdint.h %} #endif or somethign along the lines of that.

-Matthias

Nitro wrote:
> Am 28.12.2006, 20:11 Uhr, schrieb Bo Peng <ben.bob@...>:
> 
>> Dear list,
>>
>> I need to use uint16_t (or __int16 for msvc) for my python module. I
>> have two problems to process my header files with swig 1.3.31.
>>
>> 1. In my header file, I have something like
>>
>>   #ifdef _MSC_VER
>>     typedef __int16 INT16;
>>   #else
>>     typedef int16_t INT16;
>>   #endif
>>
>> However, swig does not know _MSC_VER so I have to pass -D_MSC_VER
>> explicitly from command line when msvc is used. (This is of course not
>> swig's fault).
>>
>> 2. When I use %include "stdint.i", stdint.h is always included in the
>> generated _wrap file. Because msvc does not define this header file. I
>> have to use
>>   #ifndef _MSC_VER
>>   %include "stdint.i"
>>   #endif
>> to get around this.
>>
>> The problem is that the generated _wrap files are different
>> with/without -D_MSC_VER so I can not distribute a single _wrap file
>> with my source distribution (so that users do not have to install swig
>> to compile the python module). Is there any trick I can use to fix
>> this? I guess I can accept something like
>>   %ifndef _WIN32
>>   %include "stdint.i"
>>   %endif
>> by forcing users to use msvc under windows.
>>
>> Many thanks in advance
>> Bo
> 
> You could just copy the contents of stdint.i (can be found somewhere in  
> your swig library) and paste/%include them in your wrapper file. Then  
> modify them as necessary (for example doing #ifndef _WIN32 %{ #include  
> "stdint.h %} #endif or somethign along the lines of that.
> 
Alternatively, use the freely available portable stdint.h
implementations. There are two mentioned at the bottom of this page:

http://en.wikipedia.org/wiki/Stdint.h

William

> Alternatively, use the freely available portable stdint.h
> implementations. There are two mentioned at the bottom of this page:
>
> http://en.wikipedia.org/wiki/Stdint.h

This method seems to be easier, and it actually works. Thank you very much.

Bo

Hello list,

I've been struggling with this for several days and I cant get it to  
work.

I've looked at the 30.7.9 Example: STL Vector to Ruby Array but I  
can't get it to work as I don't understand where to put what.

Can someone please give me a real code example of accessing a STL  
vector from ruby.

Regards,
Henrik

How about the example that's in the SWIG source code tree 
(Examples/ruby/std_vector/)?

Josh


On Fri, 29 Dec 2006, Henrik Zagerholm wrote:

> Hello list,
>
> I've been struggling with this for several days and I cant get it to
> work.
>
> I've looked at the 30.7.9 Example: STL Vector to Ruby Array but I
> can't get it to work as I don't understand where to put what.
>
> Can someone please give me a real code example of accessing a STL
> vector from ruby.
>
> Regards,
> Henrik

>> -----Original Message-----
>> From: Petr Novotny [mailto:Petr.Novotny@...
>> Sent: 22. joulukuuta 2006 16:53
>>=20
>> Hi,
>>=20
>> from your description I guess that the C code that you are=20
>> compiling didn't see the declaration of fnl_request_filename=20
>> and therefore it assumes that the function returns "int".=20
>> Then it extends the "int" to a "char *".
>>=20
>> Doesn't C compiler print a warning message?
>>=20
>> The fix is to make sure that the generated code contains the=20
>> declaration of fnl_request_filename, e.g. by putting it into=20
>> %inline block, or repeating it in the plain %{ ... %} block.

Hi,

I tried that but I'll give it another chance.

thx & br,

/jUSSi
--=20
perl -e '$@=3D[[0,0112,0,0],[0,0101,0,0],
[0,0120,0,0],[0,0110,0,0]];$[=3D256/8-0x1D;
print(chr(@{$_}[+($[+1-1+1)]))for(@{$@});'

Disclaimer: This message and any attachments thereto are intended solely=
 for
the addressed recipient(s) and may contain confidential information. If you
are not the intended recipient, please notify the sender by reply e-mail=
 and
delete the e-mail (including any attachments thereto) without producing,
distributing or retaining any copies thereof. Any review, dissemination or
other use of, or taking of any action in reliance upon, this information by
persons or entities other than the intended recipient(s) is prohibited.
Thank you.

>> Hi,
>>=20
>> from your description I guess that the C code that you are=20
>> compiling didn't see the declaration of fnl_request_filename=20
>> and therefore it assumes that the function returns "int".=20
>> Then it extends the "int" to a "char *".
>>=20
>> Doesn't C compiler print a warning message?
>>=20
>> The fix is to make sure that the generated code contains the=20
>> declaration of fnl_request_filename, e.g. by putting it into=20
>> %inline block, or repeating it in the plain %{ ... %} block.


Hi again :-)

the inline block did the trick. Previously I tried to include the header
file, but gave up since the SWIG complained about my enum declarations
among other things and I didn't want to change my headers.

Thanks a lot for the tip!

br,

/jUSSi
--=20
perl -e '$@=3D[[0,0112,0,0],[0,0101,0,0],
[0,0120,0,0],[0,0110,0,0]];$[=3D256/8-0x1D;
print(chr(@{$_}[+($[+1-1+1)]))for(@{$@});'

Disclaimer: This message and any attachments thereto are intended solely=
 for
the addressed recipient(s) and may contain confidential information. If you
are not the intended recipient, please notify the sender by reply e-mail=
 and
delete the e-mail (including any attachments thereto) without producing,
distributing or retaining any copies thereof. Any review, dissemination or
other use of, or taking of any action in reliance upon, this information by
persons or entities other than the intended recipient(s) is prohibited.
Thank you.

Am 22.12.2006, 10:55 Uhr, schrieb Mononen Jussi  =

<Jussi.Mononen@...>:

>
> Hi,
>
> I am experiencing a strange problem with a very simple SWIG interface =
to
> a C library used from Perl. The used C-function simply generates a
> filename and returns a pointer to a static character buffer:
>
> char * fnl_request_filename(const char * filename,
>                             const char * separation_value,
>                             const char *src_id,
>                             int sequence_update) {
>
>     static char fname[MAXNAMELEN];
>     /*
>      * create filename
>      */
>     fprintf(stderr, "fname pointer : %p\n", fname);
>     return fname;
> }
>
> So, nothing fancy in it. The SWIG generated wrapper code is listed
> below:
>
> XS(_wrap_fnl_request_filename) {
>     char _swigmsg[SWIG_MAX_ERRMSG] =3D "";
>     const char *_swigerr =3D _swigmsg;
>     {
>         char *arg1 ;
>         char *arg2 ;
>         char *arg3 ;
>         int arg4 ;
>         char *result;
>         int argvi =3D 0;
>         dXSARGS;
>
>        if ((items < 4) || (items > 4)) {
>             SWIG_croak("Usage:
> fnl_request_filename(filename,separation_value,src_id,sequence_update)=
;"
> );
>         }
>         if (!SvOK((SV*) ST(0))) arg1 =3D "";
>         else arg1 =3D (char *) SvPV(ST(0), PL_na);
>         if (!SvOK((SV*) ST(1))) arg2 =3D "";
>         else arg2 =3D (char *) SvPV(ST(1), PL_na);
>         if (!SvOK((SV*) ST(2))) arg3 =3D "";
>         else arg3 =3D (char *) SvPV(ST(2), PL_na);
>         arg4 =3D (int) SvIV(ST(3));
>         result =3D (char *)fnl_request_filename((char const *)arg1,(ch=
ar
> const *)arg2,(char const *)arg3,arg4);
>
>         fprintf(stderr, "result : %p\n", result);
>         fprintf(stderr, "Filename is : ");
>         fprintf(stderr, "%s\n", result);
>        ST(argvi) =3D sv_newmortal();
>         if (result) {
>             sv_setpv((SV*)ST(argvi++), (char *) result);
>             fprintf(stderr, "Result stacked\n");
>         }else {
>             sv_setsv((SV*)ST(argvi++), &PL_sv_undef);
>         }
>         fprintf(stderr, "Performing XSRETURN\n");
>         XSRETURN(argvi);
>         fail:
>         (void) _swigerr;
>     }
>     croak(_swigerr);
> }
>
> Note the additional fprint -statements for debugging purposes.
>
> The perl scirpt uses the function like this:
>
> my $name =3D fnl_request_filename("DataFile", undef, undef, 1);
>
> When I run my perl script I get the following:
>
> sol9dev> perl example.pl
> fname pointer : ffffffff77d2cf88
> result : 77d2cf88
> Filename is : Segmentation Fault
>
> The first line comes from the used C-library itself and the pointer
> address is valid, the next two lines are printed from the SWIG wrapper=

> code. As can be seen the address where the pointer points to has been
> tampered and all 'f' characters have been removed rendering the addres=
s
> invalid.

I have no experience with this, but doesn't it look like fname pointer i=
s  =

64-bit and result is just 32-bit? I've got no idea why this happens, may=
be  =

the swig wrapper was compiled in 32-bit mode somehow while your library =
is  =

64-bit?

-Matthias

>> -----Original Message-----
>> From: Nitro [mailto:nitro@...
>> Sent: 22. joulukuuta 2006 16:47
>>
>> I have no experience with this, but doesn't it look like=20
>> fname pointer is 64-bit and result is just 32-bit? I've got=20
>> no idea why this happens, maybe the swig wrapper was=20
>> compiled in 32-bit mode somehow while your library is 64-bit?
>>=20
>> -Matthias

Hi,

I have to check this, since my library *is* 64-bit.

thx & br,

/jUSSi
--=20
perl -e '$@=3D[[0,0112,0,0],[0,0101,0,0],
[0,0120,0,0],[0,0110,0,0]];$[=3D256/8-0x1D;
print(chr(@{$_}[+($[+1-1+1)]))for(@{$@});'

Disclaimer: This message and any attachments thereto are intended solely=
 for
the addressed recipient(s) and may contain confidential information. If you
are not the intended recipient, please notify the sender by reply e-mail=
 and
delete the e-mail (including any attachments thereto) without producing,
distributing or retaining any copies thereof. Any review, dissemination or
other use of, or taking of any action in reliance upon, this information by
persons or entities other than the intended recipient(s) is prohibited.
Thank you.

Le dim 24/12/2006 =C3=A0 02:20 Mildred =C3=A0 =C3=A9crit:
> Hi,
>=20
> I'm trying to create a binding for the lua language and the Crystal
> Space 3D framework <http://crystalspace3d.org> (it uses swig). The
> problem is that when I use g++ to compile the file created by swig, it
> fails because of errors in the source code.
>=20
> Can someone help mee see why it fails ?
>=20

The problem is in the function (line 21351) :

static int _wrap_csIntersect2_SegmentSegment(lua_State* L) {
    int SWIG_arg;
    csSegment2 *arg1 =3D 0 ;
    csSegment2 *arg2 =3D 0 ;
    csVector2 *arg3 =3D 0 ;
    float *arg4 =3D 0 ;
    bool result;
    $*type temp4 ; /***** THE PROBLEM IS HERE *****/
   =20
    arg4 =3D &temp4;=20
    if(!lua_isuserdata(L,1)) SWIG_fail_arg(1);
    if(!lua_isuserdata(L,2)) SWIG_fail_arg(2);
    if(!lua_isuserdata(L,3)) SWIG_fail_arg(3);
    arg1=3D(csSegment2 *) SWIG_MustGetPtr(L,1,SWIGTYPE_p_csSegment2,0,1,
                                        "csIntersect2_SegmentSegment");
    arg2=3D(csSegment2 *)SWIG_MustGetPtr(L,2,SWIGTYPE_p_csSegment2,0,2,
                                       "csIntersect2_SegmentSegment");
    arg3=3D(csVector2 *)SWIG_MustGetPtr(L,3,SWIGTYPE_p_csVector2,0,3,
                                      "csIntersect2_SegmentSegment");
    result =3D (bool)csIntersect2::SegmentSegment(
            (csSegment2 const &)*arg1,
            (csSegment2 const &)*arg2,*arg3,*arg4);

    SWIG_arg=3D0;
    lua_pushboolean(L,(int)result); SWIG_arg++;
    lua_pushnumber(L, (double) *arg4); SWIG_arg++;
    return SWIG_arg;=20

    fail:
    lua_error(L);
}

It results of the following declaration :


class CS_CRYSTALSPACE_EXPORT csIntersect2
{
public:
  ...
  static bool SegmentSegment (
    const csSegment2& a, const csSegment2& b,
    csVector2& isect, float& dist);
  ...
};



There, you can see the following line :
    $*type temp4 ;
Where it should be :
    float temp4 ;

So I assume that somewhere defined in the Lua bindings files, there is
a template and instead of $type, there is an extra star making it
$*type ... causing this error.

Does anyone know how to repair that ?
Thanks.

Mildred

--=20
Mildred       <xmpp:mildred@...> <http://mildred632.free.fr/>
Clef GPG :    <hkp://pgp.mit.edu> ou <http://mildred632.free.fr/gpg_key>
Fingerprint : 197C A7E6 645B 4299 6D37 684B 6F9D A8D6 [9A7D 2E2B]

Le dim 24/12/2006 =C3=A0 19:50 Mildred =C3=A0 =C3=A9crit:
>=20
> The problem is in the function (line 21351) :
>=20
> static int _wrap_csIntersect2_SegmentSegment(lua_State* L) {
>     int SWIG_arg;
>     csSegment2 *arg1 =3D 0 ;
>     csSegment2 *arg2 =3D 0 ;
>     csVector2 *arg3 =3D 0 ;
>     float *arg4 =3D 0 ;
>     bool result;
>     $*type temp4 ; /***** THE PROBLEM IS HERE *****/
>    =20
>     arg4 =3D &temp4;=20
>     if(!lua_isuserdata(L,1)) SWIG_fail_arg(1);
>     if(!lua_isuserdata(L,2)) SWIG_fail_arg(2);
>     if(!lua_isuserdata(L,3)) SWIG_fail_arg(3);
>     arg1=3D(csSegment2 *) SWIG_MustGetPtr(L,1,SWIGTYPE_p_csSegment2,0,1,
>                                         "csIntersect2_SegmentSegment");
>     arg2=3D(csSegment2 *)SWIG_MustGetPtr(L,2,SWIGTYPE_p_csSegment2,0,2,
>                                        "csIntersect2_SegmentSegment");
>     arg3=3D(csVector2 *)SWIG_MustGetPtr(L,3,SWIGTYPE_p_csVector2,0,3,
>                                       "csIntersect2_SegmentSegment");
>     result =3D (bool)csIntersect2::SegmentSegment(
>             (csSegment2 const &)*arg1,
>             (csSegment2 const &)*arg2,*arg3,*arg4);
>=20
>     SWIG_arg=3D0;
>     lua_pushboolean(L,(int)result); SWIG_arg++;
>     lua_pushnumber(L, (double) *arg4); SWIG_arg++;
>     return SWIG_arg;=20
>=20
>     fail:
>     lua_error(L);
> }
>=20
> It results of the following declaration :
>=20
>=20
> class CS_CRYSTALSPACE_EXPORT csIntersect2
> {
> public:
>   ...
>   static bool SegmentSegment (
>     const csSegment2& a, const csSegment2& b,
>     csVector2& isect, float& dist);
>   ...
> };
>=20
>=20
>=20
> There, you can see the following line :
>     $*type temp4 ;
> Where it should be :
>     float temp4 ;
>=20
> So I assume that somewhere defined in the Lua bindings files, there is
> a template and instead of $type, there is an extra star making it
> $*type ... causing this error.
>=20

Many of my errors were resolved by applying the following patch.
Can someone explain to me why variables like $*type aren't recognized ?

--- /usr/share/swig/1.3.27/lua/typemaps.i.bak   2006-12-24 20:20:33.0000000=
00 +0100
+++ typemaps.i  2006-12-24 21:31:52.000000000 +0100
@@ -48,18 +48,18 @@
=20
=20
 %define SWIG_NUMBER_TYPEMAP(TYPE)
-%typemap(in,checkfn=3D"lua_isnumber")    TYPE *INPUT($*type temp), TYPE &I=
NPUT($*type temp)
-%{ temp =3D ($*type)lua_tonumber(L,$input);
+%typemap(in,checkfn=3D"lua_isnumber")    TYPE *INPUT(TYPE temp), TYPE &INP=
UT(TYPE temp)
+%{ temp =3D (TYPE)lua_tonumber(L,$input);
    $1 =3D &temp; %}
-%typemap(in, numinputs=3D0) TYPE *OUTPUT ($*type temp)
+%typemap(in, numinputs=3D0) TYPE *OUTPUT (TYPE temp)
 %{ $1 =3D &temp; %}
 %typemap(argout) TYPE *OUTPUT
 %{  lua_pushnumber(L, (double) *$1); SWIG_arg++;%}
 %typemap(in) TYPE *INOUT =3D TYPE *INPUT;
 %typemap(argout) TYPE *INOUT =3D TYPE *OUTPUT;
 // const version (the $*ltype is the basic number without ptr or const's)
-%typemap(in,checkfn=3D"lua_isnumber")    const TYPE *INPUT($*ltype temp)
-%{ temp =3D ($*ltype)lua_tonumber(L,$input);
+%typemap(in,checkfn=3D"lua_isnumber")    const TYPE *INPUT(TYPE temp)
+%{ temp =3D (TYPE)lua_tonumber(L,$input);
    $1 =3D &temp; %}
 %enddef


I still have an error which should be easy to fix.

Mildred

--=20
Mildred       <xmpp:mildred@...> <http://mildred632.free.fr/>
Clef GPG :    <hkp://pgp.mit.edu> ou <http://mildred632.free.fr/gpg_key>
Fingerprint : 197C A7E6 645B 4299 6D37 684B 6F9D A8D6 [9A7D 2E2B]

Le dim 24/12/2006 =C3=A0 21:38 Mildred =C3=A0 =C3=A9crit:
>=20
> I still have an error which should be easy to fix.
>=20
> Mildred
>=20

I don't know where it comes from.
The following generated function is wrong :

static void *_csOrthoTransformTo_csReversibleTransform(void *x) {
    return (void *)((csReversibleTransform)  ((csOrthoTransform) x));
}

My solution was to *manually* change it to :

static void *_csOrthoTransformTo_csReversibleTransform(void *x) {
    return (void *)((csReversibleTransform *)  ((csOrthoTransform *)
x));
}

Because it is not possible to cast a void pointer to an object itself
(not a reference and not a pointer). And it compiles. i don't know yet
if it works :)
I don't know where this error comes from. If you have any idea, please
tell me.

I still have a lot of warnings, but I think thoe are normal when I see
the source code generated.

Mildred

--=20
Mildred       <xmpp:mildred@...> <http://mildred632.free.fr/>
Clef GPG :    <hkp://pgp.mit.edu> ou <http://mildred632.free.fr/gpg_key>
Fingerprint : 197C A7E6 645B 4299 6D37 684B 6F9D A8D6 [9A7D 2E2B]

Dave Yost wrote:
> It would be helpful if the warning message would say instead:
> 
>    Warning(503): Use %rename(someMethodName) operator==;
> 
> First I tried
>    %rename(opEquals) foo::operator==(foo w1, foo w2);
> which is similar to another rename I have, then I tried
>    %rename(opEquals) foo::operator==;
> then finally after reviewing the doc, I tried
>    %rename(opEquals) operator==;
> 
> Sure, RTFM, but the warning message could make it easier.
> 
> Swig is a rather complex ball of wax, and anything you can do to make 
> it easier for us is welcome.
> 

Unfortunately we can't give an exact syntax as the exact syntax depends
on what someone wants to do. This is in the manual, but if we gave

    %rename(opEquals) operator==;

as the syntax to use, it would be a global rename. Globals are not good.
You have basically not worked out a fundamental feature of SWIG. If you
can suggest ways of making the documentation clearer, please do, but
%rename has some powerful matching rules which need to be understood really.

The attempts you made are incorrect, as it looks to me as though you are
mixing a global operator== with an member one. %rename is very simple.
Take the original declaration and remove the return type in order to
make an exact match, so your declaration is probably:

  // global namespace
  bool operator==(foo w1, foo w2);

so therefore you need:

  %rename(globalopEquals) operator==(foo w1, foo w2);

Note the foo class scoping has gone.

If however you had the common alternative to using operator==:

  class foo {
  public:
    bool operator==(const foo& b);
  };

then you'd need:

  %rename(EqualEqual) foo::operator==(const foo& b);

William