[Mono-list] Diagnostic Messages

[Jonathan Pryor]

Reply inline.

On Sun, 2002-05-26 at 14:03, Lawrence Pit wrote:
    Hi Jonathan,
    
    > Linux/Unix, as far as I can tell, has no equivalent to
    > `OutputDebugString'.  The console must be used instead (until someone
    > tells me a better way to do it).
    
    I'm not really familiar with Linux, but google tells me it has a syslog
    (which they got from BSD). Regardless, if a system doesn't have something
    similar to OutputDebugString I see no problem in simply sending the output
    to /dev/null by default.

Yes, by default.  Notice that this was the behavior of my proposal: by
default the calls to {Trace|Debug}.WriteLine is ignored.  Output is only
present if mono/mint is started with a ``--diagnostic'' parameter.
    
    > So I have a problem: I want to leave trace code in the program, but I
    > don't want the user to see it by default.
    [...]
    > If I want to see debug messages:
    >
    > $ mono --diagnostics=debug
    > ** Mono-Debug: Debug Message
    > Console Message
    [...]
    > The point I'm attempting to demonstrate is that this isn't a compiler
    > issue, this is a runtime issue.  Trace and debug messages need to be
    > sent somewhere in order to be seen (and thus useful), but we don't want
    > them to be seen all the time, as it isn't appropriate.
    
    The point I was trying to make is that it should not be a runtime issue, but
    a compile time issue. Read the remarks in the documentation for
    ConditionalAttribute, the compiler should ignore calls to Debug and Trace
    methods unless a compilation variable is defined.

Yes, I'm well aware of this.  Again, the behavior I'm concerned about is
when the call to {Debug|Trace}.WriteLine is within the IL code --
meaning that TRACE or DEBUG was defined when the program was compiled. 
So I'm concerned with post-compiler behavior, hence runtime behavior.
    
    Certainly for debugging no switch should exist for mono. That would be a bit
    of a shame, as the consequence would be that all debugging statements are in
    the compiled code regardless of how it's compiled, therefor impacting
    performance and code size of production software.
    
I'm not sure that I follow you here.  Debugging statements would only be
present in the compiled code if the appropriate macro (TRACE, DEBUG) was
defined during compilation, in which case it should be a reasonable
assumption that run-time diagnostic behavior may be desired.

    Tracing is somewhat different as you MIGHT want to enable that (temporarily)
    in a production environment. Tracing is however usually controlled through
    the application configuration file as it's not simply a matter of switching
    tracing on or off when you startup a program, instead you can switch tracing
    on for an ASP.NET application and off for another while both are running in
    the same mono runtime instance. Also, via the app configuration file you can
    configure more than just the property values on/off, but also things like
    indent level, the trace switches that should be used, etc.
    
I will have to read more about the configuration files, but I believe
that I have a general idea of how they work.

Thus, I'll pose a question to you: what should happen at runtime if the
application configuration file specifies that diagnostic messages should
be displayed, and it leaves the `DefaultTraceListener' intact?  (For
example, it only adds additional listeners, or otherwise doesn't remove
the "Default" trace listener.)

Should the `DefaultTraceListener' do nothing, even though diagnostic
messages have been requested?  I should think not; it should do
something, otherwise it will look like it isn't working, leading to
annoyed developers.

If it should do something, then what should it do?  This is the crux of
all my questioning: when we *know* that the `DefaultTraceListener'
should do something, what should it do?  Send output to `syslog'?  A
plausible idea, but I'm not too keen on it until someone demonstrates a
way to view `syslog' messages without needing to directly view
`/var/log/messages,' which is readable only by the root user (on Red Hat
7.3, anyway).

Should it send output to the console?  This is my current thinking,
lacking any other idea of where to send it.

However...what if the program has no application configuration file? 
What is a reasonable default?  Not everyone will know about application
configuration files, though perhaps they should.  This is where I
believe a ``--diagnostics'' parameter to mono/mint would be useful: you
could enable/disable the output of diagnostic messages without needing
to create a configuration file.

I would find this tremendously useful, as I tend to write lots of small
test programs to gain greater understanding about how something works,
and needing to create configuration files for such programs could be a
nuisance.  (Of course we can also argue about the usefulness of Trace
messages within such small applications, but I'll skip that discussion
for now.)
    
    Greets,
    Lawrence

Thank you for contributing to the discussion.  This is raising several
issues I hadn't considered before.

 - Jon