Status of Grblock

GNU Radio
1

Hi community

I hope you’re doing well. I had been using the GrBlock feature, that
was in Josh’s branch http://gnuradio.org/cgit/jblum.git/log/?h=next,
but I wonder if it was merged into the master project? I had the
version 3.5.0rc0. Is it safe to continue developing using GrBlock?

Regards,

Sergio Antonio Pino Gallardo

2

On 03/09/2012 08:41 AM, spino wrote:

Hi community

I hope you’re doing well. I had been using the GrBlock feature, that
was in Josh’s branch http://gnuradio.org/cgit/jblum.git/log/?h=next,
but I wonder if it was merged into the master project? I had the
version 3.5.0rc0. Is it safe to continue developing using GrBlock?

Sorry, the work has not been merged yet. But, I think its safe to use.
If it turns out that writing blocks in python is too awesome a feature
for gnuradio to contain, I can move this feature into a standalone
gr-extras package. That way you can use an official release and this
feature.

FWIW, The work has been squashed and ready for merge last year:
http://gnuradio.org/cgit/jblum.git/log/?h=python_blocks

-Josh

3

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 snuff.
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 be
superior, I have no problem with it. But it needs to be proven.

  1. Offering additional APIs to pass writable buffers does not change the
    performance of passing read-only buffers in any way.

  2. PMTs are readonly but only sometimes but because Erlang? Lets assume
    that makes sense… then the feature of the writable PMT blobs feature
    isnt any worse than the existing code. In-fact, its better because it
    adds a useful feature.

  3. Want read-only PMTs to be 100% erlang/C++ compliant? This is 100%
    orthogonal to the writeable PMT blob feature. I wrote instructions here
    if you really want to be erlang compliant:
    http://gnuradio.org/redmine/issues/490

  4. And none of this has anything to do with the fact that writing
    blocks in python may be useful to have as a feature in gnuradio. This
    PMT stuff is completely orthogonal to writing blocks in python. The only
    reason python_blocks uses the writable pmt work is to share some common
    swig code.

Having widely different styles is unproductive.

Hmm… Looks like this wasn’t an issue for gr-audio, gr-uhd, misc
gr-core blocks, oh and a component you wrote, gr-shd. It would be
horrible if we merged another block into gnuradio core that hid its
implementation in a cc file. Mind you also, this block, has no installed
headers, its implementation is completely private.

Can I conclude that the new importance of conforming to your coding
style now trumps (at any cost) adding useful features into gnuradio?

-Josh

4

On Fri, Mar 9, 2012 at 12:17 PM, Josh B. [email protected] wrote:

-Josh
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
yet
due to some objections I have with it that are not satisfied. This is
going
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
it
to a C++ block. It would be nice to have the ability to do this as part
of
a GNU Radio flowgraph so that I could get the benefits from it
immediately,
like signal/sample generation, plotting tools, filtering, etc. and not
have
to create them in Python.

The first concern comes in when people start developing in Python and
then
not getting the necessary performance out of it. If you can get the
Python
code to run fast enough for you, that’s great, but the intent should be
to
prototype here and then recode it in C++ for efficiency. I see a lot of
potential troubleshooting issues arising from this. The pros outweigh
the
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
object,
which goes against the design philosophy of a PMT primitive structure.
All
PMT primitives are read only (there are exceptions with containers like
PMT
vectors that are historic). This comes from a functional programming
concept to help us ensure thread safety without having to worry about
mutex
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
snuff.
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
be
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
in
a way that does not conform to the GNU Radio coding style:
http://gnuradio.org/redmine/projects/gnuradio/wiki/Coding_guide
http://gnuradio.org/redmine/projects/gnuradio/wiki/Development

Some of you might think this is silly, but there is a reason for a
coding
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
are
trying to learn how to program with the project or at least understand
it.
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
this,
such as it would help us in moving towards an application binary
interface
(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
to
start moving more out of gnuradio-core and into new top-level blocks,
like
gr-filter. We’re thinking of adopting a similar structure when we create
a
new top-level block (and hopefully find time to fix the existing
top-level
blocks like gr-digital). So while we would have different coding
standards,
they would be grouped more logically, each top-level block would be
internally consistent, explained in our coding guide, and steadily
adopted
project-wide. We still have to come up with the structure, which would
be
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
for
years, and changing this style would be a decision we would want to
debate
and solidify before moving that way. I know we can find plenty of
instances
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
of
it isn’t, but since the question was asked, I thought I would give
everyone
the details about why a number of branches are not yet merged in.

Tom

5

This might be a very stupid question, as I’m sure that it is, but I am
new to both Linux and GR. How do I get this branch? I have been all
over the websites and forums on how one downloads this awesomeness, but
I can’t get it. Please advise.

Thanks,
Jeremy

6

spino wrote in post #1050855:

Hi community

I hope you’re doing well. I had been using the GrBlock feature, that
was in Josh’s branch http://gnuradio.org/cgit/jblum.git/log/?h=next,
but I wonder if it was merged into the master project? I had the
version 3.5.0rc0. Is it safe to continue developing using GrBlock?

Regards,

Sergio Antonio Pino Gallardo

This might be a very stupid question, as I’m sure that it is, but I am
new to both Linux and GR. How do I get this branch? I have been all
over the websites and forums on how one downloads this awesomeness, but
I can’t get it. Please advise.

Thanks,
Jeremy