- Boost - lists.preview.boost.org

Seeking Endorsement for Charconv
by Matt Borland 22 Sep '23

22 Sep '23

Hello, At the beginning of the summer I solicited feedback for an in-progress C++11 implementation of <charconv> for a proposal to Boost. The library is now complete with that feedback incorporated, and I am seeking endorsement. Should the library receive endorsement Chris Kormanyos has volunteered to serve as the review manager. What is Charconv? It is a character conversion library that converts a character sequence into a number (from_chars) or converts a number into a character sequence (to_chars). This is similar to strtod and printf with two key differences. First and most important is a roundtrip guarantee. That is a number converted into a character sequence, and then back into a number will be identical to the starting value. Second, you can easily specify an input/output format with a chars_format argument, and also provide a target precision. Lastly, instead of requiring recent compilers (e.g. GCC 11, and MSVC 19.24) and C++17 to get full support for <charconv> you can have it now with GCC 5, Clang 3.7, or MSVC 19.00 and C++11. What types are supported? All builtin integers plus __int128 and unsigned __int128. For floating point types all built-in IEEE 754 compliant types to include those provided in C++23’s <stdfloat>, and __float128. A notable example of a non-IEEE 754 compliant built-in type is ibm128 provided on older versions of PowerPC. How do I use the library? The repo can be found here: https://github.com/cppalliance/charconv. Since this is a compiled library, directions for use with b2, vcpkg, and conan are provided. What is the performance like? I added a table of benchmarks (https://master.charconv.cpp.al/#ref_benchmarks) that compares this implementation to the performance of: STL (printf, strtoX, and <charconv>), Boost.Lexical_Cast, Boost.Spirit, and libdouble-conversion. In summary we meet or exceed the performance of GCC and MSVC <charconv>, and exceed by up to several multiples the performance of all the other libraries. Thanks to Stephan T. Lavavej for providing his benchmarking file in the original discussion. Why is this not going into Boost.Compat? The size of this library exceeds the scope of Boost.Compat. Compat is designed for headers that can be implemented in a small amount of code. <latch> with implementation, testing and documentation was ~350 LOC while Charconv is ~29,500. Please let me know if you have any questions or issues with the library. Thanks, Matt Borland —- C++ Alliance Staff Engineer

5 7

Async review scheduled for September 22, 2023 - October 2, 2023
by Mateusz Loskot 08 Sep '23

08 Sep '23

Hi, Following request from Nial and Klemens, we have scheduled new round of the Async review for September 22, 2023 - October 2, 2023 https://www.boost.org/community/review_schedule.html Best regards, -- Mateusz Loskot, on behalf of the Review Wizards

3 2

Presenting BoostServerTech chat
by Ruben Perez 07 Sep '23

07 Sep '23

Hi all, I'm Ruben, the author of Boost.MySQL, and I want to present (and maybe get some feedback about) a project I'm developing to showcase how to do async stuff with Boost server-side. This started because I want to write a connection_pool class for MySQL. It's a complex feature with a lot of trade-offs, and I wish I had more field experience to guide me when making the required decisions. We currently have great libs for async networking (Asio, Beast, Redis, MySQL). They've got examples and docs, but I think they sometimes fall short. Often users get lost since setting up an async server is not trivial, and we offer a lot of flexibility that can sometimes stun newcomers. So I've decided to blend these two needs together and create a project that allows Boost authors to try new things in a realistic environment, while demonstrating to users how they can use Boost to build an app. (Note: this is **not** a Boost library, and will never be). Code: https://github.com/anarthal/servertech-chat/ Docs: https://anarthal.github.io/servertech-chat/ Live demo: http://13.48.215.34/ It's still a work-in-progress. Although I've implemented some features, I've tried to focus on the skeleton, getting testing, deployments and C++ best practices in place. I plan on adding more stuff in the future, like showing how you can call 3rd party REST APIs using Boost. One cool feature is that, if you have an AWS account, you can fork the repo and get a live server in minutes (see https://anarthal.github.io/servertech-chat/03-fork-modify-deploy.html) I actually envision this as a series of projects, showcasing different applications and needs. I originally wrote this document (https://docs.google.com/document/d/1ZQrod1crs8EaNLLqSYIRMacwR3Rv0hC5l-gfL-j…) describing how I saw it. If any other author wants to step forward and create their own ServerTech application, please let me know. I'd like to have some (hopefully constructive) feedback from you guys. I'd thank you if you give the live demo a try. And if someone's interested, there's a ton of work to do, so let me know. Note: if you've scanned through the code and you're asking "where is the connection_pool" - nowhere yet, that's still to come. Thanks, Ruben.

5 8

Boost Solvers Library
by Pascal Kesseli 03 Sep '23

03 Sep '23

In the course of my research in static program analysis, I have been a contributor to the Bounded Model Checker for C (CBMC - https://github.com/diffblue/cbmc) for quite some time now. Projects like these map static analysis problems to a variety of back-end solvers like SAT, SMT, QBF, etc. What always surprised me is how often tools like CBMC have to come up with an intermediate C++ layer for the various back-end solvers like MiniSAT or Glucose (see https://github.com/diffblue/cbmc/tree/develop/src/solvers/sat) For this reason I am considering to create a unified C++ wrapper for these different solvers, with an initial focus on SAT. I intend to include a naive default DPLL implementation, but the real value for such a library would stem from making the aforementioned third party engines easily accessible. I was wondering whether this would be a fit for a Boost library, but I am uncertain whether: A) There is even interest in the community for this or B) The scope of the library with inherent dependencies on external SAT solvers fits the Boost format Thus I thought I'd drop this message in the mailing list to ask what people think. Thanks,

1 0

[boost.async] Some feedback
by Andrzej Krzemienski 29 Aug '23

29 Aug '23

Hi Everyone, I will not be able to write a decent review due to the lack of time (I am now on vacation), but I wanted to share some partial feedback. I am not well familiar with C++ coroutines. I wrote some toy examples of an async TCP echo server in ASIO in the past, to try to learn how coroutines work, but my knowledge is very superficial. I hoped to understand coroutines better from studying Boost.Async's docs. When I discovered Boost some 18 years ago, I found it useful not only because of the high quality libraries but also because of extraordinary documentation that often provided a very deep insight into the problem domain, a lot of rationale, design goals, and the documentation of engineering trade-offs of different sorts. I do not know how people feel about the importance of documentation nowadays. For me, however, it is the primary focus. I devoted like 10 hours in total for studying the docs and running some toy examples. Because I am not very good at C++ coroutines, you get a typical, I would think, feedback from a user that wants to learn how coroutines are used, what problems they solve, and what problems they do not solve. Regarding the *really* asynchronous part, promises and tasks, I guess they would work fine. By "really asynchronous" I mean the situations where a coroutine is resumed by events unpredictable by the programmer (when data arrives, when certain time passes, when an external connection is requested). I also guess that when Marcelo and Ruben say they successfully integrated Boost.Async into their projects, they meant types `task` and `promise`, rather than `generator`. My investigation was interrupted by `generator` which I cannot understand or appreciate. It feels like a type quite separate from the rest of the library. For instance, through all the simple examples in the docs, only the examples for `generator` never use the trick with `co_await async::this_coro::executor`. I needed to ask a lot of questions, and even though Klemens is very responsive and very helpful, I still do not understand how `async::generator` solves real problems. This may indicate that either I am a very slow learner, or that there is something wrong with the design of `generator`. But even if it is the former, I think I represent the average user of this library. When I try to use a C+23 std::generator, the usage is intuitive and straightforward to me. I know how to easily yield a sequence of values, and on the caller side how to easily check if I can still obtain the next value from the generator: ``` std::generator<int> seq(int from, int to) { for (int i = from; i <= to; ++i) co_yield i; } int main() { for(int i : seq(1, 4)) std::cout << i << std::endl; } ``` https://godbolt.org/z/PTvz3v4Y6 But when I try what I believe to be an analogous example in Boost.Async, I get an exception: ``` async::generator<int> seq(int from, int to) { for (int i = from; i <= to; ++i) co_yield i; } async::main co_main(int argc, char* argv[]) { auto s = seq(1, 4); while (s) { std::cout << co_await s << std::endl; } } ``` And the docs or examples don't help me understand why this use case doesn't work. The case with the eager generator that can be injected values is even weirder. I think it is wrong. Klemens thinks otherwise, but the docs do not give any convincing example of where and how it could be used. The lack of examples or description can be just that, but it could also indicate that the design for generators is missing something. In this feedback, I am only mentioning generators, because this is the place where I stuck in my review. I guess that other parts of the library do not have this problem. I am pretty sure that this library will be accepted into Boost at some point. It addresses a real need (although not necessarily the generators), and the feedback from Ruben and Marcelo are strong testimony to the quality of the library. But at this point, I am not comfortable with adding a library whose design for generators cannot be explained in the docs to the extent that I consider satisfactory. Would this library lose in usability if generators were removed? I know it is not a fair review. I only covered one subject, and my feeling is that it is not the most relevant one. So please consider it as "just feedback" rather than a review. Again, thanks Klemens for writing and sharing this library. I hope that this message does not come across as negative. I want to think that I am contributing to the quality of Boost.Async. Regards, &rzej;

2 2

remez, chebyshev polynomial approximation
by Brian Budge 25 Aug '23

25 Aug '23

Hi folks - I have a couple of questions regarding the math tools for polynomial approximation. Context: I'm interested in making fast math approximations that are also highly accurate. These include standard functions, but also custom fits. I've successfully used the chebyshev_transform and remez tools to make such approximations. However, I know in many cases I could get better results. So my questions are the following: 1. For the remez tool, how could we constrain e.g. odd or even powers of numerator, denominator, or both to zero? This is common in highly accurate trig approximations for example. Looking at the code, I suspect we'd need to change the degrees of freedom for the solver, but I don't know how straightforward it would be to make such a change (or if there are theoretical reasons why this couldn't work with the remez algorithm) 2. Getting accurate results with chebyshev_transform requires the Crenshaw algorithm, which makes these approximations far slower than those I get from the remez tool. Are there a class of polynomials where I could transform these to a standard Horner's or Estrin's scheme in a way that is numerically stable? If so, any pointers to how to do that? Thanks, Brian

2 3

[Async] Try again review
by Niall Douglas 23 Aug '23

23 Aug '23

I received one formal review, and two bits of substantial feedback. My thanks to their authors. I received more formal requests to run the review in September than reviews, so I guess we're going to have to try this review again. Does anybody object to Friday 15th September to Monday 25th of September? Niall

5 11

[boost.async] Some questions
by Andrzej Krzemienski 20 Aug '23

20 Aug '23

Hi Everyone, I would like to thank Klemens for writing and sharing this library. I am sure the community needs a higher level library for asynchronous computations based on C++20 coroutines. Boost.Async addresses the need. I would like to ask a couple of questions to better understand the design goals and the scope of the library. Q1. Is single-threaded-ness the design goal? Or is the plan to enable multi-threaded use cases? There is a GitHub issue ( https://github.com/klemens-morgenstern/async/issues/19) suggesting the latter. Q2. Reading through the docs, I get an impression that Boost.Async is "Either a wrapper over ASIO, or an isolated usage for a generator". They seem like two unrelated worlds. The former requires a hard prerequisite of having a Boost.ASIO library (with Boost version at least 1.82). The latter can hardly be called "asynchronous". Generators, the way I understand them, are perfectly synchronous. Is this impression correct? The following are more remarks regarding the choice of names. Q3. The docs say that `promise` and `task` differ primarily by their level of eagerness. But the names do not seem to reflect this. What is the rationale or the intuition behind those names? R1. I find the name `use_op` uninformative. The examples in documentation suggest that it is an *adapter*: they change the Boost.ASIO interface into the Boost.Async interface. Is that correct? Regards, &rzej;

3 11

[boost.asynch] another generator query
by Andrzej Krzemienski 19 Aug '23

19 Aug '23

Hi Klemens, I have another question regarding the generator. I think the initial examples in the dcs for `generator` are too simplistic, because the caller seems to already know how many times it is allowed to co_await on the Awaitable. I tried it with a loop, where I use the explicit conversion to bool to check when to break the iteration: ``` async::generator<std::string> worker(int limit) { for (int i = 0; i < limit; ++i) { co_yield std::format("--{}--", i); } } async::main co_main(int argc, char* argv[]) { try { auto w = worker(3); while (w) { std::cout << co_await w << std::endl; } } catch (std::exception const& e) { std::cout << "ERR: " << e.what() << std::endl; } } ``` But I am surprised that this construct ends with throwing an exception. Am I doing something wrong? Regards, &rzej;

2 2

[Async] Review of proposed Boost.Async begins
by Niall Douglas 18 Aug '23

18 Aug '23

Dear Boost, It is my great pleasure to announce the beginning of the peer review of proposed Boost.Async, which is hoped to become the most popular way of programming C++ coroutines in future C++. The peer review shall run between Tuesday 8th August and Friday 18th August. Like many of you have found, until now there has been no good standard and easy way of writing C++ coroutine code which works easily with multiple third party codebases and foreign asynchronous design patterns. ASIO’s current coroutine support is tightly coupled to ASIO, and it rejects foreign awaitables. Libunifex is dense to master and non-obvious to make work well with foreign asynchronous design patterns, not helped by a lack of documentation, a problem which also afflicts stdexec which also has a steep and dense learning curve. CppCoro is probably currently the best in class solution to the space of easy to use fire and forget C++ coroutine programming, but it isn’t particularly portable and was designed long before C++ coroutine standardisation was completed. Klemens very kindly stepped up and created for us an open source ground-up reimplementation of the best ideas of hitherto proprietary commercial C++ coroutine libraries, taking in experience and feedback from multiple domain experts in the area to create an easy to use C++ coroutine support library with excellent support for foreign asynchronous design patterns. For example, if you want your coroutine to suspend while a stackful fiber runs and then resume when that fiber has done something – AND that fiber implementation is unknown to Boost.Async – this is made as easy as possible. If your C++ coroutine code wants to await on unknown foreign awaitables, that generally “just works” with no added effort. This makes tying together multiple third party dependencies into a solution based on C++ coroutines much easier than until now. The industry standard executor is ASIO, so Boost.Async uses Boost.ASIO as its base executor. To keep things simple and high performance, Boost.Async requires each pool of things it works with to execute on a single kernel thread at a time – though there can be a pool of things per kernel thread, or an ASIO strand can ensure execution never occurs on multiple kernel threads. The basic concurrency primitives of promise, generator and task are provided, with the fundamental operations of select, join and gather. Some more complex async support is supplied: Go-type channels, and async teardown. Performance is superior to both stackful coroutines and ASIO’s own C++ coroutine support, and sometimes far superior. You can read the documentation at https://klemens.dev/async/ and study or try out the code at https://github.com/klemens-morgenstern/async. Anyone with experience using C++ coroutines is welcome to contribute a review at the Boost mailing list (https://lists.boost.org/mailman/listinfo.cgi/boost) here at this Reddit page, via email to me personally, or any other mechanism where I the review manager will see it. In your review please state at the end whether you recommend acceptance, acceptance with conditions, or rejection. Please state your experience with C++ coroutines and ASIO in your review, and how many hours you spent on the review. Thanks in advance for your time and reviews! Niall

8 13

[Async] Review ends tomorrow
by Niall Douglas 17 Aug '23

17 Aug '23

Dear Boost, The peer review of Boost.Async ends tomorrow. Currently no reviews have been received, there has been almost no discussion, and it appears nobody has been testing Klemens' library. Unless there is a major change by tomorrow, I suspect we'll have to try this again next month when more people return from summer holidays. Niall

4 3

Review of proposed Boost.Async
by Ruben Perez 15 Aug '23

15 Aug '23

Hi all, Thanks Klemens for submitting this library. I've taken a different approach for the review this time. I've tried to build something useful with it. I was already writing a web chat application with a C++ backend. It was using Boost.Context coroutines (the ones you get with boost::asio::spawn). I have rewritten the server to use Boost.Async coroutines. This email is not a review (I'll write it later), but just a summary of my experience using the library, in case anyone finds it useful. You can see the full source code here: https://github.com/anarthal/servertech-chat/tree/async-rewrite/server The application =============== It is a super-simplistic chatting application, where users can send messages that get broadcast to other users in the same chat room. The application uses a HTTP webserver to serve static files, websockets for message broadcasting and Redis for message persistence. It uses Boost.Asio, Boost.Beast, Boost.Redis and now Boost.Async (together with other foundational Boost libraries). My experience ============= I've been able to rewrite it and make it work. I've had some problems (which I described below) but have been able to solve them. Control flow was mostly identical to stackful coroutines, except in some key places I describe below. I've used the use_op token extensively to interoperate with Beast and Redis. As proposed, it causes problems with Beast's websockets, as it's moving the websocket's internal implementation. As a result, after the first initiation that uses use_op, the websocket is rendered unusable. I could overcome it by slightly modifying use_op's implementation. This is tracked by https://github.com/klemens-morgenstern/async/issues/68. It's still under discussion whether this is a bug in Async or in Beast. use_op uses a per-operation, stack-based memory pool of 2KB internally. It creates a completion handler with an associated allocator that will consume this stack-based memory before calling operator new. The pool gets destroyed once the co_await expression finishes execution. I had a problem with Boost.Redis, where redis::connection::async_exec was calling complete() without releasing the memory allocated in the operation, which led to crashes. I think it's a problem in Boost.Redis, not in Async. Tracked by https://github.com/boostorg/redis/issues/140. By default, use_op converts error codes to exceptions. This is consistent with Asio's use_awaitable, but it's a setting I personally don't like using. However, it's easy to adapt it by using asio::as_tuple(async::use_op) as completion token. This should probably be mentioned in docs. I'm using async::with to clean-up Redis connections on application exit. I think it's a very useful feature, and one that Asio doesn't offer. It would be a nice addition to be able to return values from the with call though, to make code less verbose. Tracked by https://github.com/klemens-morgenstern/async/issues/69. As any Beast-based HTTP server, my code has a TCP acceptor that listens for connections and launches HTTP sessions. At first, I was running these sessions as detached promises (by using async::promise::operator+). This caused a deadlock on finalization. async::co_main does not cancel detached promises, but does wait for them to finish after receiving a SIGINT. I solved this by placing my promises in an async::wait_group instead of detaching them. However, I think this behavior is non-obvious and can cause problems for people less experienced with Asio. I've raised https://github.com/klemens-morgenstern/async/issues/72 to track this. I'm currently using detached promises to broadcast messages over websocket sessions. Compared to asio::spawn, spawning detached tasks in Boost.Async is significantly easier. As you may know, when using Beast's websockets, you need to make sure that the application doesn't perform two concurrent async reads or writes on the same websocket at the same time. In this chat server, two concurrent writes can happen if two messages need to be broadcast at the same time. Thus, I was using a hand-rolled async_mutex, based on Asio channels, to guarantee mutual exclusion (unfortunately, there is no asio::mutex). I tried re-writing my async_mutex using async::channel, but I couldn't, because my implementation relied on asio::channel::try_send, which Async does not offer. It would be great if this library could offer async locking primitives, like mutex, condition_variable or event, like Python's asyncio does. I don't think this is a requirement for inclusion, though. I then decided to remove the mutex and base my strategy on channels. Websocket reads and writes are now managed by a single coroutine. If any other session needs to write through a different session's websocket, it writes a message through a channel. The coroutine running the websocket session reads from the websocket and the channel in parallel, using async::select. My first, naive implementation used async::select(websocket.async_read(..., use_op), channel.read()). This does not work as intended because, if the channel read completes first, select will cancel the websocket read, which will cause the websocket connection to close. This can be overcome easily with generators, as they implement the wait_interrupt mechanism. If the channel read completes first, the generator can be resumed later, without losing information. Although there exists an asio::experimental::parallel_group with similar functionality, I don't think this channel-based strategy could be achieved using plain Asio, since the non-destructive capabilities of the generator are vital. parallel_group is also almost undocumented, which makes it difficult to use. My only concern with channels as they are is that channel.read() will throw an exception on cancellation. This means that async::select(websocket_generator, channel.read()) will throw-and-catch an exception internally every time a message arrives on the websocket. I believe that exceptions should be exceptional, and it's not the case here. It makes debugging harder, and may have a performance impact (which I haven't measured). https://github.com/klemens-morgenstern/async/issues/76 tracks this. I've been able to successfully build this project using clang-17 under Linux. I had problems building wait_group under gcc-12 (https://github.com/klemens-morgenstern/async/issues/73) Some other minor issues I found: * https://github.com/klemens-morgenstern/async/issues/75 * https://github.com/klemens-morgenstern/async/issues/66 * https://github.com/klemens-morgenstern/async/issues/71 Some of these issues have already been fixed in the develop branch by Klemens. If you're trying the library, I'd advise you to use this branch. Questions ========= Q1. Is it possible to somehow address the deadlock problem? Q2. Is it possible to get non-throwing overloads of the channel functions? Q3. The docs mention that MSVC compilers have broken coroutine implementations. What compilers/OS does this library target/has been tested with? Thanks Klemens for making the async world less painful. Regards, Ruben.

1 0

Review of proposed Boost.Async
by Marcelo Zimbres Silva 14 Aug '23

14 Aug '23

Hi, this is my review of the proposed Boost.Async. Before I issue my final decision (ACCEPT/REJECT) I would like to ask the author some questions. First of all, I have plenty of reasons to want a library such as Boost.Async into Boost. Some of them are * A common concern I hear from my peers is that Asio is too difficult to get started with. One of the reasons for that is that its Universal Asynchronous Model built around the completion token is too generic for most use cases and in some cases encourages just bad practice like the use_future token. A library like Boost.Async that adds a thin coroutine-only layer over Asio and its corresponding facilities like select, gather etc. will lower the entrance barrier in the Asio asynchronous world. * Docs: Even Asio experts agree that Asio documentation is not easily digestible (async_initiate I am looking at you) and I think it will be difficult for its author alone to address users' complaints given how low-level and generic Asio is. Also, regular users should not be bothered with many of the details. Boost.Async documentation is linear and to the point. It uses names that are more easily recognized by people coming from other languages, like select and with. * NodeJs and Go Tokio, etc. have shown us that successful networking libraries will flourish once a decent asynchronous environment is available. We have more than that, Asio is robust and battle tested, but I am afraid it might not be the correct ground on which high-level abstractions should be prototyped and evolved, not every library needs Duff's device to perform some milliseconds better. As I mentioned above, it is perhaps too generic and low-level and a layer over it might be necessary. Boost.Async looks like the correct step in that direction. We will be one step closer to writing code that is as simple as python, NodeJs, etc. but that runs at C++ speed. * It will help us gather more field experience with C++20 coroutines in domains where C++ is extensively used, like high-performance network servers. * Boost.Async has good defaults, for example a single threaded context. Too many people play around with multi-thread io_context and strands not knowing it might actually have a negative impact on performance. This is also likely to play well with other network Boost networking libraries like Boost.Beast, Boost.MySql and Boost.Redis. Also, the automatic installation of signal handling is a good thing. Q1: Default completion token for other Boost libraries ================================================================ I guess it will be a very common thing for all apps using Boost.Async to have to change the default completion token to use_op or use_task. Like you do in the examples > using tcp_acceptor = async::use_op_t::as_default_on_t<tcp::acceptor>; > using tcp_socket = async::use_op_t::as_default_on_t<tcp::socket>; Could this be provided automatically, at least for other Boost libraries? I know this would be a lot of work, but it would make user code less verbose and users would not have to face the token concept at first. Q2: Lazy vs Eager ================================================================ > It’s an eager coroutine and recommended as the default; Great, we can experiment with eagerness and laziness. But why is an eager coroutine recommended as default? Q3: async_ready looks great ================================================================ > We can however implement our own ops, that can also utilize the > async_ready optimization. To leverage this coroutine feature, async > provides an easy way to create a skipable operation: I think I have a use case for this feature: My first implementation of the RESP3 parser for Boost.Redis was based on Asio's async_read_until, which like every Asio async function, calls completion as if by post. The cost of this design is however high in situations where the next \r\n delimiter is already in the buffer when async_read_until is called again. The resulting rescheduling with post is actually unnecessary and greatly impacts performance, being able to skip the post has performance benefits. But what does *an easy way to create a skipable operation* actually mean? Does it - avoid a suspension point? - avoid a post? - act like a regular function call? Q4: Synchronization primitives ================================================================ Will this library ever add synchronization primitives like async mutexes, condition variables, barriers etc. Or are they supposed to be used from an external library like proposed Boost.Sem. Q5: Boost.Async vs Boost.Asio ================================================================ I use C++20 coroutines whenever I can but know very little about their implementation. They just seem to work in Asio and look very flexible with use_awaitable, deferred, use_promise and use_coro. What advantage will Boost.Async bring over using plain Asio in regards to coroutine? NOTE1 ================================================================ > Please state your experience with C++ coroutines and ASIO in your > review, and how many hours you spent on the review. I have spent a bit more than a day reading the docs, writing the review and integrating Boost.Redis. My experience with C++20 coroutines is limited to using them with Asio. I would also like to thank Klemens for submitting Boost.Async and Niall for offering to be its review manager. Marcelo

3 4

Re: [boost] [Async] Review of proposed Boost.Async begins
by Niall Douglas 14 Aug '23

14 Aug '23

On 08/08/2023 06:33, Niall Douglas wrote: > It is my great pleasure to announce the beginning of the peer review of > proposed Boost.Async, which is hoped to become the most popular way of > programming C++ coroutines in future C++. The peer review shall run > between Tuesday 8th August and Friday 18th August. A reminder that five days remains for this review. To date, I have received zero reviews. Niall

3 2

The master branch is now open for all changes
by Marshall Clow 11 Aug '23

11 Aug '23

Next deadline: October 25th - Boost 1.84.0 closed for new libraries and breaking changes` As always, the calendar is at: https://www.boost.org/development/ — Marshall

1 0

[release] Boost 1.83.0
by Marshall Clow 11 Aug '23

11 Aug '23

Release 1.83.0 of the Boost C++ Libraries is now available. These open-source libraries work well with the C++ Standard Library, and are usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use. This release one new library: * Boost.Compat: A repository of C++11 implementations of standard components added in later C++ standards, from Peter Dimov and contributors. The release also contains numerous enhancements and bug fixes for existing libraries. For details, including download links, see <http://www.boost.org/users/news/version_1.83.0> You can also download directly from: <https://boostorg.jfrog.io/artifactory/main/release/1.83.0/> To install this release on your system, see <http://www.boost.org/doc/libs/release/more/getting_started/index.html> Thanks to everyone who participated in this release. -- The Boost Release Team Marshall Clow, Glen Fernandes

1 0

[release] Boost 1.83.0 Release Candidate 2 is available
by Marshall Clow 10 Aug '23

10 Aug '23

The second release candidates for the 1.83.0 release are now available at: <https://boostorg.jfrog.io/artifactory/main/release/1.83.0/source/> The SHA256 checksums are as follows: c86bd9d9eef795b4b0d3802279419fde5221922805b073b9bd822edecb1ca28e boost_1_83_0_rc2.zip 6478edfe2f3305127cffe8caf73ea0176c53769f4bf1585be237eb30798c3b8e boost_1_83_0_rc2.tar.bz2 c0685b68dd44cc46574cce86c4e17c0f611b15e195be9848dfd0769a0a207628 boost_1_83_0_rc2.tar.gz 22ee9dcf3f1fb58f585772f70c69113a4077b92adeac58b643b3543b78633a16 boost_1_83_0_rc2.7z The only change between RC1 and RC2 is the addition of some missing "#include"s in Boost.Unordered 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. -- The Release managers

5 5

[release] Boost 1.83.0 Release Candidate 1 is available
by Marshall Clow 08 Aug '23

08 Aug '23

The first release candidates for the 1.83.0 release are now available at: <https://boostorg.jfrog.io/artifactory/main/release/1.83.0/source/> The SHA256 checksums are as follows: 9e99f679ea059a25a11bbcb46141868b71c1b33cf89fac916fa392cff20d1577 boost_1_83_0_rc1.7z 4c1cfd15a92ce003a5c2f4bd11311225e7fe42c6686bffabc64e41534167395d boost_1_83_0_rc1.tar.bz2 0571eb39fc0dd92cc8d1d01d3197c58bb28043392e1038df57090676fd6574fa boost_1_83_0_rc1.zip 2d6cf669fb45a2c1e2f92f90c9d444b19a4af25420fbf54747366f637a22a3f7 boost_1_83_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. -- The Release managers

8 13

Status of the 1.83.0 release
by Marshall Clow 08 Aug '23

08 Aug '23

On Thursday, we created 1.83.0 RC1. There have been two problems reported against it. * A couple of missing “include” statements in Unordered * A regression against 1.82.0 (code that used to compile no longer does) in Stl_interfaces. https://github.com/boostorg/stl_interfaces/issues/62 Zach has opined to me that this failure in stl_interfaces is deliberate; so we will not be addressing that. We will be producing an RC2 later today/early tomorrow with the fix for Unordered. This means that the release will probably NOT happen on Wednesday, 9-Aug. Hopefully Thursday. — The release managers.

1 0

[release] Master Branch is closed for ALL changes
by Marshall Clow 03 Aug '23

03 Aug '23

Please do not commit anything to the master branch. Other branches are always fine. The 1.82.0 release is scheduled for next Wednesday, 10-Aug. — Marshall

1 0

Master Branch is now open for bug fixes
by Marshall Clow 02 Aug '23

02 Aug '23

The master branch is now open for bug fixes and documentation changes. Other changes by release manager permission, as described in https://github.com/boostorg/wiki/wiki/Releases%3A-Beta-Merge-Policy The next deadline: On August 5th, master closes for all changes. As always, the calendar is at https://www.boost.org/development/ — Marshall

4 7

oneAPI build
by Alain O' Miniussi 01 Aug '23

01 Aug '23

Hi, I'm trying to build master with oneAPI 2023.1.0's icpx. So far I am mostly getting warnings for unknown/unsupported options like: icpx: warning: -Wl,-rpath,/data/spack/opt/spack/linux-centos7-x86_64/gcc-12.2.0/intel-oneapi-mkl-2023.1.0-x6dxpakvvn4sntkmbzqvtjdndc3g5ttn/mkl/2023.1.0/lib/intel64: 'linker' input unused [-Wunused-command-line-argument] intel-linux.compile.c++ bin.v2/libs/log/build/intel-linux-2023.1.0/release/cxxstd-17-iso/threading-multi/visibility-hidden/setup/matches_relation_factory.o icpx: command line warning #10430: Unsupported command line options encountered These options as listed are not supported. For more information, use '-qnextgen-diag'. option list: -ip -wd177,780,2196,1782,193,304,981,1418,411,734,279 Is oneAPI supported ? the following page: https://www.intel.com/content/www/us/en/developer/articles/technical/buildi… only mention 1.75 and 1.78 Thanks Alain

2 2

Request to merge fixes to docca
by Krystian Stasiowski 28 Jul '23

28 Jul '23

I would like to merge the following commits: https://github.com/boostorg/docca/commit/0ce4e198398dbb52f1de0029f4ed9b7d2b… https://github.com/boostorg/docca/commit/8ba36c0c1e1adb32dbf4cd9c7f3cb36f33… https://github.com/boostorg/docca/commit/4b61682742d6fc0d373698d42635024088… To address these issues: https://github.com/boostorg/docca/issues/136 https://github.com/boostorg/docca/issues/105 These fix assorted compatibility issues with doxygen 1.8.16 and newer

2 1

[boost.async] Seeking Endorsement
by Klemens Morgenstern 28 Jul '23

28 Jul '23

Dear fellow Boost developers, I am seeking endorsement for my C++20 async coroutine library boost.async. It provides coroutine primitives & utilities that are easy to use and intuitive, to anyone who has seen python's asyncio or javascripts async/await APIs before. It simplifies using asio and increases compile times significantly by encouraging the usage of translations units. The features include: - coroutine types (eager, lazy, generators) - built-in cancellation - synchronization of multiple coroutines (select, gather, join) - channels - with (an async scope akin to python's with expression) - asio integration, i.e. completion tokens I think this kind of library is much needed in boost and the wider C++ community. code: https://github.com/klemens-morgenstern/async docs: https://klemens.dev/async/

11 31

Request to merge a fix to Boost.Core
by Peter Dimov 26 Jul '23

26 Jul '23

May I please merge the following fix https://github.com/boostorg/core/commit/c7134904e27237dbbb81ba28f0f23fc365b… to address issue https://github.com/boostorg/core/issues/150 ? I can't verify that the fix actually works, but it doesn't affect non-Android platforms, so can't make things any worse.

2 1