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 <l...@simula.no>
>>>>>>>>>>> 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.

> 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);

Garth



(Or was there a boost solution for this?)
>
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@fenics.org
> http://www.fenics.org/mailman/listinfo/dolfin-dev


_______________________________________________
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Reply via email to