On Tue, Sep 10, 2013 at 7:44 PM, Rick Spanbauer <rspanba...@ieee.org> wrote:
> 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
Hi Rick,
The problem isn't with 3.7 and the namespaces. You would have had to
use the '.base()' call on that block, even in the previous 3.6 way of
doing things. It's a larger issue of inheritance and managing classes
and shared pointers. But basically, when creating a constellation
class in Python and passing it as an argument to a
function/constructor, you need to return it as a shared pointer to the
parent class (gr::digital::constellation class in this case). If you
look at your constructor, you are asking for a 'constellation_sptr' as
the class of the input. But the qam_constellation will return
something derived from constellation (like constellation_rect_sptr).
Swig doesn't think these two are the same thing and won't let you do
it. So you recast the object as a consetllation_sptr and use that,
instead.
There could be a way around this in swig-land that we haven't really
looked into, though.
--
Tom
Visit us at GRCon13 Oct. 1 - 4
http://www.trondeau.com/grcon13
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
