Re: [Discuss-gnuradio] Status of Grblock

[Josh Blum]

> 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.
> 

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.

> 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.
> 

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