ffc team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Tue, Jan 13, 2009 at 07:46:30PM +0100, Martin Sandve Alnæs wrote:
> On Tue, Jan 13, 2009 at 5:55 PM, Anders Logg <logg@xxxxxxxxx> wrote:
> > On Tue, Jan 13, 2009 at 08:53:32AM +0100, Martin Sandve Alnæs wrote:
> >> On Mon, Jan 12, 2009 at 11:51 PM, Anders Logg <logg@xxxxxxxxx> wrote:
> >> > On Mon, Jan 12, 2009 at 10:17:53PM +0100, UFL wrote:
> >> >> One or more new changesets pushed to the primary ufl repository.
> >> >> A short summary of the last three changesets is included below.
> >> >>
> >> >> changeset:   497:da99d5c093fb248990c351324a4e49bd28c877c5
> >> >> tag:         tip
> >> >> user:        Anders Logg <logg@xxxxxxxxx>
> >> >> date:        Mon Jan 12 22:14:47 2009 +0100
> >> >> files:       ufl/algorithms/ad.py ufl/output.py
> >> >> description:
> >> >> Add function set_loglevel in output.py and change printing in ad.py to ufl_debug.
> >> >
> >> > Changed to
> >> >
> >> >  log.set_level(INFO)
> >> >  log.set_level(DEBUG)
> >> >  etc
> >> >
> >> > in new log.py module.
> >> >
> >> > This is not yet used in UFL, but I suggest we move to it.
> >> >
> >> > I've added some new features copied from the old log module (debug.py)
> >> > in FFC:
> >> >
> >> > 1. Writing messages and inreasing/decreasing indentation:
> >> >
> >> >   begin("Analyzing form")
> >> >   <nested print statements>
> >> >   end()
> >> >
> >> > 2. One-liners for checks and similar:
> >> >
> >> >  info("Checking whether form is valid...")
> >> >  if <check>:
> >> >     info("yes")
> >> >  else:
> >> >     info("no")
> >> >
> >> > Results in
> >> >
> >> >  Checking whether form is valid...  yes
> >>
> >> Ok, this looks good.
> >>
> >> But you can't do what you do in FFC, you're hijacking the entire UFL
> >> log instead of tapping in on its output. So if I do:
> >>
> >> import ffc
> >> import sfc
> >> sfc.dostuff() # UFL log output would be in the FFC log
> >>
> >> and I can't get the UFL log output from SFC.
> >>
> >>
> >> What you want to do (what logging is designed to do) is
> >> make your own FFC logger, and attach your FFC logging
> >> handler to the UFL logger, which merges the output of both
> >> logs in the same stream. A logger can have several handlers,
> >> so FFC and SFC can both do that .
> >>
> >> Martin
> >
> > That sounds like I must reproduce all the functions in log.py in UFL
> > also in FFC. If I want to do say
> >
> >  info("foo")
> >
> > in FFC, then if I call the info() function in UFL, the UFL logger will
> > be used.
> >
> > Is there a way that I can reuse the functions in log.py in UFL without
> > needing to reimplement them in FFC?
> 
> Why is that a concern, it's only about 100 lines?

It's enough that it would be good to keep in one place.

> Since these logging wrappers depend on some data,
> that data must either be global like now, or associated
> with an object the functions are also associated with, which
> means you end up passing a logger-like object around anyway.

I'll see if I can find a solution.

-- 
Anders

Attachment: signature.asc
Description: Digital signature