On Fri, Mar 9, 2012 at 12:17 PM, Josh B. [email protected] wrote:
There are a few reasons why this branch has not yet been merged into the
main GNU Radio code. It can eventually get there, but it’s not ready
due to some objections I have with it that are not satisfied. This is
to be a rather lengthy email, but there are a good number of issues to
discuss and reasons to discuss them.
First of all, I think the idea of a tool like this is useful. I like to
prototype in Python to get the math and algorithms correct and then move
to a C++ block. It would be nice to have the ability to do this as part
a GNU Radio flowgraph so that I could get the benefits from it
like signal/sample generation, plotting tools, filtering, etc. and not
to create them in Python.
The first concern comes in when people start developing in Python and
not getting the necessary performance out of it. If you can get the
code to run fast enough for you, that’s great, but the intent should be
prototype here and then recode it in C++ for efficiency. I see a lot of
potential troubleshooting issues arising from this. The pros outweigh
cons, but I want to make sure everyone understands where and why this
capability is useful and not try to depend on it.
More importantly, the reasons why this has not been merged are due to
inconsistencies with the rest of GNU Radio. The PMTs have been changed
somewhat radically. First, the pmt_blob has been made a read/write
which goes against the design philosophy of a PMT primitive structure.
PMT primitives are read only (there are exceptions with containers like
vectors that are historic). This comes from a functional programming
concept to help us ensure thread safety without having to worry about
all over the place. If data needs to be changed in a PMT, it is expected
that you make a new PMT with the new or modified data from the old PMT.
Standard stuff in concurrency-oriented languages (see Erlang).
There is also the PMT memory pool issue that has been introduced. Eric
Blossom was the original designer and creator of the PMTs and he tried
something similar originally but found the performance wasn’t up to
His implementation of how to create and handle PMTs was based on
benchmarks. If the new way of handling PMTs in this branch turns out to
superior, I have no problem with it. But it needs to be proven.
Aside from the issues involved with the PMTs, the new blocks are written
a way that does not conform to the GNU Radio coding style:
Some of you might think this is silly, but there is a reason for a
standard and we expect our developers to follow it, if not exactly than
mostly. Deviating from the coding standard makes it really difficult to
evaluate, debug, and/or add to the code. It’s helpful to new users who
trying to learn how to program with the project or at least understand
Having widely different styles is unproductive.
Now, Josh uses a structure where there is a public API class and an
implementation class (impl). There are some really good reasons to do
such as it would help us in moving towards an application binary
(ABI). However, it is significantly different than what we do now.
Johnathan C. and I have talked about this and are in agreement that
this is a good direction to take in the future, but we want to introduce
the changes in a reasonable and more systematic manner. We have thoughts
start moving more out of gnuradio-core and into new top-level blocks,
gr-filter. We’re thinking of adopting a similar structure when we create
new top-level block (and hopefully find time to fix the existing
blocks like gr-digital). So while we would have different coding
they would be grouped more logically, each top-level block would be
internally consistent, explained in our coding guide, and steadily
project-wide. We still have to come up with the structure, which would
different from what’s in these new blocks. Probably something like a
.cc, .h, _impl.cc, and _impl.h.
But right now, we have a published coding style that we have been using
years, and changing this style would be a decision we would want to
and solidify before moving that way. I know we can find plenty of
where we’ve broken our own rules, but we are really trying to be good.
Some of this is stuff that Josh and I have debated off-list about, some
it isn’t, but since the question was asked, I thought I would give
the details about why a number of branches are not yet merged in.