[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] Specify which methods show up in SWIG version of
Re: [Discuss-gnuradio] Specify which methods show up in SWIG version of C++ block
Wed, 9 Oct 2013 20:55:50 +0000
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)
If you added your block with gr_modtool, you'll find this in
The above statements will automagically SWIG anything defined in myblock.h.
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
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