Hi all, Activity on the develop branches of the Boost libraries between 19 and 25 October. This report has been generated automatically with AI. THE NUMBERS - 260 commits on develop (21 CI-related) - 46 pull requests opened against develop, 57 merged - 14 issues opened, 28 closed - 35 libraries with activity, 30 contributors Most active libraries: - Asio: 72 commits PRs: 0 opened, 0 merged; issues: 0 opened, 0 closed - Graph: 17 commits PRs: 16 opened, 15 merged; issues: 1 opened, 0 closed - Container: 37 commits PRs: 0 opened, 0 merged; issues: 0 opened, 1 closed - Fiber: 18 commits PRs: 0 opened, 7 merged; issues: 0 opened, 1 closed - IOStreams: 16 commits PRs: 1 opened, 0 merged; issues: 0 opened, 4 closed - Interval: 7 commits PRs: 4 opened, 4 merged; issues: 2 opened, 3 closed - Intrusive: 20 commits PRs: 0 opened, 0 merged; issues: 0 opened, 0 closed - Decimal: 5 commits PRs: 2 opened, 5 merged; issues: 2 opened, 5 closed Most active contributors: - Christopher Kohlhoff (72 commits, 1 library) - Ion Gaztañaga (64 commits, 4 libraries) - Mateusz Jakub Fila (17 commits, 1 library) - Tobias Stensbeck (16 commits, 1 library) - Peter Dimov (14 commits, 2 libraries) - Jean-Louis Leroy (10 commits, 1 library) - Arnaud Becheler (9 commits, 2 libraries) - Andrea Cassioli (7 commits, 1 library) HIGHLIGHTS Asio Christopher Kohlhoff pushed 72 commits on 21 October. New features include asio::eager, a completion token that starts an operation at once and returns a handle to await later; asio::trampoline, an executor adapter that batches nested submissions; a dependency-free spawn() for x86-64 and AArch64 on Linux and macOS (Boost.Context stays the default); a "spin" reactor backend that avoids epoll_wait-style syscalls; and Perfetto-format handler tracking. channel and concurrent_channel move to the asio namespace, and ready() is deprecated in favour of can_receive(). Fixes cover a possible deadlock in the reactor, a hang in cancel_after/cancel_at with reentrant cancellation and duplicate work counting. poll() now runs the scheduler's task at most once per call. The rest is mostly performance work. Intrusive, Container and Move Ion Gaztañaga reviewed exception guarantees across the three libraries. In Intrusive, move assignment now copies the predicates and moves the nodes instead of swapping, a potentially breaking change; BOOST_INTRUSIVE_MOVE_ASSIGNMENT_SWAPS restores the old behaviour. Every Intrusive container got a friend swap, and swaps and move constructors got conditional noexcept. Container got many noexcept corrections and allocator fixes: private_adaptive_pool::allocate not throwing bad_alloc, a division by zero in alignment-only adaptive pools, an overflow in the aligned_allocate fallback, a string bug when moving to the internal buffer, and devector reallocating despite enough capacity. Move fixed is_constructible on GCC 8-11 in C++03 mode. Graph Arnaud Becheler fixed binary serialization of adjacency_list, whose layout changed by accident in 1.92: archives written by 1.92 can't be read by other releases, and 1.93 goes back to the 1.91 layout. He also extended stateful visitors to planar face traversal, make_maximal_planar, make_connected and make_biconnected_planar, and moved the distributed parts of BGL into GraphParallel. Andrea Cassioli, Varun Sharma and Sayan Samanta removed more legacy compatibility code. New PRs: #664, deprecating labeled and named graphs; #656, Kerem Okyay's fix for #655, a colour map from boykov_kolmogorov_max_flow that is not a minimum cut. Charconv Michiel van Slobbe fixed five writes past the end of a buffer in to_chars (#314 to #318). Several paths wrote a minus sign or a zero without checking the room left: into an empty range, for negative 128-bit integers and for negative zero. Some of them then reported success. General format with a large precision overflowed a stack buffer by one byte for some negative values. Decimal Shen-Ta Hsieh fixed a series of defects he had reported: fmod, remainder and remquo are now exact for exponents far apart (#1517), scalbn and scalbln handle large exponents, acosh and atanh give NaN outside their domain, fma no longer drops a small addend in a tie, and fdim is right for infinities and signaling NaNs. New PRs: #1529, for #1528, equal infinities with payload bits hashing differently. Interval Square roots of point intervals could miss the true root. Sonny Guardian stopped GCC with -frounding-math from reusing the downward-rounded root for the upper end (#61, fixes #60). Sayan Samanta made 32-bit MSVC use x87 fsqrt or SSE, because its runtime sqrt ignores the rounding mode (#64), and Andrey Semashev optimised the SSE2 path. Sayan Samanta also kept GCC from moving x87 arithmetic across the rounding-mode change (#62, fixes #41). Math Nick Thompson added two global optimisers, multilevel coordinate search (closes #1577) and TuRBO, a trust-region Bayesian method, and removed Eigen from CMA-ES. Jacob Hass merged Gauss-Laguerre and Gauss-Jacobi quadrature with anti-Gauss error estimates (#1517, 33 comments). New issues: #1585, documentation for the new quadratures; #1586, hermite, jacobi and laguerre zeros as special functions. JSON Dmitry Arkhipov merged a refactor of how users customise conversion categories (#1156) and ranked described classes lowest ahead of reflection (#1205). New PRs: #1211, splitting a parse_into test that needed over 3GB to build; #1213, for #1212, an option to stop relying on the no_destroy attribute. New issues: #1212, a linker error with Clang on Windows against an MSVC-built Boost (6 comments); #1214, documenting the config macros. Fiber Mateusz Jakub Fila merged CUDA and HIP work from August and September: the HIP integration now uses its own namespace, callbacks use LaunchHostFunc where available, and cudaLaunchHostFunc_v2 flags can be passed (#350). Helena Pankov's futex support for macOS 14.4 and later (#330), first written in April 2025, was merged too. Also last week * UUID and System: Peter Dimov added std::format support to UUID (fixes #201) and made System's to_string_formatter conform to std::formattable. * Beast: Mohammad Nejati's permessage-deflate offer no longer sends server_max_window_bits=15, which some servers reject (fixes #2671), and sends client_max_window_bits without a value. * MSM: Christian Granzin removed the experimental status of backmp11, now the recommended back-end, and removed its active state switch policies and deprecated process_result values. * OpenMethod: Jean-Louis Leroy fixed or annotated the open Coverity defects and merged named_static_rtti for class identity across shared libraries (#127). New issues: #137, static validation of closed overrider sets. * IOStreams: Tobias Stensbeck made the C++11 and CMake 3.8 requirements explicit and fixed test warnings. New PRs: #195, a buffer overrun in range_adapter, from @aouxwoux. * Lockfree: Michiel van Slobbe stopped Clang turning spsc_queue's index wrap into a division on every push and pop (#144). * Config and Predef: Matt Turner added Alpha to the architecture checks. * Wave: Martin Medler added a C++14 language mode. New PRs: #276, a C++26 mode. * New issues and PRs: Process PR #571 (OpenBSD descriptor cleanup), Redis PR #441 (moved-from flat_tree), ProgramOptions PR #161 (C++20 module), GIL issue #817 (Iterator and MPL dependencies). CI MAINTENANCE * Boost.CI: Alexander Grund added Coveralls as a coverage option, made the OpenCppCoverage install more reliable and fixed the Xcode SDK setup; Jean-Louis Leroy fixed Homebrew Clang on macos-26 (#353). * IOStreams: Tobias Stensbeck overhauled the workflow: containers for old compilers, retired runners dropped, GCC 15/16, Clang 20-22, MSVC 14.5 and macOS 26 added, Travis and AppVeyor removed. * Container, Intrusive, Move and Interprocess: Ion Gaztañaga added CMake-based test runs to GitHub Actions. * Interval: Sayan Samanta fixed link failures with Homebrew Clang on macos-26. * UUID: Peter Dimov added libc++ testing. Have a good week!
El 26/10/2026 a las 9:01, Boost Fiscal Sponsorship Committee via Boost escribió:
Hi all,
Activity on the develop branches of the Boost libraries between 19 and 25 October. This report has been generated automatically with AI.
[...]
Hi, We at the FSC have built this small AI tool to inform the community of the most relevant development activity happening across Boost libraries. Please let us know if you find this useful/interesting and what you would change/add to make it better. Thank you! Joaquín M López Muñoz
On 26 Oct 2026 12:20, Joaquin M López Muñoz via Boost wrote:
El 26/10/2026 a las 9:01, Boost Fiscal Sponsorship Committee via Boost escribió:
Hi all,
Activity on the develop branches of the Boost libraries between 19 and 25 October. This report has been generated automatically with AI.
[...]
Hi,
We at the FSC have built this small AI tool to inform the community of the most relevant development activity happening across Boost libraries. Please let us know if you find this useful/interesting and what you would change/add to make it better. Thank you!
Please, don't spam the ML with this. Make it a separate subscription for those who are interested. ML is for human communication, not for activity reports or similar notifications/spam.
On Mon, Oct 26, 2026 at 3:02 AM Andrey Semashev via Boost < boost@lists.boost.org> wrote:
Please, don't spam the ML with this. Make it a separate subscription for those who are interested. ML is for human communication, not for activity reports or similar notifications/spam.
I think its pretty insulting to call it spam. Joaquin, and others, are trying to provide a useful service with value to the authors. Insulting his work is demotivating, and let me tell you - the mailing list needs the activity because it is looking pretty dead these days. Just because you personally do not find value in it, does not mean it belongs elsewhere.
On 26 Oct 2026 13:05, Vinnie Falco wrote:
On Mon, Oct 26, 2026 at 3:02 AM Andrey Semashev via Boost <boost@lists.boost.org <mailto:boost@lists.boost.org>> wrote:
Please, don't spam the ML with this. Make it a separate subscription for those who are interested. ML is for human communication, not for activity reports or similar notifications/spam.
I think its pretty insulting to call it spam. Joaquin, and others, are trying to provide a useful service with value to the authors. Insulting his work is demotivating,
I didn't insult anyone. And for that matter, I didn't say it wasn't useful (to anyone). I said it was not appropriate for this list and suggested to move it elsewhere. And yes, being an automated mass notification activity, it is spam by definition.
and let me tell you - the mailing list needs the activity because it is looking pretty dead these days. Just because you personally do not find value in it, does not mean it belongs elsewhere.
Increasing ML activity with spam notifications is not improving its quality. I would rather prefer the ML silent than a spam source. The latter would only incentivise me to unsubscribe. Again, I'm not saying burn the thing with fire. I'm saying move it elsewhere, so that people who are interested can subscribe, and those who are not are not bothered.
El 26/10/2026 a las 11:14, Andrey Semashev via Boost escribió:
On 26 Oct 2026 13:05, Vinnie Falco wrote:
On Mon, Oct 26, 2026 at 3:02 AM Andrey Semashev via Boost <boost@lists.boost.org <mailto:boost@lists.boost.org>> wrote:
Please, don't spam the ML with this. Make it a separate subscription for those who are interested. ML is for human communication, not for activity reports or similar notifications/spam.
I think its pretty insulting to call it spam. Joaquin, and others, are trying to provide a useful service with value to the authors. Insulting his work is demotivating, I didn't insult anyone. And for that matter, I didn't say it wasn't useful (to anyone). I said it was not appropriate for this list and suggested to move it elsewhere. And yes, being an automated mass notification activity, it is spam by definition.
The _production_ of the report uses an AI tool (a Claude skill, if people are curious). After the report is produced in my machine, I review it, change whatever I feel needs changing and then send it to the ML by hand. Does this procedure still qualify as spam in your estimation? Joaquín M López Muñoz
Thank you to the FSC for putting this together! Getting a summary of cross-repo changes in the ecosystem is very useful. As a maintainer, I definitely see myself looking at it to get an idea of what is moving around me. It's about 5mn of reading per week, so it's doable. Weekly cadence and ~1,150 words is comparable to what LWN or “This Week in Rust” do, and those are well liked (although a bit different in format and nature) - https://lwn.net/ - https://this-week-in-rust.org/ It is useful to surface elements that would be costly to investigate personally, like the adjacency_list serialization break, or the Intrusive move assignment behavior change. It credits contributors by name, which is useful for community building and visibility. I was happy to see several BGL contributors (several new ones!) being credited. The predictable structure will allow us to rapidly scan and locate the information we need. That being said, what could possible diminish its interest is length creep of the lib(s) highlight. Also I wonder if the "Numbers" section is very useful, I'm unsure what I could do with this. But as a first iteration it's very well done! Some people on the ML might find the frequency too high and perceive this report as spam which would be a shame given its quality. I'd encourage everyone to share kind and constructive feedback on how they perceive it, because the alternative is making user-oriented decisions blindly, at the risk of frustrated users leaving the ML. Decisions based on user feedback are the best we can do for them :) One proxy we could use is to post this one report on Reddit and poll the community about its perceived usefulness and possible improvements. It could be a way to gather feedback on the initiative. I am now wondering if I should start a Boost.Graph Monthly News on the Github Discussions. That would be an interesting way to interact with users and contributors regarding the repo's ongoing dynamics and direction. Thanks again to the FSC for this initiative, Best wishes, Arnaud Becheler
Arnaud Becheler wrote:
That being said, what could possible diminish its interest is length creep of the lib(s) highlight. Also I wonder if the "Numbers" section is very useful, I'm unsure what I could do with this. But as a first iteration it's very well done!
I agree that the numbers section is the weakest part. I would remove this THE NUMBERS - 260 commits on develop (21 CI-related) - 46 pull requests opened against develop, 57 merged - 14 issues opened, 28 closed - 35 libraries with activity, 30 contributors and remove the second line from these Most active libraries: - Asio: 72 commits PRs: 0 opened, 0 merged; issues: 0 opened, 0 closed - Graph: 17 commits PRs: 16 opened, 15 merged; issues: 1 opened, 0 closed - Container: 37 commits PRs: 0 opened, 0 merged; issues: 0 opened, 1 closed That is, this would leave Most active libraries: - Asio: 72 commits - Graph: 17 commits - Container: 37 commits although we should probably sort by commits then, or it would look weird.
El 26/10/2026 a las 11:59, Arnaud Becheler via Boost escribió:
[..]
That being said, what could possible diminish its interest is length creep of the lib(s) highlight. [...] This last week has been unusually active, so what you've seen is on the right tail of the distribution lengthwise. I am now wondering if I should start a Boost.Graph Monthly News on the Github Discussions. [...]
I can send you the Claude skill if you're interested in adapting it for your needs :-) Joaquín M López Muñoz
Andrey Semashev wrote:
On 26 Oct 2026 12:20, Joaquin M López Muñoz via Boost wrote:
El 26/10/2026 a las 9:01, Boost Fiscal Sponsorship Committee via Boost escribió:
Hi all,
Activity on the develop branches of the Boost libraries between 19 and 25 October. This report has been generated automatically with AI.
[...]
Hi,
We at the FSC have built this small AI tool to inform the community of the most relevant development activity happening across Boost libraries. Please let us know if you find this useful/interesting and what you would change/add to make it better. Thank you!
Please, don't spam the ML with this. Make it a separate subscription for those who are interested. ML is for human communication, not for activity reports or similar notifications/spam.
On the one hand, I found this report, unlike previous AI attempts, high quality and informative. On the other, maybe posting this every week will indeed prove too much. Maybe the report belongs on the web somewhere, and we just need the link posted here every week?
On 26 Oct 2026 13:23, Peter Dimov via Boost wrote:
Maybe the report belongs on the web somewhere, and we just need the link posted here every week?
I don't think posting a link here every week would be productive either. I think, it should be a separate subscription. There used to be a News section with the associated RSS feed. But I don't see it in the current version of the website. There are Posts, but there isn't an RSS feed for it, as far as I can see. Maybe adding RSS to Posts and posting these reports there would be appropriate.
Andrey Semashev wrote:
On 26 Oct 2026 13:23, Peter Dimov via Boost wrote:
Maybe the report belongs on the web somewhere, and we just need the link posted here every week?
I don't think posting a link here every week would be productive either. I think, it should be a separate subscription.
The purpose of posting here, as I understand it, is to provide a hook where discussion about some of the changes can be hanged. Or with less metaphors, to start a thread, if one is needed.
El 26/10/2026 a las 11:51, Peter Dimov via Boost escribió:
Andrey Semashev wrote:
On 26 Oct 2026 13:23, Peter Dimov via Boost wrote:
Maybe the report belongs on the web somewhere, and we just need the link posted here every week? I don't think posting a link here every week would be productive either. I think, it should be a separate subscription. The purpose of posting here, as I understand it, is to provide a hook where discussion about some of the changes can be hanged.
Or with less metaphors, to start a thread, if one is needed.
That's exactly right. What follows are my personal impressions (not the FSC's): I ran the tool over an entire year and was pleasantly surprised to discover that there's a good deal of activity under the radar, some of interest for authors/contributors depending on specific libraries, some generally applicable to many authors/contributors (to give an example from this first report, Coveralls support in Boost.CI). Because of the modular structure of the project, and because GitHub is not particularly oriented towards human discussion of development activity, I thought bridging GH activity and the ML may be a good idea. Also, this report is about activity in _develop_, which I think aligns with the developers' ML interests --probably not so much with the general audience, who typically won't consume the results until the next Boost release. Joaquín M López Muñoz
participants (6)
-
Andrey Semashev -
Arnaud Becheler -
Boost Fiscal Sponsorship Committee -
Joaquin M López Muñoz -
Peter Dimov -
Vinnie Falco