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

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
>
>