Subject: CVS domivogt: * ... and removed debug code.

From: CVS <[email-masked]>
Date: Wed, 10 May 2000 08:49:47 -0500 (CDT)

CVSROOT:	/home/cvs/fvwm
Module name:	fvwm
Changes by:	domivogt	00/05/10 08:49:47

Modified files:
	fvwm           : builtins.c functions.c 

Log message:
* ... and removed debug code.

--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: [email-masked] (Paul D. Smith)
Date: 10 May 2000 10:52:27 -0400

%% CVS <[email-masked]> writes:

  c> * ... and removed debug code.

I see this sort of thing all the time.

Wouldn't it be better to provide a more feature-rich, configurable
debugging library for FVWM so we could just _leave_ all that debugging
stuff in there, but people wouldn't normally see it?

I have a macro-ized (so it evals to nothing if you want to compile out
debugging) little debugging library (one .c and one .h) which provides a
standard format for messages that include filename/linenumber
information, a "debugging level" feature that lets you classify
debugging messages so you can choose a level of verbosity, etc. that I'd
be happy to contribute.  You can set the level either from within the
code or via environment variables, and output can be written to stderr
or to a logfile.

It's not perfect: for example, you can't classify debugging messages by
"area" (as in print only the debugging messages associated with module
messages).  But, I think it's better than adding/removing printfs all
the time :)

If anyone is interested I can throw it in.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <[email-masked]>         Network Management Development
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 10 May 2000 16:26:29 +0200

> If anyone is interested I can throw it in.

Hm, I don't know if I'd actually use it (I don't have to think when
throwing in a fprintf).  What I'd definitely need though is a
mechanism to filter out only messages used to debug a specific
problem.  E.g. each printf gets an 'id' and I can specify to
print out only messages with a certain id.

Bye

Dominik ^_^

-- 
Dominik Vogt, Agilent Technologies, Dept. BVS
Herrenberger Str.130, 71034 Boeblingen, Germany
phone: 07031/464-4596, fax: 07031/464-3883, [email-masked]
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Tim Phipps <[email-masked]>
Date: Wed, 10 May 2000 16:38:10 +0100

> print out only messages with a certain id.
My thoughts too, there already is the DBUG macro. I keep it off because
turning it on produces too much.  Maybe if the function called byt the
DBUG macro had a filter controllable at run time it would be more
useful. It would be nice if the macro knew the name of the function it
was called from too.

Cheers,
Tim.

---

From: [email-masked] (Paul D. Smith)
Date: 10 May 2000 11:49:34 -0400

%% Dominik Vogt <[email-masked]> writes:

  dv> Hm, I don't know if I'd actually use it (I don't have to think
  dv> when throwing in a fprintf).

It's designed to be just as simple as that, if not moreso (you don't
need to specify a FILE* like you do with fprintf() :).

To add debugging message to the "basic" level, you use:

 DB(("This is some message, with string %s", str));

Except for the extra ()'s, it's just like a printf.  For a different
level of debugging you have to give the level, as well:

 DBL(5, ("This is some special message, with value %ld", myval));

  dv> What I'd definitely need though is a mechanism to filter out only
  dv> messages used to debug a specific problem.  E.g. each printf gets
  dv> an 'id' and I can specify to print out only messages with a
  dv> certain id.

That could be done, but would require more interface of course.

---

From: [email-masked] (Paul D. Smith)
Date: 10 May 2000 11:59:52 -0400

%% Tim Phipps <[email-masked]> writes:

  tp> My thoughts too, there already is the DBUG macro. I keep it off
  tp> because turning it on produces too much.

That's where levels come in handy.

Of course, if you put your stuff at level 9 then you get the rest of the
level 9 stuff, which sucks.  That's why I said some kind of "code area
selection" would be a good enhancement.

  tp> It would be nice if the macro knew the name of the function it was
  tp> called from too.

My version does print the function name, if you compile with GCC--note
that there is no way in standard C89 to derive the function name, except
by setting it somehow.  GCC provides an extension that does this, and my
debugging library does take advantage of that (if you don't use GCC the
library still works, but no function name is printed).

In C99 they introduced a FUNCNAME (that's not what it's called, but I
forget) but unfortunately it's a variable instead of a preprocessor
constant string, like GCC's.  GCC's is better.  But, the way I use it,
it actually doesn't matter.  Of course, I don't know of any C99
compilers yet so that point is moot :).

  tp> Maybe if the function called byt the DBUG macro had a filter
  tp> controllable at run time it would be more useful.

It's simple to do that; what's a pain is deciding which macros belong in
which filtered section.  The only way to do that is either on a
per-filename or per-function name basis, or in the debug invocation
itself.

If all you want is per-file or per-function (in GCC), you can simply use
grep or whatever on the output since it's all automatically added for
you.  The output format of a debugging function is well-defined and
contains all the info you need to do intelligent searching, even if the
output is pretty voluminous.