SWIG 3.0.3 Issue

GNU Radio
1

SWIG 3.0.3 was released today (30 Dec 2014) < http://www.swig.org/ >,
and I maintain this port in MacPorts. So, I naturally was curious to see
if it works with GNU Radio. Sadly, GNU Radio fails because some of the
SWIG-generated Python scripts have errors in them. For example, in SWIG
3.0.2 the vector_source_b::make is defined in blocks_swig1.py as:
{{{
def make(*args, **kwargs):
“”"
make(std::vector< unsigned char,std::allocator< unsigned char >
> const & data, bool repeat=False,
int vlen=1, tags_vector_t tags=std::vector< gr::tag_t >())
→ vector_source_b_sptr
}}}
while in 3.0.3 this code is:
{{{
def make(data, repeat=False, vlen=1, tags):
“”"
make(std::vector< unsigned char,std::allocator< unsigned char >
> const & data, bool repeat=False, int vlen=1, tags_vector_t
tags) → vector_source_b_sptr
}}}

The above are both generated using the current GIT HEAD (c67281b6), just
changing which version of SWIG is used.

For now, I won’t upgrade SWIG to 3.0.3 since this is a pretty critical
issue. I’ll also report it to the SWIG devs to see what they think – it
might be that there were changes to how SWIG %-things are used; it also
might be that there’s an actual error in the SWIG Python generator code.

  • MLD
2

Yay, SWIG troubles. Until we’ve figured out what’s up, we should
probably put in a version check < 3.0.3 into our build setup.

From your example, I actually prefer the 3.0.3 code output and am
curious why this would throw an error.

M

3

On Sun, Jan 4, 2015 at 5:09 AM, Martin B. [email protected]
wrote:

Yay, SWIG troubles. Until we’ve figured out what’s up, we should
probably put in a version check < 3.0.3 into our build setup.

From your example, I actually prefer the 3.0.3 code output and am
curious why this would throw an error.

M

Yes, this is supposedly a new feature of SWIGs. From their changelog:

2014-10-28: vadz
[Python] Patch #201 The generated .py file no longer uses *args for all
Python parameters.
Instead, the parameters are named using the C++ parameter names.

2014-10-21: wsfulton
Fix issue #242 - Use of the “kwargs” feature no longer automatically
turns
on the
“compactdefaultargs” feature if the target language does not support
kwargs.
Only Java and Python support kwargs, so this affects all the other
languages.

*** POTENTIAL INCOMPATIBILITY ***

So either we need to change the syntax of something to point swig to set
a
proper default argument for std::vector arguments or they need to fix a
bug.

Tom

4

I sent the primary SWIG maintainer (William S Fulton) an email, and got
a prompt reply forwarding my email to the SWIG developer’s list. He
primarily just verified and checked in the changes (that Tom found and
quoted, below); he hopes that some of the SWIG developers can help him
figure out what’s going on – is it a bug in their code, or the way GNU
Radio is handling things. I don’t subscript to this list; maybe Tom or
Martin does? I do see SWIG checkins, so if anything comes up there
hopefully I’ll catch it.

On Sun, Jan 4, 2015, at 05:09 AM, Martin B. wrote:

Yay, SWIG troubles. Until we’ve figured out what’s up, we should
probably put in a version check < 3.0.3 into our build setup.

Agreed.

From your example, I actually prefer the 3.0.3 code output and am
curious why this would throw an error.

Yes, I do to.

On Sun, Jan 4, 2015, at 01:59 PM, Tom R. wrote:

Yes, this is supposedly a new feature of SWIGs. From their changelog:
{{{
2014-10-28: vadz
[Python] Patch #201 The generated .py file no longer uses *args for all
Python parameters.
Instead, the parameters are named using the C++ parameter names.

2014-10-21: wsfulton
Fix issue #242 - Use of the “kwargs” feature no longer automatically
turns on the
“compactdefaultargs” feature if the target language does not support
kwargs.
Only Java and Python support kwargs, so this affects all the other
languages.

*** POTENTIAL INCOMPATIBILITY ***
}}}

So either we need to change the syntax of something to point swig to set a
proper default argument for std::vector arguments or they need to fix a bug.

Also agreed. I think the hard part will be to keep compatibility for
both the “new” and “old” ways at the same time, if this is not a bug. -
MLD