[Mono-list] Diagnostic Messages
Dwivedi , Ajay Kumar
AjayKumar.Dwivedi@dresdner-bank.com
Mon, 27 May 2002 08:24:41 +0100
Hi all,
Great discussion going on. I couln't resist jumping in ;)
I like the trace functionality but don't like the way they are used. I mean
writing my own tracelistener etc..Here's my suggestion for the trace classes
based on the discussion.
We should Use the config file as in the .NET , our aim is to make mono run
exactly similiar or better than .NET :) For each key defined in the
settings,
we add a class to the Trace.Listeners by reflection. And every call to
Trace.Write() calls the Write() methods on eash of the objects in Listener.
The default should be not to do anything. The DefaultTraceListener can send
the output to /dev/null but that would be an added overhead.
As lupus suggested, we should allow Environment Variable based
configurations too. This is especially needed when the application and its
configuration settings are readonly for a user. (There doesn't seem to be
any security risks involved)
Further, mono should have some built-in TraceListeners. These should include
syslog, file and console listener. Lazy developers like me might not like to
write their own listeners ;) We can use the syslog library call for
implementing syslog.
Happy Hacking,
Ajay
PS: While going through the Mono source for Trace class, I see all the
methods delegated to an internal class. Trace is not an abstract class, so
is there any particular reason for doing so?
> -----Original Message-----
> From: Jonathan Pryor [mailto:jonpryor@vt.edu]
> Sent: Monday, May 27, 2002 8:50 AM
> To: Mono List
> Subject: Re: [Mono-list] Diagnostic Messages
>
>
> 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
>
>
>
>
>
> _______________________________________________
> Mono-list maillist - Mono-list@ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-list
>