metacomm borland 5_8_* results
Hi, at the moment, results for borland_5_8_1 and borland_5_8_2b compiler on RC_1_34_0 branch are pretty bad. See: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/developer/su... Unless a user of borland can step forward and look into those failures, we'll essentially have no support for those toolsets in 1.34. Any volunteers? Thanks, Volodya
Vladimir Prus wrote:
at the moment, results for borland_5_8_1 and borland_5_8_2b compiler on RC_1_34_0 branch are pretty bad. See:
http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/develo per/summary.html
Unless a user of borland can step forward and look into those failures, we'll essentially have no support for those toolsets in 1.34. Any volunteers?
I know there are at least two of us actively looking into the issues now. Unforunately I was effectively offline last week in Berlin, so am only catching up now. The 0x581 issues look a lot worse than 0x564 simply because many expected failures have not been marked up yet. There are still some library config issues to straighten out, but I think it is pretty close otherwise. In this form, it is simply showing how scary 0x564 is without the markup as well! 0x582 is a bit strange. Basically, Borland have made the next patch of their compiler available to myself and Aleksey as the patch and Boost 1.34 will probably ship around the same time. Boost regressions are one of the focusses of this patch, and it gives me much better results locally. I have just checked out the release branch (vs. the mainline I have been working with) and should have some more patches ready to roll tonight. So far, I have not been applying patches directly, but posting them to the list. Some of those patches can take a while to be applied, and I think a couple went missing. Is there anything I can do to speed up applying patches? -- AlisdairM
AlisdairM wrote:
Vladimir Prus wrote:
at the moment, results for borland_5_8_1 and borland_5_8_2b compiler on RC_1_34_0 branch are pretty bad. See:
http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/develo per/summary.html
Unless a user of borland can step forward and look into those failures, we'll essentially have no support for those toolsets in 1.34. Any volunteers?
I know there are at least two of us actively looking into the issues now. Unforunately I was effectively offline last week in Berlin, so am only catching up now.
I am also looking into this and have posted a few patches lately to the list. So far only Robert Ramey took notice though. [...]
0x582 is a bit strange. Basically, Borland have made the next patch of their compiler available to myself and Aleksey as the patch and Boost 1.34 will probably ship around the same time. Boost regressions are one of the focusses of this patch, and it gives me much better results locally. I have just checked out the release branch (vs. the mainline I have been working with) and should have some more patches ready to roll tonight.
Alisdair, the last time I looked borland.hpp wasn't updated for 5.8.2 . I refrained from posting a patch because I believe you have more extensive changes to submit than I have.
So far, I have not been applying patches directly, but posting them to the list. Some of those patches can take a while to be applied, and I think a couple went missing. Is there anything I can do to speed up applying patches?
Exactly my point of view. Maybe some of the most experienced Boosters could step in and review our patches if library authors aren't available... Cheers, Nicola Musatti
As far as I'm concerned, I would like to see these gentlemen be able to insert these patches directly. Robert Ramey AlisdairM wrote:
So far, I have not been applying patches directly, but posting them to the list. Some of those patches can take a while to be applied, and I think a couple went missing. Is there anything I can do to speed up applying patches?
Robert Ramey writes:
AlisdairM wrote:
So far, I have not been applying patches directly, but posting them to the list. Some of those patches can take a while to be applied, and I think a couple went missing. Is there anything I can do to speed up applying patches?
As far as I'm concerned, I would like to see these gentlemen be able to insert these patches directly.
Same here. -- Aleksey Gurtovoy MetaCommunications Engineering
Aleksey Gurtovoy <agurtovoy@meta-comm.com> writes:
Robert Ramey writes:
AlisdairM wrote:
So far, I have not been applying patches directly, but posting them to the list. Some of those patches can take a while to be applied, and I think a couple went missing. Is there anything I can do to speed up applying patches?
As far as I'm concerned, I would like to see these gentlemen be able to insert these patches directly.
Same here.
To get CVS access they need to submit requests to the moderators (boost-owner@lists.boost.org) containing their SourceForge (symbolic) userIDs. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote: [...]
To get CVS access they need to submit requests to the moderators (boost-owner@lists.boost.org) containing their SourceForge (symbolic) userIDs.
David, the problem is not one of CVS access, which both Alisdair and I have, but rather how to behave when library authors are apparently not available to review our patches. Cheers, Nicola Musatti
Nicola Musatti wrote:
David Abrahams wrote: [...]
To get CVS access they need to submit requests to the moderators (boost-owner@lists.boost.org) containing their SourceForge (symbolic) userIDs.
David, the problem is not one of CVS access, which both Alisdair and I have, but rather how to behave when library authors are apparently not available to review our patches.
Patches that insert an additional BOOST_WORKAROUND or fix the version of an existing one should be relatively safe to make "by default" if nobody objects within, say, 3 days or so. (I should note that your last patch didn't fall into that category, though, IIRC.)
Peter Dimov wrote: [...]
Patches that insert an additional BOOST_WORKAROUND or fix the version of an existing one should be relatively safe to make "by default" if nobody objects within, say, 3 days or so. (I should note that your last patch didn't fall into that category, though, IIRC.)
Which one are you referring to? Cheers, Nicola Musatti
Nicola Musatti wrote:
Peter Dimov wrote: [...]
Patches that insert an additional BOOST_WORKAROUND or fix the version of an existing one should be relatively safe to make "by default" if nobody objects within, say, 3 days or so. (I should note that your last patch didn't fall into that category, though, IIRC.)
Which one are you referring to?
http://lists.boost.org/Archives/boost/2006/04/102855.php http://lists.boost.org/Archives/boost/2006/04/102856.php both seem to introduce modifications to correct code in order to work around bugs in BCB2006, so they won't enjoy an "autocommit" status. :-) One reason for not doing things that way, even though it's easier and I've been known to use it myself, is to allow compilation with all workarounds disabled. This can be useful for compiler/frontend vendors, for example.
Peter Dimov wrote: [...]
http://lists.boost.org/Archives/boost/2006/04/102855.php http://lists.boost.org/Archives/boost/2006/04/102856.php
both seem to introduce modifications to correct code in order to work around bugs in BCB2006, so they won't enjoy an "autocommit" status. :-)
One reason for not doing things that way, even though it's easier and I've been known to use it myself, is to allow compilation with all workarounds disabled. This can be useful for compiler/frontend vendors, for example.
You're right and I see your point of view. On the other hand when the workaround is valid and simple I see a trade of with the clutter added by conditional compilation. Cheers, Nicola Musatti
Speaking for myself. The patches you've submitted for the serialization library seem to be targeted to making borland work without affection anything else. Since I can't even test these new borland compilers, I'm 100% dependent upon your judgement in any case so we just as well can cut out the middle man (me in this case). Robert Ramey Nicola Musatti wrote:
David Abrahams wrote: [...]
To get CVS access they need to submit requests to the moderators (boost-owner@lists.boost.org) containing their SourceForge (symbolic) userIDs.
David, the problem is not one of CVS access, which both Alisdair and I have, but rather how to behave when library authors are apparently not available to review our patches.
Cheers, Nicola Musatti
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
"Robert Ramey" <ramey@rrsd.com> writes:
Speaking for myself. The patches you've submitted for the serialization library seem to be targeted to making borland work without affection anything else. Since I can't even test these new borland compilers, I'm 100% dependent upon your judgement in any case so we just as well can cut out the middle man (me in this case).
Exactly. When I find fixes like this, whose effect I can confidently isolate (in this case, to one compiler version), I'll post them in a batch to the list, warn everyone that unless there are objections in a few days I'll apply them, wait a few days for any complaints, and check them in. -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (7)
-
Aleksey Gurtovoy -
AlisdairM -
David Abrahams -
Nicola Musatti -
Peter Dimov -
Robert Ramey -
Vladimir Prus