Re: [Discuss-gnuradio] Dynamically changing the flowgraph

[Eric Blossom]

On Sun, Oct 23, 2005 at 03:58:47PM -0400, Ilia Mirkin wrote:
> On Sun, 2005-10-23 at 11:09 -0700, Eric Blossom wrote:
> > partially connected (internally), and then the sanity checker
> > complains that it doesn't have inputs or outputs connected when you
> > try to restart.
> 
> Why is it even making sure that everything is connected up properly? If
> it's not, it should just not call its work function... (I realize that
> the answer is 'because it's coded that way' but I'm hoping to see if
> there is a more rational explanation.)
> 
> Ilia

It's coded this way to avoid "quiet failures".

[...and the existing hierarchical block implementation is the
"simplest thing that could possibly work (most of the time)"]

This problem only shows up when using hierarchical blocks.  Right now,
the insides of the block are wired together in the constructor.  This
leads to the problem where if the i/o ports of the block aren't
connected, there are blocks (the guts of the hier block) in the
flattened flow graph that are partially connected.

Perhaps a better solution is to avoid flattening the hierarchical
graph until somewhere in the fg.start() method, just before where the
contract checks are performed (validate()).  Likewise fg.stop() would
unwire the guts.  Perhaps we should express the internal connectivity
of the block with some kind of declarative method vs the existing
procedural approach, or at least move the wiring / unwiring into new
methods of gr.hier_block_base, e.g., connect_me, unconnect_me.  This
would allow us to still validate blocks' interface contracts, without
tripping over this current implementation detail.  Defering the
internal connection would also allow us to construct blocks that take
a look at how they're being connected, and then use this information
to figure out their internal topology.  [E.g., takes N inputs and N
outputs then creates N parallel paths internally, or similarly, have
the input and output signatures of the hier block be explicity
provided, instead of passively inherited from the head and tail args
to the superclass constructor.]  If we delay connecting the guts,
internally we'll probably need to provide some kind of proxy to
represent the external connection intention, and then at "flattening
time" instantiate the guts and wire up via the proxy.

Want to take a shot at this?  It would be a *very* useful enhancement.
The current code is on the order of a couple of hundred lines of
python.  The changes would probably go in hier_block.py and
basic_flow_graph.py.

Eric