Re: [Discuss-gnuradio] passing USRP source block shared pointer through SWIG

[Martin Braun]

You should easily be able to pass a basic_block sptr and then 
dynamic-cast it in your block.

What you're trying to do is not recommended procedure, although I can 
see how it's necessary at times. Can you tell us what you're trying to 
do? We've been working on making the message ports more useful, which 
should hopefully take care of most issues.

M

On 23.03.2015 10:13, Anderson, Douglas J. wrote:
> Hi all,
>
> I'm looking into the possibility of passing the <gr_block gr uhd usrp
> source (0)> object from Python into a C++ out of tree module. In my
> module, I have:
>
>      controller_cc_impl::controller_cc_impl(gr::uhd::usrp_source::sptr
> usrp, [...])
>
> I get a TypeError when I instantiate the block. It seems like the object
> created in Python is not a proxy for the sptr, and I can't figure out
> quite how to get access to the sptr from Python.
>
> I've tried both of the alternatives to passing back in the sptr: I've
> tried sending commands to the USRP via message passing interface, but
> only freq and gain are implemented. At the very least I need the full
> tune_request capability.
>
> I've also tried making that call with fevall_dd, but it's a blocking
> call and it's too slow for my application. I could maybe spawn that call
> in its own thread so it doesn't block, but I think passing the shared
> pointer back is the cleaner and more correct solution.
>
> So, how hard is this going to be? SWIG 2.0 supports boost's shared
> pointer. I'm wondering if it'd just be a few extra lines in
> GR_SWIG_BLOCK_MAGIC2to expose it, or am I kidding myself?
>
> http://www.swig.org/Doc2.0/Library.html#Library_std_shared_ptr
>
> Thanks in advance,
> -Doug
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio