On 4/28/2016 5:29 AM, Belcourt, Kenneth wrote:

...

On Apr 27, 2016, at 3:37 PM, Vladimir Prus wrote:

The release candidates for the 1.61.0 release are now available at:

http://boost.cowic.de/rc/boost_1_61_0_rc1.zip http://boost.cowic.de/rc/boost_1_61_0_rc1.7z http://boost.cowic.de/rc/boost_1_61_0_rc1.tar.bz2 http://boost.cowic.de/rc/boost_1_61_0_rc1.tar.gz

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.

Built and ran all status/Jamfile.v2 tests from [graph ... MPI] inclusive, with clang on El Capitan. No obvious issues though there are many test failures in hana and at least one failure in integer, io, iostreams, iterator, lexical_cast, locale, and lockfree.

There’re a fair number of warnings. Checked that various documentation links for the new, and some existing, libraries worked fine.

Thanks for testing! I've done builds on Windows and OSX, and everything appear to build, although I'd say the number of warnings is rather disappointing - seem that some libraries trigger warnings in MPL. Hana is failing across the board - it only passes with 4 toolsets in the matrix (clang-linuxg 3.6 and 3.7, gcc 6.0.1 and 7.0) - it would be nice it expected failures markup were up-to-date. -- Vladimir Prus http://vladimirprus.com

Louis Dionne wrote

Vladimir Prus writes:

...

[...]

Hana is failing across the board - it only passes with 4 toolsets in the matrix (clang-linuxg 3.6 and 3.7, gcc 6.0.1 and 7.0) - it would be nice it expected failures markup were up-to-date.

I tried marking some toolsets as "unusable" in a PR [1] a while ago, but it seems like that didn't work. What am I missing? I would like to rectify the situation, as the current matrix for Hana is not very useful.

Regards, Louis

[1]: https://github.com/boostorg/boost/pull/111

ping I don't mean to harass, but I'm really willing to fix this issue. Louis -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-1-61-0-Release-Candidate-1-tp468573... Sent from the Boost - Dev mailing list archive at Nabble.com.

On 28.04.2016 11:41, Rob Stewart wrote:

On April 27, 2016 5:37:32 PM EDT, Vladimir Prus wrote:

...

The release candidates for the 1.61.0 release are now available

Thanks for your work to create this release, especially given the last minute breakages, etc.

Actually, we all need to thank Rene; the build automation he created was most excellent and allowed to build packages auto-magically. -- Vladimir Prus http://vladimirprus.com

On 29.04.2016 13:45, Carlos Ferreira wrote:

To when can the 1.61 release be expected?

Carlos, This depends on the amount and nature of feedback we'll receive about the release candidate. Did you have a chance to try it? What compiler did you use and what were the results? Thanks, -- Vladimir Prus http://vladimirprus.com

@Vladimir No, I did not tried the RC1 version, but since you are expecting feedback, I will give it a try with the development version of Boost.Fiber (I really want to use this, because it is so similar to Python's asyncio module). I was just asking since the date at the Google Calender was not modified to reflect the current release status. Thank you for the info. Carlos Ferreira On 29 April 2016 at 20:19, Belcourt, Kenneth wrote:

...

On Apr 27, 2016, at 3:37 PM, Vladimir Prus wrote:

The release candidates for the 1.61.0 release are now available at:

http://boost.cowic.de/rc/boost_1_61_0_rc1.tar.gz

...

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.

I built and installed with gcc-4.7.2, gcc-4.9.1, intel-12.1.6, and intel-16.0.2 on RH Linux, everything appears to be fine. Many more warnings with Intel than Gcc.

One issue is that the gcc builds mangle the bin.v2 directory with the compiler version number, for example:

bin.v2/libs/thread/build/gcc-4.9.1/release

whereas the Intel builds do not include the version number. Seems like we should update the intel-linux.jam to behave like gcc does, so we don’t end up with, for example:

bin.v2/libs/mpi/build/intel-linux/release

Not worth holding up the release for this but perhaps we should fix for the next release as it is error prone if you’re not paying close attention and building with multiple different Intel toolsets.

—- Noel

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

-- Carlos Miguel Ferreira Researcher at Telecommunications Institute Aveiro - Portugal Work E-mail - cmf@av.it.pt Skype & GTalk -> carlosmf.pt@gmail.com LinkedIn -> http://www.linkedin.com/in/carlosmferreira

On Apr 30, 2016, at 7:34 AM, Marcel Raad wrote:

Vladimir Prus-4 wrote

...

The release candidates for the 1.61.0 release are now available at:

[...]

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.

I compiled a few projects with it.

Graph is still broken with MSVC 14 as commit 0fc1749bd7b300b0ad7a6ec45eefff5ea9057a0f is missing in master.

Cherry picked this to master and tested on Darwin and Linux, both graph and graph_parallel are fine with this commit.

Vladimir Prus-4 wrote

On 30/04/2016 16:34, Marcel Raad wrote:

...

Signals2 is missing commit db0d3f55cccb2dbd8ab88a146af9100f2fca740b in master and thus doesn't work with Boost.Any and Boost.Variant on MSVC 14 Update 2.

Marcel,

is there an issue for that problem? is there a test that fails on master?

There's no failing test, but there's also no tester running VC 14 Update 2. There are two tickets: https://svn.boost.org/trac/boost/ticket/12110 https://svn.boost.org/trac/boost/ticket/12123 -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-1-61-0-Release-Candidate-1-tp468573... Sent from the Boost - Dev mailing list archive at Nabble.com.

[Vladimir Prus]

Thanks - that sounds like unfortunate situation, and that boost::any can't do much, as its constructor is designed to accept anything.

Can you avoid using 1-tuples internally? 2-tuples aren't affected by this breaking change. STL

[STL]

Can you avoid using 1-tuples internally? 2-tuples aren't affected by this breaking change.

[Vladimir Prus]

Are you suggesting that boost::signals2 specially handles the case of 1 parameter, and starts using 2-tuples in that case? Only Frank can tell how much effort that would be, but it sounds rather intrusive.

I don't know how much work it would be, just that mixing 1-tuples with unconstrained constructors is going to be problematic unless C++17 is significantly reworded. [Frank Mori Hess]

The fixes were just a work-around for a broken compiler

[Vladimir Prus]

I would guess Stephan is in better position to say whether it's indeed broken compiler - from his blog post it sounds like accurate implementation of a broken/suboptimal specification.

As far as I'm aware, VC 2015 Update 2's tuple is a completely accurate implementation of C++17 WP N4582 + LWG 2549's PR (absolutely required for correctness) + LWG 2312's PR (VC has shipped this for years), with the exception of LWG 2485 "get() should be overloaded for const tuple&&" (which was my issue, voted into the WP, just haven't gotten around to implementing it yet). A user recently reported that 1-tuples of UDTs with unconstrained *by-value* constructors can trigger infinite recursion and compiler errors. I analyzed the repro, and it turned out that the infinite recursion is mandated by the current WP Standardese, so I sent a mail to the LWG reflector. (The compiler error appears to be a compiler bug, but if it were fixed, we'd get the infinite recursion AFAICT.) libc++ isn't affected because it has implemented a non-Standard (but probably desirable) constraint for this scenario, which I'm considering. Note that unconstrained by-reference constructors are a different issue. I'm wondering whether we should Standardize explicit tags for disambiguation. In Update 2, I have the (totally internal and undocumented, DON'T use it) ability to tell a tuple, "I am constructing you from exact arguments, perfectly forwarded" or "I am constructing you from another pair/tuple, please unpack its elements". This avoids the 1-tuple problems, which is necessary because our tuple is recursively implemented. If you believe that our tuple isn't following the WP plus the PRs I mentioned, please send me a self-contained repro directly and I'll take a look. If you believe that the WP is defective, please figure out how to fix it. Seriously - there are only so many metaprogrammers in the world, and we need all the help we can get. Thanks, STL

On 06/05/2016 00:44, Frank Mori Hess wrote:

On Thu, May 5, 2016 at 5:10 PM, Vladimir Prus wrote:

...

...

There are two tickets: https://svn.boost.org/trac/boost/ticket/12110 https://svn.boost.org/trac/boost/ticket/12123

Thanks - that sounds like unfortunate situation, and that boost::any can't do much, as its constructor is designed to accept anything.

I've cherry-picked that commit - could you double-check that the master branch of the superproject is now fine?

The commits weren't in master because I made the fix after master was already closed for 1.61. I was waiting for it to re-open after the release. The fixes were just a work-around for a broken compiler, I really don't see why the release process should be bothering with them.

