Lets do 1.70.1 WHO IS WITH ME!!!

older
b2 --layout=versioned compiler tag...

Vinnie Falco

4 May 2019 4 May '19

10:36 p.m.

A crashing defect in Beast was discovered shortly after release: https://github.com/boostorg/beast/issues/1599 It happens under high load when things happen at just the right time (or wrong time depending on how you look at it). It *will* eventually happen to any long-lived connection that sees enough traffic and timeouts. The fix is trivial: https://github.com/vinniefalco/beast/commit/8620439f8e38db62713cff55a428bf8b... Thanks to the detailed report we were able to write a unit test which reproduces it reliably. Is this worth putting up a 1.70.1 for? The timeout feature is new in 1.70 and it is rather a shame that people might not be able to use it because of a defect. Regards

Show replies by date

James E. King III

5 May 5 May

1:49 a.m.

On Sat, May 4, 2019 at 6:37 PM Vinnie Falco via Boost wrote:

...

A crashing defect in Beast was discovered shortly after release:

https://github.com/boostorg/beast/issues/1599

It happens under high load when things happen at just the right time (or wrong time depending on how you look at it). It *will* eventually happen to any long-lived connection that sees enough traffic and timeouts. The fix is trivial:

https://github.com/vinniefalco/beast/commit/8620439f8e38db62713cff55a428bf8b...

Thanks to the detailed report we were able to write a unit test which reproduces it reliably.

Is this worth putting up a 1.70.1 for? The timeout feature is new in 1.70 and it is rather a shame that people might not be able to use it because of a defect.

Boost releases are quite expensive and happen on a regular schedule. Releases happen every 4 months and people can get the latest from develop with the fix. That should be sufficient. - Jim

Joshua Marshall

2:19 a.m.

Why are releases expensive? On Sat, May 4, 2019, 21:49 James E. King III via Boost < boost@lists.boost.org> wrote:

...

On Sat, May 4, 2019 at 6:37 PM Vinnie Falco via Boost wrote:

...
A crashing defect in Beast was discovered shortly after release:

https://github.com/boostorg/beast/issues/1599

It happens under high load when things happen at just the right time (or wrong time depending on how you look at it). It *will* eventually happen to any long-lived connection that sees enough traffic and timeouts. The fix is trivial:

<

https://github.com/vinniefalco/beast/commit/8620439f8e38db62713cff55a428bf8b...

...
Thanks to the detailed report we were able to write a unit test which reproduces it reliably.

Is this worth putting up a 1.70.1 for? The timeout feature is new in 1.70 and it is rather a shame that people might not be able to use it because of a defect.

Boost releases are quite expensive and happen on a regular schedule. Releases happen every 4 months and people can get the latest from develop with the fix. That should be sufficient.

- Jim

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

James E. King III

2:49 a.m.

On Sat, May 4, 2019 at 10:20 PM Joshua Marshall via Boost wrote:

...

Why are releases expensive?

They are expensive due to the downstream effects to all the packaging and build tools that have to support it.

Vinnie Falco

3:04 a.m.

On Sat, May 4, 2019 at 7:50 PM James E. King III via Boost wrote:

...

They are expensive due to the downstream effects to all the packaging and build tools that have to support it.

Oh! Umm...well, I wasn't imagining that the entire world would be updating to the newer version. I thought there would just be a 1.70.1 archive that users could optionally install only if they need the fix. Thanks

Andrey Semashev

1:01 p.m.

On 5/5/19 5:49 AM, James E. King III via Boost wrote:

...

On Sat, May 4, 2019 at 10:20 PM Joshua Marshall via Boost wrote:

...
Why are releases expensive?

They are expensive due to the downstream effects to all the packaging and build tools that have to support it.

Not only that, they are expensive on Boost release managers' side as well. As I understand, there is a considerable amount of work in preparing and testing a release.

Richard Hodges

9:11 a.m.

On Sun, 5 May 2019 at 03:49, James E. King III via Boost < boost@lists.boost.org> wrote:

...

On Sat, May 4, 2019 at 6:37 PM Vinnie Falco via Boost wrote:

...
A crashing defect in Beast was discovered shortly after release:

https://github.com/boostorg/beast/issues/1599

It happens under high load when things happen at just the right time (or wrong time depending on how you look at it). It *will* eventually happen to any long-lived connection that sees enough traffic and timeouts. The fix is trivial:

<

https://github.com/vinniefalco/beast/commit/8620439f8e38db62713cff55a428bf8b...

...
Thanks to the detailed report we were able to write a unit test which reproduces it reliably.

Is this worth putting up a 1.70.1 for? The timeout feature is new in 1.70 and it is rather a shame that people might not be able to use it because of a defect.

Boost releases are quite expensive and happen on a regular schedule. Releases happen every 4 months and people can get the latest from develop with the fix. That should be sufficient.

I'm quite keen to recompile my production systems against the latest asio/beast changes in boost 1.70 as they are extremely pertinent to my domain. If there is any way of getting a patch release out into the wild as a complete tar.gz that would be helpful as it would mean I don't have to redefine my build environment in terms of git submodules. I am pretty sure I've seen patch releases of boost before, or a I mistaken? If it's not possible, would anyone be able to advise on what is the official cmake-compatible git repo for boost, and which tag/commit I should use? Just want to add my vote of thanks to Vinnie and Damien (not to mention Chris Kholoff!) whose tireless work on async i/o-based web protocols in c++ has made my working life a joy.

...

From the bottom of my heart guys, you are awesome.

...

- Jim

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

-- Richard Hodges hodges.r@gmail.com office: +442032898513 home: +376841522 mobile: +376380212

Vinnie Falco

12:06 p.m.

On Sun, May 5, 2019 at 2:12 AM Richard Hodges via Boost wrote:

...

If there is any way of getting a patch release out into the wild as a complete tar.gz that would be helpful as it would mean I don't have to redefine my build environment in terms of git submodules.

Changes to the Beast in Boost 1.70 for the fix can be obtained from this branch: https://github.com/boostorg/beast/commits/v248-hf1 you can retrieve a patch from github using this URI format: https://github.com/boostorg/beast/compare/boost-1.70.0...v248-hf1.diff The fix has also been merged to master and develop: https://github.com/boostorg/beast/commits/master Thanks

Prashant Thakre

12:56 p.m.

On Sun, 5 May 2019 at 17:36, Vinnie Falco via Boost wrote:

...

On Sun, May 5, 2019 at 2:12 AM Richard Hodges via Boost wrote:

...
If there is any way of getting a patch release out into the wild as a complete tar.gz that would be helpful as it would mean I don't have to redefine my build environment in terms of git submodules.

Changes to the Beast in Boost 1.70 for the fix can be obtained from this branch:

https://github.com/boostorg/beast/commits/v248-hf1

you can retrieve a patch from github using this URI format:

https://github.com/boostorg/beast/compare/boost-1.70.0...v248-hf1.diff

The fix has also been merged to master and develop:

https://github.com/boostorg/beast/commits/master

Thanks

Hi, Is the patch meant for WebSocket implementation only? Just moved to 1_70_0 recently. Regards, Prashant

...

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

-- regards, Prashant Thakre

Vinnie Falco

6:18 p.m.

On Sun, May 5, 2019 at 5:56 AM Prashant Thakre via Boost wrote:

...

Is the patch meant for WebSocket implementation only? Just moved to 1_70_0 recently.

Yes

Andrey Semashev

12:57 p.m.

On 5/5/19 3:06 PM, Vinnie Falco via Boost wrote:

...

On Sun, May 5, 2019 at 2:12 AM Richard Hodges via Boost wrote:

...
If there is any way of getting a patch release out into the wild as a complete tar.gz that would be helpful as it would mean I don't have to redefine my build environment in terms of git submodules.

Changes to the Beast in Boost 1.70 for the fix can be obtained from this branch:

https://github.com/boostorg/beast/commits/v248-hf1

you can retrieve a patch from github using this URI format:

https://github.com/boostorg/beast/compare/boost-1.70.0...v248-hf1.diff

The fix has also been merged to master and develop:

https://github.com/boostorg/beast/commits/master

One thing you could do to aid 1.70 users is to create a PR for 1.70 release notes[1], adding a note about the problem with a link to the patch/commit that fixes it. You can look in past release notes for examples, we've had multiple occasions of such notes. [1]: https://github.com/boostorg/website/blob/master/feed/history/boost_1_70_0.qb...

Vinnie Falco

6:25 p.m.

On Sun, May 5, 2019 at 5:58 AM Andrey Semashev via Boost wrote:

...

create a PR for 1.70 release notes[1]

Here: https://github.com/boostorg/website/pull/422 Thanks

Andrey Semashev

6 May 6 May

11:24 a.m.

On 5/5/19 9:25 PM, Vinnie Falco wrote:

...

On Sun, May 5, 2019 at 5:58 AM Andrey Semashev via Boost wrote:

...
create a PR for 1.70 release notes[1]

Here:

https://github.com/boostorg/website/pull/422

This is not what I suggested.

Vinnie Falco

5:46 p.m.

On Mon, May 6, 2019 at 4:24 AM Andrey Semashev via Boost wrote:

...

...
https://github.com/boostorg/website/pull/422

This is not what I suggested.

Please look again Thanks

Vinnie Falco

7:05 p.m.

Nevermind, this is turning out to be more trouble than it is worth and I am dealing with other things right now so please disregard. On Mon, May 6, 2019 at 10:46 AM Vinnie Falco wrote:

...

On Mon, May 6, 2019 at 4:24 AM Andrey Semashev via Boost wrote:

...
...
https://github.com/boostorg/website/pull/422

This is not what I suggested.

Please look again

Thanks

-- Regards, Vinnie Follow me on GitHub: https://github.com/vinniefalco

Robert Ramey

5 May 5 May

2:38 a.m.

On 5/4/19 3:36 PM, Vinnie Falco via Boost wrote:

...

A crashing defect in Beast was discovered shortly after release:

https://github.com/boostorg/beast/issues/1599

It happens under high load when things happen at just the right time (or wrong time depending on how you look at it). It *will* eventually happen to any long-lived connection that sees enough traffic and timeouts. The fix is trivial:

https://github.com/vinniefalco/beast/commit/8620439f8e38db62713cff55a428bf8b...

Thanks to the detailed report we were able to write a unit test which reproduces it reliably.

Is this worth putting up a 1.70.1 for? The timeout feature is new in 1.70 and it is rather a shame that people might not be able to use it because of a defect.

Perhaps this is a good opportunity to craft and test a procedure for a single library update. This would be one small step in the direction of boost modularization. In theory this shouldn't be actually very hard if one can presume that the user has 1.70 installed. This is a pretty solid assumption since otherwise he wouldn't need to update anyway. Robert Ramey

James E. King III

3 a.m.

On Sat, May 4, 2019 at 10:39 PM Robert Ramey via Boost wrote:

...

Perhaps this is a good opportunity to craft and test a procedure for a single library update.

Isn't this called "git pull" and build? If someone is going to take a patch of boost today, they can reasonably expect to have to build. What other little fixes are going to get slipped into 1.70.1? Surely there are other candidates too. I haven't seen a comprehensive plan put forth that would lead to modularization. Wouldn't that have to start with selection of a package manager capable of dealing with the versioning requirements and pre-built dependency acquisition? For example if I want to use boostorg/graph version 1.68.0, how do I tell something to download everything I need for that, repeatably, efficiently (see: don't re-download it if I have it and all the deps), for every build I do? How do I tell my build system where to find those things that were downloaded? Once that package manager is selected and each boost module declares the dependency and version requirements it has, and all boost modules moved into this system, then boost modules could update at will and there would be no more need for a monolithic release. Until then, we have 3 releases a year, which is really quite good for something this complex. - Jim

Robert Ramey

3:49 a.m.

On 5/4/19 8:00 PM, James E. King III via Boost wrote:

...

On Sat, May 4, 2019 at 10:39 PM Robert Ramey via Boost wrote:

...
Perhaps this is a good opportunity to craft and test a procedure for a single library update.

Isn't this called "git pull" and build? If someone is going to take a patch of boost today, they can reasonably expect to have to build.

Right. That's all a single library update is. There might be a b2 headers or something, but that would require a version of b2, that the user has to pull then compile that etc.... But it SHOULD be simple for any user to as downloading from github one particular library into one's source tree and if library is header only just rebuild his project. It should be about 2 minutes. BUT, since we we don't have the the header structure the same in github as we have in one the user's disk, extra effort has to be made. This is what we somehow have to address.

...

What other little fixes are going to get slipped into 1.70.1? Surely there are other candidates too.

So boost 1.70.1 is a bad idea. Just focust on boost 1.71

...

I haven't seen a comprehensive plan put forth that would lead to modularization.

Right - that's what have haven't been able to reach a concensus on. Actually, it's worse. We haven't been able to reach a concensus on how to reach a concensus on this.

...

Wouldn't that have to start with selection of a package manager capable of dealing with the versioning requirements and pre-built dependency acquisition?

In Vinnie's case, all that is done' He's per-determined that downloading a patch to any boost 1.70 installation is guarenteed to work. For example ... Right - but that example is not what I'm addressing here. I'm addressing Vinnie's case. And of course other cases the future because ... there is always someone.

...

Until then, we have 3 releases a year, which is really quite good for something this complex.

Right - I don't see that changing for quite a while. Robert Ramey BTW - I want to explicitly acknowledge the tremendous work you've done on making big improvements in Boost library quality.

...

- Jim

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

Rene Rivera

4:46 a.m.

On Sat, May 4, 2019 at 10:00 PM James E. King III via Boost < boost@lists.boost.org> wrote:

...

I haven't seen a comprehensive plan put forth that would lead to modularization.

Some of us have worked for years in that direction, without the need for a formal plan. We're actually rather close.

...

Wouldn't that have to start with selection of a package manager capable of dealing with the versioning requirements and pre-built dependency acquisition?

No. There is no need to select that. We only need to make it possible and easy for existing package managers to consume Boost in modular parts. There are plenty of existing package managers and people to create appropriate packages.

...

For example if I want to use boostorg/graph version 1.68.0, how do I tell something to download everything I need for that, repeatably, efficiently (see: don't re-download it if I have it and all the deps), for every build I do? How do I tell my build system where to find those things that were downloaded?

You read the documentation for the package manager of your choice that has Boost packages available.

...

Once that package manager is selected and each boost module declares the dependency and version requirements it has, and all boost modules moved into this system, then boost modules could update at will and there would be no more need for a monolithic release.

Ah, yes, that would be a tangential problem. What kind of cross-version compatibility you want to offer. Do you even test cross-versions? Oh, so many questions in that can of worms :-)

...

Until then, we have 3 releases a year, which is really quite good for something this complex.

You can still have only 3 releases with modular libraries. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net

James E. King III

4:26 p.m.

On Sun, May 5, 2019 at 12:46 AM Rene Rivera wrote:

...

On Sat, May 4, 2019 at 10:00 PM James E. King III via Boost wrote:

...
I haven't seen a comprehensive plan put forth that would lead to modularization.

Some of us have worked for years in that direction, without the need for a formal plan. We're actually rather close.

To that end I started a discussion on Conan's github issues page to figure out how one could use it purely to download boost modules (and all their dependencies), and more importantly how to then use the downloaded bits with any build system (i.e. should be able to ask conan, "for this recipe, what are the include paths?", "for this recipe, what are the library paths and libraries?"). I'm not particularly interested in using conan as a build and packaging system for my own projects which already have their own, but to be able to leverage conan to download pre-built boost moduls and only the ones I need would be pretty cool. The ability to allow other build systems to run commands that download and find paths of dependencies would be really useful but I'm not sure conan does that. Another concern I have is that dependencies all seem to be manually managed right now for all of these third party systems. The recent cmake check-ins I have seen all have a manual set of module dependencies and I pushed back on this. Conan has their own list of dependencies; cmake has its own list of dependencies. I believe they all get their info from boostdep right now, which is good, but I think it is a manual consumption process for each release. Each boost repository should be able to automatically advertise the compile/runtime dependencies as well as the test-only dependencies. I slapped something together quickly this morning that helps visualize that (https://github.com/jeking3/boost-deptree), perhaps some of that type of logic could find its way into b2 so that b2 could automatically manage direct compile/runtime dependencies and direct test dependencies inside each project's meta directory? Then cmake, conan, and whatever else would be able to programmatically consume that data out of the repository it is trying to package or deliver. - JIm

2015

Age (days ago)

2017

Last active (days ago)

List overview

Download

19 comments

8 participants

participants (8)

Andrey Semashev
James E. King III
Joshua Marshall
Prashant Thakre
Rene Rivera
Richard Hodges
Robert Ramey
Vinnie Falco