- Boost - lists.preview.boost.org

Linux regressions
by Aleksey Gurtovoy 20 Sep '04

20 Sep '04

A clarification for developers monitoring regression reports: a significant number of Linux regressions showing up in the current reports (http://www.meta-comm.com/engineering/boost-regression/developer/summary.html) is NOT a result of some recent checkin. Most of these failures were there for some time, but weren't highlighted as regressions because the report generation tools didn't have the data for this platform to compare against. This was fixed yesterday. Similarly, new regressions for "cw-8.3" toolset are only a result of updating the old toolset name ("cwpro83") in the 1.30.2 results. I hope we can take care of these new issues quickly, although "gcc-2.95.3-stlport-4.5.3-linux" in particular doesn't look that good. Is it still a widely-used configuration? -- Aleksey Gurtovoy MetaCommunications Engineering

4 6

[Function] GCC 3.4.1 failure
by Aleksey Gurtovoy 20 Sep '04

20 Sep '04

Doug, Could you please take a look at this one (from http://tinyurl.com/7yyu5) "C:\MinGW341\bin\g++" -c -Wall -ftemplate-depth-255 -g -O0 -fno-inline -mno-cygwin -I"C:\MinGW\Bronek\boost\results\bin\boost\libs\function\test" -I "C:\MinGW\Bronek\boost\boost" -o "C:\MinGW\Bronek\boost\results\bin\boost\libs\function\test\lambda_test.test\mingw-3.4.1\debug\lambda_test.obj" "C:\MinGW\Bronek\boost\boost\libs/function/test/lambda_test.cpp" C:\MinGW\Bronek\boost\boost\libs/function/test/lambda_test.cpp: In function `int test_main(int, char**)': C:\MinGW\Bronek\boost\boost\libs/function/test/lambda_test.cpp:30: error: call of overloaded `bind(unsigned int (&)(int, bool, double), int, const boost::lambda::lambda_functor<boost::lambda::placeholder<1> >&, const boost::lambda::lambda_functor<boost::lambda::placeholder<2> >&)' is ambiguous C:/MinGW/Bronek/boost/boost/boost/lambda/detail/bind_functions.hpp:500: note: candidates are: const boost::lambda::lambda_functor<boost::lambda::lambda_functor_base<boost::lambda::action<4, boost::lambda::function_action<4, T> >, typename boost::lambda::detail::bind_tuple_mapper<Result (&)(Par1, Par2, Par3), const Arg2, const Arg3, const Arg4, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type>::type> > boost::lambda::bind(Result (&)(Par1, Par2, Par3), const Arg2&, const Arg3&, const Arg4&) [with Result = unsigned int, Par1 = int, Par2 = bool, Par3 = double, Arg2 = int, Arg3 = boost::lambda::lambda_functor<boost::lambda::placeholder<1> >, Arg4 = boost::lambda::lambda_functor<boost::lambda::placeholder<2> >] C:/MinGW/Bronek/boost/boost/boost/lambda/detail/bind_functions.hpp:528: note: const boost::lambda::lambda_functor<boost::lambda::lambda_functor_base<boost::lambda::action<4, boost::lambda::function_action<4, boost::lambda::detail::unspecified> >, typename boost::lambda::detail::bind_tuple_mapper<const Arg1, const Arg2, const Arg3, const Arg4, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type>::type> > boost::lambda::bind(const Arg1&, const Arg2&, const Arg3&, const Arg4&) [with Arg1 = unsigned int ()(int, bool, double), Arg2 = int, Arg3 = boost::lambda::lambda_functor<boost::lambda::placeholder<1> >, Arg4 = boost::lambda::lambda_functor<boost::lambda::placeholder<2> >] ? -- Aleksey Gurtovoy MetaCommunications Engineering

2 2

Python/indirect_traits_test fails on all platforms
by Aleksey Gurtovoy 20 Sep '04

20 Sep '04

For instance (from http://tinyurl.com/5qne8) call "c:\Programme\Metrowerks\Codewarrior\Other Metrowerks Tools\Command Line Tools\cwenv.bat" -quiet mwcc -c -lang c++ -maxerrors 5 -warn on -maxwarnings 20 -nowraplines -g -O0 -inline off -cwd include -warn nounusedexpr,nounused -runtime dmd -DNOMINMAX -RTTI on -iso_templates on "-IC:\boost_regression\results\bin\boost\libs\python\test" -I- "-IC:\boost_regression\boost" -o "C:\boost_regression\results\bin\boost\libs\python\test\indirect_traits_test.test\cw-9.3\debug\threading-multi\indirect_traits_test.obj" "..\libs\python\test\indirect_traits_test.cpp" ### mwcc Compiler: # File: ..\libs\python\test\indirect_traits_test.cpp # ----------------------------------------------------- # 15: using namespace boost::python::detail; # Error: ^^^^^^ # undefined identifier 'detail' ### mwcc Compiler: # 19: ((is_reference_to_function<int (&)()>::value) ? ((void) 0) : __msl_assertion_failed("is_ref; # Error: ^ # undefined identifier 'is_reference_to_function' ### mwcc Compiler: # 20: ((!is_reference_to_function<int (*)()>::value) ? ((void) 0) : __msl_assertion_failed("!is_re; # Error: ^ # undefined identifier 'is_reference_to_function' ### mwcc Compiler: # 21: ((!is_reference_to_function<int&>::value) ? ((void) 0) : __msl_assertion_failed("!is_referen; # Error: ^ # undefined identifier 'is_reference_to_function' ### mwcc Compiler: # 24: ((!is_pointer_to_function<int (&)()>::value) ? ((void) 0) : __msl_assertion_failed("!is_po; # Error: ^ # undefined identifier 'is_pointer_to_function' # Too many errors printed, aborting program User break, cancelled... -- Aleksey Gurtovoy MetaCommunications Engineering

2 1

[all/build] Build change that affects testers...
by Rene Rivera 19 Sep '04

19 Sep '04

All, Some time ago the following problem surfaced: Robert Ramey wrote: > Almost all the tests for the serialization system fail to link with the > following message: > > ### mwld Linker Error: > # Undefined symbol: '_errno' > # referenced from 'void > boost::unit_test::hrf_report_formatter::report_assertions_stat(class > std::basic_ostream<char, struct std::char_traits<char> > &, unsigned int, > unsigned long, unsigned long, unsigned long) > (?report_assertions_stat@hrf_report_formatter@unit_test@boost@@UAEXAAV?$basi > c_ostream@DU?$char_traits@D@std@@@std@@IKKK@Z)' in unit_test_result.obj > (libboost_test_exec_monitor.lib) > ### mwld Linker Error: > # Undefined symbol: '_errno' > # referenced from 'void > boost::unit_test::hrf_report_formatter::report_sub_test_cases_stat(class > std::basic_ostream<char, struct std::char_traits<char> > &, unsigned int, > unsigned long, unsigned long) > (?report_sub_test_cases_stat@hrf_report_formatter@unit_test@boost@@UAEXAAV?$ > basic_ostream@DU?$char_traits@D@std@@@std@@IKK@Z)' in unit_test_result.obj > (libboost_test_exec_monitor.lib) > > Errors caused tool to abort. > > To me, this suggests some issue regarding libboost_test_exec_monitor.lib . > > Anyone care to comment? I spent most of yesterday and today trying to figure this problem out. What it boiled down to was the "errno" use in the std::log10 function. But that wasn't the real problem... The reason it gives the above error is that when building certain tests like serialization and threads the library was using the multi-threaded runtime while the Boost.Test was using single-threaded runtime. Which needles to say is a very bad thing of the build system to do. Much time later I managed to track down the problem in the build system and fix. Now, the *important* part... This change will affect all platforms that use multiple runtimes. As far as I know this includes all Win32 compilers. So don't be surprised if the next run of regression tests take a long time and more disk space, because different variants of things will get compiled now. And if you are really paranoid about testing, you might be advised to delete the "bin/boost" build directory to start fresh. Enjoy -- the corrected functionality ;-) PS. I'm starting a fresh run of the CW-8.3/release tests now. Which should show a large number of fixed failures. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

4 6

old regression results question
by Reece Dunn 19 Sep '04

19 Sep '04

On the regression summary page (http://www.meta-comm.com/engineering/boost-regression/developer/summary.html) there are several instances where a toolset is duplicated (win32+cw-8.3, win32+vcX.X). I was wondering if it was possible to display only the most recent results for the toolset in that instance. This would help to see where the regressions are and shorten the width of the table. Regards, Reece _________________________________________________________________ Stay in touch with absent friends - get MSN Messenger http://www.msn.co.uk/messenger

3 3

Re: [boost] Where are they now? (needed license permissions)
by JOAQUIN LOPEZ MU?Z 19 Sep '04

19 Sep '04

----- Mensaje original ----- De: John Maddock <john(a)johnmaddock.co.uk> Fecha: Jueves, Septiembre 16, 2004 2:20 pm Asunto: [boost] Where are they now? (needed license permissions) > Here are the people we still need to contact, in order to move the > rest of > Boost over to the BSL, if anyone has a more up to date email > address for > these folks than the ones shown here, please let me know, as at > present > they're not responding :-( > > Joaquín M López Muñoz joaquin(a)tid.es Hi John, this is Joaquín. I'm afraid my name appears in the list due to the occurrence of the SGI text in some of my files which are, otherwise, under the BSL license. This thread will probably refresh your mind, as we already discussed the issue: http://lists.boost.org/MailArchives/boost/msg69520.php I case you still need my permission in the blanket tile (which I don't think it's the case) please tell me so. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

stlport.jam patch
by Aleksey Gurtovoy 19 Sep '04

19 Sep '04

I just commited the following patch to "stlport.jam": =================================================================== RCS file: /cvsroot/boost/boost/tools/build/v1/stlport.jam,v retrieving revision 1.7 diff -r1.7 stlport.jam 103,104c103,106 < flags $(CURR_TOOLSET) FINDLIBS <stlport-iostream>on/<runtime-build>debug : $(STLPORT_LIB_BASE_NAME)_stldebug ; < flags $(CURR_TOOLSET) FINDLIBS <stlport-iostream>on/<runtime-build>release : $(STLPORT_LIB_BASE_NAME) ; --- > flags $(CURR_TOOLSET) FINDLIBS <stlport-iostream>on/<runtime-build>debug/<runtime-link>static : $(STLPORT_LIB_BASE_NAME)_stldebug_static ; > flags $(CURR_TOOLSET) FINDLIBS <stlport-iostream>on/<runtime-build>debug/<runtime-link>dynamic : $(STLPORT_LIB_BASE_NAME)_stldebug ; > flags $(CURR_TOOLSET) FINDLIBS <stlport-iostream>on/<runtime-build>release/<runtime-link>static : $(STLPORT_LIB_BASE_NAME)_static ; > flags $(CURR_TOOLSET) FINDLIBS <stlport-iostream>on/<runtime-build>release/<runtime-link>dynamic : $(STLPORT_LIB_BASE_NAME) ; That should take care of a number of failures with all STLPort-based toolsets; for instance, like this one -- http://tinyurl.com/5djsj. -- Aleksey Gurtovoy MetaCommunications Engineering

1 0

Avoiding warning on the do{...}while(0) macro implementation trick
by Ivan Vecerina 19 Sep '04

19 Sep '04

I've noticed discussions about this a couple of years ago. For assert-style macros that include multiple statements, a common idiom is to enclose the statements in a do{...}while(0) dummy loop. This makes the macro behave like a single statement. A problem with some compilers (notably VC7.x) is that this triggers a warning (C4127: conditional expression is constant). The workaround adopted by boost is to automatically disable this warning -- which however can be legitimate and useful in user code. I think I have found a better 'always-false' condition which does not trigger a warning, and works at least in VC7.1: do{ }while(__LINE__==-1) Do you see a problem with this approach? Could this approach be used to stop disabling warning 4127 when boost is compiled? Do other compilers have similar warnings and workarounds? Should a boost macro that expands to a warning-free always-false (or always-true) compile-time constant be considered? This would also allow statements such as BOOST_ASSERT(BOOST_FALSE), while(BOOST_TRUE), or do{...}while(BOOST_FALSE) to compile without warning... Regards, Ivan -- http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form

2 1

Concept_check.hpp question
by Aleksey Gurtovoy 19 Sep '04

19 Sep '04

Is there a good reason for the following #ifdef in "concept_check.hpp": template <class Concept> inline void function_requires(mpl::identity<Concept>* = 0) { #if !defined(NDEBUG) void (Concept::*x)() = BOOST_FPTR Concept::constraints; ignore_unused_variable_warning(x); #endif } ? It causes "concept_check_fail_expected" test to fail if compiled in "release mode"; see http://tinyurl.com/6u286. Any objections to removing it? -- Aleksey Gurtovoy MetaCommunications Engineering

1 0

Re:[boost] Re: [static_assert] Regression with gcc 3.4.2?
by Robert Ramey 19 Sep '04

19 Sep '04

"David B. Held" <dheld(a)codelogicconsulting.com> wrote in message news:cihmvu$3ik$1@sea.gmane.org... > #include <boost/static_assert.hpp> > > template <typename T> > struct foo > { > void bar(void) > { > BOOST_STATIC_ASSERT(false); > } > }; I use .... BOOST_STATIC_ASSERT(sizeof(T) == 0); .... Robert Ramey

2 1