Menu
▾
▴
Re: [Mxflib-developers] Re: getchar() before exit...
|
From: Oliver M. <ol...@me...> - 2004-11-10 17:46:31
|
OK=0D
=0D
Can we move swiftly to implement -q -v and -z=0D
And make the behaviour of -v (plain) to set DebugFlag =3D ~(Uint64)0=0D
=0D
Agree that degub is stdout, warnings and errors are stderr=0D
=0D
thanks=0D
Oliver=0D
=0D
On Wed Nov 10 2:40 , 'Matt Beard' <ma...@be...> sent:=0D
=0D
>=0D
>----- Original Message -----=0D
>From: Oliver Morgan ol...@me...>=0D
>To: mxf...@li...=0D
>Subject: [Mxflib-developers] Re: getchar() before exit...=0D
>Date: Tue, 09 Nov 2004 14:17:58 -0600=0D
>=0D
>> =0D
>> Fine on making default not getchar(), providing an option can reenable i=
t.=0D
>> =0D
>> I was aiming for the following other behaviours consistet across all app=
s:=0D
>> =0D
>> -q quiet:=0D
>> never writes to stdout=0D
>> writes errors to stderr=0D
>> sets exit code on errors and warnings=0D
>=0D
>Sounds a good idea.=0D
>=0D
>> =0D
>> (none)default:=0D
>> writes sparsely to stdout=0D
>> writes errors warnings and config to stderr=0D
>> sets exit code on errors and warnings=0D
>=0D
>Also sounds a good idea.=0D
>=0D
>> =0D
>> -v verbose:=0D
>> writes verbosely to stdout=0D
>> writes errors warnings and config to stderr=0D
>> sets exit code on errors and warnings=0D
>=0D
>Yes, but I would like to go further (but it would take a bit of work to ac=
hieve). I would like to =0D
have a 64-bit variable that holds a set of debug flags. For example bit 0 s=
et will produce XML-parser =0D
debug, bit 1 will produce dictionary loader debug, bit 2 will produce smart=
pointer debug etc... One =0D
section of bits will be reserved for the application and the rest for the l=
ibrary. debug messages =0D
would change to:=0D
>=0D
> debug( DEBUG_SMARTPTR, "Incrementing reference to %d\n", Count );=0D
>=0D
>The verbose flag would be -v (set default set of flags decided by the app)=
or -v=3D0x00f0c3070 (set a =0D
complex set of debug flags) or maybe even -v=3DSMARTPTR|DICT|XML (to debug =
smart pointers, dictionary =0D
loading and XML parsing)=0D
>=0D
>> =0D
>> Questions: is the proposed -z orthogonal to this? Or could it be seen as=
a "very verbose" (-vv) =0D
level? My vote would be for -vv=0D
>=0D
>I see -z being orthogonal. There may be times that a pause is required, bu=
t debug isn't. -vv may =0D
simply be -v=3D0xffffffffffffffff.=0D
>=0D
>Also it seems that some embedded systems may not cope with getchar() at al=
l (yuck!) so maybe we gain =0D
a new function in system.h of the form PauseForInput() which will print a p=
rompt and wait - or on =0D
embedded systems wait for some other form of input.=0D
>=0D
>> =0D
>> Another: how does this relate to #ifdef MXFLIB_DEBUG and the mxflib::deb=
ug() function? The present =0D
code seems to imply that debug =0D
>> messages are only output by mxflib::debug() if both -v and MXFLIB_DEBUG.=
Is that what we want?=0D
>> =0D
>=0D
>The idea is that debug messages will only be produced when -v is set, but =
all debug messages can be =0D
removed by not defining MXFLIB_DEBUG. The result is that both MXFLIB_DEBUG =
and -v are required to get =0D
debug. Why? Because the runtime test is done after putting together much of=
the debug info so even =0D
with -v not supplied most of the CPU cycles are still used. When MXFLIB_DEB=
UG is not defined the debug =0D
code does not get compiled in. For example:=0D
>=0D
> debug("Length of %s is %s\n", Object->Name().c_str(), Int64toString(Obje=
ct->Size()).c_str());=0D
>=0D
>...will still build a string version of the 64-bit size and extract buffer=
pointers to this and the =0D
string containing the object name and passing them to the debug function wh=
ich simply discards them.=0D
>=0D
>> Should mxflib::debug use vfprintf(stderr, Fmt, args)?=0D
>> Should mxflib::warning use vfprintf(stderr, Fmt, args)?=0D
>> Should mxflib::error use vfprintf(stderr, Fmt, args)?=0D
>> =0D
>=0D
>mxflib::debug use vfprintf(STDOUT, Fmt, args)=0D
>mxflib::warning use vfprintf(stderr, Fmt, args)=0D
>mxflib::error use vfprintf(stderr, Fmt, args)=0D
>=0D
>Two important reasons why debug messages should go to stdout... firstly th=
ey are not errors, they are =0D
debug, but secondly stdout can easily be redirected, stderr can't. Debug p=
roduces loads of output and =0D
will often need to be captured to a file for processing.=0D
>=0D
>> thanks=0D
>> Oliver=0D
>> =0D
>> =0D
>> -------------------------------------------------------=0D
>> This SF.Net email is sponsored by:=0D
>> Sybase ASE Linux Express Edition - download now for FREE=0D
>> LinuxWorld Reader's Choice Award Winner for best database on Linux.=0D
>> http://ads.osdn.com/\?ad_idU88&alloc_id=12065&op=3Dclick=0D
>> _______________________________________________=0D
>> Mxflib-developers mailing list=0D
>> Mxf...@li...=0D
>> https://lists.sourceforge.net/lists/listinfo/mxflib-developers=0D
>> =0D
>=0D
>=0D
>=0D
>-------------------------------------------------------=0D
>This SF.Net email is sponsored by:=0D
>Sybase ASE Linux Express Edition - download now for FREE=0D
>LinuxWorld Reader's Choice Award Winner for best database on Linux.=0D
>http://ads.osdn.com/\?ad_idU88&alloc_id=12065&op=3Dclick=0D
>_______________________________________________=0D
>Mxflib-developers mailing list=0D
>Mxf...@li...=0D
>https://lists.sourceforge.net/lists/listinfo/mxflib-developers=0D
=0D
=0D
|
