Here is a reply to your message, cc-ed to the whole group so that everybody
can see what we are talking about. The basic idea is to come up with a scheme
to make it easy to tell what is going on inside the OS.
Here are my requirements:
1- Ability to see what objects are being created, instantiated and deleted.
2- Ability to see what attributes are being modified (set/add/delete/clear
methods)
3- Ability to see what attributes are being accessed (get methods).
4- Ability to turn tracing on and off without recompiling.
5- Ability to turn tracing on and off on individual tools.
6- Ability to turn tracing on and off in the server and clients independently.
7- Ability to turn tracing on on and off in the server without restarting the
server.
Goes without saying that this should not become a project in itself. 1 or 2
days max. The idea is to have something useful, not necessarily perfect.
> >In the past few days we spent a lot of time recompiling the object system
> >with print statements to try to figure out what is going on.
>
> You and me both.
>
> >I think we
> >need a scheme for doing this so that we don't have to keep recompiling and
> >relinking to turn debug info on and off.
>
> Yes, I agree. Unfortunately I've never found any schemes that work particularly
> well. The method I've sorta settled on is the standard
> #ifdef DEBUG
> ...
> #endif
> trick. Then when I want a system with debugging I edit an Imakefile to turn
> -DDEBUG on and rebuild. Unfortunately our system does not propagate command
> line switches down into subdirectories, so at present this means we have
> to make this mod in every relevant Imakefile.
>
I don't really like this scheme because it doesn't meet requirement 4.
-----------------------------------------------------------------
> >Can we have a -debug command line argument for all programs so that one can
> >say things like
> > browser -debug "OS=SetAdd, OS=Instantiate"
>
> I've done something similar to this before and have found it rather
> difficult to manage. The problem is that you will tend to want to encode
> a great deal of "micro"-state into you settings in order to get
> just the right debugging info out. That's not to say it can't be done.
>
There will be special circumstances when tracking down certain bugs will
required very focused debugging output. I don't think we can foresee all
situations, just the most common ones. For the special cases, recompilation
will be necessary.
-----------------------------------------------------------------
> >The idea is that there would be a standard function called something like
> > set_debug_switches (some args here)
> >One would call these function at the beginning of a program, and it would
> >parse the relevant parts of the command line and set the debug switches.
>
> Right. My argument is that you tend to add switches often in order to
> center the focus of your current work, thus involving recompiles, and
> the intrusion of these recording devices tends to make large programs
> more difficult to comprehend.
>
Yes, there will be a lot of debugging code inserted in the source files, but I
rather have that than have to add it and delete it every time I want to do
some kind of tracing.
-----------------------------------------------------------------
> Now, it's interesting to note that the last problem comes from the
> inherent linear nature of code. In systems like WEB and CWEB this
> is not as big of an issue.
>
I really want to stay away from things like WEB and CWEB. I don't think the
payoffs are worth it. Also, I like to see the debugging code in the sources:
sometimes the lack of tracing output is evidence that one didn't execute a
piece of code, and that is useful info.
-----------------------------------------------------------------
> >In a program one could do the following
> >when_debug(OS=SetAdd) {
> > cout << ....;
> > cout << ....;
> >}
> >
> >when_debug would be a macro that generates the appropriate code when files
> >are compiled with -DDEBUG, otherwise all the wh_debug code would be thrown away.
>
> when_debug can't be a macro because the options are being passed in
> at the command line. But, of course all of the when_debug code will be
> wrapped in #ifdef DEBUG code so that it doesn't appear in a production
> version.
>
Let me recap the design of the debug scheme here, because I think that
when_debug can be a macro. The debug scheme consists of three parts:
- One or more variables to keep track of what debug options are turned on. I
think an array of strings would be enough. Each string would be a debug
option (eg. "OS=SetAdd").
- A function called, say, set_debug_options (argv, argc), that takes the
options in the command line and stores them in the array. I am assuming
everyone has to have this function at the top of the main program.
- A macro called when_debug(option) to guard the debugging code.
The macro would work as follows. When DEBUG is set, it expands into an if
statement something like the following:
if (option_set("OS=SetAdd"))
and if DEBUG is not set, it expands into
if (0) // or whatever is the way to give the false constant.
So, if DEBUG is not set, any compiler with minimal brains will throw out the
whole if statement.
The option_set function would look up the string in the array of set options,
so that would be simple.
I am not quite sure what the parameters to when_debug should be. Should one
call is as when_debug(OS=SetAdd) or when_debug("OS=SetAdd").
I think this scheme meets most of the requirements, except for 7-, which we
can do later on.
One last thing is that we need to make sure that the cpp version does not
print the debugging output twice (once for the server, and once for the
client). I think this will be taken care off by the way the code is currently
designed, but I need to check.
The other thing is whether the debugging output should go to cerr, cout, or
whather we should have our own stream for that?
-----------------------------------------------------------------
> >Is there a convenient way of doing this?
>
> I think that the general problem is difficult given the issues raised.
> So my answer is that we should design this with great care. Let's talk about
> it more on Monday. I imagine that Spencer might have some good ideas here
> as well.
>
I think that the set of flags we need for the object system is a super set of
the ones that I listed in the requirements. When we go through the code, it
will be evident what additional flags we need. We can argue about the names
later.
Pedro Szekely
USC/ISI, 4676 Admiralty Way, Marina del Rey, CA 90292
Phone: 310/822-1511, Fax: 310/822-0751
http://www.isi.edu/isd/szekely.html, http://www.isi.edu/isd/Mastermind