[Discuss-gnuradio] Hierarchical blocks and release 3.1

[Johnathan Corgan]

(Re-posting this as it showed up as a reply to the original thread
rather than the start of a new thread.)

Tom Rondeau wrote:

> You can run GNU Radio using the new version of the hierarchical 
> blocks.

Strictly speaking, the new hierarchical blocks should really be called
"new runtime with (optionally) nestable flow graphs."  Existing,
"single-level" flow graphs will run nearly unchanged, with some fairly
minor syntactic changes in the the code.

Thus, release 3.1 will have a new way to create flow graphs of existing
blocks.  In addition, this new capability will allow one to encapsulate
an entire flow graph, with arbitrary numbers of inputs and outputs, into
a single block definition, which can then itself be used in another
flowgraph, etc. (Contrast this to the existing hierarchical blocks,
which can only take a single input and single output.)

The plan for the 3.1 release is to duplicate the existing GNU Radio
examples but use the the new infrastructure for them.  In addition, the
hierarchical blocks that live in the blks namespace will be duplicated
into blks2.  As of 3.1 the "old" way of using gr.flow_graph will be
supported, but deprecated.

Having this period of time where these both exist side by side will
allow a graceful cut over in user code, and in release 3.2, we'll be
removing the old way of doing things.

In the trunk right now, the code is done and is usable, but still has
some issues.  If you just want to create flat or nested flow graphs, it
works fine. Josh Blum has converted his GNU Radio Companion project to
use the new feature set.

A new capability, however, is to be able to reconfigure a running flow
graph and preserve all the data in transit between blocks that are
unaffected. This is buggy right now and will likely remain
"experimental" for the release.

The new runtime and flow graph infrastructure is now written entirely in
C++.  This foreshadows another release 3.2 feature, the ability to write
GNU Radio applications entirely in C++, with no Python interpreter needed.

-- 
Johnathan Corgan
Corgan Enterprises LLC
http://corganenterprises.com