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”)
tb.connect(…)
rt = gr.runtime(tb)
rt.run()
…you have the simpler code:
tb = gr.top_block(“foo”)
tb.connect(…)
tb.run()
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
gr.top_block.
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
process.
–
Johnathan C.
Corgan Enterprises LLC
http://corganenterprises.com