[m-dev.] logging proposal

[Ian MacLarty]

On Tue, Feb 28, 2006 at 01:41:24AM +0100, Peter Ross wrote:
> On Tue, Feb 28, 2006 at 01:59:19AM +1100, Ian MacLarty wrote:
> > On Mon, Feb 27, 2006 at 12:19:36PM +0100, Peter Ross wrote:
> > > On Mon, Feb 27, 2006 at 09:31:16PM +1100, Ian MacLarty wrote:
> > > > Hi,
> > > > 
> > > > As a result of the recent discussion about how to trick Mercury into not
> > > > optimising away logging calls, I am proposing the following simple
> > > > solution:
> > > > 
> > > > We add a special procedure `log' to the builtin module.  The new
> > > > procedure takes a string as input (or possibly an I/O closure).  The
> > > > compiler is then modified to treat calls to log as being the same as
> > > > true, unless an "--enable-logging" options is given.  If this option is
> > > > given then the logging predicates write their output somewhere (where
> > > > they write their output could be given by another mmc option).
> > > > 
> > > > What are the feelings on introducing such a scheme?  Clearly some kind
> > > > of logging feature is necessary, especially for very long running
> > > > programs that would be too slow in debugging grades. Also it would be
> > > > better that user's could add a logging mechanism to their code without
> > > > tricking and/or lying to the compiler.
> > > > 
> > > > We could also have different levels of logging.
> > > > 
> > > Why don't we just use the log4m module that I posted to the list quite
> > > awhile ago, it has the advantage of being extremely flexible, and with
> > > a bit of work I think one could make the determination of whether to log
> > > or not much more efficient.
> > > 
> > 
> > Because there you either have to use impure code (and if you don't want
> > the impurity to propogate up you have lie to the compiler), or you have
> > to pass the I/O state, which means you can't do logging of nondet code,
> > or you have to use the unsafe version which may or may not get optimized away.
> > 
> I think there has to be two halves to the proposal, one half is how
> to stop the compiler optimizing the code away, the other is how to
> control the logging so  that the user can only log the things that
> they are interested in .  For me log4m meets the second need, but not
> the first.

Well we've agreed debug goals should be general I/O goals (either
closures or DCG)s, so of course you could use log4m in debug goals.

Ian.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------