discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss-gnuradio] swig smart pointer inheritance issue


From: Rick Spanbauer
Subject: [Discuss-gnuradio] swig smart pointer inheritance issue
Date: Tue, 10 Sep 2013 19:44:24 -0400

I'm converting some old blocks I wrote for ~3.5 gnuradio APIs to 3.7.  I have a block that
calculates the MER of an incoming signal - this block is a synchronous decimator, and
the make function takes a constellation_sptr and decimation rate as input:

mer::sptr
    mer::make(gr::digital::constellation_sptr mod_const, int decim_rate)
    {
      return gnuradio::get_initial_sptr (new mer_impl(mod_const, decim_rate));
    }

Note, I'm using gr_modtool to rough out all the details of building a module
template & associated build system scaffolding.  

To test, I'm trying to pass in a constellation_rect_sptr, which is a subclass
of the constellation class.  The relevant code snippet is this:

def make_qam_constellation(pts):
    return gr_qam.qam_constellation(constellation_points=pts, differential=False)


When I pass in the constellation_rect_sptr, like this:

#!/usr/bin/python
from myqam import *
from qam_demod import mer
import gnuradio

c = make_qam_constellation(256)
print "type(c) = ", type(c)
print "type(c.base()) = ", type(c.base())
m = mer(c.base(), 4096)


the swig type checker is throwing out the c.base() input:

type(c) =  <class 'gnuradio.digital.digital_swig.constellation_rect_sptr'>
type(c.base()) =  <class 'gnuradio.digital.digital_swig.constellation_sptr'>
Traceback (most recent call last):
  File "/home/rick/Z/test_mer.py", line 9, in <module>
    m = mer(c.base(), 4096)
  File "/usr/local/lib/python2.7/dist-packages/qam_demod/qam_demod_swig.py", line 95, in make
    return _qam_demod_swig.mer_make(*args, **kwargs)
TypeError: in method 'mer_make', argument 1 of type 'gr::digital::constellation_sptr'  <<<<<

Just looking at the output from the two type() statements, the types seem proper, though
the dotted notation vs '::' is interesting.

I notice that Ben Reynwar posted a very similar issue back in 2010.  I had the same problem
at the time, and resolved it via using the .base() method, apparently just as he did.  I suspect
this issue, while similar, may have something to do with 3.7's use of namespaces, and some
of the complexity of SWIG's processing of namespace.  I'm a definite SWIG neophyte, and
perhaps I'm just missing something obvious, or at least I hope so.

Has anyone run into this issue and found a resolution?  Looking at the .i files in the distribution
didn't provide much in the way of inspiration as to how to solve the problem.

Any pointers would be greatly appreciated. 

Rick Spanbauer

reply via email to

[Prev in Thread] Current Thread [Next in Thread]