[1.46] Last few merges needed?
I've been sifting through what needs to change on the release branch (for 1.46) in Boost.Config to revert some of the changes made by Bryce which have already been reverted in Trunk. Specifically: The patches to the pathscale config need to be merged to Release (unfortunately it took until now to get these working on Trunk): --- boost/config/select_compiler_config.hpp 2011-01-24 18:05:13.486000000 +0 000 +++ ../branches/release/boost/config/select_compiler_config.hpp 2011-01-17 15:59 :34.498000000 +0000 @@ -52,7 +52,7 @@ // Comeau C++ # define BOOST_COMPILER_CONFIG "boost/config/compiler/comeau.hpp" -#elif defined(__PATHSCALE__) && (__PATHCC__ >= 4) +#elif defined __PATHSCALE__ // PathScale EKOPath compiler (has to come before clang and gcc) # define BOOST_COMPILER_CONFIG "boost/config/compiler/pathscale.hpp" And also the Boost.Config docs need to be merged to release so that the new BOOST_*_NIX macros that were added and then removed are no longer documented in 1.46 (the actual changed headers can wait till 1.47 for merging). Is there likely to be a window when these changes can be merged - maybe between beta and release? Also are there any other pending reverts in Trunk but not release? Regards, John.
On 27 January 2011 12:24, John Maddock <boost.regex@virgin.net> wrote:
Also are there any other pending reverts in Trunk but not release?
It's not in trunk yet, but there's the iterator_traits issue highlighted in the '[V1.46] [Iterator] Ask for release notes modification' thread. It's unlikely that it will be ready for the beta. Daniel
On 27 January 2011 13:19, Daniel James <dnljms@gmail.com> wrote:
It's not in trunk yet, but there's the iterator_traits issue highlighted in the '[V1.46] [Iterator] Ask for release notes modification' thread. It's unlikely that it will be ready for the beta.
I just looked into it, and it's a clean revert on the release branch (it's the last change to the iterator library) so I'll just revert it directly on the release branch. Shall I wait? Daniel
On Thu, Jan 27, 2011 at 4:05 PM, Daniel James <dnljms@gmail.com> wrote:
On 27 January 2011 13:19, Daniel James <dnljms@gmail.com> wrote:
It's not in trunk yet, but there's the iterator_traits issue highlighted in the '[V1.46] [Iterator] Ask for release notes modification' thread. It's unlikely that it will be ready for the beta.
I just looked into it, and it's a clean revert on the release branch (it's the last change to the iterator library) so I'll just revert it directly on the release branch. Shall I wait?
Go ahead. I tested a minor script change this afternoon, and am planning to build the beta release candidates tomorrow (Friday) morning, US Eastern time. --Beman
Is there likely to be a window when these changes can be merged - maybe between beta and release?
A second that question: we have some doc updates (in Spirit) we would like to merge before release. When can we do that? Regards Hartmut --------------- http://boost-spirit.com
On 1/27/2011 9:30 PM, Hartmut Kaiser wrote:
Is there likely to be a window when these changes can be merged - maybe between beta and release?
A second that question: we have some doc updates (in Spirit) we would like to merge before release. When can we do that?
Doc changes can be made whenever. Fire away. -- Eric Niebler BoostPro Computing http://www.boostpro.com
Is there likely to be a window when these changes can be merged - maybe between beta and release?
I have encountered a problem today that I would like to fix and merge before release: When preceded by the include #include <boost/thread.hpp> Boost.Icl code #include <boost/icl/some_icl_file.hpp> does not compile anymore. The problem could be located in macro code: BOOST_STATIC_CONSTANT(bool, value = (interval_bound_type<Type>::value < icl::interval_bounds::undefined)); This bug obviously would be very annoying to users, who want to use Boost.Icl together with Boost.Tread. The fix is very tiny and trivial BOOST_STATIC_CONSTANT(bool, value = ((interval_bound_type<Type>::value) < icl::interval_bounds::undefined)); parentheses around a subexpression in two lines. I've just committed that fix to the trunk after testing locally. So I'd like to ask for permission to merge this small fix to the release branch. Regards, Joachim
Next time, please start a new thread / subject... On 1/27/2011 9:51 AM, Joachim Faulhaber wrote:
Is there likely to be a window when these changes can be merged - maybe between beta and release?
I have encountered a problem today that I would like to fix and merge before release:
When preceded by the include #include<boost/thread.hpp>
Boost.Icl code #include<boost/icl/some_icl_file.hpp>
does not compile anymore. The problem could be located in macro code:
BOOST_STATIC_CONSTANT(bool, value = (interval_bound_type<Type>::value < icl::interval_bounds::undefined));
This bug obviously would be very annoying to users, who want to use Boost.Icl together with Boost.Tread.
The fix is very tiny and trivial
BOOST_STATIC_CONSTANT(bool, value = ((interval_bound_type<Type>::value) < icl::interval_bounds::undefined));
parentheses around a subexpression in two lines.
I've just committed that fix to the trunk after testing locally.
So I'd like to ask for permission to merge this small fix to the release branch.
Short answer, no. Long answer, this doesn't look like a showstopper to me. Perhaps just a small comment on the release notes pointing to the trac issue is enough? -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
2011/1/27 Rene Rivera <grafikrobot@gmail.com>:
Next time, please start a new thread / subject...
On 1/27/2011 9:51 AM, Joachim Faulhaber wrote:
Is there likely to be a window when these changes can be merged - maybe between beta and release?
I have encountered a problem today that I would like to fix and merge before release:
When preceded by the include #include<boost/thread.hpp>
Boost.Icl code #include<boost/icl/some_icl_file.hpp>
does not compile anymore. The problem could be located in macro code:
BOOST_STATIC_CONSTANT(bool, value = (interval_bound_type<Type>::value < icl::interval_bounds::undefined));
This bug obviously would be very annoying to users, who want to use Boost.Icl together with Boost.Tread.
The fix is very tiny and trivial
BOOST_STATIC_CONSTANT(bool, value = ((interval_bound_type<Type>::value) < icl::interval_bounds::undefined));
parentheses around a subexpression in two lines.
I've just committed that fix to the trunk after testing locally.
So I'd like to ask for permission to merge this small fix to the release branch.
Short answer, no. Long answer, this doesn't look like a showstopper to me.
Hmm. The effect makes Boost.Icl almost unusable for users that include <boost.thread.hpp> somewhere before icl stuff. On the other hand the fix is pretty trivial. But well, the decision is up to you. Joachim
On 1/27/2011 10:22 AM, Joachim Faulhaber wrote:
2011/1/27 Rene Rivera<grafikrobot@gmail.com>:
Next time, please start a new thread / subject...
On 1/27/2011 9:51 AM, Joachim Faulhaber wrote:
Is there likely to be a window when these changes can be merged - maybe between beta and release?
I have encountered a problem today that I would like to fix and merge before release:
When preceded by the include #include<boost/thread.hpp>
Boost.Icl code #include<boost/icl/some_icl_file.hpp>
does not compile anymore. The problem could be located in macro code:
BOOST_STATIC_CONSTANT(bool, value = (interval_bound_type<Type>::value < icl::interval_bounds::undefined));
This bug obviously would be very annoying to users, who want to use Boost.Icl together with Boost.Tread.
The fix is very tiny and trivial
BOOST_STATIC_CONSTANT(bool, value = ((interval_bound_type<Type>::value) < icl::interval_bounds::undefined));
parentheses around a subexpression in two lines.
I've just committed that fix to the trunk after testing locally.
So I'd like to ask for permission to merge this small fix to the release branch.
Short answer, no. Long answer, this doesn't look like a showstopper to me.
Hmm. The effect makes Boost.Icl almost unusable for users that include <boost.thread.hpp> somewhere before icl stuff. On the other hand the fix is pretty trivial. But well, the decision is up to you.
Sure.. But isn't it just as "easy" to tell users to swap the includes around? Note.. I'm only being annoying because we are already running rather behind on the release :-( -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
2011/1/27 Rene Rivera <grafikrobot@gmail.com>:
On 1/27/2011 10:22 AM, Joachim Faulhaber wrote:
So I'd like to ask for permission to merge this small fix to the release branch.
Short answer, no. Long answer, this doesn't look like a showstopper to me.
Hmm. The effect makes Boost.Icl almost unusable for users that include <boost.thread.hpp> somewhere before icl stuff. On the other hand the fix is pretty trivial. But well, the decision is up to you.
Sure.. But isn't it just as "easy" to tell users to swap the includes around?
Most developers that I know would rather be offended by software that comes with a plea attached to it to please first move your includes around. ...
Note.. I'm only being annoying because we are already running rather behind on the release :-(
Such last minutes surprises are always not very welcome, I know ... I won't take your decision personal ;) Joachim
On 1/27/2011 10:48 AM, Joachim Faulhaber wrote:
2011/1/27 Rene Rivera<grafikrobot@gmail.com>:
On 1/27/2011 10:22 AM, Joachim Faulhaber wrote:
So I'd like to ask for permission to merge this small fix to the release branch.
Short answer, no. Long answer, this doesn't look like a showstopper to me.
Hmm. The effect makes Boost.Icl almost unusable for users that include <boost.thread.hpp> somewhere before icl stuff. On the other hand the fix is pretty trivial. But well, the decision is up to you.
Sure.. But isn't it just as "easy" to tell users to swap the includes around?
Most developers that I know would rather be offended by software that comes with a plea attached to it to please first move your includes around. ...
Note.. I'm only being annoying because we are already running rather behind on the release :-(
Such last minutes surprises are always not very welcome, I know ... I won't take your decision personal ;)
After a brief talk on IRC.. How about if you.. 1. Add a test to show the problem in trunk. Passing with the fix in it of course. 2. Wait for the beta to get done. 3. Then you can ask again to make this change after the beta is out. And we'll likely say yes. And as always.. Please make such a request with pointers to diffs, tests, trac tickets, etc. As it makes it faster to evaluate. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
2011/1/27 Rene Rivera <grafikrobot@gmail.com>:
On 1/27/2011 10:48 AM, Joachim Faulhaber wrote:
Such last minutes surprises are always not very welcome, I know ... I won't take your decision personal ;)
After a brief talk on IRC.. How about if you..
1. Add a test to show the problem in trunk. Passing with the fix in it of course. 2. Wait for the beta to get done. 3. Then you can ask again to make this change after the beta is out. And we'll likely say yes.
And as always.. Please make such a request with pointers to diffs, tests, trac tickets, etc. As it makes it faster to evaluate.
perfect! Thanx, Joachim
Dear release managers, as discussed before, I've done my homework related the bug that I've detected, which is described in ticket #5135: https://svn.boost.org/trac/boost/ticket/5135. See details below. 2011/1/27 Joachim Faulhaber <afojgo@googlemail.com>:
2011/1/27 Rene Rivera <grafikrobot@gmail.com>:
On 1/27/2011 10:48 AM, Joachim Faulhaber wrote:
Such last minutes surprises are always not very welcome, I know ... I won't take your decision personal ;)
After a brief talk on IRC.. How about if you..
1. Add a test to show the problem in trunk. Passing with the fix in it of course.
1.1: I've fixed the code (see patchfile) Index: is_interval.hpp =================================================================== --- is_interval.hpp (revision 68546) +++ is_interval.hpp (working copy) @@ -26,7 +26,7 @@ { typedef is_interval<Type> type; BOOST_STATIC_CONSTANT(bool, - value = (interval_bound_type<Type>::value < interval_bounds::undefined)); + value = ((interval_bound_type<Type>::value) < interval_bounds::undefined)); }; @@ -34,7 +34,7 @@ { typedef has_static_bounds<Type> type; BOOST_STATIC_CONSTANT(bool, - value = (interval_bound_type<Type>::value < interval_bounds::dynamic)); + value = ((interval_bound_type<Type>::value) < interval_bounds::dynamic)); }; template <class Type> struct has_dynamic_bounds =================================================================== 1.2 I've added two test to the trunk that test the bug fix: (1.2.1) A minimal test containing the bug and it's fix http://svn.boost.org/svn/boost/trunk/libs/icl/test/fix_include_after_thread_... (1.2.2) A test with includes of ICL-files that caused the error before when preceeded by boost/thread.hpp http://svn.boost.org/svn/boost/trunk/libs/icl/test/fix_icl_after_thread_/fix... The tests ran successfully for 2 nights.
2. Wait for the beta to get done. Has happened tonight.
3. Then you can ask again to make this change after the beta is out. And we'll likely say yes.
I have prepared a merge that does the fix and adds the two new tests. Do I have permission now to commit the merge to the release branch? Best regards, Joachim
On 1/29/2011 12:38 PM, Joachim Faulhaber wrote:
Dear release managers,
as discussed before, I've done my homework related the bug that I've detected, which is described in ticket #5135: https://svn.boost.org/trac/boost/ticket/5135. See details below.
2011/1/27 Joachim Faulhaber<afojgo@googlemail.com>:
2011/1/27 Rene Rivera<grafikrobot@gmail.com>:
On 1/27/2011 10:48 AM, Joachim Faulhaber wrote:
Such last minutes surprises are always not very welcome, I know ... I won't take your decision personal ;)
After a brief talk on IRC.. How about if you..
1. Add a test to show the problem in trunk. Passing with the fix in it of course.
1.1: I've fixed the code (see patchfile) Index: is_interval.hpp =================================================================== --- is_interval.hpp (revision 68546) +++ is_interval.hpp (working copy) @@ -26,7 +26,7 @@ { typedef is_interval<Type> type; BOOST_STATIC_CONSTANT(bool, - value = (interval_bound_type<Type>::value< interval_bounds::undefined)); + value = ((interval_bound_type<Type>::value)< interval_bounds::undefined)); };
@@ -34,7 +34,7 @@ { typedef has_static_bounds<Type> type; BOOST_STATIC_CONSTANT(bool, - value = (interval_bound_type<Type>::value< interval_bounds::dynamic)); + value = ((interval_bound_type<Type>::value)< interval_bounds::dynamic)); };
template<class Type> struct has_dynamic_bounds ===================================================================
1.2 I've added two test to the trunk that test the bug fix:
(1.2.1) A minimal test containing the bug and it's fix http://svn.boost.org/svn/boost/trunk/libs/icl/test/fix_include_after_thread_...
(1.2.2) A test with includes of ICL-files that caused the error before when preceeded by boost/thread.hpp http://svn.boost.org/svn/boost/trunk/libs/icl/test/fix_icl_after_thread_/fix...
The tests ran successfully for 2 nights.
2. Wait for the beta to get done. Has happened tonight.
3. Then you can ask again to make this change after the beta is out. And we'll likely say yes.
I have prepared a merge that does the fix and adds the two new tests. Do I have permission now to commit the merge to the release branch?
I'm going to say OK. One worry I have is that some of the release toolsets haven't run that test yet on the trunk :-( But there's nothing you can do about that. And they are the older set of compilers anyway (i.e. msvc8). And thanks for being patient with us :-) PS. It seems some toolset should be marked as N/A as they are failing most of the ICL lib tests. PPS. Yes, I'm breaking my own no-work-in-the-weekends rule :-( -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
2011/1/29 Rene Rivera <grafikrobot@gmail.com>:
On 1/29/2011 12:38 PM, Joachim Faulhaber wrote:
Dear release managers,
as discussed before, I've done my homework related the bug that I've detected, which is described in ticket #5135: https://svn.boost.org/trac/boost/ticket/5135. See details below.
2011/1/27 Joachim Faulhaber<afojgo@googlemail.com>:
2011/1/27 Rene Rivera<grafikrobot@gmail.com>:
On 1/27/2011 10:48 AM, Joachim Faulhaber wrote:
Such last minutes surprises are always not very welcome, I know ... I won't take your decision personal ;)
After a brief talk on IRC.. How about if you..
1. Add a test to show the problem in trunk. Passing with the fix in it of course.
1.1: I've fixed the code (see patchfile) Index: is_interval.hpp =================================================================== --- is_interval.hpp (revision 68546) +++ is_interval.hpp (working copy) @@ -26,7 +26,7 @@ { typedef is_interval<Type> type; BOOST_STATIC_CONSTANT(bool, - value = (interval_bound_type<Type>::value< interval_bounds::undefined)); + value = ((interval_bound_type<Type>::value)< interval_bounds::undefined)); };
@@ -34,7 +34,7 @@ { typedef has_static_bounds<Type> type; BOOST_STATIC_CONSTANT(bool, - value = (interval_bound_type<Type>::value< interval_bounds::dynamic)); + value = ((interval_bound_type<Type>::value)< interval_bounds::dynamic)); };
template<class Type> struct has_dynamic_bounds ===================================================================
1.2 I've added two test to the trunk that test the bug fix:
(1.2.1) A minimal test containing the bug and it's fix
http://svn.boost.org/svn/boost/trunk/libs/icl/test/fix_include_after_thread_...
(1.2.2) A test with includes of ICL-files that caused the error before when preceeded by boost/thread.hpp
http://svn.boost.org/svn/boost/trunk/libs/icl/test/fix_icl_after_thread_/fix...
The tests ran successfully for 2 nights.
2. Wait for the beta to get done.
Has happened tonight.
3. Then you can ask again to make this change after the beta is out. And we'll likely say yes.
I have prepared a merge that does the fix and adds the two new tests. Do I have permission now to commit the merge to the release branch?
I'm going to say OK.
Done!
One worry I have
Don't worry . . . beee happy :)
is that some of the release toolsets haven't run that test yet on the trunk :-( But there's nothing you can do about that. And they are the older set of compilers anyway (i.e. msvc8).
The fix is extremely trivial.
And thanks for being patient with us :-)
It's been a pleasure for me :D
PS. It seems some toolset should be marked as N/A as they are failing most of the ICL lib tests.
You're right. I should do that for sun and borland. Concerning clang I think it's a compiler error, that the clang people should be interested in, so N/A would hide that information.
PPS. Yes, I'm breaking my own no-work-in-the-weekends rule :-(
At least I appreciate that :) Thank you again, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de
This conversation is all hunky dory, but I haven't seen an answer to the original question yet - other than that docs changes are OK to merge.... John.
On 1/27/2011 12:30 PM, John Maddock wrote:
This conversation is all hunky dory, but I haven't seen an answer to the original question yet - other than that docs changes are OK to merge....
Sorry.. Wasn't totally following the start of the thread.. Now that I reread I'm still confused. What are *all* the changes that need to get merged? Scatterly-brain-hampered-ly yours ;-) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
This conversation is all hunky dory, but I haven't seen an answer to the original question yet - other than that docs changes are OK to merge....
Sorry.. Wasn't totally following the start of the thread.. Now that I reread I'm still confused. What are *all* the changes that need to get merged?
Scatterly-brain-hampered-ly yours ;-)
Me too ;-) Here's the diff for the pathscale config, without it pathscale prior to v4 is completely broken: --- ../branches/release/boost/config/select_compiler_config.hpp 2011-01-17 15:59 :34.498000000 +0000 +++ boost/config/select_compiler_config.hpp 2011-01-24 18:05:13.486000000 +0 000 @@ -52,7 +52,7 @@ // Comeau C++ # define BOOST_COMPILER_CONFIG "boost/config/compiler/comeau.hpp" -#elif defined __PATHSCALE__ +#elif defined(__PATHSCALE__) && (__PATHCC__ >= 4) // PathScale EKOPath compiler (has to come before clang and gcc) # define BOOST_COMPILER_CONFIG "boost/config/compiler/pathscale.hpp" Thanks, John.
On 1/28/2011 3:21 AM, John Maddock wrote:
This conversation is all hunky dory, but I haven't seen an answer to the original question yet - other than that docs changes are OK to merge....
Sorry.. Wasn't totally following the start of the thread.. Now that I reread I'm still confused. What are *all* the changes that need to get merged?
Scatterly-brain-hampered-ly yours ;-)
Me too ;-)
Here's the diff for the pathscale config, without it pathscale prior to v4 is completely broken:
--- ../branches/release/boost/config/select_compiler_config.hpp 2011-01-17 15:59 :34.498000000 +0000 +++ boost/config/select_compiler_config.hpp 2011-01-24 18:05:13.486000000 +0 000 @@ -52,7 +52,7 @@ // Comeau C++ # define BOOST_COMPILER_CONFIG "boost/config/compiler/comeau.hpp"
-#elif defined __PATHSCALE__ +#elif defined(__PATHSCALE__) && (__PATHCC__ >= 4) // PathScale EKOPath compiler (has to come before clang and gcc) # define BOOST_COMPILER_CONFIG "boost/config/compiler/pathscale.hpp"
Look OK to me... After the beta is out please feel free to merge that change to release. Of course also tell us when you do it also :-) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
On 27 January 2011 18:30, John Maddock <boost.regex@virgin.net> wrote:
This conversation is all hunky dory, but I haven't seen an answer to the original question yet - other than that docs changes are OK to merge....
I'm not sure what's happening with the beta so I left it for Beman or Eric to answer, but IMO the pathscale patch should certainly go into the final release since it doesn't effect any other compilers, and without it nothing works on Pathscale 3.2. Daniel
participants (7)
-
Beman Dawes -
Daniel James -
Eric Niebler -
Hartmut Kaiser -
Joachim Faulhaber -
John Maddock -
Rene Rivera