I spent some time reading the .cxx files swig generates, and trying to understand how my
use of gr::digital::constellation_sptr was falling off the tracks relative to other, similar applications
in the master branch (for example ofdm_equalizer_simpledfe.cc). I constructed a simplified
example where I was passed in gr::digital::constellation_rect::sptr, without any subclassing to
the base constellation class, and still got type errors. Which was puzzling. This issue didn't seem
related to my build environment, since other examples I built using simple types (floats, doubles, etc)
as parameters worked fine.
What seemed to work for me was to be very literal in declaring the constellation class parameter
to my MER block as boost::shared_ptr<gr::digital::constellation> rather than using the
constellation_sptr typedef from constellation.h. So the constructor for my MER block looks
like this:
mer::sptr
mer::make(boost::shared_ptr<gr::digital::constellation> mod_const, int decim_rate)
{
return gnuradio::get_initial_sptr (new mer_impl(mod_const, decim_rate));
}
And can be called from from python, as I have in the following example:
#!/usr/bin/python
from qam_demod import mer
from gnuradio import digital
cnst = digital.constellation_qpsk()
print "type(c) = ", type(cnst)
print "type(c.base()) = ", type(cnst.base())
m = mer(cnst.base(), 4096)
I did try importing constellation.i in the module swig .i file; this didn't seem to help - constellation.i
has a few template definitions for the useful constellation classes of interest to me.
I'm still trying to understand the swig reason as to why this workaround is necessary - certainly the
section on the complications that namespaces introduce, especially so given some of the
particular examples they give about typedefs and namespaces may provide some clues.
But at least I'm back to porting my 3.5 code to the 3.7 APIs, rather than spending time
squinting at swig's c++ files.