discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] Q's on gr-filter (was: Developers' Call for June,


From: Johnathan Corgan
Subject: Re: [Discuss-gnuradio] Q's on gr-filter (was: Developers' Call for June, 2012)
Date: Fri, 22 Jun 2012 09:15:53 -0700

On Fri, Jun 22, 2012 at 2:42 AM, Martin Braun (CEL) <address@hidden> 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

reply via email to

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