On Tue, Dec 30, 2008 at 5:03 AM, James Turner wrote: > > On 30 Dec 2008, at 09:51, Alasdair Campbell wrote: > > > Looking initially at the atis.cxx, ATCmgr.cxx, etc code I notice a > > bunch > > of commented-out "cout" statements, which give me a good idea of where > > to look for solutions. I wonder if there is a case for introducing > > a -v > > (--verbose) option for turning all occurences these statements ON > > via an > > IFDEF condition. Suggestions on where to introduce such a condition > > welcome. I would be willing to undertake the "grunt" work. Long live > > find/grep/sed. > > (sadly I can't offer much useful advice on the radios front, but as a > more general thing:) > > We already have this, it's the SG_LOG() mechanism, which wraps a C++ > iostream (like cout) with a module and level parameters. You can set > the log-level in various ways (eg, from .fgfsrc) or using --log-level > on the command line. By default, SG_ALERT is shown - the 'lower' > levels are warning, info, bulk and debug. > > The problem is, there's code which uses INFO where it should probably > use BULK or DEBUG, and so info is a a bit much to deal with, and BULK > is more or less impossible (interactively). It's fine for recording to > a text file and then grep-ing / sed-ing of course. > > Also, for any of these lines, we pay all the string manipulation > penalty regardless of the whether the message is logged or not. In > some code this cost is potentially significant, especially inside > loops. (One I just killed: the apt loader was looking each line in the > file to BULK as it read it) > > My personal feeling is that DEBUG should be for debugging, i.e removed > once the code in question is in a stable, and that longer term we > should be considering what BULK is really useful for. Being able to > grep/sed/find in logs is nice, but finding a way to avoid the runtime > cost when the messages are suppressed (which is 99.99....% of the > time) would be equally nice :)
Originally this scheme was designed to completely collapse out of the code when not in use, but I'm not sure if that feature has been maintained over the years. Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/
------------------------------------------------------------------------------
_______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
