Re: [Discuss-gnuradio] gr-fec generic_encoder::sptr

[Tom Rondeau]

On Tue, Feb 16, 2016 at 8:27 AM, Marcus Müller <address@hidden> wrote:

Hi Jawad,

thanks for the feedback!
My guess would be that SWIG (which generates all the wrappers to use GNU Radio's C++ classes from python) gets confused by the gr::fec::generic_encoder::sptr typedef. That's a bit peculiar (because it works elsewhere), but "peculiar" is one of the words I'd use to describe SWIG...

Best regards,
Marcus

On 02/16/2016 02:22 PM, Jawad Seddar wrote:

Apparently using a boost::shared_ptr<gr::fec::generic_encoder> seems to work, contrary to a gr::fec::generic_encoder::sptr.

Problem solved

2016-02-16 10:32 GMT+01:00 Jawad Seddar <address@hidden>:

Hi all,

I'm trying to create a block that takes a gr::fec::generic_encoder::sptr as an argument (like the async_encoder block found in gr-fec).

Everyhting compiles and installs fine (I included <gnuradio/fec/generic_encoder.h>)but when I try using my block in a python flowgraph, I get a TypeError : argument 1 of type 'gr::fec::generic_encoder::sptr'.

When I use the same parameter in a async_encoder, then it works without problems.

The parameter in question is instantiated the following way :

enc_cc = fec.cc_encoder_make(4096, 7, 2, (79, 109), 0, fec.CC_TERMINATED, False)

Calling fec.async_encoder(enc_cc) works fine, but calling my_block(enc_cc) returns the above TypeError.

my_block doesn't do anything for now, it's just an empty shell.

I'm thinking it might be some SWIG magic that I'm missing in order to make it work in the python realm.

Thanks for any pointers you might provide regarding this issue.

Regards,

Jawad

Jawad,

Can you try something for me here? In your OOT's swig directory, you'll have your xxx_swig.i file. In there, you should see:

#define OOT_API

For whatever your OOT's name is. Right after that, can you put:

#define FEC_API

That might be needed to properly export those symbols into the Python library.

Tom