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

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs