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

[Isdren Gineer]

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"
...
GR_SWIG_BLOCK_MAGIC2(OOT, myblock);

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.

Ethan

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

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