# Developers' Call for June, 2012 **URL:** \ **Category:** GNU Radio\ **Created:** [June 21, 2012, 2:37pm UTC](https://www.ruby-forum.com/t/developers-call-for-june-2012/220826 "2012-06-21T14:37:03Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![aris](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/258eb7/32.png) [@aris](https://www.ruby-forum.com/u/aris)\ **Post date:** [June 21, 2012, 2:37pm UTC](https://www.ruby-forum.com/t/developers-call-for-june-2012/220826/1 "2012-06-21T14:37:03Z")
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](http://gnuradio.org/redmine/projects/gnuradio/wiki/Call20120621) Thanks, Tom ---
**Author:** ![tomrobinson](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/d78d45/32.png) [@tomrobinson](https://www.ruby-forum.com/u/tomrobinson)\ **Post date:** [June 22, 2012, 11:43am UTC](https://www.ruby-forum.com/t/developers-call-for-june-2012/220826/2 "2012-06-22T11:43:31Z")
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 \’ instead of ‘#include \’ 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 ---
**Author:** ![tomrobinson](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/d78d45/32.png) [@tomrobinson](https://www.ruby-forum.com/u/tomrobinson)\ **Post date:** [June 26, 2012, 10:40am UTC](https://www.ruby-forum.com/t/developers-call-for-june-2012/220826/3 "2012-06-26T10:40:33Z")
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 1. Where are the benefits of this approach? (The simple three-line swig files seemed to work without the additional abstract blocks) 2. 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 ---
**Author:** ![tomrobinson](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/d78d45/32.png) [@tomrobinson](https://www.ruby-forum.com/u/tomrobinson)\ **Post date:** [June 22, 2012, 6:17pm UTC](https://www.ruby-forum.com/t/developers-call-for-june-2012/220826/4 "2012-06-22T18:17:23Z")
On Fri, Jun 22, 2012 at 2:42 AM, Martin B. (CEL) [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)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 \’ instead of ‘#include > \’ 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 ---
**Author:** ![tomrobinson](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/d78d45/32.png) [@tomrobinson](https://www.ruby-forum.com/u/tomrobinson)\ **Post date:** [June 26, 2012, 3:10pm UTC](https://www.ruby-forum.com/t/developers-call-for-june-2012/220826/5 "2012-06-26T15:10:36Z")
On Tue, Jun 26, 2012 at 4:39 AM, Martin B. (CEL) [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > > I don’t quite follow your question. Could you elaborate? > > 1. 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. > 1. 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