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

[Marcus Müller]

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

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio