fenics team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Sun, Mar 23, 2008 at 01:42:40PM +0100, Martin Sandve Alnæs wrote:
> 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.

This sounds good to me, but it will be far down on *my* TODO list. ;-)

-- 
Anders