GRC, per-se, isn't involved in the runtime environment of the generated
python code. Making it more involved would be a non-trivial
architectural change. But, at least *conceivably*, one could mate-up GRC
with ControlPort in ways that are "integrated and creamy". 

But with only basically 1 person maintaining GRC, there may be more
important things on the plate.... 

On 2015-06-03 13:08, Richard Bell wrote: 

> Correct me if I'm wrong, but this is what I envisioned.
> 
> From an OOT module I've been able to send various debug info out using 
> std::cout. It doesn't matter to me if it's configured at runetime or compile 
> time, because I'm sending the runtime values out. Instead of directing things 
> like buffer sizes and item length to stdout, I'd like to feed them up the 
> chain to be used in GRC. 
> 
> I'm not familiar with control ports, but you say something like this might be 
> coming out in release 3.8 then?
> 
> Rich 
> 
> On Wed, Jun 3, 2015 at 10:02 AM, Douglas Geiger 
> <[email protected]> wrote:
> 
> Sounds like you want gr-perf-monitorx: which requires ControlPort (i.e. 
> either an older release with the ICE backend, or current master with the 
> Thrift backend). 
> 
> On Wed, Jun 3, 2015 at 12:48 PM, Richard Bell <[email protected]> 
> wrote: 
> 
> Hi all,
> 
> I just had this idea and would like to know if there is any major impediment 
> to doing it. Could I add a little colored rectangle next to each input and 
> output port that would change from green to yellow to red depending on the 
> size left in that ports buffer? I feel it would help me narrow down sample 
> rate problems or figuring out which blocks are slow in the chain. 
> 
> Would this be a relatively simple addition to the block class? 
> v/r, Rich _______________________________________________
> Discuss-gnuradio mailing list
> [email protected]
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1]
> 
> -- 
> 
> Doug Geiger
> [email protected]

_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1]

 

Links:
------
[1] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Reply via email to