|
From: | Tom Rondeau |
Subject: | Re: [Discuss-gnuradio] gr-fec generic_encoder::sptr |
Date: | Wed, 17 Feb 2016 11:42:26 -0500 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |