On Fri, Jul 27, 2018, at 6:23 AM, Müller, Marcus (CEL) wrote:
> Awesome! Folks, this is the way I always hoped the community works.
> Cheers to you!
LOL thanks but maybe premature?!
This issue is somewhat more complicated than I thought, mostly because I'm
still learning how to actually use a c++ hier_block2 block to do things ...
mostly by example: internal to GR (nope) and OOTs (not much) ... because the
source isn't exactly obvious how to use.
Unless folks can convince me otherwise, I'm going say that this issue is an
unfortunate mix of a little-used API (hier_block2), the fact that "hier_block2"
inherits from "basic_block" so one can use the latter's API even if one isn't
supposed to (e.g., "message_port_register_in" and "set_msg_handler"), and, of
course, user (me) error.
After much ado, I now believe that the following is true:
{{{
The idea behind a hier_block2 is that it is just a class that holds internal
flowgraph(s), allowing connections from the outside to the inside and vice
versa. It should -never- actually implement DSP; it should just instantiate and
connect blocks. These connections can be just internal, or internal <->
external; they can be for stream or message types.
}}}
My error was thinking I could add in some DSP to a hier_block2 ... but that's
not what it's designed for && I don't see a good way to mix and match
functionality for which the class wasn't designed. That said, the basic_block
-> hier_block2 APIs don't preclude one trying to mix and match as I tried.
Hence, what I'll do is tweak the hier_block2 API to overload specific
"basic_block" methods & print out a runtime error to -not- do this.
Again: Unless folks can convince me otherwise that hier_block2 is actually
meant to be able to mix and match flowgraph and DSP as described. - MLD
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
