Re: [Mxflib-developers] Re: getchar() before exit...

[Matt B. <ma...@be...>]

----- Original Message -----
From: Oliver Morgan <ol...@me...>
To: mxf...@li...
Subject: [Mxflib-developers] Re: getchar() before exit...
Date: Tue, 09 Nov 2004 14:17:58 -0600

>=20
> Fine on making default not getchar(), providing an option can reenable it.
>=20
> I was aiming for the following other behaviours consistet across all apps:
>=20
> -q	quiet:
> 	never writes to stdout
> 	writes errors to stderr
> 	sets exit code on errors and warnings

Sounds a good idea.

>=20
> (none)default:
> 	writes sparsely to stdout
> 	writes errors warnings and config to stderr
> 	sets exit code on errors and warnings

Also sounds a good idea.

>=20
> -v	verbose:
> 	writes verbosely to stdout
> 	writes errors warnings and config to stderr
> 	sets exit code on errors and warnings

Yes, but I would like to go further (but it would take a bit of work to ach=
ieve).  I would like to have a 64-bit variable that holds a set of debug fl=
ags. For example bit 0 set will produce XML-parser debug, bit 1 will produc=
e dictionary loader debug, bit 2 will produce smart pointer debug etc... On=
e section of bits will be reserved for the application and the rest for the=
 library. debug messages would change to:

  debug( DEBUG_SMARTPTR, "Incrementing reference to %d\n", Count );

The verbose flag would be -v (set default set of flags decided by the app) =
or -v=3D0x00f0c3070 (set a complex set of debug flags) or maybe even -v=3DS=
MARTPTR|DICT|XML (to debug smart pointers, dictionary loading and XML parsi=
ng)

>=20
> Questions: is the proposed -z orthogonal to this? Or could it be seen as =
a "very verbose" (-vv) level? My vote would be for -vv

I see -z being orthogonal. There may be times that a pause is required, but=
 debug isn't. -vv may simply be -v=3D0xffffffffffffffff.

Also it seems that some embedded systems may not cope with getchar() at all=
 (yuck!) so maybe we gain a new function in system.h of the form PauseForIn=
put() which will print a prompt and wait - or on embedded systems wait for =
some other form of input.

>=20
> Another: how does this relate to #ifdef MXFLIB_DEBUG and the mxflib::debu=
g() function? The present code seems to imply that debug=20
> messages are only output by mxflib::debug() if both -v and MXFLIB_DEBUG. =
Is that what we want?
>=20

The idea is that debug messages will only be produced when -v is set, but a=
ll debug messages can be removed by not defining MXFLIB_DEBUG. The result i=
s that both MXFLIB_DEBUG and -v are required to get debug. Why? Because the=
 runtime test is done after putting together much of the debug info so even=
 with -v not supplied most of the CPU cycles are still used. When MXFLIB_DE=
BUG is not defined the debug code does not get compiled in.  For example:

  debug("Length of %s is %s\n", Object->Name().c_str(), Int64toString(Objec=
t->Size()).c_str());

...will still build a string version of the 64-bit size and extract buffer =
pointers to this and the string containing the object name and passing them=
 to the debug function which simply discards them.

> Should mxflib::debug use vfprintf(stderr, Fmt, args)?
> Should mxflib::warning use vfprintf(stderr, Fmt, args)?
> Should mxflib::error use vfprintf(stderr, Fmt, args)?
>=20

mxflib::debug use vfprintf(STDOUT, Fmt, args)
mxflib::warning use vfprintf(stderr, Fmt, args)
mxflib::error use vfprintf(stderr, Fmt, args)

Two important reasons why debug messages should go to stdout... firstly the=
y are not errors, they are debug, but secondly stdout can easily be redirec=
ted, stderr can't.  Debug produces loads of output and will often need to b=
e captured to a file for processing.

> thanks
> Oliver
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_idU88&alloc_id=12065&op=3Dclick
> _______________________________________________
> Mxflib-developers mailing list
> Mxf...@li...
> https://lists.sourceforge.net/lists/listinfo/mxflib-developers
>=20