discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Do we really need logging in GNU Radio?


From: Andrej Rode
Subject: Re: [Discuss-gnuradio] Do we really need logging in GNU Radio?
Date: Thu, 29 Aug 2019 20:30:46 +0200

Hi,

> > during the last congress (35c3) we have been talking about
> > the logging in GNU Radio. I was not thinking about this much,
> > until the recent discussion with another GNU Radio developer
> > at the CCCamp 2019 (unfortunately, I forgot his name, sorry).

I plead guilty. It was me. 

> > Instead of printing directly to stderr (or anywhere else),
> > we can define a value-string array of possible events:
> > 
> >   enum gr_audio_event_t {
> >     GR_AUDIO_EV_OVERRUN,
> >     GR_AUDIO_EV_UNDERRUN,
> >     GR_AUDIO_EV_FOO_BAR,
> >     /* other events... */
> >   };
> > 
> >   struct value_string {
> >     unsigned int value;
> >     const char *string;
> >   } gr_audio_events[] = {
> >     { GR_AUDIO_EV_OVERRUN, "Buffer overrun" },
> >     { GR_AUDIO_EV_UNDERRUN, "Buffer underrun" },
> >     { GR_AUDIO_EV_FOO_BAR, "Pretty description" },
> >     /* other events... */
> >     { 0, NULL }
> >   };
> > 
> > and give a possibility to the API user to subscribe either to
> > some of the events, or to all of them, so logging can be done
> > by the user itself, if needed. For GUI applications, the
> > corresponding part of UI can be updated instead.

This idea was especially valuable as blocks/objects/modules could keep
the logging messages in a binary format. Meaning that for each
event/block there could be a struct which contains information and
instead of serializing/stringifying every event logged the information
could stay in a binary/original format until it really needs to be
converted to a string. (Which is actually how the python logging
library handles string formating as well).

I thought about something like passing a
"event_severity, event_component, event_data_t, event_data_fmt" with
the last argument being a function pointer which can convert
event_data_t to string. For simple logging messages with static content
this could just be a static string, but for dynamic content this could
convert all sorts of information to a printable string (if needed).

Obviously I'm not going to implement this, just my 2 cents where this
idea originated. 

Cheers
Andrej




reply via email to

[Prev in Thread] Current Thread [Next in Thread]