fenics team mailing list archive

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

2008/3/27, 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

Of course... This became more complicated than I first thought.
Anyway, dolfin can wait until all Python projects use it "some time in
the future"(tm).

-- 
Martin