[feature request] logging

[Thomas Hisch]

There is a lot of std::cout code (some of which is commented out) in the mshr repo. It would be nice if the output to stdout goes through a logger, which when used from python redirects log messages to an appropriate python logger (sth. like logging.getLogger('mshr')).

[Benjamin Dam Kehlet]

You are right. A little cleanup is needed. I think the outcommented code is acceptable (it is quite usefull if we later need to debug the code).

In generally mshr should use output through the dolfin::Log class. Is this a good solution for you? I don't think dolfin::Log can distinguish between output that originates from mshr and other sources, but maybe we can improve dolfin::Log if needed.

A special issue here is the output from CGAL's 3D mesher. That is enabled with a #define statement and is really meant as debug output, but the output is quite usefull and the mesh generation becomes very unresponsive if the output is turned off since it often takes some time. An ideal (in my opinion) solution would be if it took a callback functor as a template argument, so the user could controll the output. If a dummy implementation is provided, the compiler should be able to optimize the callbacks away, so there should be no overhead.

[Thomas Hisch]

I also think that the logging feature belongs to dolfin in the end. I'll try to come up with a PR for the dolfin repo.

The callback functor approach you mentioned sounds good, even if I don't think that its really needed especially from the python side.

[Benjamin Dam Kehlet]

Ok, great. I'll make sure all output actually goes through the dolfin::Log system.

[Benjamin Dam Kehlet]

Clean up output. Ref issue #20.

→ <<cset ffa60461e19f>>

[Thomas Hisch]

I've just pushed a minimal working logging example to https://github.com/thisch/boost_python_logger. It uses boost_python is an almost 1:1 copy of the logger from espresso++. I still need to think about how I want to integrate it into the dolfin logger.