[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Specify which methods show up in SWIG version of

From: Isdren Gineer
Subject: Re: [Discuss-gnuradio] Specify which methods show up in SWIG version of C++ block
Date: Wed, 9 Oct 2013 14:22:05 -0700

When you create a block with gr_modtool your implementation goes in the lib/[block_name]_impl.[h|cc] files. However, the swig procedures look at the include/[package_name]/[block_name].h files to determine which methods to expose in the generated python class. So, to make a C++ method available in the python class, create a virtual method in the include/[package_name]/[block_name].h and implement it in the lib/[block_name]_impl.[cc|h] subclass.

On Wed, Oct 9, 2013 at 1:55 PM, Nowlan, Sean <address@hidden> wrote:
Declare a pure virtual function in (for example) gr-OOT/include/OOT/myblock.h :

virtual int how_many_things(const int n) const = 0;

Then declare a concrete function in gr-OOT/lib/myblock_impl.h :

int how_many_things(const int n) const;

Then define your concrete function in gr-OOT/lib/myblock_impl.cc :

int how_many_things(const int n)
    return n;

If you added your block with gr_modtool, you'll find this in gr-OOT/swig/OOT_swig.i :

#include "OOT/myblock.h"
%include "OOT/myblock.h"

The above statements will automagically SWIG anything defined in myblock.h.

-----Original Message-----
From: discuss-gnuradio-bounces+sean.nowlan=address@hidden [mailto:discuss-gnuradio-bounces+sean.nowlan=address@hidden] On Behalf Of Ethan Trewhitt
Sent: Wednesday, October 09, 2013 4:36 PM
To: GnuRadio Discussion List
Subject: [Discuss-gnuradio] Specify which methods show up in SWIG version of C++ block

I'm working on some custom C++ blocks. I would like to have a few methods in the C++ world visible to Python so that they can be called directly. My understanding is that GRC can then make such things visible through the <callback> tag in the block's XML specification.

Looking at the GR3.7 version of fir_filter, for instance, shows that it has a "set_taps" method and an "update_tap" method, both of which are public. However, only "set_taps" gets translated into the SWIG Python version of the fir_filter block, while "update_tap" does not.
What part of the gr-filter source tree instructs SWIG to include one but not the other? Does it have something to do with the way the
GR_SWIG_BLOCK_MAGIC2() macro works within filter_swig.i?

Short version: how do I instruct the SWIG build process to translate a particular method of a C++ GR block into its Python version?

Thanks in advance.


Discuss-gnuradio mailing list

Discuss-gnuradio mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]