fenics team mailing list archive

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

2008/3/20, Anders Logg <logg@xxxxxxxxx>:
> On Thu, Mar 20, 2008 at 03:45:56PM +0100, Martin Sandve Alnæs wrote:
>  > 2008/3/19, Anders Logg <logg@xxxxxxxxx>:
>  > > On Wed, Mar 19, 2008 at 09:00:55PM +0100, Martin Sandve Alnæs wrote:
>  > > > 2008/3/18, Anders Logg <logg@xxxxxxxxx>:
>  > > > > On Tue, Mar 18, 2008 at 10:54:09AM -0500, Andy Ray Terrel wrote:
>  > > > > > Matthew Knepley wrote:
>  > > > > > > On Tue, Mar 18, 2008 at 10:34 AM, Anders Logg <logg@xxxxxxxxx> wrote:
>  > > > > > >
>  > > > > > >> On Sun, Mar 16, 2008 at 04:50:07PM +0100, Martin Sandve Alnæs wrote:
>  > > > > > >>  > I highly recommend that all Python projects in FEniCS use the module
>  > > > > > >>  > "logging" that comes with Python from version 2.3. It is very simple
>  > > > > > >>  > and very flexible, in particular for creating cross-module logs. For
>  > > > > > >>  > the most basic usage, look at output.py and the tests in UFL.
>  > > > > > >>  >
>  > > > > > >>  > Basic tutorial (good site for handy python modules):
>  > > > > > >>  > http://blog.doughellmann.com/2007/05/pymotw-logging.html
>  > > > > > >>  >
>  > > > > > >>  > Reference:
>  > > > > > >>  > http://docs.python.org/lib/module-logging.html
>  > > > > > >>
>  > > > > > >>  Sounds good, but the big problem is more likely to coordinate logging
>  > > > > > >>  from C++ (DOLFIN) and Python. Is there a nice solution for this?
>  > > > > > >>
>  > > > > > >
>  > > > > > > As long as whole lines are always written, and the file is line buffered, I
>  > > > > > > think writing from two different file descriptors should be fine. The nice
>  > > > > > > thing would be to replicate the format in C++.
>  > > > > > >
>  > > > > > >    Matt
>  > > > > > >
>  > > > > > >
>  > > > > >
>  > > > > > Or you could just write a C api that calls into python.  Is there any
>  > > > > > reason you would be needing to log from C++ and python at the same time?
>  > > > >
>  > > > > Yes, when running DOLFIN from Python. We then call DOLFIN C++ code,
>  > > > > DOLFIN Python code (not everything is done in SWIG), FFC Python code
>  > > > > and FIAT Python code (which is quiet most of the time).
>  > > >
>  > > > You can subclass the "logging.Logger" class (or something similar) in
>  > > > PyDOLFIN, simply passing the log messages to the C++ DOLFIN log
>  > > > system. So nothing (or very little) needs to change in C++ DOLFIN.
>  >
>  > (Maybe we want something more though, I might have oversimplified things here.)
>  >
>  > > Then what's the point of using the logging module in PyDOLFIN, instead
>  > > of just calling the DOLFIN log system directly?
>  >
>  > Python libraries can't depend on the DOLFIN log system.
>
>
> I agree, but didn't you suggest that we pass the log messages to the
>  C++ DOLFIN log system?

A python application that uses ufl, ffc and pydolfin should be able to
merge the logging output from ufl and ffc into the dolfin log. This
can be done by subclassing logging.Handler to pass log messages to the
dolfin system, and attaching this handler object to the ufl and ffc
Logger objects. Something like

h = dolfin.getLoggingHandler()
ufllog = logging.getLogger("ufl")
ffclog = logging.getLogger("ffc")
ufllog.addHandler(h)
ffclog.addHandler(h)

This should handle piping everything through the C++ dolfin log system
without tying the pure python projects to dolfin.

However, this is one of those designs that make dolfin "less a
library" and more an "application backend", which it would be nice to
avoid. As you say here:

> Good, but the problem still remains what to do about the messages
>  issued from DOLFIN in C++. Maybe there's a way to "attach" these to the
>  Python logging module? It's possible to specify the output destination
>  as a std::ostream. This might not be enough, but perhaps something
>  similar could work.

What we need to make this work is to subclass logging.Logger in
pydolfin (lets call the subclass dolfin.Logger), such that messages in
the C++ dolfin log system can be passed through a dolfin.Logger object
if PyDOLFIN is in use, but not if it's a C++ application.

So we need to subclass std::ostream in the swig wrappers for pydolfin
such that they pipe their output to suitable python calls on the
global dolfin.Logger object. This should be possible, and all the ugly
bits can be confined to the .i files.

--
Martin