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 _______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
