[1.48.0] Schedule heads up
branches/release for 1.48.0 is long since closed for new libraries. October 10: branches/release closed for major code changes. Still open for serious problem fixes and docs changes. October 17: branches/release closed for all library changes except when specific permission given by release manager(s). October 24: Beta target date. Further betas and/or release candidates as feedback dictates. November 7: Release target date View Boost calendar: http://tinyurl.com/4xacpyj --Beman
2011/10/7 Frédéric Bron <frederic.bron@m4x.org>:
As always, review the trunk test results and make sure the changes are stable. See http://beta.boost.org/development/tests/trunk/developer/summary.html Then merge trunk to your local svn working copy of branches/release. See boost-root/tools/release/merge2release.bat and 2release.bat for Windows scripts to do the actual merge. They are really simple, so it should be pretty easy to create POSIX versions if that is what you need. Use the --dry-run option to get a feel, if merging is new to you. Once you've merged to your working copy, take a look at the results, do any local tested you think indicated, then commit. Watch closely over the next few days as the release tests cycle to make sure the tests are passing.
Is it too late?
You have until the 10th. I'm assuming a types trait addition is fairly major. HTH, --Beman
I think it's going to be touch and go whether we can get everything done in time for Beman's deadline - but let's give it a go. To kick things off I've just given you full SVN access. The trick now will be to do the merge without touching anything that shouldn't be touched ;-) Are you happy to the actual merge, if you can't figure it out I can try it here, though I probably don't know any more than you do! HTH, John.
To kick things off I've just given you full SVN access.
OK, thanks. I am getting everything with: $ svn co https://svn.boost.org/boost Can you confirm that it is the right address?
The trick now will be to do the merge without touching anything that shouldn't be touched ;-)
It is not very difficult in fact as I am only adding new files apart from 2 small additions to type_trailts/detail/bool_trait_{un,}def.hpp
Are you happy to the actual merge, if you can't figure it out I can try it here, though I probably don't know any more than you do!
I will try to do it on trunk. Then let's see how the test pass or not. Maybe you can then do the merge to the release branch after that step. Thanks, Frédéric
on Fri Oct 07 2011, Frédéric Bron <frederic.bron-AT-m4x.org> wrote:
It's not. You need https://svn.boost.org/svn/boost ^^^ and you probably want to append "/trunk" to that as well. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
Some investigations after the first regression tests: * good news, all tests pass for: - gcc-4.4 (darwin-4.4) - gcc-4.4 c++0x (darwin-4.4_0x) - gcc-4.2.4 (sandia) - gcc-4.3.4 (sandia) - gcc-4.3.4 (sandia 0x) - gcc-4.4.4 (sandia) - gcc-4.4.4 (sandia 0x) - gcc-4.5.2 (sandia) - gcc-4.6.1 (debian-sid) - gcc-4.6.1 (maxime-gcc 0x) - gcc-4.6.1 (my pc) - intel-linux-11.1 (intel-darwin-11.1) - intel-linux-11.1 (sandia-itanium) - intel-linux-11.1 (sandia) - intel-linux-11.1 (my pc) * bad news, those have failed tests: - pathscale 4.0.8 has_post_increment< bool, bool & > had an invalid value (found 1, expected 0) has_post_increment< bool &, bool & > had an invalid value (found 1, expected 0) means that the following works with patscale: void f(bool&); bool b; f(b++); should not work because b++ is a prvalue which cannot be used as non const reference. -> error of pathscale? - intel-linux-10.0 (on my pc): many tests failed the only compile time error I can see in the log is "error #177: function ... was declared but never referenced" This should be a warning (and is a warning with versions 11 and 12) Note the compile option -Werror - intel-linux-10.1 (sandia): many tests failed same as with intel-linux 10.0: error #177 - intel-linux-12.0 (on my pc): has_post_increment fails: error #751: incrementing a bool value is deprecated The standard (both 2003 and draft 2011) says for bool x: x-- and --x are forbidden (implemented in the type trait extension) x++ and ++x: set x to true but is deprecated! It is funny that if it was deprecated in 2003, it is still deprecated in 2011 and not forbidden... for --, the standard is clear: forbidden with bool. I can easily say that ++ it is forbidden for bool. OK for this? - sun-5.10 (sandia): many failures The tests compile and link but the values found are wrong. This indicates that the technique used to detect the operators do not work with this compiler. - msvc- 9.0 (wm5 stlport5.2 veecoFTC): all tests fail but all other tests fail also so that I would not rely on this one to know if we have issues with msvc So up to now, I do not see any major issue but I still do not have the regression tests with msvc. Frédéric
msvc-10 test results are now shown (thank you John): http://www.boost.org/development/tests/trunk/developer/type_traits.html Same as intel-linux 12: issue with deprecated ++ for bool. I have just pushed a patch to trunk (r74841) which makes has_{pre,post}_increment< bool >::value==false Works for me on gcc-4.6.1 and intel-linux 11.1 and 12.0. Hope everything is fine with msvc. If it is the case, I think it would be ready to merge to branch/release. Frédéric
msvc-10 test results are now shown (thank you John): http://www.boost.org/development/tests/trunk/developer/type_traits.html
Not my doing <shrug>.
Tested with msvc 8, 9 and 10 locally and everything looks cool. I'm in the process of installing Intel's compiler to check with that as well. John.
Thank you KTC!
Tested with msvc 8, 9 and 10 locally and everything looks cool. I'm in the process of installing Intel's compiler to check with that as well.
Great and thanks for this testing. It seems that going to release branch will be possible. Frédéric
FYI, many of the newly added tests are failing on clang as Doug reported in Clang's mailing list. ( http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-October/017842.html ) Douglas Gregor wrote: <snip>
<snip>
TypeTraits: lots of two-phase name lookup failures in the has_* tests
Tests results for type_traits are here: http://www.boost.org/development/tests/trunk/developer/type_traits_.html http://www.boost.org/development/tests/release/developer/type_traits_.html Regards, Michel
Thanks for the pointer.
I have seen that but honestly, I do not know how to improve the situation. I would need to have a clang compiler. I will try to install it on my linux machine but I guess the time to release is now very short. I am of course ready to help if you find something and to push any patch that would not break other compilers (gcc, intel and msvc). Regards, Frédéric
Frédéric Bron wrote:
OK, let's think about <boost/type_traits/has_negate.hpp>. Minimal test case: #include <iostream> #include <boost/type_traits/has_negate.hpp> struct XXX { }; int main (int argc, char* argv[]) { std::cout << boost::has_negate<XXX>::value << std::endl; return 0; } Clang's compilation error: boost/type_traits/detail/has_prefix_operator.hpp:72: error: call to function 'operator-' that is neither visible in the template definition nor found by argument-dependent lookup BOOST_STATIC_CONSTANT(bool, value = (sizeof(::boost::type_traits::yes_type)==sizeof(returns_void((BOOST_TT_TRAIT_OP make<Rhs>(),returns_void_t()))))); The error occurred because no_operator operator BOOST_TT_TRAIT_OP (const any&); is declared too late (line 135 in has_prefix_operator.hpp). Is it possible to move "Step 4" (line 122-135) before "Step 2" (line 51-74)? This removes the compilation errors in has_negate_test.cpp. I think other test failures on clang can be fixed in a similar way. Regards, Michel
Michel Morin wrote:
Follow-up: After fixing detail/has_binary_operator.hpp, has_postfix_operator.hpp and has_prefix_operator.hpp (by moving "Step 4" before "Step 2"), all the tests ran successfully on clang (trunk) both in C++03 and C++11 modes. Regards, Michel
Dear Michel, Thank you very much for your message. At some point I changed something in the implementation and had to reorder the steps in the detail namespace. I did not see that the definition of the detail operator was coming too late but nothing told me the contrary because there was no failure with g++ and intel-linux. Now that you say it, I wonder why it works for other compilers! I have applied the changes and all tests still pass with g++ 4.5.2 and 4.6.1 and intel-linux 11 and 12. So I believe it is safe. Committed to trunk r74924. Can you rerun the test on the trunk? I will then ask for permission to merge to release if everything is fine (I would also wait for new testing with msvc). Frédéric
Hi Frédéric, Thank you for the quick fix! Frédéric Bron wrote:
It's just that two-phase name look-up was not implemented correctly on compilers other than clang ;)
Run successfully on gcc (4.4-4.6) and clang (trunk and Apple clang 2.1) both in C++03 and C++11 modes. Regards, Michel
Run successfully on gcc (4.4-4.6) and clang (trunk and Apple clang 2.1) both in C++03 and C++11 modes.
Good news. Happy to have one more compiler working. As soon as I have results with msvc, I'll ask for merging to branches/release. Regards, Frédéric
Run successfully on gcc (4.4-4.6) and clang (trunk and Apple clang 2.1) both in C++03 and C++11 modes.
Good news. Happy to have one more compiler working. As soon as I have results with msvc, I'll ask for merging to branches/release.
Tested locally with msvc-8,9,10 and Intel-11.1&12.1 and all look OK (as far as type_traits tests go anyway). John.
On 10/12/2011 8:59 AM, Frédéric Bron wrote:
You don't need permission. At least, not until the 17th. So get on it! :-) -- Eric Niebler BoostPro Computing http://www.boostpro.com
I see that branches/release is not very regularly tested on windows. Would it be possible to have more test cycles, at least before a beta? Tests of branches/release for type traits addition give: - msvc 9: all fine. - msvc 10: all fine but some "300 second time limit exceeded". Can we increase the time out or test on a quicker machine? - gcc fine apart from gcc 3.4.6: I can see only warnings but probably because it is compiled with -Werror, they produce an error. I compiled gcc 3.4.6. Then I compiled one of the broken tests without -Werror and it compiled and linked nicely. The program then produced no error. So the code is OK with 3.4.6 but does not compile with -Werror. - clang fails; is there any experienced user of clang that could help? Frédéric
Just noticed that the new traits aren't included from the "include everything" type_traits.hpp. Can you take care of that: provided it won't break anything for old/obsolete compilers? Also I take it that these need SFINAE to work? If so we should document the limitation. Thanks, John.
On Fri, Oct 7, 2011 at 1:16 PM, Olaf van der Spek <ml@vdspek.org> wrote:
There is no reason to delay committing to trunk, even though the deadline for merging major changes to branches/release is Monday. If all goes well, and John is satisfied, then the changes can go in for 1.48.0. If issues come up then the changes shouldn't get merged to branches/release until it opens for 1.49.0. --Beman
The big issue really is how quickly the regression tests cycle, and whether we hit any showstoppers in the new code.
I just realize that msvc is not regularly tested. Right now, this is what I can see on the trunk regression summary: - msvc 8.0 (VC8 jc-bell.com) is dated Sept. 30th. - msvc 9.0 (RW_WinXP_VC) Oct. 6th. - no msvc 10.0 tested. John, you said you was running some local tests with msvc 10.0. Do you have any result? Regards, Frédéric
On 08/10/2011 23:29, Frédéric Bron wrote:
Oh. I used to run it sometimes, and Richard Webb used to run VC10 regularly as well. I think it's more likely some kind of error causes no new result and erasing the old result from the table on trunk for Richard's. (Happens when a blank result is uploaded by the test suite.) I actually started a run yesterday. For some reason it "died" early. Seems like mine wasn't the only one it happened to. A lot are missing but type_traits is on there. I'll try to run it more regularly in the short term at least until 1.48 release. KTC
October 24: Beta target date. Further betas and/or release candidates as feedback dictates.
The web page of 1.48.0 (http://svn.boost.org/svn/boost/branches/release/index.html) says: "This release includes 3 new libraries (Container, Locale and Move) as well as updates to many existing libraries. See Release History for more information." Could the addition of operator type traits be more visible? It seems to me that it is a bit more than an "update to existing library". Could we say for example: "This release includes 3 new libraries (Container, Locale and Move), an extension of the type trait library to operator detection as well as updates to many existing libraries. See Release History for more information." I have a very discontinuous internet connection up to next Sunday so that if you agree on the modification, I would appreciate if someone with commit permissions could push the change before the beta. Regards, Frédéric
2011/10/23 Frédéric Bron <frederic.bron@m4x.org>:
Done. I also added a mention to the website release notes. Let me know if you want to say anything more: http://beta.boost.org/users/history/version_1_48_0.html
Boost..Math for 1.48 as ( at least) Added new series evaluation methods to the cyclic Bessel I, J, K and Y functions. Also taken great care to avoid spurious over and underflow of these functions. Fixes issue #5560 Added an example of using Inverse Chi-Squared distribution for Bayesian statistics, provided by Thomas Mang. Thanks Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com
That list is out of date, full changes for 1.48 Boost.Math are: * Added new series evaluation methods to the cyclic Bessel I, J, K and Y functions. Also taken great care to avoid spurious over and underflow of these functions. Fixes issue #5560 * Added an example of using Inverse Chi-Squared distribution for Bayesian statistics, provided by Thomas Mang. * Added tests to use improved version of lexical_cast which handles C99 nonfinites without using globale facets. * Corrected wrong out-of-bound uniform distribution CDF complement values #5733. * Enabled long double support on OpenBSD (issue #6014). * Changed nextafter and related functions to behave in the same way as other implementations - so that nextafter(+INF, 0) is a finite value (issue #5832). * Changed tuple include configuration to fix issue when using in conjunction with Boost.Tr1 (issue #5934). * Changed class eps_tolerance to behave correctly when both ends of the range are zero (issue #6001). * Fixed missing include guards on prime.hpp (issue #5927). * Removed unused/undocumented constants from constants.hpp (issue #5982). * Fixed missing std:: prefix in nonfinite_num_facets.hpp (issue #5914). * Minor patches for Cray compiler compatibility. Also change log for Boost.Regex is: Fixed issues: #698, #5835, #5958, #5736. Cheers, John.
participants (11)
-
Beman Dawes -
Daniel James -
Dave Abrahams -
Eric Niebler -
Frédéric Bron -
John Maddock -
KTC -
Michel Morin -
Olaf van der Spek -
Paul A. Bristow -
Richard Webb