ufl team mailing list archive

["Martin Sandve Alnæs" <martinal@xxxxxxxxx>]

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?

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.

Martin