I would guess Stephan is in better position to say whether it's indeed broken compiler - from his blog post it sounds like accurate implementation of a broken/suboptimal specification. Anyway, boost::signals2, boost::any and boost::variant seem like fairly important parts of Boost, there are already two independent bug reports, and having this problem on the most recent version of a popular compiler is somewhat embarrassing. If it can be solved by delaying the release by a day or so, it seems reasonable. Do you see any reason why this commit might explode on master? Thanks, -- Vladimir Prus http://vladimirprus.com

[Frank Mori Hess]

The specification change is the removal of the converting constructor for 1-tuples. The thing is, signals2 never did any converting construction of tuples. It was a straight copy construction of some templated function arguments. The compiler error was using the converting tuple constructor at all.

Can you please demonstrate this with a self-contained, STL-only, Boost-free repro? What you're describing doesn't correspond to the test cases I've seen. (I have the ability to reduce Boost-using repros, but it is very slow - Boost is complicated and I'm not familiar with its internals.) I don't believe there's a bug in our implementation, but if there is, I want to know immediately so I can fix it. Thanks, STL

[Frank Mori Hess]

There is a testcase3.cpp attached to ticket 12110 https://svn.boost.org/trac/boost/ticket/12110 You have to uncomment the foo call.

Ok, this one's different from the repros I saw earlier. Here, VS 2015 Update 2's implementation is correctly implementing the C++17 Working Paper N4582. What's happening is that you have a DoubleHolder with an unconstrained constructor DoubleHolder(const ValueType&). (It really should be constrained to exist only when its body would compile.) Then you construct a tuple<DoubleHolder>. Finally, you pass it to foo() which (after template argument deduction) takes a tuple<DoubleHolder> by value. What is INTENDED is copy construction, from the modifiable lvalue x. There are two other relevant constructors, though. The converting copy constructor turns out to be a red herring - it doesn't participate because of LWG 2549's PR, and even if it did, the plain copy ctor would be preferred (const tuple& beats const tuple<U>&). The one that wins is the perfect forwarding ctor. The change here is that the perfect forwarding ctor is (sometimes) implicit in C++17, to support brace-returning tuples. In this case, it is indeed implicit because DoubleHolder's constructor is implicit. So, it has to be considered when constructing foo()'s parameter from x in main(). This perfect forwarding constructor participates because DoubleHolder claims to be able to accept a tuple<DoubleHolder> (that's the unconstrained bit previously mentioned). And the perfect forwarding ctor wins because it takes (tuple<DoubleHolder>&), which is an exact match and better than the copy ctor's (const tuple<DoubleHolder>&). This is similar to the other bug report that I mentioned, except that your DoubleHolder avoids additional weirdness caused by the UDT constructor taking by value. The root cause is the same: tuple's perfect forwarding ctor can out-compete the copy ctor. I've been informed that libc++, while having recently implemented the WP Standardese, is immune to this issue because they implemented a (non-Standard) constraint to prevent the perfect forwarding ctor from outcompeting here. And I've been informed that libstdc++'s implementation of the WP is equally affected like VC's, although I'm not sure how new of a version (perhaps trunk) is required. I am strongly considering applying libc++'s strategy to VC for Update 3. In general, I am wary of doing anything not mandated by the Standard, especially in something as complicated as tuple, but the disambiguation should be simple to implement and very targeted (I cannot imagine a reason where the perfect forwarding ctor should ever be allowed to outcompete the copy/move ctor). In the meantime, I thought of an additional workaround for Boost. Instead of using 2-tuples which are immune, if you detect when this scenario is about to happen (i.e. trying to copy this kind of 1-tuple), if you manually get<0> the element within, that should avoid the problem of giving whole tuples to types like DoubleHolder. Thanks, STL

On 5/3/16 12:46 AM, Vladimir Prus wrote:

On 02.05.2016 11:07, Murray Cumming wrote:

...

On Do, 2016-04-28 at 00:37 +0300, Vladimir Prus wrote:

...

The release candidates for the 1.61.0 release are now available at:

http://boost.cowic.de/rc/boost_1_61_0_rc1.zip http://boost.cowic.de/rc/boost_1_61_0_rc1.7z http://boost.cowic.de/rc/boost_1_61_0_rc1.tar.bz2 http://boost.cowic.de/rc/boost_1_61_0_rc1.tar.gz [snip]

Thanks.

This is a very minor issue, but I noticed that the boost graph examples are missing a little fix that has been in develop (but not master) since before 1.60 but it didn't get into 1.60 or this 1.61 release candidate: https://github.com/boostorg/graph/commit/63dd92da7247018f3291d48cfe04a5 7e51b48eb0

