Gr-uhd swig troubles

Hey guys,

I started to have this with the git master and uhd from yesterday
evening:

linux; GNU C++ version 4.6.0 20110415 (prerelease); Boost_104600;
UHD_003.000.001-8212f22

[…]

ub/grotarapi/PHY/PhysicalLayer.py", line 47, in init
self.u_tx = uhd.usrp_sink(hint,
io_type=uhd.io_type_t.COMPLEX_FLOAT32, num_channels=1)
File “/usr/lib/python2.7/site-packages/gnuradio/uhd/init.py”, line
73, in constructor_interceptor
if kwargs.has_key(key): kwargs[key] = cast(kwargs[key])
File “/usr/lib/python2.7/site-packages/gnuradio/uhd/uhd_swig.py”, line
409, in init
this = _uhd_swig.new_io_type_t(*args)
NotImplementedError: Wrong number or type of arguments for overloaded
function ‘new_io_type_t’.
Possible C/C++ prototypes are:
uhd::io_type_t(uhd::io_type_t::tid_t)
uhd::io_type_t(size_t)

[…]

If I try the same with a size_t instead (in bpython):

a = uhd.usrp_sink(device_addr=‘type=usrp2’, io_type=32, num_channels=1)

OUT: Traceback (most recent call last):

OUT: File “”, line 1, in

OUT: File

“/usr/lib/python2.7/site-packages/gnuradio/uhd/init.py”, line 74,

in constructor_interceptor

OUT: return old_constructor(*args, **kwargs)

OUT: File

“/usr/lib/python2.7/site-packages/gnuradio/uhd/uhd_swig.py”, line

1854, in usrp_sink

OUT: return _uhd_swig.usrp_sink(*args, **kwargs)

OUT: RuntimeError: gr_io_signature(3)

Any hints how to fix this? Did someone already see something like this?
I think it might be somehow related to
7787d1fc1aecc7b59e476c31865b4f32348cb729

All the best,
Moritz

Whats your swig version? The last time I encountered this, someone had
swig 2 and it was incorrectly parsing an enum to type ‘str’ (rather than
int). Whats this print?

python -c “from gnuradio import uhd; print
type(uhd.io_type.COMPLEX_FLOAT32)”

-Josh

On 04/20/2011 08:41 AM, Moritz Fischer wrote:

as you guessed:

<type ‘str’>

What do other gnuradio enums give you?

python -c “from gnuradio import gr; print type(gr.GR_COS_WAVE)”

Can you create a gr.sig_source?

Just trying to narrow it down…

-Josh

On Wed, Apr 20, 2011 at 06:28:45PM +0200, Josh B. wrote:

What do other gnuradio enums give you?

python -c “from gnuradio import gr; print type(gr.GR_COS_WAVE)”

Can you create a gr.sig_source?
Yeah, it’s a <type ‘int’>

Just trying to narrow it down…
Thanks for your efforts :wink:

Moritz

On 04/20/2011 10:02 AM, Moritz Fischer wrote:

On Wed, Apr 20, 2011 at 06:28:45PM +0200, Josh B. wrote:

What do other gnuradio enums give you?

python -c “from gnuradio import gr; print type(gr.GR_COS_WAVE)”

Can you create a gr.sig_source?
Yeah, it’s a <type ‘int’>

I think I see why:

//! Complex floating point (64-bit floats) range [-1.0, +1.0]
COMPLEX_FLOAT64 = ‘d’,
//! Complex floating point (32-bit floats) range [-1.0, +1.0]
COMPLEX_FLOAT32 = ‘f’,
//! Complex signed integer (16-bit integers) range [-32768, +32767]
COMPLEX_INT16 = ‘s’,
//! Complex signed integer (8-bit integers) range [-128, 127]
COMPLEX_INT8 = ‘b’

Swig 2 is interpreting that as a string. Which in kind of nice, except
that things that use those enums in python expect type int.

I dont know the magical swig switch to turn that off. Does this diff
make it work for you?

         //! Complex floating point (64-bit floats) range [-1.0, +1.0]
  •        COMPLEX_INT8 =    int('b')
       };
    

-Josh

On Wed, Apr 20, 2011 at 07:13:15PM +0200, Josh B. wrote:

Swig 2 is interpreting that as a string. Which in kind of nice, except
that things that use those enums in python expect type int.
Swig seems to me like black magic … on the other hand … the whole
gnuradio build process sometimes does …

I dont know the magical swig switch to turn that off. Does this diff
make it work for you?
If you didn’t know it, you pushed it by accident or good guess :wink:
It’s working just fine now :slight_smile:

Thanks again for your quick fix!

All the best,
Moritz

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs