[range][1.33.1] last few regressions.
Otto, can the last few regressions for the range lib be fixed (http://engineering.meta-comm.com/boost-regression/CVS-RC_1_33_0/developer/is...) or should these just be marked up as expected? Thanks, John.
In my particular case (serialization) I have a regression on test_shared_ptr. This test builds and runs correctly on both the borland compilers I have here. So as far as I'm concerned its not expected. Another test test_no_rtti fails on the test matrix at compile time. On my machine it fails on runtime (borland 5.64) or compiles and passes (borland 5.51). My inclination is just to leave these without any markup at all as I really don't know what I should be expecting. Robert Ramey John Maddock wrote:
Otto, can the last few regressions for the range lib be fixed (http://engineering.meta-comm.com/boost-regression/CVS-RC_1_33_0/developer/is...) or should these just be marked up as expected?
Thanks,
John.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
In my particular case (serialization) I have a regression on test_shared_ptr. This test builds and runs correctly on both the borland compilers I have here. So as far as I'm concerned its not expected. Another test test_no_rtti fails on the test matrix at compile time. On my machine it fails on runtime (borland 5.64) or compiles and passes (borland 5.51).
My inclination is just to leave these without any markup at all as I really don't know what I should be expecting.
I'll try and run the Borland tests on my machine and figure out what's going on, BTW the link to Spirit-1.6 is broken in your docs. Also which spirit version are you using 1.6.3? Just checking.... As for the other failures, those for test_demo_xml_load all appear to be caused by a failed assertion on opening the file stream, is this likely to be another dependency issue that hasn't been nailed down yet? The remaining Intel-8 failure ( test_shared_ptr_132_text_warchive ) passes on my machine, so looks to be spurious. Thanks, John.
I'll try and run the Borland tests on my machine and figure out what's going on, BTW the link to Spirit-1.6 is broken in your docs. Also which spirit version are you using 1.6.3? Just checking....
To answer my own question: I can reproduce the issue with spirit 1.6.3 and Borland C++ Builder 6 Up4, the patch below fixes the problem, OK to commit?
As for the other failures, those for test_demo_xml_load all appear to be caused by a failed assertion on opening the file stream, is this likely to be another dependency issue that hasn't been nailed down yet?
Confirmed as a dependency issue: building test_demo_xml_save first fixes the problem. Was the suggested fix for these dependency issues ever committed? I don't see it in cvs. Here's the Borland patch: Index: boost/serialization/shared_ptr.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/serialization/shared_ptr.hpp,v retrieving revision 1.15.2.3 diff -u -b -r1.15.2.3 shared_ptr.hpp --- boost/serialization/shared_ptr.hpp 2 Oct 2005 05:57:24 -0000 1.15.2.3 +++ boost/serialization/shared_ptr.hpp 24 Oct 2005 12:26:37 -0000 @@ -53,14 +53,22 @@ struct version< ::boost::shared_ptr<T> > { \ typedef mpl::integral_c_tag tag; typedef mpl::int_<1> type; +#if BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT(0x570)) + BOOST_STATIC_CONSTANT(unsigned int, value = 1); +#else BOOST_STATIC_CONSTANT(unsigned int, value = type::value); +#endif }; // don't track shared pointers template<class T> struct tracking_level< ::boost::shared_ptr<T> > { typedef mpl::integral_c_tag tag; typedef mpl::int_< ::boost::serialization::track_never> type; +#if BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT(0x570)) + BOOST_STATIC_CONSTANT(int, value = ::boost::serialization::track_never); +#else BOOST_STATIC_CONSTANT(int, value = type::value); +#endif }; }} #define BOOST_SERIALIZATION_SHARED_PTR(T) John.
John Maddock wrote:
Confirmed as a dependency issue: building test_demo_xml_save first fixes the problem. Was the suggested fix for these dependency issues ever committed? I don't see it in cvs.
No, Robert never applied it. http://article.gmane.org/gmane.comp.lib.boost.devel/133254 -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
On Oct 24, 2005, at 9:48 AM, Rene Rivera wrote:
John Maddock wrote:
Confirmed as a dependency issue: building test_demo_xml_save first fixes the problem. Was the suggested fix for these dependency issues ever committed? I don't see it in cvs.
No, Robert never applied it.
I've applied it. Thanks, Troy! Doug
On Oct 24, 2005, at 7:30 AM, John Maddock wrote:
Confirmed as a dependency issue: building test_demo_xml_save first fixes the problem. Was the suggested fix for these dependency issues ever committed? I don't see it in cvs.
Here's the Borland patch:
Index: boost/serialization/shared_ptr.hpp [snip]
Looks good! I've committed it. There was some fuzz because of some BOOST_DEDUCED_TYPENAMEs that are there in the latest version of the file, but are clearly wrong. The CVS log states that they were added to work around compiler bugs, but we don't know which compiler, so I've yanked them back out. Doug
On Oct 24, 2005, at 10:32 AM, Douglas Gregor wrote:
On Oct 24, 2005, at 7:30 AM, John Maddock wrote: Looks good! I've committed it. There was some fuzz because of some BOOST_DEDUCED_TYPENAMEs that are there in the latest version of the file, but are clearly wrong. The CVS log states that they were added to work around compiler bugs, but we don't know which compiler, so I've yanked them back out.
Looks like it was CodeWarrior that needed them... they're back in for CodeWarrior, and we'll see what happens tomorrow. Doug
John Maddock <john <at> johnmaddock.co.uk> writes:
Otto, can the last few regressions for the range lib be fixed (http://engineering.meta-comm.com/boost-regression/CVS-
RC_1_33_0/developer/issues.html)
or should these just be marked up as expected?
I need to spend some more time on the range library before I feel comfortable about releasing it together with boost.foreach. I need to change the concept requirements and update the docs and won't have time until the weekend. br -Thorsten
Thorsten Ottosen wrote:
John Maddock <john <at> johnmaddock.co.uk> writes:
Otto, can the last few regressions for the range lib be fixed (http://engineering.meta-comm.com/boost-regression/CVS-
RC_1_33_0/developer/issues.html)
or should these just be marked up as expected?
I need to spend some more time on the range library before I feel comfortable about releasing it together with boost.foreach.
Boost.Foreach is not part of 1.33.1. -- Eric Niebler Boost Consulting www.boost-consulting.com
participants (1)
-
Doug Gregor -
Douglas Gregor -
Eric Niebler -
John Maddock -
Rene Rivera -
Robert Ramey -
Thorsten Ottosen