Request for 1.73 patch release
Dear all, Just prior to the release of boost 1.73, some changes appeared in Asio which use the new c++20 concepts (and concepts-ts) features where available. These changes have introduced breakage in Beast in compilers where concepts are enabled. Examples are gcc=10 and clang10 with -std=c++20. I have pushed a fix to beast/develop to address this, but sadly we only became aware of the problem after the release of boost 1.73.0 I suspect the cause here is a combination of my relatively new appointment as a Beast maintainer and the ground-breaking event which I am sure c++20 will prove to be. I welcome any guidance on preparing or initiating a patch release as I lack the Arcane Knowledge required. For information, here is a link to the commit which fixes the problem: https://github.com/boostorg/beast/pull/1927 And some bug reports that alerted us that somethig was wrong: https://github.com/boostorg/beast/issues/1916 https://github.com/boostorg/beast/issues/1925 -- Richard Hodges hodges.r@gmail.com office: +442032898513 home: +376841522 mobile: +376380212
On Sat, May 2, 2020 at 12:04 PM Richard Hodges wrote:
I welcome any guidance on preparing or initiating a patch release as I lack the Arcane Knowledge required.
For information, here is a link to the commit which fixes the problem: https://github.com/boostorg/beast/pull/1927
Hi Richard, I can help you prepare a Beast patch for Boost 1.73 that we can list on https://www.boost.org/patches/ and also from the 1.73 release notes, but is that what you're asking for? Or are you asking for a 1.73.1 Boost release? Glen
On Sat, May 2, 2020 at 12:19 PM Vinnie Falco <vinnie.falco@gmail.com> wrote:
On Sat, May 2, 2020 at 9:15 AM Glen Fernandes via Boost <boost@lists.boost.org> wrote:
are you asking for a 1.73.1 Boost release?
What are the pros and cons of each option?
Option 1 (providing a patch) is very easy to do. In fact, I would suggest doing it immediately once you've put those changes through your testing and are sure they're ready for users. However, some users don't apply these patches. They just upgrade to official Boost releases. So option 1 wouldn't cover them. Option 2 (a 1.73.1 release) would work for them. Or they would wait until 1.74 a few months from now. A new release is costly - i.e. going through the whole release process (release candidates, testing, etc.) and really should only be reserved for something critical (e.g. Most libraries in Boost 1.73 are largely unusable by many users because of some defect). Glen
On Sat, May 2, 2020 at 9:34 AM Glen Fernandes <glen.fernandes@gmail.com> wrote:
A new release is costly
Understood. The problem is that the Boost 1.73 release as it is currently shipped, has a Beast that does not work with C++20 coroutines. Thus one or more other individuals besides me and Richard should decide if this is important enough to justify the cost of a new release. I can go either way on it. The fixes are stable and well tested. Thanks
Beast patch for the Boost 1.73 release: * https://www.boost.org/patches/ * https://www.boost.org/users/history/version_1_73_0.html * https://www.boost.org/patches/1_73_0/0002-beast-coroutines.patch Glen
On 5/2/20 10:44 AM, Vinnie Falco via Boost wrote:
On Sat, May 2, 2020 at 9:34 AM Glen Fernandes <glen.fernandes@gmail.com> wrote:
A new release is costly
Understood. The problem is that the Boost 1.73 release as it is currently shipped, has a Beast that does not work with C++20 coroutines. Thus one or more other individuals besides me and Richard should decide if this is important enough to justify the cost of a new release. I can go either way on it. The fixes are stable and well tested.
We'll have another release in 2-4 months. I very much doubt that there are many users who are currently using Beast with C++20. And I don't see a huge hardship if those users need to wait a couple of months. I just don't see that a patch is worth all the extra work, including distribution, publicity, and confusion it might cause. Onward !!! don't waste time looking back. better to spend a little more time to tweak the testing/release process so that such a thing can't recurre. Robert Ramey
Thanks
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Thank you all for your help and attention. I have been spending the day investigating the root cause of compilation problems and extensively testing our fix. In summary, I am inclined to de-escalate for now as I have discovered that neither * clang-10 -std=c++20, nor * gcc-10 -std=c++20 will compile any asio program which involves a call to asio::co_spawn, which is fundamental requirement in a coroutine-enabled asio program. What seems to be happening is that when concepts are enabled (which they are in the above compilers) asio is checking the result_of the supplied coroutine. In clang-9 with -fcoroutines-ts, concepts are not enabled, so the check is not made. I thinik I have been told previously by Lewis that it's not possible to take the result_of a coroutine. It's entirely possible that I have misunderstood as coroutine implementation is not yet my domain of expertise. In summary, one of either (Asio && MSVC) || (clang && gcc) are in the wrong. I am not qualified to say which at this stage. I suspect there's a workaround in clang & gcc which will involve using macro definitions to convince asio that concepts are not available when compiled in c++20. It's late for me now but I'll check this train of thought in the morning. R On Sat, 2 May 2020 at 22:11, Robert Ramey via Boost <boost@lists.boost.org> wrote:
On 5/2/20 10:44 AM, Vinnie Falco via Boost wrote:
On Sat, May 2, 2020 at 9:34 AM Glen Fernandes <glen.fernandes@gmail.com> wrote:
A new release is costly
Understood. The problem is that the Boost 1.73 release as it is currently shipped, has a Beast that does not work with C++20 coroutines. Thus one or more other individuals besides me and Richard should decide if this is important enough to justify the cost of a new release. I can go either way on it. The fixes are stable and well tested.
We'll have another release in 2-4 months. I very much doubt that there are many users who are currently using Beast with C++20. And I don't see a huge hardship if those users need to wait a couple of months. I just don't see that a patch is worth all the extra work, including distribution, publicity, and confusion it might cause. Onward !!! don't waste time looking back.
better to spend a little more time to tweak the testing/release process so that such a thing can't recurre.
Robert Ramey
Thanks
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Richard Hodges hodges.r@gmail.com office: +442032898513 home: +376841522 mobile: +376380212
FYI - Boost practice is to prefer bottom posting. On 5/2/20 2:09 PM, Richard Hodges via Boost wrote:
Thank you all for your help and attention.
I have been spending the day investigating the root cause of compilation problems and extensively testing our fix.
In summary, I am inclined to de-escalate for now as I have discovered that neither
* clang-10 -std=c++20, nor * gcc-10 -std=c++20
will compile any asio program which involves a call to asio::co_spawn, which is fundamental requirement in a coroutine-enabled asio program.
What seems to be happening is that when concepts are enabled (which they are in the above compilers) asio is checking the result_of the supplied coroutine.
In clang-9 with -fcoroutines-ts, concepts are not enabled, so the check is not made.
I thinik I have been told previously by Lewis that it's not possible to take the result_of a coroutine. It's entirely possible that I have misunderstood as coroutine implementation is not yet my domain of expertise.
In summary, one of either (Asio && MSVC) || (clang && gcc) are in the wrong.
I am not qualified to say which at this stage.
I suspect there's a workaround in clang & gcc which will involve using macro definitions to convince asio that concepts are not available when compiled in c++20.
It's late for me now but I'll check this train of thought in the morning.
R
On Sat, 2 May 2020 at 22:11, Robert Ramey via Boost <boost@lists.boost.org> wrote:
On 5/2/20 10:44 AM, Vinnie Falco via Boost wrote:
On Sat, May 2, 2020 at 9:34 AM Glen Fernandes <glen.fernandes@gmail.com> wrote:
A new release is costly
Understood. The problem is that the Boost 1.73 release as it is currently shipped, has a Beast that does not work with C++20 coroutines. Thus one or more other individuals besides me and Richard should decide if this is important enough to justify the cost of a new release. I can go either way on it. The fixes are stable and well tested.
We'll have another release in 2-4 months. I very much doubt that there are many users who are currently using Beast with C++20. And I don't see a huge hardship if those users need to wait a couple of months. I just don't see that a patch is worth all the extra work, including distribution, publicity, and confusion it might cause. Onward !!! don't waste time looking back.
better to spend a little more time to tweak the testing/release process so that such a thing can't recurre.
Robert Ramey
Thanks
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 5/2/20 2:41 PM, Robert Ramey via Boost wrote:
FYI - Boost practice is to prefer bottom posting.
On Sat, 2 May 2020 at 23:09, Richard Hodges <hodges.r@gmail.com> wrote:
Thank you all for your help and attention.
I have been spending the day investigating the root cause of compilation problems and extensively testing our fix.
In summary, I am inclined to de-escalate for now as I have discovered that neither
* clang-10 -std=c++20, nor * gcc-10 -std=c++20
will compile any asio program which involves a call to asio::co_spawn, which is fundamental requirement in a coroutine-enabled asio program.
What seems to be happening is that when concepts are enabled (which they are in the above compilers) asio is checking the result_of the supplied coroutine.
In clang-9 with -fcoroutines-ts, concepts are not enabled, so the check is not made.
I thinik I have been told previously by Lewis that it's not possible to take the result_of a coroutine. It's entirely possible that I have misunderstood as coroutine implementation is not yet my domain of expertise.
In summary, one of either (Asio && MSVC) || (clang && gcc) are in the wrong.
I am not qualified to say which at this stage.
I suspect there's a workaround in clang & gcc which will involve using macro definitions to convince asio that concepts are not available when compiled in c++20.
Confirmed: adding -DBOOST_ASIO_DISABLE_CONCEPTS to the command line options of clang-10 allows compilation.
It's late for me now but I'll check this train of thought in the morning.
R
On Sat, 2 May 2020 at 22:11, Robert Ramey via Boost <boost@lists.boost.org> wrote:
On 5/2/20 10:44 AM, Vinnie Falco via Boost wrote:
On Sat, May 2, 2020 at 9:34 AM Glen Fernandes <glen.fernandes@gmail.com> wrote:
A new release is costly
Understood. The problem is that the Boost 1.73 release as it is currently shipped, has a Beast that does not work with C++20 coroutines. Thus one or more other individuals besides me and Richard should decide if this is important enough to justify the cost of a new release. I can go either way on it. The fixes are stable and well tested.
We'll have another release in 2-4 months. I very much doubt that there are many users who are currently using Beast with C++20. And I don't see a huge hardship if those users need to wait a couple of months. I just don't see that a patch is worth all the extra work, including distribution, publicity, and confusion it might cause. Onward !!! don't waste time looking back.
better to spend a little more time to tweak the testing/release process so that such a thing can't recurre.
Robert Ramey
Thanks
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Richard Hodges hodges.r@gmail.com office: +442032898513 home: +376841522 mobile: +376380212
-- Richard Hodges hodges.r@gmail.com office: +442032898513 home: +376841522 mobile: +376380212
Just for clarification, GCC 9 supports concepts through the -fconcepts compiler flag which is how I ran into this problem. On 5/2/20 4:10 PM, Robert Ramey via Boost wrote:
On 5/2/20 10:44 AM, Vinnie Falco via Boost wrote:
On Sat, May 2, 2020 at 9:34 AM Glen Fernandes <glen.fernandes@gmail.com> wrote:
A new release is costly
Understood. The problem is that the Boost 1.73 release as it is currently shipped, has a Beast that does not work with C++20 coroutines. Thus one or more other individuals besides me and Richard should decide if this is important enough to justify the cost of a new release. I can go either way on it. The fixes are stable and well tested.
We'll have another release in 2-4 months. I very much doubt that there are many users who are currently using Beast with C++20. And I don't see a huge hardship if those users need to wait a couple of months. I just don't see that a patch is worth all the extra work, including distribution, publicity, and confusion it might cause. Onward !!! don't waste time looking back.
better to spend a little more time to tweak the testing/release process so that such a thing can't recurre.
Robert Ramey
Thanks
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 5/2/20 10:10 PM, Robert Ramey via Boost wrote:
We'll have another release in 2-4 months. I very much doubt that there are many users who are currently using Beast with C++20. And I don't see a huge hardship if those users need to wait a couple of months. I just don't see that a patch is worth all the extra work, including distribution, publicity, and confusion it might cause. Onward !!! don't waste time looking back.
FWIW, Linux distros would pick up the patch themselves, as well as anyone that is affected, when needed. So as long as it's a known issue after release, it's not a problem just to have it listed as an errata or a known issue with a patch. No need for point release if almost everything else works as advertised. Best, Adam
participants (6)
-
Adam Majer -
David P. Riedel -
Glen Fernandes -
Richard Hodges -
Robert Ramey -
Vinnie Falco