On Tue, Jul 14, 2015 at 8:10 AM, Oswin Krause < Oswin.Krause@ruhr-uni-bochum.de> wrote:

Hi,

On 2015-07-14 05:54, Marshall Clow wrote:

...

Release candidate files for 1.59.0 beta 1 are available at http://boost.cowic.de/rc/ [1]

As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.

Boost compiles fine, OS Arch Linux, x86_64.

However, i got a regression in my software using boost::spirit::qi

See attached the program (i guess it does not qualify minimal, but i do not have time to trace it further), output of g++/valgrind for boost 1.58 and for 1.59. There seems to be a signed/unsigned comparison issue and valgrind detects a conditional jump that depends on unintialized memory. In my code this showed up as 4 values read from the parsed file have wrong values albeit the 200 or so other values before and after are fine.

Best, Oswin

I found the issue, and issued a pull request to fix it. Joel let me know if you want a test case; a variable currently unitialized (presumably intentionally) would have to be value-initialized to make it reliably catch this particular case (and then it could suppress errors if the float is `0`). Lee

On 7/14/2015 9:24 PM, Deniz Bahadir wrote:

Am 14.07.2015 um 05:54 schrieb Marshall Clow:

...

Release candidate files for 1.59.0 beta 1 are available at http://boost.cowic.de/rc/

As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.

This helps ensure the candidates build OK before we push them out to SourceForge.

The files (and associated md5s) are: MD5 (boost_1_59_0_b1_rc1.7z) = f54a97e5ee7f8e3d04cd9af8396e30f9 MD5 (boost_1_59_0_b1_rc1.tar.bz2) = 9804305aae0c9de9f8cfc02e3de75167 MD5 (boost_1_59_0_b1_rc1.tar.gz) = e584770bd76885c123a0426d24466fe2 MD5 (boost_1_59_0_b1_rc1.zip) = ee34f223aa789a6b3f727cb9480651ed

Thanks!

-- The release managers

These are the results for compiling Boost 1.59.0-beta1-RC1 on Debian 7 (64 bit):

Success for the following compilers and settings: * GCC-4.8 with C++11 * GCC-4.9 with C++11 * GCC-5.1 with C++14 * Clang-3.5 with C++14 and libc++

Failure for the following compilers and settings: * GCC-4.8 with C++11 and preprocessed MPL-Headers (up to 100 elements) * GCC-4.9 with C++11 and preprocessed MPL-Headers (up to 100 elements) * GCC-5.1 with C++14 and preprocessed MPL-Headers (up to 100 elements) * Clang-3.5 with C++14 and preprocessed MPL-Headers (up to 100 elements)

Note1: The MPL-Headers were preprocessed using the scripts in libs/mpl/preprocessed. (See: https://svn.boost.org/trac/boost/ticket/11224 and https://github.com/boostorg/mpl/pull/20 and https://github.com/boostorg/mpl/pull/21)

Note2: See further down for the error-message and the bugfix.

Note3: With the bugfix, everything compiles smoothly!

I used the following Boost.Build command:

<VERBATIM>

b2 -j4 -q --build-dir=/tmp/TEST-Boost \ --build-type=complete \ --layout=versioned \ address-model=64 \ install \ --prefix="/opt/TEST-Boost" \ toolset=${TOOLSET} \ cflags="-fPIC" \ cxxflags="-fPIC -std=${CXX_STD} ${STDLIB}" \ dll-path="/opt/TEST-Boost/lib/x86_64-linux-gnu"

</VERBATIM>

with ${TOOLSET} being one of: gcc-4.8 gcc-4.9 gcc-5 clang-3.5 with ${CXX_STD} being one of: c++11 c++14 with ${CXX_STDLIB} being empty for GCC and for Clang: -stdlib=libc++

Boost.Build prints the following configuration-result:

<VERBATIM>

Performing configuration checks

- 32-bit : no - 64-bit : yes - arm : no - mips1 : no - power : no - sparc : no - x86 : yes - lockfree boost::atomic_flag : yes - has_icu builds : yes warning: Graph library does not contain MPI-based parallel components. note: to enable them, add "using mpi ;" to your user-config.jam - zlib : yes - iconv (libc) : yes - icu : yes - compiler-supports-visibility : yes - compiler-supports-ssse3 : yes - compiler-supports-avx2 : yes - gcc visibility : yes - long double support : yes warning: skipping optional Message Passing Interface (MPI) library. note: to enable MPI support, add "using mpi ;" to user-config.jam. note: to suppress this message, pass "--without-mpi" to bjam. note: otherwise, you can safely ignore this message. - zlib : yes (cached) - zlib : yes (cached) - zlib : yes (cached) - zlib : yes - zlib : yes (cached) - zlib : yes (cached) - zlib : yes (cached) - zlib : yes (cached) - zlib : yes (cached) - zlib : yes (cached) - zlib : yes (cached)

Component configuration:

- atomic : building - chrono : building - container : building - context : building - coroutine : building - date_time : building - exception : building - filesystem : building - graph : building - graph_parallel : building - iostreams : building - locale : building - log : building - math : building - mpi : building - program_options : building - python : building - random : building - regex : building - serialization : building - signals : building - system : building - test : building - thread : building - timer : building - wave : building

</VERBATIM>

The error-messages with preprocessed MPl-headers:

<VERBATIM>

gcc.compile.c++ /home/jenkins/workspace/TEST_Boost_1_59_0_b1_rc1/build/boost/bin.v2/libs/log/build/gcc-5/debug/link-static/log-api-unix/threading-multi/default_formatter_factory.o

In file included from ./boost/mpl/aux_/include_preprocessed.hpp:37:0, from ./boost/mpl/vector.hpp:46, from libs/log/src/default_formatter_factory.cpp:21: ./boost/mpl/aux_/preprocessed/gcc/vector.hpp:1281:15: error: expected template-name before ‘<’ token : vector51< ^ ./boost/mpl/aux_/preprocessed/gcc/vector.hpp:1281:15: error: expected ‘{’ before ‘<’ token ./boost/mpl/aux_/preprocessed/gcc/vector.hpp:1281:15: error: expected unqualified-id before ‘<’ token ./boost/mpl/aux_/preprocessed/gcc/vector.hpp:1313:15: error: expected template-name before ‘<’ token : vector52< ^ ./boost/mpl/aux_/preprocessed/gcc/vector.hpp:1313:15: error: expected ‘{’ before ‘<’ token ./boost/mpl/aux_/preprocessed/gcc/vector.hpp:1313:15: error: expected unqualified-id before ‘<’ token ./boost/mpl/aux_/preprocessed/gcc/vector.hpp:1345:15: error: expected template-name before ‘<’ token : vector53< ^ [...]

</VERBATIM>

The reasons seems to be that "default_formatter_factory.cpp" does not use the original value of BOOST_MPL_LIMIT_VECTOR_SIZE, but instead replaces it with 50, but is not defining BOOST_MPL_CFG_NO_PREPROCESSED_HEADERS.

A working bugfix is to define BOOST_MPL_CFG_NO_PREPROCESSED_HEADERS before undef-ing and re-defining BOOST_MPL_LIMIT_VECTOR_SIZE.

BTW: When compiling with C++11 and C++14 hundreds of warnings will be generated because of deprecated "auto_ptr". I would recommend hiding these warning when compiling with C++11/C++14, because they clutter the entire output. (Fixing the warnings would be preferred, but I am not sure if this is really possible.)

<VERBATIM>

[...] gcc.compile.c++ /home/jenkins/workspace/TEST_Boost_1_59_0_b1_rc1/build/boost/bin.v2/libs/context/build/gcc-5/debug/link-static/threading-multi/posix/stack_traits.o

In file included from ./boost/smart_ptr/shared_ptr.hpp:28:0, from ./boost/shared_ptr.hpp:17, from ./boost/date_time/time_clock.hpp:17, from ./boost/thread/thread_time.hpp:9, from ./boost/thread/lock_types.hpp:18, from ./boost/thread/pthread/thread_data.hpp:12, from ./boost/thread/thread_only.hpp:17, from ./boost/thread/thread.hpp:12, from ./boost/thread.hpp:13, from libs/context/src/posix/stack_traits.cpp:23: ./boost/smart_ptr/detail/shared_count.hpp:396:33: warning: ‘template<class> class std::auto_ptr’ is deprecated [-Wdeprecated-declarations] explicit shared_count( std::auto_ptr<Y> & r ): pi_( new sp_counted_impl_p<Y>( r.get() ) ) ^ In file included from /usr/include/c++/5/memory:81:0, from ./boost/config/no_tr1/memory.hpp:21, from ./boost/smart_ptr/shared_ptr.hpp:23, from ./boost/shared_ptr.hpp:17, from ./boost/date_time/time_clock.hpp:17, from ./boost/thread/thread_time.hpp:9, from ./boost/thread/lock_types.hpp:18, from ./boost/thread/pthread/thread_data.hpp:12, from ./boost/thread/thread_only.hpp:17, from ./boost/thread/thread.hpp:12, from ./boost/thread.hpp:13, from libs/context/src/posix/stack_traits.cpp:23: /usr/include/c++/5/bits/unique_ptr.h:49:28: note: declared here template<typename> class auto_ptr; ^ In file included from ./boost/shared_ptr.hpp:17:0, from ./boost/date_time/time_clock.hpp:17, from ./boost/thread/thread_time.hpp:9, from ./boost/thread/lock_types.hpp:18, from ./boost/thread/pthread/thread_data.hpp:12, from ./boost/thread/thread_only.hpp:17, from ./boost/thread/thread.hpp:12, from ./boost/thread.hpp:13, from libs/context/src/posix/stack_traits.cpp:23: ./boost/smart_ptr/shared_ptr.hpp:249:65: warning: ‘template<class> class std::auto_ptr’ is deprecated [-Wdeprecated-declarations] template< class T, class R > struct sp_enable_if_auto_ptr< std::auto_ptr< T >, R > ^ [...]

</VERBATIM>

The changes in MPL on 'develop' which fixed your bug never was applied to the 'master' branch. I take some responsibility for that as I was the one who discussed with you and approved the fix on 'develop'. As a matter of fact their are quite a few updates to MPL on 'develop' to fix MPL bugs, among which your fix is one of them and Bruno Dutra's fixes are others, which have been extensively regression tested on 'develop' but which were not merged to 'master' for the upcoming release. While I fell asleep regarding this I am not the only one with write access to MPL and in fact the community maintenance team also has write access to MPL and no one there thought of merging MPL 'develop' to 'master' in time for 'master' regression testing and therefore having these fixes be in the upcoming release. Because MPL is so central to everything it seems it is too late to get these fixes into 'master', have the regression tested on 'master' and into the upcoming release at this point.

On July 15, 2015 12:20:40 AM EDT, Gavin Lambert wrote:

On 15/07/2015 14:59, Edward Diener wrote:

...

Because MPL is so central to everything it seems it is too late to get these fixes into 'master', have the regression tested on 'master' and into the upcoming release at this point.

Take this with a grain of salt, since I'm not a library maintainer or release manager, but:

Personally I get put off by making excuses. Take care of it, just get 'er done. This isn't the first time, but it can be the last. Just have to want to expect excellence.

Since it's still at a beta release stage (if I'm understanding correctly), this seems to me like the perfect time to merge bugfixes, especially ones that have already been tested on develop.

Part of the point of having a beta cycle is to discover these accidentally-left-out elements and correct them.

In my view it's far better to delay the release slightly (if that would

even happen in this case, which it might not) than to ship with known bugs for which fixes are already committed. (When fixes are yet to be developed, it's a different story, of course.)

Again, this view might change a little if the fixes are breaking changes, but I presume this is not the case since they're tested on develop. Or it just means a few more fixes might need to be merged as well.

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

On July 15, 2015 10:25:44 AM EDT, Marshall Clow wrote:

On Tue, Jul 14, 2015 at 9:20 PM, Gavin Lambert wrote:

...

On 15/07/2015 14:59, Edward Diener wrote:

...

Because MPL is so central to everything it seems it is too late to get these fixes into 'master', have the regression tested on 'master' and into the upcoming release at this point.

Take this with a grain of salt, since I'm not a library maintainer or release manager, but:

Since it's still at a beta release stage (if I'm understanding correctly), this seems to me like the perfect time to merge bugfixes, especially ones that have already been tested on develop.

Part of the point of having a beta cycle is to discover these accidentally-left-out elements and correct them.

After we ship the beta, before the 1.59.0 release, library maintainers will have time to fix bugs that were found in the beta.

All due respect, but this is a gross mis-characterization of the reported concern. Fixes that are in develop *now* (i.e. before RC) should be merged, or at least staged, then perhaps patched, for consideration. I could be incorrect in how I've observed that issue.

-- Marshall

------------------------------------------------------------------------

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

On Wed, Jul 15, 2015 at 11:21 AM, Robert Ramey wrote:

On 7/14/15 9:20 PM, Gavin Lambert wrote:

...

On 15/07/2015 14:59, Edward Diener wrote:

...

Because MPL is so central to everything it seems it is too late to get these fixes into 'master', have the regression tested on 'master' and into the upcoming release at this point.

Take this with a grain of salt, since I'm not a library maintainer or release manager, but:

Since it's still at a beta release stage (if I'm understanding correctly), this seems to me like the perfect time to merge bugfixes, especially ones that have already been tested on develop.

Part of the point of having a beta cycle is to discover these accidentally-left-out elements and correct them.

In my view it's far better to delay the release slightly (if that would even happen in this case, which it might not) than to ship with known bugs for which fixes are already committed. (When fixes are yet to be developed, it's a different story, of course.)

Again, this view might change a little if the fixes are breaking changes, but I presume this is not the case since they're tested on develop. Or it just means a few more fixes might need to be merged as well.

The problem with this viewpoint is that it fails to recognize the division of responsibility between the release manager and the library maintainer.

Seen as an opportunity, clearly this isn't working. What gives?

The library maintainer is responsible for making changes, pushing them to the develop branch, watching the branch and a short time later, merging develop into master.

The release manager is responsible for generating the release and making the candidates so that any so far undetected bugs/compatibilities are detected before a final release - which he is also responsible for.

You can't hold the release manager for some failure on the part of the library maintainer.

You can't add more duties to the job of library maintainer.

Sooooooo... if one is unhappy with the fact that there are changes on the develop branch which have not yet been rolled into the release, the the person to get after is the library maintainer.

I'm not totally unsympathetic to your plight. But I would suggest that we give library maintainers more of a heads up that the release is comming. Ideally we would send a private email to the official library maintainer. Another thing we could do is run some sort of script that would flag libraries whose develop branch contains unmerged changes. Ideally this would flag libraries who have unmerged changes over a weak old. This would address the source of the problem and I believe shouldn't be all that hard to implement.

Robert Ramey

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

On 7/15/15 2:47 PM, Edward Diener wrote:

The overall problem is that there are many less people willing to actively maintain Boost libraries than there are Boost libraries themselves. The only solution to this simple fact is to have more people willing to be maintainer(s) of Boost libraries which they themselves did not originally author.

FYI, we've been actively working on this and have some new and interesting ideas that we're trying to get implemented - but it's moving very sloooooooooooooowly. Checkout the steering committee list if interested. Robert Ramey