Apologies for the late posting. We will be having our monthly
developers call today (third Thursday).
Call time is 4 PM (1600) EDT or 2000 UTC.
The agenda is posted:
http://gnuradio.org/redmine/projects/gnuradio/wiki/Call20120621
Thanks,
Tom
On Thu, Jun 21, 2012 at 08:35:14AM -0400, Tom R. wrote:
Apologies for the late posting. We will be having our monthly
developers call today (third Thursday).Call time is 4 PM (1600) EDT or 2000 UTC.
Hi,
I didn’t make it to the call (10 PM is a bit of an awkward time for me),
but I have a couple of questions/comments on gr-filter:
- I like the namespace usage! Finally this is how it should be.
- The automatic doc-block export to Python does not work in gr-filter
(yet). - Also, (and yes, this is nitpicking), can Doxygen be changed such that
it says ‘#include <filter/dc_blocker_ff.h>’ instead of ‘#include
<dc_blocker_ff>’ in the block documentation? - Can you please comment on making all blocks virtual and totally
separating the DSP from the block definition? Is this simply taking
the
separation to a new ‘extreme’, or are there other reasons? Is it still
possible to make the block non-virtual and put everything inside?
And how on earth did you convince SWIG to understand all of this
(that’s not really a question, more an expression of how impressed I
am). - Will everything look like this eventually (namespaces, virtual
blocks)? In particular, will you change gr-howto-write-a-block in the
same fashion (that will throw spanners into gr-modtool, but I’ll
figure out a way how to handle that). - By which logic is mmse_fir_interpolator_cc.cc not a ‘_impl.cc’ file?
Thanks for any answers…
MB
–
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)
Dipl.-Ing. Martin B.
Research Associate
Kaiserstraße 12
Building 05.01
76131 Karlsruhe
Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu
KIT – University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association
Hi Johnathan,
and thanks for the answers!
On Fri, Jun 22, 2012 at 09:15:53AM -0700, Johnathan C. wrote:
- Can you please comment on making *all* blocks virtual and totally separating the DSP from the block definition? Is this simply taking the separation to a new 'extreme', or are there other reasons? Is it still possible to make the block non-virtual and put everything inside?I don’t quite follow your question. Could you elaborate?
Sure: in the old system, the actual blocks are directly derived from
gr_block (or gr_sync_block etc.). Now, only virtual blocks are derived
from gr_block (and exported). Then, in ‘lib’, the virtual blocks are
further derived into the impl-blocks, where the DSP is done.
This comes with a slight cost in overhead: (e.g., extra .h-files, and
any methods which are exported need to be declared first virtual, then
derived and defined).
My questions are
- Where are the benefits of this approach? (The simple three-line swig
files seemed to work without the additional abstract blocks) - If I don’t like this method, does anything stop me from making the
block derived directly from gr_block non-virtual and putting the DSP
inside that block (I assume at the very least I have to use the old
SWIG_MAGIC function?)
- By which logic is mmse_fir_interpolator_cc.cc not a '_impl.cc' file?It’s not actually a block, and the header isn’t exported. It is code used
internally by the fractional_interporlator_cc and _ff blocks, which are
impled.
Obviously I misunderstood the usage of the _impls: I assumed anything
that wouldn’t necessarily have to be put inside a block would be an
impl.
Cheers
MB
–
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)
Dipl.-Ing. Martin B.
Research Associate
Kaiserstraße 12
Building 05.01
76131 Karlsruhe
Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu
KIT – University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association
On Fri, Jun 22, 2012 at 2:42 AM, Martin B. (CEL)
[email protected]wrote:
I didn’t make it to the call (10 PM is a bit of an awkward time for me),
but I have a couple of questions/comments on gr-filter:
- I like the namespace usage! Finally this is how it should be.
Many agree with you 
- The automatic doc-block export to Python does not work in gr-filter
(yet).
- Also, (and yes, this is nitpicking), can Doxygen be changed such that
it says ‘#include <filter/dc_blocker_ff.h>’ instead of ‘#include
<dc_blocker_ff>’ in the block documentation?
I’m sure these can be fixed at the same time.
- Can you please comment on making all blocks virtual and totally
separating the DSP from the block definition? Is this simply taking the
separation to a new ‘extreme’, or are there other reasons? Is it still
possible to make the block non-virtual and put everything inside?
I don’t quite follow your question. Could you elaborate?
And how on earth did you convince SWIG to understand all of this
(that’s not really a question, more an expression of how impressed I
am).
Actually, it wasn’t that much work. SWIG didn’t originally support
namespaces (that was the reason this wasn’t done back in the origin 2.8
C++
API.) Somewhere along the line, it did. Moving the shared pointer
definition and ‘make’ function into the class definition, and moving all
the private stuff out of the public header, allowed a simple
three-lines-per-block style in a single SWIG .i file for the whole
thing.
- Will everything look like this eventually (namespaces, virtual
blocks)? In particular, will you change gr-howto-write-a-block in the
same fashion (that will throw spanners into gr-modtool, but I’ll
figure out a way how to handle that).
Yes, all the block code will change including the howto stuff. It’s not
clear yet whether some internal code that is not exported to the API is
worth converting.
- By which logic is mmse_fir_interpolator_cc.cc not a ‘_impl.cc’ file?
It’s not actually a block, and the header isn’t exported. It is code
used
internally by the fractional_interporlator_cc and _ff blocks, which
are
impled.
Tom did a lot of work to get gr-filter done in the new API style. I’ll
make another post summarizing the current status of all the other 3.7
stuff
Tom and I are working on.
Johnathan
On Tue, Jun 26, 2012 at 4:39 AM, Martin B. (CEL)
[email protected] wrote:
I don’t quite follow your question. Could you elaborate?
- Where are the benefits of this approach? (The simple three-line swig
files seemed to work without the additional abstract blocks)
Yeah, but I think it’s very little cost in the overhead. This way, we
control exactly what get’s exported, which is why we can do the SWIG
files like that. That’s one benefit. The other benefit is that we are
free to change the implementation behind the scenes and no one using
it ever need be the wiser for it. It will help us create a binary
interface to the libraries that we can rely on. We’re not quite there
with providing an ABI compatibility, but this comes closer.
- If I don’t like this method, does anything stop me from making the
block derived directly from gr_block non-virtual and putting the DSP
inside that block (I assume at the very least I have to use the old
SWIG_MAGIC function?)
No, we haven’t removed any ability to do that (yet). The SWIG magic
that you mentioned will likely be replaced once we’ve converted
everything over to the new way. At that point, you’ll either need to
handle it yourself of switch to the new standard.
Cheers
MB
Yes, only blocks have a public header and private implementation.
Other classes and files that do non-GR block implementations of
algorithms, like fir_filter, pm_remez, and others are not done this
way so that they can be exported and used as primitives or base
classes for other components and projects.
Tom