Subject: [UFL-dev] [HG UFL] Add function set_loglevel in output.py and change printing in ad.py to ufl_debug.

From: [email-masked] (UFL)
Date: Mon, 12 Jan 2009 22:17:53 +0100 (CET)

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 <[email-masked]>
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.

changeset:   496:d0277a7178913b6aabfe2a61d587171b5fc194c8
user:        "Martin Sandve Alnæs <[email-masked]>"
date:        Mon Jan 12 13:25:17 2009 +0100
files:       ROADMAP ufl/algorithms/forward_ad.py ufl/indexing.py
description:
minor details

changeset:   495:cf4de6795ca6c369314983e26bed0aa58e783e8d
user:        "Martin Sandve Alnæs <[email-masked]>"
date:        Mon Jan 12 11:07:12 2009 +0100
files:       test/indices.py test/test.py ufl/indexing.py
description:
Implemented support for implicit sums of tensor
expressions in Indexed, not only scalars.
This makes v.dx(i)[i] and A[i,:][i] valid
expressions. Altough these look a bit weird,
they are perfectly valid operations that
will be documented clearly using pen-and-paper
syntax.

----------------------------------------------------------------------
For more details, visit http://www.fenics.org/hg/ufl

---

From: Anders Logg <[email-masked]>
Date: Mon, 12 Jan 2009 23:51:06 +0100

> 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

-- 
Anders

> _______________________________________________
> UFL-dev mailing list
> [email-masked]
> http://fenics.org/mailman/listinfo/ufl-dev

---

From: "Martin Sandve Alnæs" <[email-masked]>
Date: Tue, 13 Jan 2009 08:53:32 +0100

>  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

---

From: Anders Logg <[email-masked]>
Date: Tue, 13 Jan 2009 17:55:33 +0100

> so FFC and SFC can both do that .

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?

-- 
Anders

---

From: "Martin Sandve Alnæs" <[email-masked]>
Date: Tue, 13 Jan 2009 19:46:30 +0100

> 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