Isn't example code built as part of a release?

Murray,

I see that Noel has said he'd sync graph after the release, which should fix your immediate concern.

As for examples, no, they are not automatically built at present. This is something that would be good to change, but for 1.62 in the best case.

I'm sure somewhere we have a "tool", git command, script or whatever which can create a report which shows which libraries have differences between develop and master branches in a concise way. So maybe the release procedure should start with a generation and display of this report followed by nagging of developers to get them in sync. Once they're in sync, developers would be admonished not to check into develop until the master is checked. One great thing about git is that it lets me easily create a temporary local branch in which I can store my local changes then merge them into develop as soon as the release ships. To summarize: a) announce intention to ship master b) encourage developers to sync develop to master c) prepare summary report of differences d) review tests on master branch, ship beta, etc. cycle until done. e) ship release, open master and develop for changes. we want to maintain the distinction between master and develop. But during a hopefully short time, they should be in sync. Robert Ramey

On 5/3/16 10:22 AM, Vicente J. Botet Escriba wrote:

Le 03/05/2016 16:56, Robert Ramey a écrit :

...

...

I'm sure somewhere we have a "tool", git command, script or whatever which can create a report which shows which libraries have differences between develop and master branches in a concise way. So maybe the release procedure should start with a generation and display of this report followed by nagging of developers to get them in sync. Once they're in sync, developers would be admonished not to check into develop until the master is checked. One great thing about git is that it lets me easily create a temporary local branch in which I can store my local changes then merge them into develop as soon as the release ships. To summarize:

a) announce intention to ship master b) encourage developers to sync develop to master c) prepare summary report of differences d) review tests on master branch, ship beta, etc. cycle until done. e) ship release, open master and develop for changes.

we want to maintain the distinction between master and develop. But during a hopefully short time, they should be in sync.

When I have to fix a bug I need to commit in develop so that I can check if this is a fix and if there is no regressions.

I'm aware of this and I don't think my proposal conflicts with this. what I want to see is that we avoid the last minute hangups which make for more work. So my proposal would restrict to develop commits to just those which support the release. But maybe there's a better way. Here's a different and maybe better idea. a) generate report of differences between develop and master b) nag authors to get stuff in sync. c) verify status of master tests. d) if there's a couple of last minute changes there would two options: 1) go through develop and merge to master 2) merge to master directly and just watch the master tests. e) send out master beta (note two words!) f) after the thing ships - merge master back into develop for those libraries with last minute changes. maybe there's an even better way. a) generate report of differences between develop and master b) nag authors to get stuff in sync. c) verify status of master tests. d) create a NEW branch - beta 1.162 from the current master e) put "last minute" changes in to this new branch. f) test the beta - hmmm best way to do this. g) after shipment, authors would be responsable for merging from beta back develop. Actually, I like this last scheme a lot. It seems in line with the way git is meant to be used. I've used local branching to very good effect and it's very fast and efficient. The only rub is the beta testing matrix - I'm not sure how that would be implemented. The whole point of all this is make life less taxing for the release managers. So I don't want to make any major change. I'm just hoping we can use our existing tools to better effect. Robert Ramey

Vicente

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

On 07 May 2016, at 17:18, Vladimir Prus wrote:

could you say which 'hacks' you have in mind. It builds out of the box on OSX with system compiler, for sure.

Vladimir, here are the different build options and the corresponding results: $ ./b2 Works correctly out of the box and builds to 'darwin-4.2.1’. $ ./b2 toolset=gcc Fails to build with everything failing due to '/bin/sh: line 1: -ftemplate-depth-128: command not found’. There is probably no value in this working since ‘gcc' is just a symlink to ‘clang’ anyway, I just want to mention it for completeness. $ ./b2 toolset=gcc-4.9 Correctly pickups the compiler but fails to build with - clang: error: unsupported option '—64' - ld: unknown option: -h The ‘clang’ errors result from the assembler files of Boost.Context. The linker errors result from the build system expecting the gcc linker instead of the darwin linker. $ ./b2 toolset=gcc-5 Correctly pickups the compiler but fails for the same reasons as gcc-4.9. The ‘hack’ or workaround for this is to define '#using darwin : 5.3.0 : g++-5 : <linker-type>darwin ;’ in user-config.jam and build with ' ./b2 toolset=darwin-5.3.0’. This is not a big deal it’s just not obvious. Thomas