[ swig-Bugs-1726158 ] variadic macros won't accept zero arguments

Bugs item #1726158, was opened at 2007-05-26 17:38
Message generated for change (Comment added) made by wsfulton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=1726158&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: 5
Private: No
Submitted By: Jeremy (heivo)
Assigned to: Nobody/Anonymous (nobody)
Summary: variadic macros won't accept zero arguments

Initial Comment:
It is possible to define a variadic macro that has no fixed arguments, but impossible to call such a macro
with zero arguments. Here is a simple test case set up for GCC:

---------------------------------------
#define annotate(...) %feature("java:methodmodifiers"," <at> Annotation("#__VA_ARGS__") public")

annotate(one=1,two=2) methodTwo;
annotate(one=1)       methodOne;
annotate()            methodZero;
---------------------------------------

[ swig-Bugs-3057804 ] wrapper does not compile with python 3.2

Bugs item #3057804, was opened at 2010-09-01 23:51
Message generated for change (Tracker Item Submitted) made by amauryf
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=3057804&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: Amaury Forgeot d'Arc (amauryf)
Assigned to: Nobody/Anonymous (nobody)
Summary: wrapper does not compile with python 3.2

Initial Comment:
Since Python 3.2 (still in alpha), the PyCObject API has been removed, the PyCapsule object is proposed as a replacement.
Swig wrapper code contains calls to PyCObject_FromVoidPtr, PyCObject_AsVoidPtr and
PyCObject_Import, and won't compile anymore.
The attached patch fixes the issue and works at least for the wxPython interface, which is quite large and
spans several modules sharing the same typesystem.

Of course the changes should be guarded by some lines  like "#if PY_VERSION_HEX >= 0x03020000"

----------------------------------------------------------------------

You can respond by visiting: 

[ swig-Bugs-3058394 ] OUTPUT typemap lacks return keyword in PHP class wrappers

Bugs item #3058394, was opened at 2010-09-02 21:28
Message generated for change (Tracker Item Submitted) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=3058394&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: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ryan ()
Assigned to: Olly Betts (olly)
Summary: OUTPUT typemap lacks return keyword in PHP class wrappers

Initial Comment:
In the "Pointers and References" documentation for PHP, this example is used to demonstrate the OUTPUT
typemap in typemaps.i:

%module example
%include "typemaps.i"

void add( int *INPUT, int *INPUT, int *OUTPUT);

In PHP, the output parameter becomes the return value:

$result = add($in1,$in2);

[ swig-Bugs-3058394 ] OUTPUT typemap lacks return keyword in PHP class wrappers

Bugs item #3058394, was opened at 2010-09-02 21:28
Message generated for change (Comment added) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=3058394&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: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ryan ()
Assigned to: Olly Betts (olly)
Summary: OUTPUT typemap lacks return keyword in PHP class wrappers

Initial Comment:
In the "Pointers and References" documentation for PHP, this example is used to demonstrate the OUTPUT
typemap in typemaps.i:

%module example
%include "typemaps.i"

void add( int *INPUT, int *INPUT, int *OUTPUT);

In PHP, the output parameter becomes the return value:

$result = add($in1,$in2);

[ swig-Bugs-3058394 ] OUTPUT typemap lacks return keyword in PHP class wrappers

Bugs item #3058394, was opened at 2010-09-03 09:28
Message generated for change (Comment added) made by olly
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=3058394&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: Accepted
Priority: 5
Private: No
Submitted By: Ryan ()
Assigned to: Olly Betts (olly)
Summary: OUTPUT typemap lacks return keyword in PHP class wrappers

Initial Comment:
In the "Pointers and References" documentation for PHP, this example is used to demonstrate the OUTPUT
typemap in typemaps.i:

%module example
%include "typemaps.i"

void add( int *INPUT, int *INPUT, int *OUTPUT);

In PHP, the output parameter becomes the return value:

$result = add($in1,$in2);

[ swig-Bugs-2149523 ] wrong line numbers in error messages

Bugs item #2149523, was opened at 2008-10-06 13:36
Message generated for change (Comment added) made by wsfulton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=2149523&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: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Omni Bee (omnibee)
>Assigned to: William Fulton (wsfulton)
Summary: wrong line numbers in error messages

Initial Comment:
Swig incorrectly reports line numbers in error messages. For example, it reports:

offnums.hpp(30): Error: Syntax error in input(1).

but the input file has only 25 lines.

I used the following command file:

swig -c++ -python offnums.hpp

(no idea if it matters or not)

pcre_rename_encoder testcase is broken

Vadim, revision 12187 looks to have broken the pcre_rename_encoder 
testcase. I'm getting undefined symbols, which if I fix then give an 
attribute error when running the Python testcase. Could you take a look 
please?

William

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing
http://p.sf.net/sfu/novell-sfdev2dev

Re: pcre_rename_encoder testcase is broken

On Sat, 11 Sep 2010 00:50:38 +0100 William S Fulton <wsf <at> fultondesigns.co.uk> wrote:

WSF> Vadim, revision 12187 looks to have broken the pcre_rename_encoder 
WSF> testcase. I'm getting undefined symbols, which if I fix then give an 
WSF> attribute error when running the Python testcase. Could you take a look 
WSF> please?

 Sorry about this, I only tested with csharp and java which,
unsurprisingly, passed without problems as they didn't run the test.
I trivially fixed the undefined symbol error, as for the subsequent one
about wxDoSomething() method not being renamed to DoSomething(), it's a
consequence of the bug I mentioned before: having the second global %rename
(which applies to functions only) overrides the first one and so the regex
renaming /wx(.*)/ to /\1/ doesn't apply to it. Unfortunately I still didn't
have time to work on this bug (I still intend to but I had to switch to a
different and urgent project recently) so for now all I can do is to change
the test to pass, even if the underlying functionality is still broken.

 Sorry again about the breakage,
VZ

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing
http://p.sf.net/sfu/novell-sfdev2dev

------------------------------------------------------------------------------

Re: SVN needs Autoconf >= 2.60; docs say Autoconf >= 2.58

On Thu, 19 Aug 2010 21:30:25 -0400 "Vallon, Justin" <Justin.Vallon <at> deshaw.com> wrote:

VJ> The following only defines AC_PROG_SED if it is not already defined:
VJ> 
VJ> m4_ifdef([AC_PROG_SED], [] , [
VJ>     AC_DEFUN([AC_PROG_SED], [AC_PATH_PROG([SED], sed)])
VJ> ])
VJ> 
VJ> This could be added to Tools/config/ax_path_generic.m4, or configure.in.

 To close this topic, I've committed the fix using your fragment above as
r12216, please let me know if you still have any problems.

 Thanks,
VZ

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing
http://p.sf.net/sfu/novell-sfdev2dev

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing
http://p.sf.net/sfu/novell-sfdev2dev

Go bindings throws errno=0xc when "getting" strings

Hi,

I've noticed using the go bindings that when you call a function which
returns a string more than once, the application throws an errno=0xc
(ran out of memory). I don't know if I am using the bindings in a wrong
way, or if there is a bug in the code generated for the wrapper.  

Let me start showing a minimal scenario that I've made to illustrate
my problem. Let's say that we have the next 2 files:

mymod.c
-------
#include <mymod.h>
#include <stdlib.h>
#include <string.h>

MyModStruct *mystruct() {
    MyModStruct *ret;
    ret = (MyModStruct*)malloc(sizeof(MyModStruct));
    strcpy(ret->s, "whatever");
    return ret;
}
-------

mymod.h
-------
typedef struct mymod_struct_t {
    char s[32];
} MyModStruct;