← Back to team overview

dolfin team mailing list archive

Re: [HG DOLFIN] Add str() to Variable interface (in?C++) and overload info()

 

On Tue, May 26, 2009 at 12:06:15PM +0100, Garth N. Wells wrote:
> 
> 
> Anders Logg wrote:
> > On Tue, May 26, 2009 at 12:18:12PM +0200, Johan Hake wrote:
> >> On Tuesday 26 May 2009 11:36:52 Anders Logg wrote:
> >>> On Fri, May 22, 2009 at 07:52:09PM +0100, Garth N. Wells wrote:
> >>>> Anders Logg wrote:
> >>>>> On Sun, May 10, 2009 at 07:31:55PM +0100, Garth N. Wells wrote:
> >>>>>> Johan Hake wrote:
> >>>>>>> On Sunday 10 May 2009 12:20:24 Garth N. Wells wrote:
> >>>>>>>> DOLFIN wrote:
> >>>>>>>>> One or more new changesets pushed to the primary dolfin repository.
> >>>>>>>>> A short summary of the last three changesets is included below.
> >>>>>>>>>
> >>>>>>>>> changeset:   6112:1b2b19ddacfa92c80d36dc78a5bb4829605a10c0
> >>>>>>>>> tag:         tip
> >>>>>>>>> user:        Anders Logg <logg@xxxxxxxxx>
> >>>>>>>>> date:        Sun May 10 00:33:56 2009 +0200
> >>>>>>>>> files:       dolfin/common/Variable.cpp dolfin/common/Variable.h
> >>>>>>>>> dolfin/log/Logger.cpp dolfin/log/Table.cpp dolfin/log/Table.h
> >>>>>>>>> dolfin/log/log.cpp dolfin/log/log.h
> >>>>>>>>> dolfin/parameter/NewParameters.cpp dolfin/parameter/NewParameters.h
> >>>>>>>>> sandbox/misc/cpp/main.cpp description: Add str() to Variable
> >>>>>>>>> interface (in C++) and overload info() to accept a Variable,
> >>>>>>>>> printing the output of str().
> >>>>>>>> The function
> >>>>>>>>
> >>>>>>>>      void info(const Variable& variable);
> >>>>>>>>
> >>>>>>>> has caused a problem when compiling the Python wrappers,
> >>>>>>>> dolfin/swig/cpp_wrap.cc: In function ‘PyObject*
> >>>>>>>> _wrap_info(PyObject*, PyObject*)’:
> >>>>>>>> dolfin/swig/cpp_wrap.cc:27939: error: invalid conversion from ‘int’
> >>>>>>>> to ‘PyObject*’
> >>>>>>>> dolfin/swig/cpp_wrap.cc:27791: error: too many arguments to function
> >>>>>>>> ‘PyObject* _wrap_info__SWIG_0(PyObject*, PyObject*)’
> >>>>>>>> dolfin/swig/cpp_wrap.cc:27939: error: at this point in file
> >>>>>>>> dolfin/swig/cpp_wrap.cc:27942: error: invalid conversion from ‘int’
> >>>>>>>> to ‘PyObject*’
> >>>>>>>> dolfin/swig/cpp_wrap.cc:27861: error: too many arguments to function
> >>>>>>>> ‘PyObject* _wrap_info__SWIG_1(PyObject*, PyObject*)’
> >>>>>>>> dolfin/swig/cpp_wrap.cc:27942: error: at this point in file
> >>>>>>>> scons: *** [dolfin/swig/cpp_wrap.os] Error 1
> >>>>>>>>
> >>>>>>>>  From a quick inspection, I don't see what the problem is.
> >>>>>>> I think swig has some problems with overloading functions with
> >>>>>>> variable number of parameters.
> >>>>>> I don't particularly like the functions with a variable number of
> >>>>>> parameters (those using the ellipses (...)). Can we avoid using them?
> >>>>>> Can we make use of ostringstream instead?
> >>>>> We could do that to some extent, but the current implementation has
> >>>>> some uses:
> >>>> It looks like
> >>>>
> >>>>      http://www.boost.org/doc/libs/1_39_0/libs/format/doc/format.html
> >>>>
> >>>> might preserve the syntax but avoid using the ellipses (...).
> >>>>
> >>>> Garth
> >>> Yes, but it does not address any of the issues (1-3) below as far as I
> >>> can see.
> >> I cannot see what using boost::format for the input to the logging functions 
> >> has anything to do with the issues listed under 1-3.
> >>
> >> We could change the signatures of the logging functions to take a 
> >> boost::format instance instead of the (std::string msg, ...) that is now.
> >>
> >> Then we would have:
> >>
> >>   debug(format("Jada %1, %2")%"bada"%100);
> >>
> >> instead of:
> >>
> >>   debug("jada %s, %d","bada",100);
> > 
> > Yes, but I don't see the point.
> >
> 
> The point is to possibly get rid of the ellipses (...), the nasty macro 
> and the buffer allocation in log.cpp.

I don't think ... is so evil. It works and the usage is limited to
just one file (log.cpp), except for some places in the XML parser
where it's needed to for using the libmlx2 library.

The macro is needed to print information about line number, function
name etc during debugging. (Or was there a boost solution for this?)

-- 
Anders

Attachment: signature.asc
Description: Digital signature


Follow ups

References