On Fri, Mar 9, 2012 at 12:17 PM, Josh Blum
<address@hidden> wrote:
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
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:
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 Corgan 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 <block>.cc, <block>.h, <block>_impl.cc, and <block>_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