Incompatible trunk check-in pending (for gr.hier_block2 user

For those who are experimenting with or testing the (unreleased,
undocumented) new hierarchical flowgraph code, I am about to check in an
incompatible change. (Most people can ignore this message.)

As a final API change to the code for its official introduction in
release 3.1, the interface has been simplified by removing the need for
a ‘gr.runtime’ object. Instead, one will call start(), stop(), wait(),
or run(), directly on the gr.top_block object.

So, instead of:

tb = gr.top_block(“foo”)
rt = gr.runtime(tb)

…you have the simpler code:

tb = gr.top_block(“foo”)

Once the incompatible check in occurs, you’ll need to edit your scripts
to eliminate the call to gr.runtime and call run(), etc., on your
top_block object.

It’s not an accident that gr.top_block has come to look exactly like
gr.flow_graph in the existing code. The original plan was to introduce
a new way of building hierarchical flow graphs that had the same API as
the new mblock code. As a matter of practicality, however, maintaining
the same semantics as gr.flow_graph now will allow conversion to the new
code in most cases with a search and replace from gr.flow_graph to

For everyone else who might be wondering, the new hierarchical flow
graph code will allow you to build arbitrarily nested flow graphs to
help manage complexity in a design. In other words, you’ll be able to
build, from within Python (or C++ in release 3.2), hierarchical blocks
with arbitrary numbers of inputs and outputs, that have their own flow
graph of blocks within them. Elsewhere, you can treat that entire
flowgraph as a single block in the next “level” up in your definition.

This will be explained in much greater detail as part of the 3.1 release

Johnathan C.
Corgan Enterprises LLC