Menu
▾
▴
mxflib-developers
|
From: Matt B. <ma...@be...> - 2004-11-10 08:40:36
|
----- 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
|
|
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
|
Thanks for helping keep SourceForge clean.
X