On Wed, Apr 27, 2011 at 8:59 AM, Plett, Mark L. <mark.pl...@jhuapl.edu>wrote:
> Hi Tom, Alex, and Josh, > > We've started looking into logging for our modems as well. Currently we > use the python logging module for logging on the python side. We have > started to include the log4cplus library for logging in our blocks. We are > starting with each block having its own logger, but plan to eventually move > to one logger in a static class. > > It wasn't clear what advantages boost.log had over log4cplus. We started > with log4cplus since it has the same log4j roots as the python logging > module. So we could have similar configuration files and paradigms in C++ as > we are using in Python. Any thoughts on which library would be a better > starting point? > > Regardless of which library gets used, I would advocate using one of the > already available libraries in some kind of thin GR wrapper. > > Its important to our modems that we be able to remove the logging entirely > for performance. Which we can do with log4cplus. Can we do that with > boost.log as well? > > Our logging wish list would look something like this: > > 1) The usual logging features, rolling files, level filtering, various > output streams, file, socket, stdout etc... > 2) One module for logging in python and C++ > 3) One module for logging across separate blocks > 4) Logging easily disabled from the build so we can easily control the > trade-off between performance and debug. > > Our current plan is to roll our own logging with the log4cplus library. Is > anyone signing up to take on logging for gnuradio? Does anyone has a clear > argument for or against log4cplus vs boost.log? > > Thanks, > --mp Thanks for the input, Mark. From GNU Radio's point of view, if we were to roll any of these features into the code, I would probably go with boost, mostly because we are already pretty heavy users of Boost and this seems like the least change to the code. In other words, we wouldn't have to add another dependency to the already long list. Of course, if there is a really good argument for another project, we would have to consider it. Tom > > -----Original Message----- > From: discuss-gnuradio-bounces+mark.plett=jhuapl....@gnu.org [mailto: > discuss-gnuradio-bounces+mark.plett=jhuapl....@gnu.org] On Behalf Of Josh > Blum > Sent: Tuesday, April 26, 2011 6:07 PM > To: discuss-gnuradio@gnu.org > Subject: Re: [Discuss-gnuradio] Error handler > > > >> Hi tom, > >> > >> Thanks for the info. > >> For future enhancements one can consider creating a global object that > >> provides functions like gr_debug(), gr_error(), gr_warning() that are > >> accessible by both blocks and applications. Similar to what is available > in > >> Qt. I guess the only advantage over fprintf's would be uniform > management > >> errors and debug messages that could provide controlled shut down in > case of > >> critical errors. > >> > >> Alex > >> > > > > > > Good ideas, thanks! > > > > Tom > > > > > > > It looks like boost has a logging facility. Its not officially part of > boost yet. It seems to be all headers files, so you could probably pull > it into gnuradio and start using it. > > http://boost-log.sourceforge.net/libs/log/doc/html/index.html > http://sourceforge.net/projects/boost-log/files/boost-log-1.0.zip/download > > I'm looking into something of the like for UHD and boost is often the > answer. -Josh > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
