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 <[email protected] > <mailto:[email protected]>>: > > 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 > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
