On Fri, Dec 28, 2018 at 2:43 PM Müller, Marcus (IEH) <muel...@kit.edu>
wrote:
> For them, that's very important, as they use that to supply resilient
> infrastructure. I hope I'm representing the idea kinda correctly here:
> They might want to log system events ("SUPERVISOR: INFO system load
> surpassing 75%") somewhere, and development info ("gr-6G: TRACE found a
> preamble") on-screen, and critical messages ("gr-digital: FATAL run out of
> developer coffee") everywhere.
>
> I want that too. I want this to be easily integratable into software that
> uses GNU Radio as library. And if I'm already making wishes here,
> I want loggers that interface to modern logging systems, be it journald,
> graylog or SNMP. Something.
>
Speaking as someone who uses GNU Radio as a library, in an application
where stderr is definitely not part of the user interface, I'd really like
any logging that's done to be able to be directed to the (Python)
application for further processing.
I'd further suggest that, when a message identifiably comes from a
particular block, it should be redirectable within the scope of any
containing top block or hierarchical block. This way, a hierarchical block
may have specific handling of messages produced by the primitive or
sub-hierarchical blocks it uses — and if the hierarchical block is multiply
instantiated, the application can annotate or process the messages in a way
specific to the instance.
One possible API for this that comes to mind would be for logging from
blocks to be a special sort of message port, which propagates up the
hier-block-archy if not otherwise connected.
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
