← 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:26:37PM +0100, Garth N. Wells wrote:
> 
> 
> Anders Logg wrote:
> > 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 original point of the discussion was whether or not there is a 
> simple way to avoid using (...). After taking a look, I don't think that 
> boost::format is the way to go because of the increase in syntax 
> complexity when calling info, warning, error.

ok.

> > The macro is needed to print information about line number, function
> > name etc during debugging. 
> 
> This one?
> 
>    #define read(buffer, msg) \
>      allocate_buffer(msg); \
>      va_list aptr; \
>      va_start(aptr, msg); \
>      vsnprintf(buffer, buffer_size, msg.c_str(), aptr); \
>      va_end(aptr);

No, I meant this one:

  #define dolfin_debug(msg) do { dolfin::__debug(__FILE__, __LINE__, __FUNCTION__, msg); } while (false)

The read() macro is used to avoid code duplication in log.cpp. Due to
the weirdness of stdarg, it wasn't possible to encapsulate it in a
function (since the "..." part cannot be passed as an argument but must be
parsed before).

-- 
Anders

Attachment: signature.asc
Description: Digital signature


References