[boost] Re: Boost 1.31 release?
Matthias Troyer <[EMAIL PROTECTED]> writes: > Dear Boosters, > > Since some of the applications and libraries we plan on releasing soon > rely on Boost features and bugfixes that are in the CVS but not in > Boost 1.30.[012] I wonder what the plans are for the Boost 1.31.0 > release? Since we would prefer to base our released software on a > Boost release instead of a CVS snapshot I would be interested in > hearing about the plans for a Boost 1.31 release As far as I know the CVS is in very good health at the moment. The only major thing I know needs to be done is to complete the documentation for the new iterator adaptors. I'd like to get that over with soon, so it isn't hanging over our heads much longer. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
Douglas Paul Gregor wrote: On Fri, 8 Aug 2003, Martin Wille wrote: - function::sum_avg_portable Should be fixed now. Apparently, the error persists. Regards, m ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost 1.31 release?
Martin Wille <[EMAIL PROTECTED]> writes: > David Abrahams wrote: >> Matthias Troyer <[EMAIL PROTECTED]> writes: > ... >>>I would be interested in >>>hearing about the plans for a Boost 1.31 release >> As far as I know the CVS is in very good health at the moment. The >> only major thing I know needs to be done is to complete the >> documentation for the new iterator adaptors. I'd like to get that >> over with soon, so it isn't hanging over our heads much longer. > > In order to avoid problems to be discovered too late for fixing them > I'll list the tests that fail for many compilers/compiler versions > on Linux: > > - filesystem::operations_test > - function::sum_avg_portable > - iterator::interoperable_fail (a compile_fail test that fails, >probably not a real problem) This one is a known GCC bug for which there is no workaround. Fortunately, it has little impact on library usability. > - math::octonion_test >math::quaternion_test > - test::errors_handling_test > > I hope that lists helps. Thanks! Would the authors of those libraries please post to let me know whether they intend to fix these problems for 1.30.2? Thanks, Dave -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost 1.31 release?
Aleksey Gurtovoy <[EMAIL PROTECTED]> writes: > David Abrahams wrote: >> >> As far as I know the CVS is in very good health at the moment. >> > >> > Uhmm, I really wouldn't say so! If you look at the main trunk report - >> > > http://www.meta-comm.com/engineering/resources/cvs_main_trunk/developer_summary_page.html, >> > there are lots of regressions comparing to 1.30.0, and IMO we ought to >> > fix all these before we branch for the release or anything. >> >> I can't really tell what these represent. > > As usual, a red cell means a regression from the 1.30.0 tarball, a dark > green one - an improvement. > >> All of the new iterator library tests which weren't in 1.30.0 are >> showing up as regressions if they're failing. > > Yes, it's a known shortcoming - or a feature, depending of how you look > at it. By default, new tests are expected to pass. > >> Many are simply not going to get better; they're due to compiler bugs >> which can't be worked around. > > Which is totally fine. If you provide us with the list of expected > failures, these will be cleared. All of the *_fail tests that are failing should be cleared. Actually I don't know about bcc-5.6.4 since I don't have that compiler, but I expect the conditions are the same as for bcc-5.5.1. >> As for the others, the failures you're reporting with intel-7.1 are >> very strange; my 7.1 compiler doesn't have these problems AFAIK. > > Hmm, looks like another configuration problem to me. We'll take a look > at it. > >> What does the "meta-" prefix mean? > > "meta-" is our prefix for non-boost toolsets. It's a strange standard to hold boost libraries to, passing on toolsets which are not checked into the Boost CVS. Can we do something about that? >> Do you have some special configuration of each of these compilers? > > Well, most of them are not really special. For instance, bcc-* ones > were introduced for the only purpose of being able to test 5.5.1 and > 5.5.4 compilers simultaneously. The complete list of differences is > available here - > > http://www.meta-comm.com/engineering/resources/cs-win32_rc_1_30_0_metacomm/patches.html That's good to know. Is there a link on the main summary page? -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost 1.31 release?
Aleksey Gurtovoy <[EMAIL PROTECTED]> writes: > David Abrahams wrote: >> Regarding http://tinyurl.com/jhtn: does this compiler ever need the >> typename keyword? If not, perhaps we ought to define >> BOOST_NO_DEDUCED_TYPENAME for all Borland versions > > Any particular failure that triggered your attention? http://www.meta-comm.com/engineering/resources/cs-win32_metacomm-links.html#concept_tests-meta-bcc-5.6.4 TinyURL strips internal targets, it seems :( -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
Martin Wille wrote: 6 tests fail for 3.2.3 and 6 tests fail for 3.3.1 Doh. 5 tests fail for 3.3.1. Sorry for the typo. Regards, m ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
At 11:13 PM 8/10/2003, Aleksey Gurtovoy wrote: >Beman Dawes wrote: >> Assuming I'm release manager for 1.31.0, I'm going to publish explicit >> release criteria for key platform/compiler pairs. Basically, the >> criteria will be 100% accounting for all failures on those >> platform/compiler pairs. > >While I totally support the failures markup goal, I would like to see >_the_ release criteria to include "no regressions from the previous >release" item as well, preferrably for all non-beta compilers that are >currently under regression testing. Especially since now we have tools >to ensure it. That sounds reasonable to me. >Especially since now we have tools to ensure it. Damn. I forgot to bookmark the URL. Could you post it again please? Or better yet add something to boost-root/status/compiler_status.html linking to the permanent location. That in turn means deciding what of your experiment work is permanent and where it will live. Thanks, --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
David Abrahams wrote: > Aleksey Gurtovoy <[EMAIL PROTECTED]> writes: > > > Beman Dawes wrote: > >> Assuming I'm release manager for 1.31.0, I'm going to publish explicit > >> release criteria for key platform/compiler pairs. Basically, the > >> criteria will be 100% accounting for all failures on those > >> platform/compiler pairs. > > > > While I totally support the failures markup goal, I would like to see > > _the_ release criteria to include "no regressions from the previous > > release" item as well, preferrably for all non-beta compilers that are > > currently under regression testing. Especially since now we have tools > > to ensure it. > > I worry a little about requiring library authors not to regress on > compiler combinations they don't test with. Well, the regressions are run daily, so testing happens. Another question is whether library authors care about how their libraries perform on all the compilers the regressions are being run on. Obviously, some compilers/configurations are included in the regression testing because the ones who manage the latter are the ones who are most interested in those. Then, again, obviously, some compilers/ configurations are included in the regressions because they are very widely used. For every release, the interested parties include library authors, regression runners, the release manager, the maintenance wizard, and of course active users who are subscribed to either of the lists. Given the above "setup", the implied interests of the participating groups, and their explicit and implicit responsibilities and gratitude towards each other, I think striving for "no regressions" goal I stated above would be both a reasonable and fair strategy which can be made to work. > For example, who is going > to address the one lexical_cast failure that's plaguing the 1.30.2 > release? If I were a release manager, I would: 1) ask the library maintainer if he is interested in looking at the failure; if he is not, or he is not responding - which is kind of likely in this case since Intel+STLPort is not a very common configuration, then: 2) ask the regression maintainers to look at the failure; if they are busy/don't know how to fix it, then: 3) put the issue on the list of probable regressions, and in at least a week before the release post an explicit pre-release regression warning on possibly both the users and developers lists asking interested parties to step in; if nothing happens, release with the regression and document it in the release notes. In this particular case, you can assume that we are at the stage 2. > It's only on intel-7.1 with STLPort and looks for all the > world like a config problem. Well, then we'll take a look at it closely. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost 1.31 release?
Aleksey Gurtovoy wrote: > While I totally support the failures markup goal, I would like to see > _the_ release criteria to include "no regressions from the previous > release" item as well, preferrably for all non-beta compilers that are > currently under regression testing. Especially since now we have tools > to ensure it. OTOH, it might not always be achievable. For boost 1.31 we are having an interface breaking change to the iterator_adaptors, and not all compilers pass all tests with the new adaptors yet. While this may not be a problem for the iterators library (it is effectively new) it may have a knock-on effect on any other boost libraries implemented on top of it. The principle is a good one, but I be prepared to make a few allowances in the practice. -- AlisdairM ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost 1.31 release?
Aleksey Gurtovoy <[EMAIL PROTECTED]> writes: >> I worry a little about requiring library authors not to regress on >> compiler combinations they don't test with. > > Well, the regressions are run daily, so testing happens. Another > question is whether library authors care about how their libraries perform > on all the compilers the regressions are being run on. > > Obviously, some compilers/configurations are included in the regression > testing because the ones who manage the latter are the ones who are > most interested in those. Then, again, obviously, some compilers/ > configurations are included in the regressions because they are very > widely used. > > For every release, the interested parties include library authors, > regression runners, the release manager, the maintenance wizard, and of > course active users who are subscribed to either of the lists. > > Given the above "setup", the implied interests of the participating > groups, and their explicit and implicit responsibilities and gratitude > towards each other, I think striving for "no regressions" goal I stated > above would be both a reasonable and fair strategy which can be made to > work. Some people are posting regressions for pre-release compilers. Should a library author should be expected to keep his library healthy on some weird/broken compiler just because it happened to work there by chance at one point? -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost 1.31 release?
Aleksey Gurtovoy <[EMAIL PROTECTED]> writes: > Beman Dawes wrote: >> At 07:37 AM 8/11/2003, David Abrahams wrote: >> >Aleksey Gurtovoy <[EMAIL PROTECTED]> writes: >> > >> >> Beman Dawes wrote: >> >>> Assuming I'm release manager for 1.31.0, I'm going to publish > explicit >> >>> release criteria for key platform/compiler pairs. Basically, the >> >>> criteria will be 100% accounting for all failures on those >> >>> platform/compiler pairs. >> >> >> >> While I totally support the failures markup goal, I would like to see >> >> _the_ release criteria to include "no regressions from the previous >> >> release" item as well, preferrably for all non-beta compilers that are >> >> currently under regression testing. Especially since now we have tools >> >> to ensure it. >> > >> >I worry a little about requiring library authors not to regress on >> >compiler combinations they don't test with. For example, who is going >> >to address the one lexical_cast failure that's plaguing the 1.30.2 >> >release? It's only on intel-7.1 with STLPort and looks for all the >> >world like a config problem. >> >> It can be very time consuming to track down the exact reason for failures. >> Thus we should focus our 1.31.0 effort on a small number of widely used >> compilers which don't have a lot of problems. > > It doesn't have to be the release manager who investigates all the issues > himself, though. There might be enough of the interested parties with > motivation/resources to resolve most of these in a reasonable time frame > if they a given a chance/"managed" properly. I am especially concerned about the toll it takes on a release manager to "give them a chance/manage them". Managing a release, as I've recently discovered, is not a piece of cake. It will suck up at least a couple of days of someone's time. Asking the release manager to (attempt to) track someone down to handle each failure on such a wide variety of platforms/compilers may not be reasonable. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
David Abrahams wrote: In that case, can I release 1.30.2? I don't like having the 1.30.1 debacle hanging over my head. There are new regressions on Linux (RC_1_30_0 branch): http://boost.sourceforge.net/regression-logs/cs-Linux-rc-1_30_0/developer_summary_page.html crc has regressions for gcc-3.1 and gcc-3.2.3 config, format and io have regressions for intel 7.1 Regards, m ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
At 02:56 PM 8/11/2003, David Abrahams wrote: >Beman Dawes <[EMAIL PROTECTED]> writes: >> For a lightly used toolset like intel-7.1 with STLPort, "looks for all >> the world like a config problem" seems like a good enough resolution >> to me. > >In that case, can I release 1.30.2? Yes, as far as I'm concerned. > I don't like having the 1.30.1 >debacle hanging over my head. Understood. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost 1.31 release?
David Abrahams wrote: > Douglas Paul Gregor <[EMAIL PROTECTED]> writes: > > > On Mon, 11 Aug 2003, David Abrahams wrote: > >> According to your chart, the following libraries are all regressing: > >> function > >> > >> Are these real regressions or just newly-tested compilers? Can the > >> library authors/maintainers address these problems? Where is our > >> maintenance wizard? > > > > All of the failures for function are due to newly-tested compilers. > > Misha and Aleksey -- I think we really need to distinguish those > failures from real regressions in the chart somehow or we'll never be > able to tell where we stand. Well, it was assumed that when adding a new compiler one should use re-run the regressions against the previous release and report the current status using _those_ expected results. But in any case, you have a point - for one, it's not always practical/possible to do the full re-run. We'll look into it. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
Beman Dawes wrote: > At 11:13 PM 8/10/2003, Aleksey Gurtovoy wrote: > > >Beman Dawes wrote: > >> Assuming I'm release manager for 1.31.0, I'm going to publish explicit > >> release criteria for key platform/compiler pairs. Basically, the > >> criteria will be 100% accounting for all failures on those > >> platform/compiler pairs. > > > >While I totally support the failures markup goal, I would like to see > >_the_ release criteria to include "no regressions from the previous > >release" item as well, preferrably for all non-beta compilers that are > >currently under regression testing. Especially since now we have tools > >to ensure it. > > That sounds reasonable to me. > > >Especially since now we have tools to ensure it. > > Damn. I forgot to bookmark the URL. Could you post it again please? Here's the page that links to all the reports we currently provide - http://www.meta-comm.com/engineering Please note that at the moment the main trunk report is not run against 1.30.0 results, but using the failures markup you provided us with - thus a greater number of red color there. > Or > better yet add something to boost-root/status/compiler_status.html linking > to the permanent location. That in turn means deciding what of your > experiment work is permanent and where it will live. Will happily do that, although it'll probably take some time to figure out the best way. We'll post the prototype for the discussion before actually checking it in. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost 1.31 release?
[EMAIL PROTECTED] writes: >> On Mon, 11 Aug 2003, David Abrahams wrote: > [snip] >> Are these real regressions or just newly-tested compilers? Can the >> library authors/maintainers address these problems? Where is our >> maintenance wizard? > > He's back online after three weeks of no-internet-access-whatsoever; > currently reading through a few hundred emails to see what's been happening > during that time. Quite a bit, it would seem. Welcome back, Bjorn! I'm very relieved to have you here. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Boost 1.31 release?
> On Mon, 11 Aug 2003, David Abrahams wrote: [snip] > Are these real regressions or just newly-tested compilers? Can the > library authors/maintainers address these problems? Where is our > maintenance wizard? He's back online after three weeks of no-internet-access-whatsoever; currently reading through a few hundred emails to see what's been happening during that time. Quite a bit, it would seem. Bjorn ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost 1.31 release?
Aleksey Gurtovoy wrote: > David Abrahams wrote: > > Misha and Aleksey -- I think we really need to distinguish those > > failures from real regressions in the chart somehow or we'll never be > > able to tell where we stand. > > Here - > http://www.meta-comm.com/engineering/resources/cs-win32_metacomm/developer_summary_page.html > > Yellow cells indicate failures on the newly added tests/compilers. The > updated report tools are not in the CVS yet, we will check them in after the > first round of feedback. The new reports are now checked into the main trunk and RC_1_30_0 branch. Martin, if you are interested in upgrading to these, you would need to re-generate the expected results file from the 1.30.0 tarball run - it has to contain more information to support the new status higlighting. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
Martin Wille wrote: > > The new reports are now checked into the main trunk and RC_1_30_0 branch. > > > > Martin, if you are interested in upgrading to these, you would need to > > re-generate the expected results file from the 1.30.0 tarball run - it has > > to contain more information to support the new status higlighting. > > I tried the new reports for the 1_30_0 branch.The results look broken > now. Everything that used to be in red is yellow now. (yellow is ok for > gcc-3.4-cvs, but the other fields should be red). Err, sorry, broken check-in! Fixed now. Could you please re-generate the expected results file, and try it again? Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost 1.31 release?
Aleksey Gurtovoy <[EMAIL PROTECTED]> writes: > David Abrahams wrote: >> Matthias Troyer <[EMAIL PROTECTED]> writes: >> >> > Dear Boosters, >> > >> > Since some of the applications and libraries we plan on releasing soon >> > rely on Boost features and bugfixes that are in the CVS but not in >> > Boost 1.30.[012] I wonder what the plans are for the Boost 1.31.0 >> > release? Since we would prefer to base our released software on a >> > Boost release instead of a CVS snapshot I would be interested in >> > hearing about the plans for a Boost 1.31 release >> >> As far as I know the CVS is in very good health at the moment. > > Uhmm, I really wouldn't say so! If you look at the main trunk report - > http://www.meta-comm.com/engineering/resources/cvs_main_trunk/developer_summary_page.html, > there are lots of regressions comparing to 1.30.0, and IMO we ought to fix > all these before we branch for the release or anything. There's got to be something wrong with the program that's making these tables. Look, for example, at http://www.meta-comm.com/engineering/resources/cvs_main_trunk/developer_result_page.html#function It says that lambda_test is a regression on msvc. Everyone knows that lambda has never worked on msvc (right?). -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost 1.31 release?
David Abrahams <[EMAIL PROTECTED]> writes: > > It says that lambda_test is a regression on msvc. Everyone knows > that lambda has never worked on msvc (right?). Dave, It is actually our fault, right now it displays only Beman's expected failure notes - we haven't done merging of Beman's expected failure notes and 1.30.1 regression results. For the example of failure markup see: http://boost.sourceforge.net/regression-logs/cs-win32_metacomm/ links.html#credit_card_example-cwpro8 As soon as we have a good method of "merging" the regression results and explicit failure markup the results will be much more helpful for the release manager and boost community in general. P.S. Actually we are running quite behind in implementing the features requested, but we are working on it actively. -- Misha Bergal MetaCommunications Engineering ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
David Abrahams wrote: > Aleksey Gurtovoy <[EMAIL PROTECTED]> writes: > > >> I worry a little about requiring library authors not to regress on > >> compiler combinations they don't test with. > > > > Well, the regressions are run daily, so testing happens. Another > > question is whether library authors care about how their libraries perform > > on all the compilers the regressions are being run on. > > > > Obviously, some compilers/configurations are included in the regression > > testing because the ones who manage the latter are the ones who are > > most interested in those. Then, again, obviously, some compilers/ > > configurations are included in the regressions because they are very > > widely used. > > > > For every release, the interested parties include library authors, > > regression runners, the release manager, the maintenance wizard, and of > > course active users who are subscribed to either of the lists. > > > > Given the above "setup", the implied interests of the participating > > groups, and their explicit and implicit responsibilities and gratitude > > towards each other, I think striving for "no regressions" goal I stated > > above would be both a reasonable and fair strategy which can be made to > > work. > > Some people are posting regressions for pre-release compilers. Should > a library author should be expected to keep his library healthy on > some weird/broken compiler just because it happened to work there by > chance at one point? You skipped the part of my original posting which explicitly said: > > While I totally support the failures markup goal, I would like to see > > _the_ release criteria to include "no regressions from the previous > > release" item as well, preferrably for all non-beta compilers that are > > currently under regression testing. Especially since now we have tools > > to ensure it. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost 1.31 release?
David Abrahams wrote: > Misha and Aleksey -- I think we really need to distinguish those > failures from real regressions in the chart somehow or we'll never be > able to tell where we stand. Here - http://www.meta-comm.com/engineering/resources/cs-win32_metacomm/developer_summary_page.html Yellow cells indicate failures on the newly added tests/compilers. The updated report tools are not in the CVS yet, we will check them in after the first round of feedback. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
Aleksey Gurtovoy wrote: Aleksey Gurtovoy wrote: David Abrahams wrote: Misha and Aleksey -- I think we really need to distinguish those failures from real regressions in the chart somehow or we'll never be able to tell where we stand. Here - http://www.meta-comm.com/engineering/resources/cs-win32_metacomm/developer_summary_page.html Yellow cells indicate failures on the newly added tests/compilers. The updated report tools are not in the CVS yet, we will check them in after the first round of feedback. The new reports are now checked into the main trunk and RC_1_30_0 branch. Martin, if you are interested in upgrading to these, you would need to re-generate the expected results file from the 1.30.0 tarball run - it has to contain more information to support the new status higlighting. I tried the new reports for the 1_30_0 branch.The results look broken now. Everything that used to be in red is yellow now. (yellow is ok for gcc-3.4-cvs, but the other fields should be red). Regards, m ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
Rene Rivera wrote: > [2003-08-11] David Abrahams wrote: > > >Aleksey Gurtovoy <[EMAIL PROTECTED]> writes: > > > >> Well, sure, as long as we are in agreement about having differently > >> named toolsets for different compiler versions/configurations, e.g. > >> > >> bcc-5.5.1 > >> bcc-5.6.4 > >> intel-7.1-vc60 > >> intel-7.1-vc60-stlport > > > >It's OK with me. > > I'd rather that they have the same root as the base toolsets... > > borland-5.5.1 > borland-5.6.4 > intel-win32-7.1-vc60 > intel-win32-7.1-vc60-stlport > > Makes for easier maintenance. OK, we'll go with these. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
At 10:50 PM 8/10/2003, David Abrahams wrote: >Beman Dawes <[EMAIL PROTECTED]> writes: >>... >> iterator/interoperable_fail (compile_fail test isn't failing) > >That is a compiler bug, which I guess ought to be reported again. Yes. It saves us work in the long run when compilers get fixed. Please do report it. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
David Abrahams wrote: > >> Misha and Aleksey -- I think we really need to distinguish those > >> failures from real regressions in the chart somehow or we'll never be > >> able to tell where we stand. > > > > Well, it was assumed that when adding a new compiler one should use re-run > > the regressions against the previous release and report the current status > > using _those_ expected results. > > Many tests might have worked on the new compiler "by chance" with the > previous release. It isn't fair to demand that maintainers to fix > bugs on compilers they haven't agreed to support. I am not sure how your remark is related to this particular sub-thread, but I agree, actually. On the other hand, some of the compilers which the library author(s) might be indifferent to are of some interest to the regression test maintaniners and some number of users. It would be unfair to _not_ to give them a chance to keep those supported by a small amount of cooperation on everyone's side. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost 1.31 release?
Beman Dawes <[EMAIL PROTECTED]> writes: > At 04:11 PM 8/10/2003, Martin Wille wrote: > > >I added gcc-3.3.1 to the Linux tests for CVS HEAD. > > > >Test failures have been down to 1% for gcc versions 3.2.3 and 3.3 a > >few weeks ago. I think 3.2.3 and 3.3.1 would be good candidates for > >being release criteria. > > OK, let's use 3.2.3 and 3.3.1 as the Linux release criteria. Since > someone has to research every failure, and this is our first release > using formal criteria, we don't want to go overboard. > > >6 tests fail for 3.2.3 and 6 tests fail for 3.3.1 > > > > > > From the list I recently posted 1 failure has been fixed and > >1 failure is due to a compiler error and not considered harmful. > > > >That leaves > > > > function::sum_avg_portable > > math::octonion_test > > math::quaternion_test > > test::errors_handling_test > > > >to be fixed or to be explained. Note, all these tests fail for > >both CVS HEAD and RC_1_30_0. > > I've just installed 3.3.1 on Windows, and am getting those same four > failure plus failures from: > > date_time/testmicrosec_time_clock (runtime failure) > iterator/interoperable_fail (compile_fail test isn't failing) That is a compiler bug, which I guess ought to be reported again. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
David Abrahams wrote: > >> Many are simply not going to get better; they're due to compiler bugs > >> which can't be worked around. > > > > Which is totally fine. If you provide us with the list of expected > > failures, these will be cleared. > > All of the *_fail tests that are failing should be cleared. Actually > I don't know about bcc-5.6.4 since I don't have that compiler, but I > expect the conditions are the same as for bcc-5.5.1. Will be done. > > >> As for the others, the failures you're reporting with intel-7.1 are > >> very strange; my 7.1 compiler doesn't have these problems AFAIK. > > > > Hmm, looks like another configuration problem to me. We'll take a look > > at it. > > > >> What does the "meta-" prefix mean? > > > > "meta-" is our prefix for non-boost toolsets. > > It's a strange standard to hold boost libraries to, passing on > toolsets which are not checked into the Boost CVS. Can we do > something about that? Well, sure, as long as we are in agreement about having differently named toolsets for different compiler versions/configurations, e.g. bcc-5.5.1 bcc-5.6.4 intel-7.1-vc60 intel-7.1-vc60-stlport etc. > > >> Do you have some special configuration of each of these compilers? > > > > Well, most of them are not really special. For instance, bcc-* ones > > were introduced for the only purpose of being able to test 5.5.1 and > > 5.5.4 compilers simultaneously. The complete list of differences is > > available here - > > > > http://www.meta-comm.com/engineering/resources/cs-win32_rc_1_30_0_metacomm/patches.html > > That's good to know. Is there a link on the main summary page? It's on our TODO list (the regressions on the branch and on the main trunk are being run on different machines, and these are slightly out of sync). Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Boost 1.31 release?
> I've just installed 3.3.1 on Windows, and am getting those same four > failure plus failures from: > > date_time/testmicrosec_time_clock (runtime failure) This is likely due to the posix API call to std::time not providing stable return values. That is, when I sample the time rapidly the second value is less than the previous value. So this is more of a platform / library issue than a compiler issue. This isn't a new problem with this particular configuration... Jeff ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
Beman Dawes wrote: > At 05:12 AM 8/11/2003, Alisdair Meredith wrote: > >Aleksey Gurtovoy wrote: > > > >> While I totally support the failures markup goal, I would like to see > >> _the_ release criteria to include "no regressions from the previous > >> release" item as well, preferrably for all non-beta compilers that are > >> currently under regression testing. Especially since now we have tools > >> to ensure it. > > > >OTOH, it might not always be achievable. > >For boost 1.31 we are having an interface breaking change to the > >iterator_adaptors, and not all compilers pass all tests with the new > >adaptors yet. > > > >While this may not be a problem for the iterators library (it is > >effectively new) it may have a knock-on effect on any other boost > >libraries implemented on top of it. > > > >The principle is a good one, but I be prepared to make a few allowances > >in the practice. > > I think a reasonable goal is that any regressions should be understood and > discussed, rather than silent. Exactly my sentiments. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost 1.31 release?
Aleksey Gurtovoy <[EMAIL PROTECTED]> writes: > David Abrahams wrote: >> >> Misha and Aleksey -- I think we really need to distinguish those >> >> failures from real regressions in the chart somehow or we'll never be >> >> able to tell where we stand. >> > >> > Well, it was assumed that when adding a new compiler one should use > re-run >> > the regressions against the previous release and report the current > status >> > using _those_ expected results. >> >> Many tests might have worked on the new compiler "by chance" with the >> previous release. It isn't fair to demand that maintainers to fix >> bugs on compilers they haven't agreed to support. > > I am not sure how your remark is related to this particular > sub-thread, but I agree, actually. It's related because I was suggesting that previously unsupported compilers should be demarcated so it's clear which ones those are. > On the other hand, some of the compilers which the library author(s) might > be indifferent to are of some interest to the regression test maintaniners > and some number of users. It would be unfair to _not_ to give them a chance > to keep those supported by a small amount of cooperation on > everyone's side. What kind of special cooperation is needed at the point the release manager is involved? If these regression maintainers and users care, won't they be posting and/or applying patches to keep the platform healthy? If that isn't happening or the patches aren't being applied, for whatever reason, I'm reluctant to add it to the release manager's list of responsibilities. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost 1.31 release?
David Abrahams wrote: > Martin Wille <[EMAIL PROTECTED]> writes: > > > David Abrahams wrote: > > > >> In that case, can I release 1.30.2? I don't like having the 1.30.1 > >> debacle hanging over my head. > > > > > > There are new regressions on Linux (RC_1_30_0 branch): > > http://boost.sourceforge.net/regression-logs/cs-Linux-rc-1_30_0/developer_summary_page.html > > [BTW, Misha and Aleksey, when I click any of the failure links they > lead to the log but not to any internal target showing the specific > failure. Can this be fixed?] Fixed in the RC_1_30_0 branch; if the next run is done with the updated/rebuilt tools, the problem will go away. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
At 09:56 AM 8/9/2003, Matthias Troyer wrote: >As far as I can see Jens Maurer has updated boost.random to his >standards proposal, but not yet the documentation. I believe it would >be important to have the random documentation be consistent with the >sources, especially since the interface has changed significantly. I've added this to the 1.31.0 task list. See http://sourceforge.net/pm/task.php?group_project_id=30994&group_id=7586&func=browse Thanks, --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
David Abrahams wrote: Matthias Troyer <[EMAIL PROTECTED]> writes: ... I would be interested in hearing about the plans for a Boost 1.31 release As far as I know the CVS is in very good health at the moment. The only major thing I know needs to be done is to complete the documentation for the new iterator adaptors. I'd like to get that over with soon, so it isn't hanging over our heads much longer. In order to avoid problems to be discovered too late for fixing them I'll list the tests that fail for many compilers/compiler versions on Linux: - filesystem::operations_test - function::sum_avg_portable - iterator::interoperable_fail (a compile_fail test that fails, probably not a real problem) - math::octonion_test math::quaternion_test - test::errors_handling_test I hope that lists helps. Regards, m ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost 1.31 release?
Martin Wille <[EMAIL PROTECTED]> writes: > David Abrahams wrote: > >> In that case, can I release 1.30.2? I don't like having the 1.30.1 >> debacle hanging over my head. > > > There are new regressions on Linux (RC_1_30_0 branch): > http://boost.sourceforge.net/regression-logs/cs-Linux-rc-1_30_0/developer_summary_page.html [BTW, Misha and Aleksey, when I click any of the failure links they lead to the log but not to any internal target showing the specific failure. Can this be fixed?] > > crc has regressions for gcc-3.1 and gcc-3.2.3 OK, Daryle, can you address these, and the intel io library failures? > config John, can you address this? > , format and io have regressions for intel 7.1 Samuel? -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost 1.31 release?
Aleksey Gurtovoy <[EMAIL PROTECTED]> writes: > Beman Dawes wrote: >> Assuming I'm release manager for 1.31.0, I'm going to publish explicit >> release criteria for key platform/compiler pairs. Basically, the >> criteria will be 100% accounting for all failures on those >> platform/compiler pairs. > > While I totally support the failures markup goal, I would like to see > _the_ release criteria to include "no regressions from the previous > release" item as well, preferrably for all non-beta compilers that are > currently under regression testing. Especially since now we have tools > to ensure it. I worry a little about requiring library authors not to regress on compiler combinations they don't test with. For example, who is going to address the one lexical_cast failure that's plaguing the 1.30.2 release? It's only on intel-7.1 with STLPort and looks for all the world like a config problem. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
Martin Wille wrote: If there is enough time left then I'll run the tests for the 1.30.0 release and gcc-3.1.1. The chart for the RC_1_30_0 branch should look better then. Done. There are no regressions for gcc-3.3.1/Linux. Regards, m ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
Beman Dawes wrote: > Assuming I'm release manager for 1.31.0, I'm going to publish explicit > release criteria for key platform/compiler pairs. Basically, the > criteria will be 100% accounting for all failures on those > platform/compiler pairs. While I totally support the failures markup goal, I would like to see _the_ release criteria to include "no regressions from the previous release" item as well, preferrably for all non-beta compilers that are currently under regression testing. Especially since now we have tools to ensure it. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
At 07:37 AM 8/11/2003, David Abrahams wrote: >Aleksey Gurtovoy <[EMAIL PROTECTED]> writes: > >> Beman Dawes wrote: >>> Assuming I'm release manager for 1.31.0, I'm going to publish explicit >>> release criteria for key platform/compiler pairs. Basically, the >>> criteria will be 100% accounting for all failures on those >>> platform/compiler pairs. >> >> While I totally support the failures markup goal, I would like to see >> _the_ release criteria to include "no regressions from the previous >> release" item as well, preferrably for all non-beta compilers that are >> currently under regression testing. Especially since now we have tools >> to ensure it. > >I worry a little about requiring library authors not to regress on >compiler combinations they don't test with. For example, who is going >to address the one lexical_cast failure that's plaguing the 1.30.2 >release? It's only on intel-7.1 with STLPort and looks for all the >world like a config problem. It can be very time consuming to track down the exact reason for failures. Thus we should focus our 1.31.0 effort on a small number of widely used compilers which don't have a lot of problems. For a lightly used toolset like intel-7.1 with STLPort, "looks for all the world like a config problem" seems like a good enough resolution to me. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
On Mon, 11 Aug 2003, David Abrahams wrote: > According to your chart, the following libraries are all regressing: > function > > Are these real regressions or just newly-tested compilers? Can the > library authors/maintainers address these problems? Where is our > maintenance wizard? All of the failures for function are due to newly-tested compilers. Doug ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
Aleksey Gurtovoy wrote: Martin Wille wrote: The new reports are now checked into the main trunk and RC_1_30_0 branch. Martin, if you are interested in upgrading to these, you would need to re-generate the expected results file from the 1.30.0 tarball run - it has to contain more information to support the new status higlighting. I tried the new reports for the 1_30_0 branch.The results look broken now. Everything that used to be in red is yellow now. (yellow is ok for gcc-3.4-cvs, but the other fields should be red). Err, sorry, broken check-in! Fixed now. Could you please re-generate the expected results file, and try it again? Yes, now the colours look fine. In the meantime, some fixes have been applied to the RC_1_30_0 code. Now, there are only these regressions left for Linux in the RC_1_30_0 branch: crc_test for gcc 3.1 and gcc.3.2.3 format tests for intel 7.1 New results for cvs head will be available tomorrow. Regards, m ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost 1.31 release?
Aleksey Gurtovoy <[EMAIL PROTECTED]> writes: > Well, sure, as long as we are in agreement about having differently > named toolsets for different compiler versions/configurations, e.g. > > bcc-5.5.1 > bcc-5.6.4 > intel-7.1-vc60 > intel-7.1-vc60-stlport It's OK with me. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
David Abrahams wrote: > Beman Dawes <[EMAIL PROTECTED]> writes: > > For a lightly used toolset like intel-7.1 with STLPort, "looks for all > > the world like a config problem" seems like a good enough resolution > > to me. > > In that case, can I release 1.30.2? I don't like having the 1.30.1 > debacle hanging over my head. Can it wait a day or two? As regression maintainers, we are interested in fixing this one. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
On Fri, 8 Aug 2003, Martin Wille wrote: > - function::sum_avg_portable Should be fixed now. Doug ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost 1.31 release?
Aleksey Gurtovoy <[EMAIL PROTECTED]> writes: > David Abrahams wrote: >> Misha and Aleksey -- I think we really need to distinguish those >> failures from real regressions in the chart somehow or we'll never be >> able to tell where we stand. > > Here - > http://www.meta-comm.com/engineering/resources/cs-win32_metacomm/developer_summary_page.html > > Yellow cells indicate failures on the newly added tests/compilers. The > updated report tools are not in the CVS yet, we will check them in after the > first round of feedback. Very nice! I am looking for a library which has both red and yellow for the same compiler so that I can verify that it shows up red in the top-level summary. I have looked at the iterator library failure with meta-intel-7.1-stlport. It appears to me that either BOOST_NO_STD_ITERATOR_TRAITS or BOOST_MSVC_STD_ITERATOR is misconfigured for this library. This configuration probably needs to change depending on whether you are using STLPort iostreams and which Dinkum library underlies your STLPort. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Boost 1.31 release?
At 08:45 AM 8/11/2003, Jeff Garland wrote: >> I've just installed 3.3.1 on Windows, and am getting those same four >> failure plus failures from: >> >> date_time/testmicrosec_time_clock (runtime failure) > >This is likely due to the posix API call to std::time not providing >stable return values. That is, when I sample the time rapidly the second >value is less than the previous value. So this is more of a platform / >library issue than a compiler issue. This isn't a new problem with this >particular configuration... OK, I've added a note to that effect. Consider the failure accounted for. Is there any point to report this to someone? Cygwin? --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
David Abrahams wrote: Martin Wille writes: David Abrahams wrote: In that case, can I release 1.30.2? I don't like having the 1.30.1 debacle hanging over my head. There are new regressions on Linux (RC_1_30_0 branch): http://boost.sourceforge.net/regression-logs/cs-Linux-rc-1_30_0/developer_summary_page.html crc has regressions for gcc-3.1 and gcc-3.2.3 config, format and io have regressions for intel 7.1 According to your chart, the following libraries are all regressing: config crc date_time format function graph io math multi_array numeric/interval numeric/ublas optional random static_assert test type_traits utility Are these real regressions or just newly-tested compilers? Can the library authors/maintainers address these problems? Where is our maintenance wizard? gcc.3.3.1/gcc 3.4 are newly tested. The sixth line on the summary page says: "Note: failures for gcc-3.3.1 and gcc-3.4 are all "unexpected" because there are no 1.30.0 results to compare with." gcc-3.4 can be ignored altogether. It isn't released yet (and very likely has bugs). The regressions I reported in the message you responded to are real regressions. If there is enough time left then I'll run the tests for the 1.30.0 release and gcc-3.1.1. The chart for the RC_1_30_0 branch should look better then. Regards, m ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
David Abrahams wrote: > Regarding http://tinyurl.com/jhtn: does this compiler ever need the > typename keyword? If not, perhaps we ought to define > BOOST_NO_DEDUCED_TYPENAME for all Borland versions Any particular failure that triggered your attention? Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost 1.31 release?
"Aleksey Gurtovoy" <[EMAIL PROTECTED]> writes: > David Abrahams wrote: >> Douglas Paul Gregor <[EMAIL PROTECTED]> writes: >> >> > On Mon, 11 Aug 2003, David Abrahams wrote: >> >> According to your chart, the following libraries are all regressing: >> >> function >> >> >> >> Are these real regressions or just newly-tested compilers? Can the >> >> library authors/maintainers address these problems? Where is our >> >> maintenance wizard? >> > >> > All of the failures for function are due to newly-tested compilers. >> >> Misha and Aleksey -- I think we really need to distinguish those >> failures from real regressions in the chart somehow or we'll never be >> able to tell where we stand. > > Well, it was assumed that when adding a new compiler one should use re-run > the regressions against the previous release and report the current status > using _those_ expected results. Many tests might have worked on the new compiler "by chance" with the previous release. It isn't fair to demand that maintainers to fix bugs on compilers they haven't agreed to support. > But in any case, you have a point - for one, it's not always > practical/possible to do the full re-run. We'll look into it. Thanks. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost 1.31 release?
Aleksey Gurtovoy <[EMAIL PROTECTED]> writes: > David Abrahams wrote: >> Aleksey Gurtovoy <[EMAIL PROTECTED]> writes: >> >> >> I worry a little about requiring library authors not to regress on >> >> compiler combinations they don't test with. >> > >> > Well, the regressions are run daily, so testing happens. Another >> > question is whether library authors care about how their libraries > perform >> > on all the compilers the regressions are being run on. >> > >> > Obviously, some compilers/configurations are included in the regression >> > testing because the ones who manage the latter are the ones who are >> > most interested in those. Then, again, obviously, some compilers/ >> > configurations are included in the regressions because they are very >> > widely used. >> > >> > For every release, the interested parties include library authors, >> > regression runners, the release manager, the maintenance wizard, and of >> > course active users who are subscribed to either of the lists. >> > >> > Given the above "setup", the implied interests of the participating >> > groups, and their explicit and implicit responsibilities and gratitude >> > towards each other, I think striving for "no regressions" goal I stated >> > above would be both a reasonable and fair strategy which can be made to >> > work. >> >> Some people are posting regressions for pre-release compilers. Should >> a library author should be expected to keep his library healthy on >> some weird/broken compiler just because it happened to work there by >> chance at one point? > > You skipped the part of my original posting which explicitly said: > >> > While I totally support the failures markup goal, I would like to see >> > _the_ release criteria to include "no regressions from the previous >> > release" item as well, preferrably for all non-beta compilers that are > >> > currently under regression testing. Especially since now we have tools >> > to ensure it. Still, lots of weird/broken compilers are non-beta. IMO all the Borland tools fall into that category. Lots of people consider supporting older versions of released compilers to be unneccessary. I don't always agree, but for example I recently dropped CWPro7 support from Boost.Python, IMO with justification. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost 1.31 release?
On Friday, August 8, 2003, at 12:21 PM, David Abrahams wrote: Matthias Troyer <[EMAIL PROTECTED]> writes: Dear Boosters, Since some of the applications and libraries we plan on releasing soon rely on Boost features and bugfixes that are in the CVS but not in Boost 1.30.[012] I wonder what the plans are for the Boost 1.31.0 release? Since we would prefer to base our released software on a Boost release instead of a CVS snapshot I would be interested in hearing about the plans for a Boost 1.31 release As far as I know the CVS is in very good health at the moment. The only major thing I know needs to be done is to complete the documentation for the new iterator adaptors. I'd like to get that over with soon, so it isn't hanging over our heads much longer. As far as I can see Jens Maurer has updated boost.random to his standards proposal, but not yet the documentation. I believe it would be important to have the random documentation be consistent with the sources, especially since the interface has changed significantly. Matthias ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
En réponse à David Abrahams <[EMAIL PROTECTED]>: > Martin Wille <[EMAIL PROTECTED]> writes: > > > David Abrahams wrote: > > > >> In that case, can I release 1.30.2? I don't like having the 1.30.1 > >> debacle hanging over my head. > > > > > > There are new regressions on Linux (RC_1_30_0 branch): > > http://boost.sourceforge.net/regression-logs/cs-Linux-rc-1_30_0/developer_summary_page.html > > > > > > crc has regressions for gcc-3.1 and gcc-3.2.3 > > config, format and io have regressions for intel 7.1 > > According to your chart, the following libraries are all regressing: [...] > numeric/interval [...] Nothing has been commited to the RC_1_30_0 branch for the interval library, so there should be no regression. In fact, the "regression" you speak about happens with gcc-3.4-cvs. Martin was careful not to mention these failures in his mail. > Are these real regressions or just newly-tested compilers? Can the > library authors/maintainers address these problems? Where is our > maintenance wizard? Mainly newly-tested compilers (gcc-3.3.1 and gcc-3.4). You just have to focus on gcc-3.1, gcc-3.2.3 and intel-7.1 columns. Regards, Guillaume ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
At 04:11 PM 8/10/2003, Martin Wille wrote: >I added gcc-3.3.1 to the Linux tests for CVS HEAD. > >Test failures have been down to 1% for gcc versions 3.2.3 and 3.3 a >few weeks ago. I think 3.2.3 and 3.3.1 would be good candidates for >being release criteria. OK, let's use 3.2.3 and 3.3.1 as the Linux release criteria. Since someone has to research every failure, and this is our first release using formal criteria, we don't want to go overboard. >6 tests fail for 3.2.3 and 6 tests fail for 3.3.1 > > > From the list I recently posted 1 failure has been fixed and >1 failure is due to a compiler error and not considered harmful. > >That leaves > > function::sum_avg_portable > math::octonion_test > math::quaternion_test > test::errors_handling_test > >to be fixed or to be explained. Note, all these tests fail for >both CVS HEAD and RC_1_30_0. I've just installed 3.3.1 on Windows, and am getting those same four failure plus failures from: date_time/testmicrosec_time_clock (runtime failure) iterator/interoperable_fail (compile_fail test isn't failing) That seems like a reasonable number to fix or otherwise account for. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
At 05:12 AM 8/11/2003, Alisdair Meredith wrote: >Aleksey Gurtovoy wrote: > >> While I totally support the failures markup goal, I would like to see >> _the_ release criteria to include "no regressions from the previous >> release" item as well, preferrably for all non-beta compilers that are >> currently under regression testing. Especially since now we have tools >> to ensure it. > >OTOH, it might not always be achievable. >For boost 1.31 we are having an interface breaking change to the >iterator_adaptors, and not all compilers pass all tests with the new >adaptors yet. > >While this may not be a problem for the iterators library (it is >effectively new) it may have a knock-on effect on any other boost >libraries implemented on top of it. > >The principle is a good one, but I be prepared to make a few allowances >in the practice. I think a reasonable goal is that any regressions should be understood and discussed, rather than silent. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost 1.31 release?
David Abrahams wrote: > > Here - > > http://www.meta-comm.com/engineering/resources/cs-win32_metacomm/developer_summary_page.html > > > > Yellow cells indicate failures on the newly added tests/compilers. The > > updated report tools are not in the CVS yet, we will check them in after the > > first round of feedback. > > Very nice! Thank you! > I am looking for a library which has both red and yellow for > the same compiler so that I can verify that it shows up red in the > top-level summary. It does. See, for instance, "regex" on "cwpro8". > > I have looked at the iterator library failure with > meta-intel-7.1-stlport. It appears to me that either > BOOST_NO_STD_ITERATOR_TRAITS or BOOST_MSVC_STD_ITERATOR is > misconfigured for this library. This configuration probably needs to > change depending on whether you are using STLPort iostreams and which > Dinkum library underlies your STLPort. Thanks for the info, we will look into it. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost 1.31 release?
"Aleksey Gurtovoy" <[EMAIL PROTECTED]> writes: > Aleksey Gurtovoy wrote: >> David Abrahams wrote: >> > Misha and Aleksey -- I think we really need to distinguish those >> > failures from real regressions in the chart somehow or we'll never be >> > able to tell where we stand. >> >> Here - >> > http://www.meta-comm.com/engineering/resources/cs-win32_metacomm/developer_summary_page.html >> >> Yellow cells indicate failures on the newly added tests/compilers. The >> updated report tools are not in the CVS yet, we will check them in after > the >> first round of feedback. > > The new reports are now checked into the main trunk and RC_1_30_0 branch. Now *thats* really informative! Thanks again for all your efforts! -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
Beman Dawes wrote: Assuming I'm release manager for 1.31.0, I'm going to publish explicit release criteria for key platform/compiler pairs. Basically, the release criteria will be 100% accounting for all failures on those platform/compiler pairs. I assume that Linux/GCC will be one of those platform/compiler pairs. I need input from Linux/GCC experts as to which version of GCC should be used for the release criteria. I see GCC 3.3.1 has just been released, and so will be switching the Windows/GCC tests to use that version. Unless anyone objects, it will be one of the Windows release criteria compilers. I added gcc-3.3.1 to the Linux tests for CVS HEAD. Test failures have been down to 1% for gcc versions 3.2.3 and 3.3 a few weeks ago. I think 3.2.3 and 3.3.1 would be good candidates for being release criteria. 6 tests fail for 3.2.3 and 6 tests fail for 3.3.1 From the list I recently posted 1 failure has been fixed and 1 failure is due to a compiler error and not considered harmful. That leaves function::sum_avg_portable math::octonion_test math::quaternion_test test::errors_handling_test to be fixed or to be explained. Note, all these tests fail for both CVS HEAD and RC_1_30_0. Regards, m PS: The one additional error gcc 3.2.3 produces over 3.3.1 is in crc_test, btw. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost 1.31 release?
Douglas Paul Gregor <[EMAIL PROTECTED]> writes: > On Mon, 11 Aug 2003, David Abrahams wrote: >> According to your chart, the following libraries are all regressing: >> function >> >> Are these real regressions or just newly-tested compilers? Can the >> library authors/maintainers address these problems? Where is our >> maintenance wizard? > > All of the failures for function are due to newly-tested compilers. Misha and Aleksey -- I think we really need to distinguish those failures from real regressions in the chart somehow or we'll never be able to tell where we stand. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
Alisdair Meredith wrote: > Aleksey Gurtovoy wrote: > > > While I totally support the failures markup goal, I would like to see > > _the_ release criteria to include "no regressions from the previous > > release" item as well, preferrably for all non-beta compilers that are > > currently under regression testing. Especially since now we have tools > > to ensure it. > > OTOH, it might not always be achievable. > For boost 1.31 we are having an interface breaking change to the > iterator_adaptors, and not all compilers pass all tests with the new > adaptors yet. > > While this may not be a problem for the iterators library (it is > effectively new) Yes. > it may have a knock-on effect on any other boost libraries implemented > on top of it. And any failures concerned with the interface change per se should be fixed before the release. It might happen that major changes in a library inadvertently cause _functionality regression_ on the particular compiler, but IMO "inadvertently" is a key word here. > > The principle is a good one, but I be prepared to make a few allowances > in the practice. Sure, as long as it's an explicit decision. After all, those could be put in the release notes. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
Beman Dawes wrote: > At 07:37 AM 8/11/2003, David Abrahams wrote: > >Aleksey Gurtovoy <[EMAIL PROTECTED]> writes: > > > >> Beman Dawes wrote: > >>> Assuming I'm release manager for 1.31.0, I'm going to publish explicit > >>> release criteria for key platform/compiler pairs. Basically, the > >>> criteria will be 100% accounting for all failures on those > >>> platform/compiler pairs. > >> > >> While I totally support the failures markup goal, I would like to see > >> _the_ release criteria to include "no regressions from the previous > >> release" item as well, preferrably for all non-beta compilers that are > >> currently under regression testing. Especially since now we have tools > >> to ensure it. > > > >I worry a little about requiring library authors not to regress on > >compiler combinations they don't test with. For example, who is going > >to address the one lexical_cast failure that's plaguing the 1.30.2 > >release? It's only on intel-7.1 with STLPort and looks for all the > >world like a config problem. > > It can be very time consuming to track down the exact reason for failures. > Thus we should focus our 1.31.0 effort on a small number of widely used > compilers which don't have a lot of problems. It doesn't have to be the release manager who investigates all the issues himself, though. There might be enough of the interested parties with motivation/resources to resolve most of these in a reasonable time frame if they a given a chance/"managed" properly. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
At 01:39 PM 8/8/2003, Martin Wille wrote: >In order to avoid problems to be discovered too late for fixing them >I'll list the tests that fail for many compilers/compiler versions >on Linux: > >- filesystem::operations_test Hum... That looks like a CVS problem. It looks like boost-root/libs/filesystem/src/operations_posix_windows.cpp has not been updated to 1.15. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
[2003-08-11] David Abrahams wrote: >Aleksey Gurtovoy <[EMAIL PROTECTED]> writes: > >> Well, sure, as long as we are in agreement about having differently >> named toolsets for different compiler versions/configurations, e.g. >> >> bcc-5.5.1 >> bcc-5.6.4 >> intel-7.1-vc60 >> intel-7.1-vc60-stlport > >It's OK with me. I'd rather that they have the same root as the base toolsets... borland-5.5.1 borland-5.6.4 intel-win32-7.1-vc60 intel-win32-7.1-vc60-stlport Makes for easier maintenance. -- grafik - Don't Assume Anything -- rrivera (at) acm.org - grafik (at) redshift-software.com -- 102708583 (at) icq ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost 1.31 release?
David Abrahams wrote: > Matthias Troyer writes: > > > Dear Boosters, > > > > Since some of the applications and libraries we plan on releasing soon > > rely on Boost features and bugfixes that are in the CVS but not in > > Boost 1.30.[012] I wonder what the plans are for the Boost 1.31.0 > > release? Since we would prefer to base our released software on a > > Boost release instead of a CVS snapshot I would be interested in > > hearing about the plans for a Boost 1.31 release > > As far as I know the CVS is in very good health at the moment. The > only major thing I know needs to be done is to complete the > documentation for the new iterator adaptors. I'd like to get that > over with soon, so it isn't hanging over our heads much longer. There is still some work to be done on variant. In the next day or two, I plan to have "sugared up" recursive variant support such as the following: typedef boost::variant< int , std::vector< boost::recursive_variant > > my_variant; Also, Itay is continuing to work on the documentation and tests. I imagine we'll finish soon. Thanks, Eric ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost 1.31 release?
Martin Wille <[EMAIL PROTECTED]> writes: > David Abrahams wrote: > >> In that case, can I release 1.30.2? I don't like having the 1.30.1 >> debacle hanging over my head. > > > There are new regressions on Linux (RC_1_30_0 branch): > http://boost.sourceforge.net/regression-logs/cs-Linux-rc-1_30_0/developer_summary_page.html > > > crc has regressions for gcc-3.1 and gcc-3.2.3 > config, format and io have regressions for intel 7.1 According to your chart, the following libraries are all regressing: config crc date_time format function graph io math multi_array numeric/interval numeric/ublas optional random static_assert test type_traits utility Are these real regressions or just newly-tested compilers? Can the library authors/maintainers address these problems? Where is our maintenance wizard? -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost 1.31 release?
Beman Dawes <[EMAIL PROTECTED]> writes: > At 07:37 AM 8/11/2003, David Abrahams wrote: > >Aleksey Gurtovoy <[EMAIL PROTECTED]> writes: > > > >> Beman Dawes wrote: > >>> Assuming I'm release manager for 1.31.0, I'm going to publish explicit > >>> release criteria for key platform/compiler pairs. Basically, the > >>> criteria will be 100% accounting for all failures on those > >>> platform/compiler pairs. > >> > >> While I totally support the failures markup goal, I would like to see > >> _the_ release criteria to include "no regressions from the previous > >> release" item as well, preferrably for all non-beta compilers that are > >> currently under regression testing. Especially since now we have tools > >> to ensure it. > > > >I worry a little about requiring library authors not to regress on > >compiler combinations they don't test with. For example, who is going > >to address the one lexical_cast failure that's plaguing the 1.30.2 > >release? It's only on intel-7.1 with STLPort and looks for all the > >world like a config problem. > > It can be very time consuming to track down the exact reason for > failures. Thus we should focus our 1.31.0 effort on a small number of > widely used compilers which don't have a lot of problems. > > For a lightly used toolset like intel-7.1 with STLPort, "looks for all > the world like a config problem" seems like a good enough resolution > to me. In that case, can I release 1.30.2? I don't like having the 1.30.1 debacle hanging over my head. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
David Abrahams wrote: > >> As far as I know the CVS is in very good health at the moment. > > > > Uhmm, I really wouldn't say so! If you look at the main trunk report - > > http://www.meta-comm.com/engineering/resources/cvs_main_trunk/developer_summary_page.html, > > there are lots of regressions comparing to 1.30.0, and IMO we ought to > > fix all these before we branch for the release or anything. > > I can't really tell what these represent. As usual, a red cell means a regression from the 1.30.0 tarball, a dark green one - an improvement. > All of the new iterator library tests which weren't in 1.30.0 are > showing up as regressions if they're failing. Yes, it's a known shortcoming - or a feature, depending of how you look at it. By default, new tests are expected to pass. > Many are simply not going to get better; they're due to compiler bugs > which can't be worked around. Which is totally fine. If you provide us with the list of expected failures, these will be cleared. > As for the others, the failures you're reporting with intel-7.1 are > very strange; my 7.1 compiler doesn't have these problems AFAIK. Hmm, looks like another configuration problem to me. We'll take a look at it. > What does the "meta-" prefix mean? "meta-" is our prefix for non-boost toolsets. > Do you have some special configuration of each of these compilers? Well, most of them are not really special. For instance, bcc-* ones were introduced for the only purpose of being able to test 5.5.1 and 5.5.4 compilers simultaneously. The complete list of differences is available here - http://www.meta-comm.com/engineering/resources/cs-win32_rc_1_30_0_metacomm/patches.html Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
At 01:39 PM 8/8/2003, Martin Wille wrote: >David Abrahams wrote: >> Matthias Troyer <[EMAIL PROTECTED]> writes: >... >>>I would be interested in >>>hearing about the plans for a Boost 1.31 release >> >> >> As far as I know the CVS is in very good health at the moment. The >> only major thing I know needs to be done is to complete the >> documentation for the new iterator adaptors. I'd like to get that >> over with soon, so it isn't hanging over our heads much longer. > >In order to avoid problems to be discovered too late for fixing them >I'll list the tests that fail for many compilers/compiler versions >on Linux: > >- filesystem::operations_test >- function::sum_avg_portable >- iterator::interoperable_fail (a compile_fail test that fails, > probably not a real problem) >- math::octonion_test > math::quaternion_test >- test::errors_handling_test > >I hope that lists helps. Assuming I'm release manager for 1.31.0, I'm going to publish explicit release criteria for key platform/compiler pairs. Basically, the release criteria will be 100% accounting for all failures on those platform/compiler pairs. I assume that Linux/GCC will be one of those platform/compiler pairs. I need input from Linux/GCC experts as to which version of GCC should be used for the release criteria. I see GCC 3.3.1 has just been released, and so will be switching the Windows/GCC tests to use that version. Unless anyone objects, it will be one of the Windows release criteria compilers. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
David Abrahams wrote: > Matthias Troyer <[EMAIL PROTECTED]> writes: > > > Dear Boosters, > > > > Since some of the applications and libraries we plan on releasing soon > > rely on Boost features and bugfixes that are in the CVS but not in > > Boost 1.30.[012] I wonder what the plans are for the Boost 1.31.0 > > release? Since we would prefer to base our released software on a > > Boost release instead of a CVS snapshot I would be interested in > > hearing about the plans for a Boost 1.31 release > > As far as I know the CVS is in very good health at the moment. Uhmm, I really wouldn't say so! If you look at the main trunk report - http://www.meta-comm.com/engineering/resources/cvs_main_trunk/developer_summary_page.html, there are lots of regressions comparing to 1.30.0, and IMO we ought to fix all these before we branch for the release or anything. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost 1.31 release?
Aleksey Gurtovoy <[EMAIL PROTECTED]> writes: > David Abrahams wrote: >> Matthias Troyer <[EMAIL PROTECTED]> writes: >> >> > Dear Boosters, >> > >> > Since some of the applications and libraries we plan on releasing soon >> > rely on Boost features and bugfixes that are in the CVS but not in >> > Boost 1.30.[012] I wonder what the plans are for the Boost 1.31.0 >> > release? Since we would prefer to base our released software on a >> > Boost release instead of a CVS snapshot I would be interested in >> > hearing about the plans for a Boost 1.31 release >> >> As far as I know the CVS is in very good health at the moment. > > Uhmm, I really wouldn't say so! If you look at the main trunk report - > http://www.meta-comm.com/engineering/resources/cvs_main_trunk/developer_summary_page.html, > there are lots of regressions comparing to 1.30.0, and IMO we ought to fix > all these before we branch for the release or anything. Regarding http://tinyurl.com/jhtn: does this compiler ever need the typename keyword? If not, perhaps we ought to define BOOST_NO_DEDUCED_TYPENAME for all Borland versions> -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost 1.31 release?
Aleksey Gurtovoy <[EMAIL PROTECTED]> writes: > David Abrahams wrote: >> Matthias Troyer <[EMAIL PROTECTED]> writes: >> >> > Dear Boosters, >> > >> > Since some of the applications and libraries we plan on releasing soon >> > rely on Boost features and bugfixes that are in the CVS but not in >> > Boost 1.30.[012] I wonder what the plans are for the Boost 1.31.0 >> > release? Since we would prefer to base our released software on a >> > Boost release instead of a CVS snapshot I would be interested in >> > hearing about the plans for a Boost 1.31 release >> >> As far as I know the CVS is in very good health at the moment. > > Uhmm, I really wouldn't say so! If you look at the main trunk report - > http://www.meta-comm.com/engineering/resources/cvs_main_trunk/developer_summary_page.html, > there are lots of regressions comparing to 1.30.0, and IMO we ought to fix > all these before we branch for the release or anything. I can't really tell what these represent. All of the new iterator library tests which weren't in 1.30.0 are showing up as regressions if they're failing. Many are simply not going to get better; they're due to compiler bugs which can't be worked around. As for the others, the failures you're reporting with intel-7.1 are very strange; my 7.1 compiler doesn't have these problems AFAIK. What does the "meta-" prefix mean? Do you have some special configuration of each of these compilers? -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
