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

[Nowlan, Sean]

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: address@hidden [mailto: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