• Richard Burk (94/94) Aug 16 2001 I recommend that there be a mechanism that automatically manages
• Walter (6/100) Aug 16 2001 Those are all great ideas and part of why D supports in, out, inout, deb...

Richard Burk <sfentress home.com> writes:

I recommend that there be a mechanism that automatically manages
debugging built
into the compiler.  What I mean by this is that while the compiler
compiles the code
it should build into the code logging statements that automatically
output to a log file
the name of the class and method upon enter and exit.  It should output
the values
of parameters upon entering a method and output the return value upon
exit.  With
the in, out, and inout specification on the method signature this would
assist the
compiler in making this determination.  Log statements should be
outputted at every
decision point.  The contents of the each side of the relation should be
outputted at
each decision point.  When the compiler is done the compiler would
output in
addition to the normal files that it generates a file that would be read
by the program
on startup to determine what classes, methods, decisions, etc. would be
enabled
or disabled for logging while the program runs.  Also a compiler switch
should be
provided that does not include logging.  By including the logging you
have now
created a useful mechanism that indicates what is going on for a
program.  This
is especially useful for multithreaded programming as it is far easier
to trace a log
than it is to trace multiple threads at runtime simultaneously.  You
should include
the capability to roll the log based on size and age and how many logs
for rolling
such as log1.txt to log10.txt.  Information in the log would include the
thread id
that is outputting the log statement.  Log statements should consist of
just one line
as that makes it easier to parse statements with minimal trouble.  You
should
include a column that should the increment number of the log statement
since the
program started.  You should have another column that has the increment
number
of the current thread since it started.  Please include a column for the
date and the
time down to milliseconds or smaller if the hardware platform supports
it.  The
log statements should be synchronized so that log statements from
multiple
threads don't garble each other.  Have all log statements go to one file
but make
it flexible enough that the log statements might have a separate file
either by thread
or by log statement type.  Log statement types might be methodinout,
methodin,
methodout, decisionpoint, methodentry (includes method paramenters).
Once
this is done, you could have a log analyzer tool that could read in the
logs and
manipulate them so that the developer may analyze them.  This is a very
powerful feature.  I have done most of the log statement stuff that I
have
described above, but have relied on grep and vi for most of my log
analysis.  I
have not had enough time to develop a log analyzer as that project has
been
deferred time and again by management.  The ability to turn on and off
various
log statements allows us to see what is going on or to pay attention to
a specific
portion of the code without the noise of log statements from other parts
of the
code.  If I had had the go-ahead I would have provided an interface
while the
application was running to flexibly manipulate the log levels during
realtime.  This
should be a feature that you add to D as well.  You will have some very
happy
developers using D by offering this capability.  In addition, I suspect
that you
would be doing much of this during the implementation of D and having to
remove
it later.  Something that would be beneficial to the developer would be
the ability
to allow the developer to output statements into this logging facility.
Perhaps
that is not necessary if you provide a log type of assignment or general
which would
allow the developer to output statements that the compiler doesn't
output.  Though
what I have described is quite comprehensive (at least in my own mind if
not yours).

Richard Burk

"Walter" <walter digitalmars.com> writes:

Those are all great ideas and part of why D supports in, out, inout, debug,
etc., features, because they enable an implementation to implement all these
great ideas. I've seen attempts to do them with macros, and they all were
ugly in one way or another.

"Richard Burk" <sfentress home.com> wrote in message
news:3B7BF81B.98CD141B home.com...
 I recommend that there be a mechanism that automatically manages
 debugging built
 into the compiler.  What I mean by this is that while the compiler
 compiles the code
 it should build into the code logging statements that automatically
 output to a log file
 the name of the class and method upon enter and exit.  It should output
 the values
 of parameters upon entering a method and output the return value upon
 exit.  With
 the in, out, and inout specification on the method signature this would
 assist the
 compiler in making this determination.  Log statements should be
 outputted at every
 decision point.  The contents of the each side of the relation should be
 outputted at
 each decision point.  When the compiler is done the compiler would
 output in
 addition to the normal files that it generates a file that would be read
 by the program
 on startup to determine what classes, methods, decisions, etc. would be
 enabled
 or disabled for logging while the program runs.  Also a compiler switch
 should be
 provided that does not include logging.  By including the logging you
 have now
 created a useful mechanism that indicates what is going on for a
 program.  This
 is especially useful for multithreaded programming as it is far easier
 to trace a log
 than it is to trace multiple threads at runtime simultaneously.  You
 should include
 the capability to roll the log based on size and age and how many logs
 for rolling
 such as log1.txt to log10.txt.  Information in the log would include the
 thread id
 that is outputting the log statement.  Log statements should consist of
 just one line
 as that makes it easier to parse statements with minimal trouble.  You
 should
 include a column that should the increment number of the log statement
 since the
 program started.  You should have another column that has the increment
 number
 of the current thread since it started.  Please include a column for the
 date and the
 time down to milliseconds or smaller if the hardware platform supports
 it.  The
 log statements should be synchronized so that log statements from
 multiple
 threads don't garble each other.  Have all log statements go to one file
 but make
 it flexible enough that the log statements might have a separate file
 either by thread
 or by log statement type.  Log statement types might be methodinout,
 methodin,
 methodout, decisionpoint, methodentry (includes method paramenters).
 Once
 this is done, you could have a log analyzer tool that could read in the
 logs and
 manipulate them so that the developer may analyze them.  This is a very
 powerful feature.  I have done most of the log statement stuff that I
 have
 described above, but have relied on grep and vi for most of my log
 analysis.  I
 have not had enough time to develop a log analyzer as that project has
 been
 deferred time and again by management.  The ability to turn on and off
 various
 log statements allows us to see what is going on or to pay attention to
 a specific
 portion of the code without the noise of log statements from other parts
 of the
 code.  If I had had the go-ahead I would have provided an interface
 while the
 application was running to flexibly manipulate the log levels during
 realtime.  This
 should be a feature that you add to D as well.  You will have some very
 happy
 developers using D by offering this capability.  In addition, I suspect
 that you
 would be doing much of this during the implementation of D and having to
 remove
 it later.  Something that would be beneficial to the developer would be
 the ability
 to allow the developer to output statements into this logging facility.
 Perhaps
 that is not necessary if you provide a log type of assignment or general
 which would
 allow the developer to output statements that the compiler doesn't
 output.  Though
 what I have described is quite comprehensive (at least in my own mind if
 not yours).

 Richard Burk