May 2023 - Boost - lists.boost.org

CMake Announcement from Boost Steering Committee
by Jon Kalb 13 Aug '24

13 Aug '24

The libraries produced by the Boost community have had a greater impact on the way that the C++ community writes code than any other library implementation. The focus of the Boost community will always be on the libraries, but it is undeniable that we are dependent on and often limited by the infrastructure of our trade. Years ago, the move to Git was contentious; yet, it was required to improve development. In a similar vein our build system has become an impediment for many developers and users, existing and prospective. Therefore, we, the Steering Committee, announce to the Boost community our desire and intent to move Boost’s build system to CMake for users and developers alike. We are soliciting comments and proposals from the community to guide the process and the goals. Our desire is that the community can come to consensus by the end of the calendar year with a vision of supporting users and developers. We understand that the actual process of achieving the end goal will be long, time consuming, and not without its share of conflict. We also recognize that the Boost community is comprised of bright and passionate individuals that are eager to get involved and help get work done. The members of the Steering Committee have been encouraged by the discussions and activity surrounding CMake on the mailing lists over the years and know that many people have voiced visions. We hope that each of you rejoins the discussion to support this initiative and contributes to the common goal of improving Boost’s integration into the broader C++ ecosystem. For the Boost Steering Committee, Jon Kalb, Chair jonkalb(a)boost.org

49 200

Boost Governance?
by René Ferdinand Rivera Morell 09 Aug '24

09 Aug '24

A disclaimer: I write this solely as a Boost Library author. And not in any other capacity or representing any other interest. It's now been at least a year since Boost switched from the Software Freedom Conservancy to the Boost Foundation for its governance organization. But have people noticed any difference? Did you know that switch happened? Did you know that they held an election for the Board of Directors and for the Officers? Do you know when that election happened? Do you know who got elected? Do you know how they were selected? Do you know what their responsibilities are? Do you know what their bylaws are? Do you know their financials? More importantly: Did you answer "no" to any of those questions? As a library author, I can say I definitely answered no to many of those questions. This is a problem. As authors, without asking, we should know those answers from the organization that governs our work. We should have input into how that organization governs. In other words, we deserve open and transparent governance; not the closed and opaque status quo. -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supone Nada -- Robot Dreams - http://robot-dreams.net

10 10

Paul Bristow
by John Maddock 08 Aug '24

08 Aug '24

I've just heard that Paul Bristow who helped so much with the development of Boost.Math and indeed many other libraries, passed away peacefully last week. RIP Paul. Much missed. John.

7 7

Library proposal - indexed_array
by Julien Blanc 12 Oct '23

12 Oct '23

Hi, I've written and released a (rather small) library which allows defining arrays with arbitrary index mechanisms (hence the name, indexed_array). This especially allows indexing with scoped enums, use non zero-starting indexes, or use sparse indexes. This is not a view, but an array in the sense that it owns the data, and provides the same guarantees and functionalities as std::array, such as triviality propagation, being able to reside in read-only program sections, etc. It also supports multidimensional indexing, and provides an indexed_span template class to access lower dimension content (which can be used outside indexed_array). Finally, it provides an opt-in safer way to initialize the array content, which is especially useful when using complex and/or changing indexing schemes (like based on externally generated files). The library is available here: https://github.com/Julien-Blanc-tgcm/indexed_array And the doc is here: https://julien-blanc-tgcm.github.io/indexed_array/ It requires C++17 and mp11, and has first-class support for describe-d enums. If there is some interest, i'd like to propose it for inclusion in boost. So i'm looking for people who would endorse it. Thanks and best regards, Julien

8 24

Windows Develop Regression Tests Failing - Boost Build?
by Tom Kent 04 Jun '23

04 Jun '23

When trying to run the regression tests for the develop branch from windows, I'm getting the following error: C:/teeks99-09/run/boost_bb/src/build\project.jam:284: in find-jamfile from module project error: Unable to load Jamfile. error: Could not find a Jamfile in directory '../../C:/teeks99-09/run/boost_root'. error: Attempted to find it with pattern '[Bb]uild.jam [Jj]amfile.v2 [Jj]amfile [Jj]amfile. [Jj]amfile.jam'. error: Please consult the documentation at 'https://www.bfgroup.xyz/b2/'. C:/teeks99-09/run/boost_bb/src/build\project.jam:347: in load-jamfile from module project C:/teeks99-09/run/boost_bb/src/build\project.jam:64: in load from module project C:/teeks99-09/run/boost_bb/src/build\project.jam:105: in load-used-projects from module project C:/teeks99-09/run/boost_bb/src/build\project.jam:75: in load from module project C:/teeks99-09/run/boost_bb/src/build\project.jam:134: in load-parent from module project C:/teeks99-09/run/boost_bb/src/build\project.jam:538: in initialize from module project C:/teeks99-09/run/boost_bb/src/build\project.jam:373: in load-jamfile from module project C:/teeks99-09/run/boost_bb/src/build\project.jam:64: in load from module project C:/teeks99-09/run/boost_bb/src/build\project.jam:167: in project.find from module project C:/teeks99-09/run/boost_bb/src\build-system.jam:618: in load from module build-system C:/teeks99-09/run/boost_bb/src/kernel\modules.jam:294: in import from module modules C:/teeks99-09/run/boost_bb/src/kernel/bootstrap.jam:135: in module scope from module It looks like the last good run I had was on march 11, which corresponds to the same day as this commit to that project.jam: https://github.com/boostorg/build/commit/fda357a8f55a08535afff0a11eec50fca1… That file doesn't mean much to me, is it possible it is causing the issue? Thanks, Tom

3 4

Moving sp_thread_pause, sp_thread_sleep to Core
by Christian Mazakas 02 Jun '23

02 Jun '23

Unordered's concurrent flat map contains a hand-rolled spinlock (graciously provided by Peter Dimov) but it contains a dependency on SmartPtr for the following two headers: #include <boost/smart_ptr/detail/sp_thread_pause.hpp> #include <boost/smart_ptr/detail/sp_thread_sleep.hpp> I advocate that we move these to Core. They're small, self-contained and are useful in broader contexts. Anyone have thoughts or objections? - Christian

5 14

git hub discussions.
by Robert Ramey 31 May '23

31 May '23

As an experiment, I've added to github discussions for the safe_numerics library. The idea is to provide a place for feedback from users of the library. I'd be curious to hear other persons thoughts on this. https://github.com/boostorg/safe_numerics/discussions/133 Robert Ramey

4 5

Re: [boost] Boost.Compat
by Peter Dimov 31 May '23

31 May '23

Ruben Perez wrote: > > So my suggestion is to create a separate library/repo, Boost.Compat > > (boostorg/compat, namespace boost::compat) for them. > > > > Thoughts? (Be sure to read the discussion in the PR as well.) > > > > I'm in favor of this. I agree with not allowing extensions, too. > > I think a light review should take place before inclusion. The suggested repository is now ready for light review at https://github.com/boostorg/compat, complete with its first component, an implementation of std::latch by Christian Mazakas. Everyone's light reviews are welcome.

6 13

Sam review scheduled
by Ruben Perez 20 May '23

20 May '23

Hi all, I'm happy to announce that the Sam library, featuring asio-based synchronization primitives, is being proposed for Boost inclusion. Repo: https://github.com/klemens-morgenstern/sam Docs: https://klemens.dev/sam/ The library is being proposed by Klemens Morgenstern. The review will take place between May the 29th (Monday) and June the 8th (Thursday). I will be managing the review. Boost.Sam offers async asio-based synchronization primitives, similar to standard mutex, condition_variable, semaphore and barrier. It's geared towards library writers that require fine-grain control over their synchronization operations. You can contact both me and the author by mail or on the cpplang Slack. Kind regards, Ruben.

4 7

Re: [boost] boost 1.82.0
by John Maddock 16 May '23

16 May '23

On 16/05/2023 02:39, Prabhakar Bhatt via Boost wrote: > Hi All, > > Recently we upgraded to Boost 1.82.0. > > We compiled the boost as : > > ./bootstrap.sh > --with-libraries=filesystem,system,program_options,iostreams,log,regex,stacktrace,thread > --without-icu > > When we tried to use the regex library and build Avro product we are > getting following error: > > Boost/boost_1_82_0/include/boost/regex/v4/cpp_regex_traits.hpp:1117: > undefined reference to > `boost::scoped_static_mutex_lock::scoped_static_mutex_lock(boost::static_mutex&, > bool)' > > Please can you help us in addressing the issue. Regex is now header only, *unless* you are building with a C++03 compiler (which is now deprecated), and will require linking to the external libboost_regex. John.

1 0

Re: [boost] Determine socket is ipv4 or ipv6
by Gavin Lambert 16 May '23

16 May '23

On 16/05/2023 15:26, Tarun Batra wrote: > I have a code something like this: > > TcpConnection::pointer my_conn = GetConn(req); > > tcp::socket& my_socket = my_conn->getSocket(); > > tcp::resolver my_resolver(my_socket.get_executor()); > > > Is it possible to check if the my_socket is ipv4 socket or ipv6 socket? That depends exactly what you mean by that, but you're likely looking for something like: my_socket.remote_endpoint().address().is_v6() Doxygen doesn't do a very good job at navigating the type templates involved here; using your IDE's code completion is more successful.

1 0

Reference section of Boost.Any leads to Boost.PFR
by Antony Polukhin 15 May '23

15 May '23

Hi, Just noted that clicking on "->" arrow at the developer preview of Boost.Any https://www.boost.org/doc/libs/develop/doc/html/any/ValueType.html leads to Boost.PFR reference section. No idea how is that possible. I'd appreciate help

1 0

boost 1.82.0
by Prabhakar Bhatt 15 May '23

15 May '23

Hi All, Recently we upgraded to Boost 1.82.0. We compiled the boost as : ./bootstrap.sh --with-libraries=filesystem,system,program_options,iostreams,log,regex,stacktrace,thread --without-icu When we tried to use the regex library and build Avro product we are getting following error: Boost/boost_1_82_0/include/boost/regex/v4/cpp_regex_traits.hpp:1117: undefined reference to `boost::scoped_static_mutex_lock::scoped_static_mutex_lock(boost::static_mutex&, bool)' Please can you help us in addressing the issue. Thanks and Regards, Prabhakar

1 0

Determine socket is ipv4 or ipv6
by Tarun Batra 14 May '23

14 May '23

Hi, I have a code something like this: TcpConnection::pointer my_conn = GetConn(req); tcp::socket& my_socket = my_conn->getSocket(); tcp::resolver my_resolver(my_socket.get_executor()); Is it possible to check if the my_socket is ipv4 socket or ipv6 socket?

1 0

Re: [boost] BOOST 1.82.0 with c++17
by Vinnie Falco 13 May '23

13 May '23

On Sat, May 13, 2023 at 5:52 AM Daggumati, Rajesh via Boost <boost(a)lists.boost.org> wrote: > Does boost 1.82.0 compatible with C++ 17 compiler? Check the bottom of this page: https://www.boost.org/users/history/version_1_82_0.html Thanks

1 0

BOOST 1.82.0 with c++17
by Daggumati, Rajesh 13 May '23

13 May '23

Hi Team, As per project requirement , we are going to upgrade to BOOST(1.82.0) and Qt(6.5 LTS) in our project. QT 6.5 LTS needs C++ 17 compiler. Does boost 1.82.0 compatible with C++ 17 compiler? Kindly please let us know your response. Regards, Rajesh D Confidential - Company Proprietary Please be advised that this email may contain confidential information. If you are not the intended recipient, please notify us by email by replying to the sender and delete this message. The sender disclaims that the content of this email constitutes an offer to enter into, or the acceptance of, any agreement; provided that the foregoing does not invalidate the binding effect of any digital or other electronic reproduction of a manual signature that is included in any attachment.

1 0

Please remove me from this list
by Vitaly Budovski 12 May '23

12 May '23

The web and email unsubscribe methods do not seem to work.

1 0

Version of RapidXml used in boost
by Kacvinsky, Tom 12 May '23

12 May '23

Hi, I am trying to track down with version of RapidXml is used in Boost 1.78.0. I don't have a problem with the RapidXml license attribution, but I do need to know the specific version of it that is used in Boost for our attribution purposes (copyright year and version). >From what I can see from a git blame, RapidXml was added to Boost around 2007 by the author of RapidXml (Marcin). Does anyone have idea which version is used in Boost? Thanks, Tom

1 0

Re: [boost] New Website !
by Ion Gaztañaga 12 May '23

12 May '23

On 11/05/2023 21:47, Vinnie Falco via Boost wrote: > On Thu, May 11, 2023 at 11:36 AM Ion Gaztañaga via Boost > <boost(a)lists.boost.org> wrote: >> The release notes page seems hard to parse, though: >> >> https://www.boost.revsys.dev/releases/ > > Ahem... well, would you believe that me and Greg pulled that one out > from scratch from our collective arse just hours before the > announcement? > > In other words, it is a placeholder / design sketch. It will get a > proper treatment shortly (and be actually hooked up to the database by > the talented Lacey). Great! Ion

1 0

Re: [boost] charconv for C++11
by Matt Borland 12 May '23

12 May '23

> > Here's my full test case, built with VS 2022 17.6 Preview 7 x64 (note that x64 vs. x86 makes a HUGE difference to charconv). I didn't bother to compare the from_chars scenario (as MSVC doesn't use a highly optimized algorithm there; investigating Eisel-Lemire is on our todo list). > > Hope this helps, > STL > Stephan, Thank you for this. I can add benchmarks for Lemire’s algorithm vs. the current MSVC STL from_chars to see if it’s worth pursuing for your team. Matt

2 1

Re: [boost] charconv for C++11
by Ruben Perez 12 May '23

12 May '23

> > > What does charconv do? I need this in MySQL.

1 0

Re: [boost] charconv for C++11
by Matt Borland 12 May '23

12 May '23

> I also still think that whoever came up with that specification needs a > whap upside the head, but then I've never encountered a reason to print > a floating-point value in hex, so I assume there's some justification > for it. Gavin, Hexfloats are useful for comparison of numerical accuracy. We use them in the Boost.Math unit tests when outputting ULP distances. https://github.com/boostorg/math/blob/develop/test/math_unit_test.hpp#L136 Matt

1 0

Re: [boost] charconv for C++11
by Matt Borland 12 May '23

12 May '23

> On May 12, 2023, at 8:59 AM, Alexander Grund via Boost <boost(a)lists.boost.org> wrote: > > Am 12.05.23 um 02:52 schrieb Gavin Lambert via Boost: >> Mere moments ago, quoth I: >>>> Hex format will be of the form +1.0e2p+5. The integer part will >>>> always be 0 or 1. The exponent will be with a p instead of an e like >>>> in base 10 formats. >> (Also, FWIW, gcc fails to parse that with the leading +. And I >> couldn't even find any online calculators that understand this format.) > According to cppreference the floating point parser should not support it: > > "the plus sign is not recognized outside of the exponent (only the > minus sign is permitted at the beginning)" > > So I'd say that is a bug in Boost charconv given that it wants to be > as-if the standard one. > You two are correct that a value with a leading plus sign should be EINVAL rather than ignoring it during parsing. I opened an issue, and will address it. Matt

1 0

Re: [boost] charconv for C++11
by Alexander Grund 12 May '23

12 May '23

Am 12.05.23 um 02:52 schrieb Gavin Lambert via Boost: > Mere moments ago, quoth I: >>> Hex format will be of the form +1.0e2p+5. The integer part will >>> always be 0 or 1. The exponent will be with a p instead of an e like >>> in base 10 formats. > (Also, FWIW, gcc fails to parse that with the leading +. And I > couldn't even find any online calculators that understand this format.) According to cppreference the floating point parser should not support it: "the plus sign is not recognized outside of the exponent (only the minus sign is permitted at the beginning)" So I'd say that is a bug in Boost charconv given that it wants to be as-if the standard one.

1 0

Re: [boost] Extra file in boost serialization for 1.82.0
by Robert Ramey 12 May '23

12 May '23

On 5/11/23 9:15 PM, Robert Ramey via Boost wrote: > There is a little more to it than this though. Some time ago I modified > my usage of Git so that I have my development updates in the development > branch - so far so good. But then I noticed that all the same > information incremental files were repeated in the master branch. I > found this redundant, repetitive and confusing. So I took to using > "squash and merge" when incorporating the changes on the development > branch. This option is available on GitHub. This seemed to give me what > I wanted: a detailed history of development and a concise changes in the > history of releases. It seems that something is awry here as the "squash > & merge" option doesn't merge file deletions. When I catch up, I'll > look into this. > Note this this procedure has some effects which were unanticipated. a) when someone checks in a change into the master branch without telling me, it is wiped out by the next merger to master. At first I thought this was a bug, now I'm thinking this is more of feature as it takes a long time to track down cases where someone has made changes which leave the master permanently out of sync with the development branch. b) The development and master branches are always the same at the time of release. Again - a feature not a bug. c) Of course it probably does annoy he who checked in a change directly to master, but he shouldn't be doing that anyway. Robert Ramey

1 0

Re: [boost] Extra file in boost serialization for 1.82.0
by Glen Fernandes 12 May '23

12 May '23

On Thu, May 11, 2023 at 9:20 PM Marshall Clow via Boost < boost(a)lists.boost.org> wrote: > > On May 11, 2023, at 12:01 PM, Bryan St. Amour via Boost < > boost(a)lists.boost.org> wrote: > > > > Hi, > > > > I noticed that under boost/serialization, there is a file > "collection_size_type copy.hpp" (notice the space in the file name.) > Comparing it with the contents of collection_size_type.hpp, it looks like > "collection_size_type copy.hpp" is newer. Can someone verify which one is > the correct collection_size_type header file? > > This is https://github.com/boostorg/serialization/issues/237 < > https://github.com/boostorg/serialization/issues/237> > And https://github.com/boostorg/serialization/issues/221 < > https://github.com/boostorg/serialization/issues/221> > > Sadly, this has been a problem for several releases. > > Robert removed it from develop a while ago but it's still in master. Robert, your merges to master aren't removing the file, you need to fix your branches. Glen

2 1

Re: [boost] Extra file in boost serialization for 1.82.0
by Marshall Clow 12 May '23

12 May '23

> On May 11, 2023, at 12:01 PM, Bryan St. Amour via Boost <boost(a)lists.boost.org> wrote: > > Hi, > > I noticed that under boost/serialization, there is a file "collection_size_type copy.hpp" (notice the space in the file name.) Comparing it with the contents of collection_size_type.hpp, it looks like "collection_size_type copy.hpp" is newer. Can someone verify which one is the correct collection_size_type header file? This is https://github.com/boostorg/serialization/issues/237 <https://github.com/boostorg/serialization/issues/237> And https://github.com/boostorg/serialization/issues/221 <https://github.com/boostorg/serialization/issues/221> Sadly, this has been a problem for several releases. — Marshall

1 0

Re: [boost] charconv for C++11
by Gavin Lambert 12 May '23

12 May '23

Mere moments ago, quoth I: >> Hex format will be of the form +1.0e2p+5. The integer part will >> always be 0 or 1. The exponent will be with a p instead of an e like >> in base 10 formats. > This is some strange definition of "hex" with which I was previously > unfamiliar. > > It also contradicts itself, by saying "a p instead of an e" while the > example contains both. (And isn't a very good example, lacking actual > hex digits.) It later occurred to me that the "e" could be intended as a hex digit, thus "1.0e2 with exponent +5". This still makes it a poor example, though. It might perhaps be intended as an example of a vexing parse, but in that case it shouldn't be the *only* example (and perhaps should be elsewhere). (Also, FWIW, gcc fails to parse that with the leading +. And I couldn't even find any online calculators that understand this format.)

1 0

Re: [boost] charconv for C++11
by Gavin Lambert 12 May '23

12 May '23

On 12/05/2023 10:59, Peter Dimov wrote: > The work-in-progress documentation is here: https://develop.charconv.cpp.al/ > Hex format will be of the form +1.0e2p+5. The integer part will > always be 0 or 1. The exponent will be with a p instead of an e like > in base 10 formats. This is some strange definition of "hex" with which I was previously unfamiliar. It also contradicts itself, by saying "a p instead of an e" while the example contains both. (And isn't a very good example, lacking actual hex digits.) I've now found the reference to it -- https://en.cppreference.com/w/cpp/utility/to_chars says that "hex" uses as-if printf %a, and https://en.cppreference.com/w/cpp/io/c/fprintf says printf %a appears *somewhat* like the above (but I still think there is an error in the above). I also still think that whoever came up with that specification needs a whap upside the head, but then I've never encountered a reason to print a floating-point value in hex, so I assume there's some justification for it.

1 0

Re: [boost] charconv for C++11
by Peter Dimov 11 May '23

11 May '23

Robert Ramey wrote: > > In addition to all that, from/to_chars are standard C++17, so Charconv > > can be used by libraries that want to support C++11 (or 14) today, but > > at the same time want to be able to switch to the standard functions > > later when increasing the minimal supported standard to C++17. > > So this is an implementation in C++11 of a library which is already accepted > (and presumably shipping) in C++17 ? And the only user who would use this is > someone who has C++11 but can't upgrade to C++17? > Doesn't seem like very many people to me. Users... and library authors whose libraries still support C++11/14, such as Boost.JSON. > I didn't find an documentation for this. The work-in-progress documentation is here: https://develop.charconv.cpp.al/

1 0

Re: [boost] New Website !
by René Ferdinand Rivera Morell 11 May '23

11 May '23

On Thu, May 11, 2023 at 5:00 PM Andrey Semashev via Boost <boost(a)lists.boost.org> wrote: > > Loading the page takes noticeably longer than the original website. Interesting.. For me, on Firefox 112.0.2 on Manjaro w/Plasma doing a full reload of the home pages is: boost.org.. 1.71s boost.revsys.dev.. 1.57s So the new site is faster for some reason? -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supone Nada -- Robot Dreams - http://robot-dreams.net

2 1

Re: [boost] New Website !
by Vinnie Falco 11 May '23

11 May '23

On Thu, May 11, 2023 at 3:00 PM Andrey Semashev via Boost <boost(a)lists.boost.org> wrote: > Just opening this page immediately starts hogging CPU on my system Consider opening an issue here https://github.com/cppalliance/temp-site/issues > Please, remove the animation. We are going to remove it as it was an earlier design element that no longer suits the revised style of the site. > Loading the page takes noticeably longer than the original website. I > understand that the new website is probably hosted on a weaker server, > but I also suspect that it is overall more heavy than the original website. Shouldn't take longer to load, this is a statically generated site except for a few dynamic pages (like the Libraries). However, we have also not put any efforts into optimizing page loads (that comes last). > The release notes (https://www.boost.revsys.dev/releases/) seems to have > broken formatting. Library names are not highlighted and release note > items are not displayed as list items. Yes well.. that's not a "real" page, we just slapped it together (see my earlier reply to Ion). > There are quite a bit of information missing. For example, Release > schedule (https://www.boost.org/development/index.html) and most of the > pages under the Development menu seem to be missing. Yes there is, that's why we are doing this open beta, and not meddling with the live website at boost.org. So that we can ensure nothing is missing, everything is accounted for, and all voices are heard. And probably I want to test it for at least one release - we would release both in the live site and in the new site, and see how the release goes in the new site, to ensure we don't miss a release because something is wrong with the new code. > PS: I'm using Firefox 113.0 on Kubuntu 22.04. Please include that information in the issues you open at https://github.com/cppalliance/temp-site/issues Thanks

1 0

Re: [boost] New Website !
by Andrey Semashev 11 May '23

11 May '23

On 5/11/23 17:35, Vinnie Falco via Boost wrote: > Hey, it’s Vinnie here again! I have some very exciting news to share > with you. The renovated website for Boost that we’ve been working on > for far too long is now going into its Public Beta phase! Feel free to > poke around and kick the tires but keep in mind this is a piece of > software and it is still under development. Some parts are missing, > incomplete,or buggy. Without further ado: > > https://boost.revsys.dev Just opening this page immediately starts hogging CPU on my system. I'm assuming, this is because of the animated logo on the right half of the screen. Please, remove the animation. I would also reduce the size of or even remove the logo entirely, as it wastes too much space. Loading the page takes noticeably longer than the original website. I understand that the new website is probably hosted on a weaker server, but I also suspect that it is overall more heavy than the original website. The release notes (https://www.boost.revsys.dev/releases/) seems to have broken formatting. Library names are not highlighted and release note items are not displayed as list items. There are quite a bit of information missing. For example, Release schedule (https://www.boost.org/development/index.html) and most of the pages under the Development menu seem to be missing. PS: I'm using Firefox 113.0 on Kubuntu 22.04.

1 0

Re: [boost] charconv for C++11
by Robert Ramey 11 May '23

11 May '23

This is the useful information I was hoping to get when I asked the question. Unfortunately, I had to dig a little deeper than I expected and have a few more questions: On 5/11/23 11:05 AM, Peter Dimov via Boost wrote: > Robert Ramey wrote: > lexical_cast can convert any streamable type to any other streamable type. > It's defined as `ss << input; ss >> output; return output;` where `ss` is > a default-constructed `std::stringstream`. Hmmm - cannot not an ss be associated with a local of choice via std::imbue? Looking at the documentation for lexical cast I don't see this. I'm not sure what the issues would be with this. > This has a number of implications. One, the conversion is locale-dependent. Hmmm - conversion to/from strings isn't locale dependent, how does one deal with string numeric formats which depend on locality - e.g. some countries use , while others use . as a decimal separator. > Two, for conversion to string, you use lexical_cast<std::string>, which can > allocate. There is a section in the lexical_cast docs titled "converting to string without dynamic memory allocation". Actually it would never occur to me that one could return a string from a conversion without a dynamic memory allocation. But I guess that's me. Three, errors are signaled via exceptions (although there's > try_lexical_convert that can avoid this.) Right > lexical_cast does a good job of optimizing the from_chars and to_chars > cases when it detects it can do so, but that by definition can't be better > than the programmer just calling the primitive operations from_chars > and to_chars directly, as they are (a) locale-independent, (b) non- > allocating, (c) non-throwing. OK > > In addition to all that, from/to_chars are standard C++17, so Charconv > can be used by libraries that want to support C++11 (or 14) today, but > at the same time want to be able to switch to the standard functions > later when increasing the minimal supported standard to C++17. So this is an implementation in C++11 of a library which is already accepted (and presumably shipping) in C++17 ? And the only user who would use this is someone who has C++11 but can't upgrade to C++17? Doesn't seem like very many people to me. I didn't find an documentation for this. May I presume that it's not deemed necessary as C++17 is documented and this is an exact equivalent? Note that there is another boost library, Boost.Convert, which purports to address short comings in lexical cast. https://www.boost.org/doc/libs/1_82_0/libs/convert/doc/html/index.html Has anyone looked at or evaluated this? Is there overlap? I actually never knew about this. Robert Ramey

1 0

Re: [boost] New Website !
by Vinnie Falco 11 May '23

11 May '23

On Thu, May 11, 2023 at 11:36 AM Ion Gaztañaga via Boost <boost(a)lists.boost.org> wrote: > The release notes page seems hard to parse, though: > > https://www.boost.revsys.dev/releases/ Ahem... well, would you believe that me and Greg pulled that one out from scratch from our collective arse just hours before the announcement? In other words, it is a placeholder / design sketch. It will get a proper treatment shortly (and be actually hooked up to the database by the talented Lacey). Thanks

1 0

Re: [boost] charconv for C++11
by Stephan T. Lavavej 11 May '23

11 May '23

[Peter Dimov] > lexical_cast does a good job of optimizing the from_chars and to_chars > cases when it detects it can do so, but that by definition can't be better > than the programmer just calling the primitive operations from_chars > and to_chars directly, as they are (a) locale-independent, (b) non- > allocating, (c) non-throwing. I wondered how lexical_cast's "good job" (limited by the algorithms at the time, not its fault!) compared to charconv, so I dusted off the performance comparison I wrote for CppCon 2019 and added lexical_cast. MSVC's charconv is approximately 14x (for float) and 25x (for double) faster - that's times, not percent. (Thanks to Ryu by Ulf Adams.) This is with avoiding dynamic memory allocation in lexical_cast by converting into a small std::array. My absolute numbers (in a Ryzen 5950X VM): 452.3 ns | Boost float 1003.0 ns | Boost double 32.1 ns | STL float plain shortest 39.9 ns | STL double plain shortest Here's my full test case, built with VS 2022 17.6 Preview 7 x64 (note that x64 vs. x86 makes a HUGE difference to charconv). I didn't bother to compare the from_chars scenario (as MSVC doesn't use a highly optimized algorithm there; investigating Eisel-Lemire is on our todo list). C:\Temp>type charconv.cpp // cl /std:c++17 /EHsc /nologo /W4 /MT /O2 /Iboost_1_82_0 charconv.cpp && charconv #ifndef _MSC_VER #define AVOID_CHARCONV #define AVOID_SPRINTF_S #endif // _MSC_VER #ifndef AVOID_CHARCONV #include <charconv> #endif // AVOID_CHARCONV #include <array> #include <chrono> #include <exception> #include <random> #include <stdint.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include <system_error> #include <type_traits> #include <vector> #include <boost/lexical_cast.hpp> using namespace std; using namespace std::chrono; void verify(const bool b) { if (!b) { puts("FAIL"); exit(EXIT_FAILURE); } } enum class RoundTrip { Sci, Fix, Gen, Hex, Lossy }; constexpr size_t N = 2'000'000; // how many floating-point values to test constexpr size_t K = 5; // how many times to repeat the test, for cleaner timing constexpr size_t BufSize = 2'000; // more than enough unsigned int global_dummy = 0; template <typename Floating> void test_lexical_cast(const char* const str, const vector<Floating>& vec) { const auto start = steady_clock::now(); for (size_t k = 0; k < K; ++k) { for (const auto& elem : vec) { const auto ret = boost::lexical_cast<array<char, 25>>(elem); // "-1.2345678901234567e-100" plus null term global_dummy += static_cast<unsigned int>(ret[0]); } } const auto finish = steady_clock::now(); printf("%6.1f ns | %s\n", duration<double, nano>{finish - start}.count() / (N * K), str); } template <typename Floating> int sprintf_wrapper(char (&buf)[BufSize], const char* const fmt, const Floating elem) { #ifdef AVOID_SPRINTF_S return sprintf(buf, fmt, elem); #else // AVOID_SPRINTF_S return sprintf_s(buf, BufSize, fmt, elem); #endif // AVOID_SPRINTF_S } template <RoundTrip RT, typename Floating> void test_sprintf(const char* const str, const vector<Floating>& vec, const char* const fmt) { char buf[BufSize]; const auto start = steady_clock::now(); for (size_t k = 0; k < K; ++k) { for (const auto& elem : vec) { const int ret = sprintf_wrapper(buf, fmt, elem); global_dummy += static_cast<unsigned int>(ret); global_dummy += static_cast<unsigned int>(buf[0]); } } const auto finish = steady_clock::now(); printf("%6.1f ns | %s\n", duration<double, nano>{finish - start}.count() / (N * K), str); for (const auto& elem : vec) { verify(sprintf_wrapper(buf, fmt, elem) != -1); if constexpr (RT == RoundTrip::Lossy) { // skip lossy conversions } else if constexpr (is_same_v<Floating, float>) { verify(strtof(buf, nullptr) == elem); } else { verify(strtod(buf, nullptr) == elem); } } } #ifndef AVOID_CHARCONV constexpr chars_format chars_format_from_RoundTrip(const RoundTrip rt) { switch (rt) { case RoundTrip::Sci: return chars_format::scientific; case RoundTrip::Fix: return chars_format::fixed; case RoundTrip::Gen: return chars_format::general; case RoundTrip::Hex: return chars_format::hex; case RoundTrip::Lossy: default: puts("FAIL"); exit(EXIT_FAILURE); } } template <RoundTrip RT, typename Floating, typename... Args> void test_to_chars(const char* const str, const vector<Floating>& vec, const Args&... args) { char buf[BufSize]; const auto start = steady_clock::now(); for (size_t k = 0; k < K; ++k) { for (const auto& elem : vec) { const auto result = to_chars(buf, buf + BufSize, elem, args...); global_dummy += static_cast<unsigned int>(result.ptr - buf); global_dummy += static_cast<unsigned int>(buf[0]); } } const auto finish = steady_clock::now(); printf("%6.1f ns | %s\n", duration<double, nano>{finish - start}.count() / (N * K), str); for (const auto& elem : vec) { const auto result = to_chars(buf, buf + BufSize, elem, args...); verify(result.ec == errc{}); if constexpr (RT == RoundTrip::Lossy) { // skip lossy conversions } else { Floating round_trip; const auto from_result = from_chars(buf, result.ptr, round_trip, chars_format_from_RoundTrip(RT)); verify(from_result.ec == errc{}); verify(from_result.ptr == result.ptr); verify(round_trip == elem); } } } #endif // AVOID_CHARCONV template <RoundTrip RT, typename Floating> vector<char> prepare_strings(const vector<Floating>& vec) { vector<char> output; char buf[BufSize]; for (const auto& elem : vec) { int ret; if constexpr (RT == RoundTrip::Sci) { if constexpr (is_same_v<Floating, float>) { ret = sprintf_wrapper(buf, "%.8e", elem); } else { ret = sprintf_wrapper(buf, "%.16e", elem); } } else { static_assert(RT == RoundTrip::Hex); if constexpr (is_same_v<Floating, float>) { ret = sprintf_wrapper(buf, "%.6a", elem); } else { ret = sprintf_wrapper(buf, "%.13a", elem); } } verify(ret != -1); output.insert(output.end(), buf, buf + ret + 1); // include null terminator } return output; } template <typename Floating> void test_strtox(const char* const str, const vector<Floating>& original, const vector<char>& strings) { vector<Floating> round_trip(N); const auto start = steady_clock::now(); for (size_t k = 0; k < K; ++k) { const char* ptr = strings.data(); char* endptr = nullptr; for (size_t n = 0; n < N; ++n) { if constexpr (is_same_v<Floating, float>) { round_trip[n] = strtof(ptr, &endptr); } else { round_trip[n] = strtod(ptr, &endptr); } ptr = endptr + 1; // advance past null terminator } } const auto finish = steady_clock::now(); printf("%6.1f ns | %s\n", duration<double, nano>{finish - start}.count() / (N * K), str); verify(round_trip == original); } #ifndef AVOID_CHARCONV vector<char> erase_0x(const vector<char>& strings) { vector<char> output; output.reserve(strings.size() - 2 * N); for (auto i = strings.begin(); i != strings.end();) { if (*i == '-') { output.push_back('-'); i += 3; // advance past "-0x"; } else { i += 2; // advance past "0x"; } for (;;) { const char c = *i++; output.push_back(c); if (c == '\0') { break; } } } return output; } template <RoundTrip RT, typename Floating> void test_from_chars(const char* const str, const vector<Floating>& original, const vector<char>& strings) { const char* const last = strings.data() + strings.size(); vector<Floating> round_trip(N); const auto start = steady_clock::now(); for (size_t k = 0; k < K; ++k) { const char* first = strings.data(); for (size_t n = 0; n < N; ++n) { const auto from_result = from_chars(first, last, round_trip[n], chars_format_from_RoundTrip(RT)); first = from_result.ptr + 1; // advance past null terminator } } const auto finish = steady_clock::now(); printf("%6.1f ns | %s\n", duration<double, nano>{finish - start}.count() / (N * K), str); verify(round_trip == original); } #endif // AVOID_CHARCONV void test_all() { #if defined(__clang__) && defined(_M_IX86) const char* const toolset = "Clang/LLVM x86 + MSVC STL"; #elif defined(__clang__) && defined(_M_X64) const char* const toolset = "Clang/LLVM x64 + MSVC STL"; #elif !defined(__clang__) && defined(_M_IX86) const char* const toolset = "C1XX/C2 x86 + MSVC STL"; #elif !defined(__clang__) && defined(_M_X64) const char* const toolset = "C1XX/C2 x64 + MSVC STL"; #else const char* const toolset = "Unknown Toolset"; #endif puts(toolset); vector<float> vec_flt; vector<double> vec_dbl; { mt19937_64 mt64; vec_flt.reserve(N); while (vec_flt.size() < N) { const uint32_t val = static_cast<uint32_t>(mt64()); constexpr uint32_t inf_nan = 0x7F800000U; if ((val & inf_nan) == inf_nan) { continue; // skip INF/NAN } float flt; static_assert(sizeof(flt) == sizeof(val)); memcpy(&flt, &val, sizeof(flt)); vec_flt.push_back(flt); } vec_dbl.reserve(N); while (vec_dbl.size() < N) { const uint64_t val = mt64(); constexpr uint64_t inf_nan = 0x7FF0000000000000ULL; if ((val & inf_nan) == inf_nan) { continue; // skip INF/NAN } double dbl; static_assert(sizeof(dbl) == sizeof(val)); memcpy(&dbl, &val, sizeof(dbl)); vec_dbl.push_back(dbl); } } test_lexical_cast("Boost float", vec_flt); test_lexical_cast("Boost double", vec_dbl); test_sprintf<RoundTrip::Sci>("CRT float scientific 8", vec_flt, "%.8e"); test_sprintf<RoundTrip::Sci>("CRT double scientific 16", vec_dbl, "%.16e"); test_sprintf<RoundTrip::Lossy>("CRT float fixed 6 (lossy)", vec_flt, "%f"); test_sprintf<RoundTrip::Lossy>("CRT double fixed 6 (lossy)", vec_dbl, "%f"); test_sprintf<RoundTrip::Gen>("CRT float general 9", vec_flt, "%.9g"); test_sprintf<RoundTrip::Gen>("CRT double general 17", vec_dbl, "%.17g"); test_sprintf<RoundTrip::Hex>("CRT float hex 6", vec_flt, "%.6a"); test_sprintf<RoundTrip::Hex>("CRT double hex 13", vec_dbl, "%.13a"); #ifndef AVOID_CHARCONV test_to_chars<RoundTrip::Gen>("STL float plain shortest", vec_flt); test_to_chars<RoundTrip::Gen>("STL double plain shortest", vec_dbl); test_to_chars<RoundTrip::Sci>("STL float scientific shortest", vec_flt, chars_format::scientific); test_to_chars<RoundTrip::Sci>("STL double scientific shortest", vec_dbl, chars_format::scientific); test_to_chars<RoundTrip::Fix>("STL float fixed shortest", vec_flt, chars_format::fixed); test_to_chars<RoundTrip::Fix>("STL double fixed shortest", vec_dbl, chars_format::fixed); test_to_chars<RoundTrip::Gen>("STL float general shortest", vec_flt, chars_format::general); test_to_chars<RoundTrip::Gen>("STL double general shortest", vec_dbl, chars_format::general); test_to_chars<RoundTrip::Hex>("STL float hex shortest", vec_flt, chars_format::hex); test_to_chars<RoundTrip::Hex>("STL double hex shortest", vec_dbl, chars_format::hex); test_to_chars<RoundTrip::Sci>("STL float scientific 8", vec_flt, chars_format::scientific, 8); test_to_chars<RoundTrip::Sci>("STL double scientific 16", vec_dbl, chars_format::scientific, 16); test_to_chars<RoundTrip::Lossy>("STL float fixed 6 (lossy)", vec_flt, chars_format::fixed, 6); test_to_chars<RoundTrip::Lossy>("STL double fixed 6 (lossy)", vec_dbl, chars_format::fixed, 6); test_to_chars<RoundTrip::Gen>("STL float general 9", vec_flt, chars_format::general, 9); test_to_chars<RoundTrip::Gen>("STL double general 17", vec_dbl, chars_format::general, 17); test_to_chars<RoundTrip::Hex>("STL float hex 6", vec_flt, chars_format::hex, 6); test_to_chars<RoundTrip::Hex>("STL double hex 13", vec_dbl, chars_format::hex, 13); #endif // AVOID_CHARCONV puts("----------"); const vector<char> strings_sci_flt = prepare_strings<RoundTrip::Sci>(vec_flt); const vector<char> strings_sci_dbl = prepare_strings<RoundTrip::Sci>(vec_dbl); const vector<char> strings_hex_flt = prepare_strings<RoundTrip::Hex>(vec_flt); const vector<char> strings_hex_dbl = prepare_strings<RoundTrip::Hex>(vec_dbl); test_strtox("CRT strtof float scientific", vec_flt, strings_sci_flt); test_strtox("CRT strtod double scientific", vec_dbl, strings_sci_dbl); test_strtox("CRT strtof float hex", vec_flt, strings_hex_flt); test_strtox("CRT strtod double hex", vec_dbl, strings_hex_dbl); #ifndef AVOID_CHARCONV test_from_chars<RoundTrip::Sci>("STL from_chars float scientific", vec_flt, strings_sci_flt); test_from_chars<RoundTrip::Sci>("STL from_chars double scientific", vec_dbl, strings_sci_dbl); test_from_chars<RoundTrip::Hex>("STL from_chars float hex", vec_flt, erase_0x(strings_hex_flt)); test_from_chars<RoundTrip::Hex>("STL from_chars double hex", vec_dbl, erase_0x(strings_hex_dbl)); #endif // AVOID_CHARCONV printf("global_dummy: %u\n", global_dummy); } int main() { try { test_all(); } catch (const exception& e) { printf("Exception: %s\n", e.what()); } catch (...) { printf("Unknown exception.\n"); } } C:\Temp>cl /std:c++17 /EHsc /nologo /W4 /MT /O2 /Iboost_1_82_0 charconv.cpp && charconv charconv.cpp C1XX/C2 x64 + MSVC STL 452.3 ns | Boost float 1003.0 ns | Boost double 222.7 ns | CRT float scientific 8 381.3 ns | CRT double scientific 16 231.3 ns | CRT float fixed 6 (lossy) 818.3 ns | CRT double fixed 6 (lossy) 260.1 ns | CRT float general 9 807.6 ns | CRT double general 17 96.0 ns | CRT float hex 6 117.4 ns | CRT double hex 13 32.1 ns | STL float plain shortest 39.9 ns | STL double plain shortest 31.2 ns | STL float scientific shortest 39.7 ns | STL double scientific shortest 37.6 ns | STL float fixed shortest 111.7 ns | STL double fixed shortest 31.8 ns | STL float general shortest 39.9 ns | STL double general shortest 14.9 ns | STL float hex shortest 18.3 ns | STL double hex shortest 48.9 ns | STL float scientific 8 57.4 ns | STL double scientific 16 35.2 ns | STL float fixed 6 (lossy) 93.2 ns | STL double fixed 6 (lossy) 59.4 ns | STL float general 9 70.4 ns | STL double general 17 16.2 ns | STL float hex 6 19.1 ns | STL double hex 13 ---------- 103.7 ns | CRT strtof float scientific 191.2 ns | CRT strtod double scientific 56.6 ns | CRT strtof float hex 86.0 ns | CRT strtod double hex 77.2 ns | STL from_chars float scientific 154.3 ns | STL from_chars double scientific 26.2 ns | STL from_chars float hex 30.1 ns | STL from_chars double hex global_dummy: 3715056096 Hope this helps, STL

1 0

Re: [boost] New Website !
by Ion Gaztañaga 11 May '23

11 May '23

On 11/05/2023 19:35, Glen Fernandes via Boost wrote: > On Thu, May 11, 2023 at 10:35 AM Vinnie Falco wrote: > >> Hey, it’s Vinnie here again! I have some very exciting news to share >> with you. The renovated website for Boost that we’ve been working on >> for far too long is now going into its Public Beta phase! Feel free to >> poke around and kick the tires but keep in mind this is a piece of >> software and it is still under development. Some parts are missing, >> incomplete,or buggy. Without further ado: >> >> https://boost.revsys.dev > > Thank you for working on this. The mechanics of this site are already > impressive, and the dark mode design looks very nice (the Boost logo, > theme, and all) even in its beta form. New documentation for Boost users > about building and installing Boost, and for potential Boost authors about > contributing to Boost development is also great to see. > > If anyone else viewing this like me has their system detected by the site > as "light themed", then view the site in the dark mode. It has a much > better look, and apparently the light mode design is still in progress. > > When the site is more developed, I can make sure that the release > information also gets published to the new site. > > Glen I also would like to thank everyone pushing the new website, Boost needs a more modern one. The release notes page seems hard to parse, though: https://www.boost.revsys.dev/releases/ Maybe a bit of separation between libraries (and marking libraries with some bold or underlinining) can help a bit. Or if the library changes list is a bit long, a TOC section could also help. Best, Ion

1 0

Re: [boost] charconv for C++11
by Peter Dimov 11 May '23

11 May '23

Robert Ramey wrote: > We convert character arrays into built-in arithmetic types and vice versa. > That’s it. > > I believe that this is what lexical_cast does. It might be different in that other > than using arrays it uses strings. lexical_cast can convert any streamable type to any other streamable type. It's defined as `ss << input; ss >> output; return output;` where `ss` is a default-constructed `std::stringstream`. This has a number of implications. One, the conversion is locale-dependent. Two, for conversion to string, you use lexical_cast<std::string>, which can allocate. Three, errors are signaled via exceptions (although there's try_lexical_convert that can avoid this.) lexical_cast does a good job of optimizing the from_chars and to_chars cases when it detects it can do so, but that by definition can't be better than the programmer just calling the primitive operations from_chars and to_chars directly, as they are (a) locale-independent, (b) non- allocating, (c) non-throwing. In addition to all that, from/to_chars are standard C++17, so Charconv can be used by libraries that want to support C++11 (or 14) today, but at the same time want to be able to switch to the standard functions later when increasing the minimal supported standard to C++17.

1 0

Re: [boost] charconv for C++11
by Andrzej Krzemienski 11 May '23

11 May '23

On Wed, May 10, 2023, 19:42 Peter Dimov via Boost <boost(a)lists.boost.org> wrote: > Matt Borland wrote: > > > On May 10, 2023, at 5:42 PM, Dominique Devienne > > <ddevienne(a)gmail.com> wrote: > > > > > > On Wed, May 10, 2023 at 4:01 PM Matt Borland via Boost > > <boost(a)lists.boost.org> wrote: > > > > > >> [...] We use errno rather than std::error_code as specified in the > standard. > > > > > > Hi. Sounded like a good candidate for Boost.Compat (or > > > Boost.Polyfill), discussed recently, until that sentence. I'm lucky > > > enough to be able to use > > > C++17 at work, but if I was on C++11, I'd tend to use such a library > > > C++until > > > I could use the std one, so deviations like this would complicate > > > adoption because moving to std would then be harder. My $0.02. —DD > > > > Dominique, > > > > Thanks for the response. We discussed Boost.Compat but decided it is > outside > > of the scope. For instance <latch> is what set off the discussion and it > can be > > implemented in ~100 LOC. This implementation of charconv will be around > > 10k LOC so it should be in its own library. If the demand signal is to > use > > std::error_code instead of errno we can make the change. > > boost/charconv.hpp was initially supposed to be a very light header (with > only > a few declarations), but since from/to_chars for integral types were moved > to the headers because of constexpr, What is the connection between constexpr and moving things to headers? Regards, &rzej; that's no longer the case, so we can > probably afford the inclusion of <system_error> without anyone noticing. > > (Note that std::from/to_chars use std::errc, not std::error_code.) > > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >

2 1

Extra file in boost serialization for 1.82.0
by Bryan St. Amour 11 May '23

11 May '23

Hi, I noticed that under boost/serialization, there is a file "collection_size_type copy.hpp" (notice the space in the file name.) Comparing it with the contents of collection_size_type.hpp, it looks like "collection_size_type copy.hpp" is newer. Can someone verify which one is the correct collection_size_type header file? Thanks, Bryan

1 0

Re: [boost] New Website !
by Glen Fernandes 11 May '23

11 May '23

On Thu, May 11, 2023 at 10:35 AM Vinnie Falco wrote: > Hey, it’s Vinnie here again! I have some very exciting news to share > with you. The renovated website for Boost that we’ve been working on > for far too long is now going into its Public Beta phase! Feel free to > poke around and kick the tires but keep in mind this is a piece of > software and it is still under development. Some parts are missing, > incomplete,or buggy. Without further ado: > > https://boost.revsys.dev Thank you for working on this. The mechanics of this site are already impressive, and the dark mode design looks very nice (the Boost logo, theme, and all) even in its beta form. New documentation for Boost users about building and installing Boost, and for potential Boost authors about contributing to Boost development is also great to see. If anyone else viewing this like me has their system detected by the site as "light themed", then view the site in the dark mode. It has a much better look, and apparently the light mode design is still in progress. When the site is more developed, I can make sure that the release information also gets published to the new site. Glen

1 0

Re: [boost] charconv for C++11
by Robert Ramey 11 May '23

11 May '23

On 5/11/23 7:40 AM, Matt Borland via Boost wrote: >> How is this different from boost lexical cast? > > Robert, > > Charconv has a much smaller scope than lexical cast. We convert character arrays into built-in arithmetic types and vice versa. That’s it. I believe that this is what lexical_cast does. It might be different in that other than using arrays it uses strings. Since it has such a narrow scope we can heavily optimize these conversions, Honestly, I don't see how the scope is that much narrower than lexical_cast. which we have sunk a lot of time and effort into. I presume you're referring to charconv and not lexical_cast here. I don't question anyone's commitment, motives or competence in their efforts to contributing to boost. But this is not in itself an argument for accepting or rejecting a boost library submission. Thinking ahead a little bit, I'd have the following questions which might be brought up were such a component come up for review. a) How is this different from boost lexical cast? https://theboostcpplibraries.com/boost.lexical_cast. b) What will be the difference in user experience? c) if it's very similar, why wouldn't it be better to just enhance/refine/improve/correct lexical_cast itself? d) lexical cast uses an implementation strategy of leveraging C++ standard io library. This is a header only library which presumably, results in code highly optimized at compile time. Also it doesn't add any dependencies other than the standard library itself. Of course this optimization and hence performance will vary from one standard library/compiler implementation to another. But the same question applies to code written from scratch. Robert Ramey > > Matt > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Re: [boost] charconv for C++11
by Matt Borland 11 May '23

11 May '23

On Thu, May 11, 2023 at 17:16, Andrey Semashev via Boost <[boost@lists.boost.org](mailto:On Thu, May 11, 2023 at 17:16, Andrey Semashev via Boost <<a href=)> wrote: > On 5/11/23 17:40, Matt Borland via Boost wrote: >>> How is this different from boost lexical cast? >> >> Robert, >> >> Charconv has a much smaller scope than lexical cast. We convert character arrays into built-in arithmetic types and vice versa. That’s it. Since it has such a narrow scope we can heavily optimize these conversions, which we have sunk a lot of time and effort into. > > I remember there were a lot of optimizations poured into > Boost.Spirit.Qi/Karma. How does your library compare to those > implementations? > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Andrey, Frankly I’ve never looked at Boost.Spirit before. I can add comparison benchmarks to the charconv docs. Matt

1 0

Re: [boost] charconv for C++11
by Andrey Semashev 11 May '23

11 May '23

On 5/11/23 17:21, Vinnie Falco via Boost wrote: > On Thu, May 11, 2023 at 6:50 AM Robert Ramey via Boost > <boost(a)lists.boost.org> wrote: >> How is this different from boost lexical cast? > > Oh wow this has got to be one of the most amusing things posted to the > mailing list this year with the exception of the mathematical > breakthrough post which attached a gif of the author's monitor showing > the source code instead of providing a github link. I see nothing funny about Robert's post. Asking for comparison with existing solutions is a very reasonable request.

1 0

Re: [boost] charconv for C++11
by Andrey Semashev 11 May '23

11 May '23

On 5/11/23 17:40, Matt Borland via Boost wrote: >> How is this different from boost lexical cast? > > Robert, > > Charconv has a much smaller scope than lexical cast. We convert character arrays into built-in arithmetic types and vice versa. That’s it. Since it has such a narrow scope we can heavily optimize these conversions, which we have sunk a lot of time and effort into. I remember there were a lot of optimizations poured into Boost.Spirit.Qi/Karma. How does your library compare to those implementations?

1 0

Re: [boost] charconv for C++11
by Matt Borland 11 May '23

11 May '23

> How is this different from boost lexical cast? Robert, Charconv has a much smaller scope than lexical cast. We convert character arrays into built-in arithmetic types and vice versa. That’s it. Since it has such a narrow scope we can heavily optimize these conversions, which we have sunk a lot of time and effort into. Matt

1 0

New Website !
by Vinnie Falco 11 May '23

11 May '23

Hey, it’s Vinnie here again! I have some very exciting news to share with you. The renovated website for Boost that we’ve been working on for far too long is now going into its Public Beta phase! Feel free to poke around and kick the tires but keep in mind this is a piece of software and it is still under development. Some parts are missing, incomplete,or buggy. Without further ado: https://boost.revsys.dev This public beta will extend for at least 10 weeks as we finish the last remaining features, and put a few more rounds of polish on the artwork, visual styling, and user interface. After that if you like what you see then we will reset the database, move the repositories and the site to their new homes, and then deploy it for real! If you have suggestions or wish to report problems please feel welcome to open an issue here: https://github.com/cppalliance/temp-site/issues This is a Django site written and maintained in Python by a great group of folks from https://www.revsys.com/. The project is coordinated by Frank Wiles (https://www.revsys.com/about/bio/frankwiles) who shares the same deep commitment to open source that we Boost people do. We chose Django because it is well understood and supported, and because Python composes well with ease of maintenance. This technology stack allows us to execute on our future plans with confidence. Some cool things about this website include: * Log in with GitHub or Google * Light and Dark themes with selector * Asciidoc markdown for dynamic content * Antora content sources for site documentation * Data-driven dynamic pages for libraries and releases * Integrated control panel for producing Boost releases * Full-text search across the documentation and library headers * Professionally designed logo to evoke identity and instant recognition The layout of the site is carefully thought out to make sure that information can be found quickly. Fundamental topics each get a dedicated word in the top level navigation, visible on every page including the site and library documentation. Most of the information which is not library-specific is warehoused in “site docs” which is a collection of individual Antora content sources each authored in Asciidoc. Anyone can update the information on the website simply by contributing to the site-docs via pull request: https://github.com/cppalliance/site-docs Antora and Asciidoc are potent technologies that offer Boost plenty of room to grow to make our site documentation and library documentation more effective for users. While the initial release of the website after the beta will only have the basic functionality, we have many future plans. Some of these you have heard about already and some are new: * A web-based forum which interacts seamlessly with the mailing list * Polls and surveys for measuring the sentiment of Boost users and stakeholders * News section for aggregating off-site links, blog posts, and release progress messages * Integrated Review process. Outcomes go in the database and become dynamic content. * User Profiles record and show activity such as review participation or library submission We’re all very excited and proud of the work that went into this thing and hope that it really fulfills the positive impact that we intended. Thanks! Vinnie

1 0

Re: [boost] charconv for C++11
by Vinnie Falco 11 May '23

11 May '23

On Thu, May 11, 2023 at 6:50 AM Robert Ramey via Boost <boost(a)lists.boost.org> wrote: > How is this different from boost lexical cast? Oh wow this has got to be one of the most amusing things posted to the mailing list this year with the exception of the mathematical breakthrough post which attached a gif of the author's monitor showing the source code instead of providing a github link. Thanks

1 0

Re: [boost] charconv for C++11
by Robert Ramey 11 May '23

11 May '23

On 5/10/23 4:08 PM, Gavin Lambert via Boost wrote: > On 11/05/2023 02:01, Matt Borland wrote: >> What does charconv do? It converts a character sequence into a number >> (from_chars) or converts a number into a character sequence >> (to_chars). How is this different from boost lexical cast? Robert Ramey

1 0

Re: [boost] charconv for C++11
by Gavin Lambert 10 May '23

10 May '23

On 11/05/2023 02:01, Matt Borland wrote: > What does charconv do? It 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 a few 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. "Roundtrip guarantee" and "specify format/precision" appear to be contradictory goals.

1 0

Re: [boost] charconv for C++11
by Peter Dimov 10 May '23

10 May '23

Matt Borland wrote: > > On May 10, 2023, at 5:42 PM, Dominique Devienne > <ddevienne(a)gmail.com> wrote: > > > > On Wed, May 10, 2023 at 4:01 PM Matt Borland via Boost > <boost(a)lists.boost.org> wrote: > > > >> [...] We use errno rather than std::error_code as specified in the standard. > > > > Hi. Sounded like a good candidate for Boost.Compat (or > > Boost.Polyfill), discussed recently, until that sentence. I'm lucky > > enough to be able to use > > C++17 at work, but if I was on C++11, I'd tend to use such a library > > C++until > > I could use the std one, so deviations like this would complicate > > adoption because moving to std would then be harder. My $0.02. —DD > > Dominique, > > Thanks for the response. We discussed Boost.Compat but decided it is outside > of the scope. For instance <latch> is what set off the discussion and it can be > implemented in ~100 LOC. This implementation of charconv will be around > 10k LOC so it should be in its own library. If the demand signal is to use > std::error_code instead of errno we can make the change. boost/charconv.hpp was initially supposed to be a very light header (with only a few declarations), but since from/to_chars for integral types were moved to the headers because of constexpr, that's no longer the case, so we can probably afford the inclusion of <system_error> without anyone noticing. (Note that std::from/to_chars use std::errc, not std::error_code.)

1 0

Re: [boost] charconv for C++11
by Dominique Devienne 10 May '23

10 May '23

On Wed, May 10, 2023 at 4:01 PM Matt Borland via Boost < boost(a)lists.boost.org> wrote: > [...] We use errno rather than std::error_code as specified in the > standard. Hi. Sounded like a good candidate for Boost.Compat (or Boost.Polyfill), discussed recently, until that sentence. I'm lucky enough to be able to use C++17 at work, but if I was on C++11, I'd tend to use such a library until I could use the std one, so deviations like this would complicate adoption because moving to std would then be harder. My $0.02. --DD

2 1

charconv for C++11
by Matt Borland 10 May '23

10 May '23

I’m Matt Borland, who many might recognize from my work in Boost.Math and fewer might know from Boost.Multiprecision. I’m putting the finishing touches on a new library that I hope will become part of Boost, after a successful formal review. This library is essentially already part of C++17 and later but in the Boost tradition we wish to provide it for users and other Boost libraries that want to fully support C++14 or C++11. What does charconv do? It 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 a few 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. Third, it is much easier to check for errors. Strtod has a few different ways of reporting different errors whereas the results of to_chars returns an error code from errno. Using this is no different from POSIX where you check for 0 and then move on. We use errno rather than std::error_code as specified in the standard. This allows us to avoid including <system_error> and is more ergonomic. Lastly, charconv is significantly more performant than strtod and printf. We utilize algorithms derived from Daniel Lemire’s “Number Parsing at a Gigabyte per Second” and Junkey Jeon’s Dragonbox. You can read about those here: https://arxiv.org/abs/2101.11408 https://github.com/jk-jeon/dragonbox And here are a number of example snippets: https://develop.charconv.cpp.al/ As of now the library supports all built-in integer types, signed and unsigned __int128, float, and double. I am striving to add support for long doubles (64, 80, and 128-bit) to both from_chars and to_chars. With these in hand I have a mind to experiment with integrating this into Boost.JSON, which for lack of a better phrase, sure could use a bit of help with its conversions between IEEE floats and decimal strings. This will also help with checking our validation, accuracy, and performance. If you want to check out the library it is here: [https://github.com/cppalliance/charconv](https://github.com/CPPAlliance/cha… It is designed to be built and used in the Boost superproject. This means that if you want to clone it, you should place the repository in the libs/charconv directory of your local superproject. Feel free to hammer on it, and report any errors or performance issues that you run into. Also if you find the docs could use improvement please open an issue so that we can address it. These will help us ensure that we have the highest quality product before attempting to pass a formal review for inclusion in Boost. Thank you for your time. Matt Borland

1 0

Re: [boost] Full-Text Boost Search
by Vinnie Falco 10 May '23

10 May '23

On Wed, May 10, 2023 at 1:46 AM Antony Polukhin via Boost <boost(a)lists.boost.org> wrote: > Adding support of it to Doxygen should do the job of implementing both > searches and helping the C++ community in general. To add some context to what Mohammad is saying, I've been using Doxygen for years as part of my "docca" toolchain for building C++ library reference pages. For example: https://www.boost.org/doc/libs/1_82_0/libs/json/doc/html/json/ref/boost__js… I've reached the limit of what Doxygen is capable of and now it is blocking the improvement of documentation. Doxygen's XML output is always behind the HTML output, and there is no really good Asciidoc output. Furthermore Doxygen uses outdated technology for analyzing the C++ program. That is why I have created a new program called "Mr. Dox." This program uses clang's unstable libtooling API to generate an AST tree of a library's actual translation units (the .cpp files) and not just looking at headers using fancy regex or the simplified libclang API. Some discussion on that: https://www.foonathan.net/2019/11/standardese-post-mortem/ Because MrDox uses the exact same API that clang uses to actually compile your program, it can understand every C++ construct. If clang can compile it, then MrDox can see it. That means we can see deduction guides, alias templates, class template specializations, and much much more. The capability of extracting C++ source code features with perfect fidelity allows us to build features which enhance the generated reference in ways that Doxygen never can. For example we can recurse deeply into the AST and analyze the expression inside a conditional noexcept specification. We can understand abbreviated function template parameters. In fact, MrDox can eventually understand C++ features which are not yet part of the Standard but merged into the trunk of LLVM because they are supported by Technical Specifications ("TS") approved by the C++ Standardization Committee. This means MrDox can always stay current and keep pace with every innovation that comes to C++. The program is still in development but we are targeting the winter release date of Boost for having an packaged executable that is ready for production, with a good Asciidoc generator. Check it out here: https://github.com/cppalliance/mrdox Thanks! Vinnie

1 0

Re: [boost] Web documentation question
by Marshall Clow 10 May '23

10 May '23

> On May 10, 2023, at 2:43 AM, Alain O' Miniussi via Boost <boost(a)lists.boost.org> wrote: > > Hi, > > I sometime need to contribute to boost but it is clearly not a regular activity. > And each time it takes me an unreasonable amount of time just to find the relevant git clone command. > > I would like to know if something is inherently wrong with: > 1) go to www.boost.org > 2) unfold the "Development" menu on the right > 3) hope to find the information regarding the development cycle > > right now, these sections mostly contains pages with link the the wiki, which is expected to be at svn.boost.org which cannot be reached. > > If the information is actually at https://github.com/boostorg/wiki/wiki/Getting-Started%3A-Overview (thanks you stackoverflow) why isn't that page referenced from https://www.boost.org/development/index.html or https://github.com/boostorg/boost ? Thank you for bringing this to my (our?) attention. I am currently attending C++Now, and have no time to deal with this this week, but I have created https://github.com/boostorg/website/issues/754 <https://github.com/boostorg/website/issues/754> to track this so it will not be lost. — Marshall

1 0

Re: [boost] Full-Text Boost Search
by Antony Polukhin 10 May '23

10 May '23

On Tue, May 9, 2023, 17:16 Mohammad Nejati [Ashtum] via Boost < boost(a)lists.boost.org> wrote: <...> > Thank you for your time, and I look forward to your suggestions and > feedback. > There's a way to implement fulltext search for the whole C++ community and make the C++ docs much better worldwide. The Doxygen tool for building the docs from C++ sources has a long standing issue to implement fulltext client search https://github.com/doxygen/doxygen/issues/4111 Recently (at leats for me) a JS library appeard. With Lunar.js you could do server side searches with node.js and client side searches. Adding support of it to Doxygen should do the job of implementing both searches and helping the C++ community in general. >

2 1

Web documentation question
by Alain O' Miniussi 10 May '23

10 May '23

Hi, I sometime need to contribute to boost but it is clearly not a regular activity. And each time it takes me an unreasonable amount of time just to find the relevant git clone command. I would like to know if something is inherently wrong with: 1) go to www.boost.org 2) unfold the "Development" menu on the right 3) hope to find the information regarding the development cycle right now, these sections mostly contains pages with link the the wiki, which is expected to be at svn.boost.org which cannot be reached. If the information is actually at https://github.com/boostorg/wiki/wiki/Getting-Started%3A-Overview (thanks you stackoverflow) why isn't that page referenced from https://www.boost.org/development/index.html or https://github.com/boostorg/boost ? Thanks ---- Alain Miniussi DSI, Pôles Calcul et Genie Log. Observatoire de la Côte d'Azur Tél. : +33492003009 (Mont-Gros) +33483618544 (Sophia Antipolis) +33609650665

1 0

Re: [boost] The Future of Boost - CI
by René Ferdinand Rivera Morell 10 May '23

10 May '23

On Tue, May 9, 2023 at 4:21 PM Vinnie Falco via Boost <boost(a)lists.boost.org> wrote: > > On Tue, May 9, 2023 at 2:04 PM Tom Kent via Boost <boost(a)lists.boost.org> wrote: > > I'm happy to go with whatever the community is looking to do on this front. > > Some options as I see it: > > > > * Keep the current test matrix as a compliment to the various CI systems > > starting to roll out. > > * Merge my runner system in with the new C++ Alliance CI system > > * Shutdown the test matrix and move fully to C++ Alliance cloud CI > > We haven't put any thought or effort into how our CI might interface > with the test matrix, so I think for now the best strategy is no > strategy: Keep things as they are. > > But... since we are talking about it, my inner tech geek is tickled by > the idea of a decentralized network of runners using authors', > maintainers', and contributors' already existing commodity hardware to > run a specially prepared docker container that tests some > configurations of boost libraries and reports the results to a central > server. > > While the execution of the current test matrix is somewhat flawed, I > think the idea behind it is actually rather brilliant. In exchange for > much longer turnaround times we get a depth of coverage that cannot be > matched on cloud systems. And it is basically "free" since the > computing model is inverted: the expensive compilation and testing is > performed by numerous cheap developer machines with spare cycles, > while the cheap collation and presentation of the results is handled > by the cloud. > > If we are going to improve the test matrix I think the way to do it is > to treat it like any other software project. Assemble a team and start > writing maintainable code with documentation. We probably want to use > some off the shelf solution for deploying runners on people's PCs and > laptops, and then write our own set of scripts and dockerfiles (?) > which spread around the testing of all the different configurations of > the libraries. > > The most important part of this software project is to address the > headaches of the current system: when there is a failure, it is > difficult (and often impossible) to diagnose from the logs. There are > many false positives and noisy things like warnings which have no > possible resolution, and so on. In other words we will need to be able > to open issues on the test matrix software, triage them, get the fixes > for them in, have them tested, and then deploy a new version just like > every other software project. Once upon a time, while I was still the Testing Manager, I had the same idea and partially implemented it to run on Google cloud data services. But I just ran out of time and interest after that thing that happened. -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supone Nada -- Robot Dreams - http://robot-dreams.net

1 0

Re: [boost] The Future of Boost
by Vladimir Batov 10 May '23

10 May '23

Vinnie, thank you for putting it all together and sharing. Interesting, educational, entertaining and sobering read. Your enthusiasm and work are encouraging, commendable and promising. Very impressive and hugely appreciated. 30 years ago I'd rolled the sleeves up and jumped in. Now I wish you and your efforts all the success and the very best. Will keep fingers crossed. Thanks again. On 2023-05-09 01:46, Vinnie Falco via Boost wrote: > Greetings! > > I'm Vinnie Falco, Boost library author, C++ enthusiast, and the > founder of The C++ Alliance, a 501(c)(3) non-profit...

2 1

Re: [boost] The Future of Boost - CI
by Robert Ramey 09 May '23

09 May '23

On 5/9/23 2:03 PM, Tom Kent via Boost wrote: Let me say that you're efforts are very, very much appreciated. This is the only testing system which has worked (more or less) reliably over years. It is the only thing I feel I can actually trust. How long have you been doing this? Seems to me that it's been since I made the serialization library in 2003? Was it you that set this up and has kept it up for 20 years? It's tribute to your capability that it works so invisibility that we don't even know much about who you are. > On Mon, May 8, 2023 at 5:22 PM Andrey Semashev via Boost < > boost(a)lists.boost.org> wrote: > >> On 5/8/23 20:40, John Maddock via Boost wrote: >> >>> Machine time could well be donated by volunteers and perhaps replace the >>> current test/status matrix, which is fine, but requires you to go off >>> seeking for results, which may or may not have cycled yet. Plus that >>> matrix relies on a "build the whole of Boost" approach which >>> increasingly simply does not scale. >> >> I'm really grateful to the volunteers that run the tests and maintain >> the official test matrix, but honestly, I'm not paying attention to it >> anymore. I have three main issues with it: >> >> 1. Slow turnaround. From my memory, it could take weeks or more for the >> runners to run the tests over a commit I made. With this order of times, >> it is impossible to perform continued development while maintaining code >> in working state. >> >> 2. Lack of notifications. >> >> 3. Problematic debugging. It was not uncommon that a test run failed >> because of some misconfiguration on the runner's side. And it was also >> not uncommon that build logs were unavailable. >> >> So, while, again, I'm most grateful to the people that made public >> testing possible at all before we had the current CI services, today we >> do have CI services with the above problems fixed (more or less), and >> I'm spoiled by them. It is true that the public CI resources are limited >> and insufficient at times, so, IMHO, the way forward would be towards >> fixing this problem without losing the convenience of the CI services >> we've become used to. >> > > As the person responsible for most (currently all) of the test runners in > the official test matrix, I thought I'd throw a couple cents in here. > > I currently have three machines running these tests. These machines were > purchased by boost (then from SFC) in 2017, and are a bit old but still > running well. > > One of the machines is running windows server, it cycles running through > the last six versions of visual studio (plus the latest one with > `/std:c++latest`) for develop + master. > > The two other machines are linux runners. One of them just runs the latest > version of clang + gcc for develop + master, at about 2hr a pop there > should never be a commit that goes more than ~8hr without one of these > configurations running. > > The other machine runs a *huge* number (>150) of gcc/clang configs. This > takes approximately a week to get through all of them, but provides a > breadth of testing that isn't available anywhere else. See the table in > this readme [1] for the full list, as well as a bit more about the runners. > > To address a bit of #3 above, these are fully running on docker containers, > I'd be more than happy to add other users configs to this list. > > I've also got a couple raspberry pi machines running gcc + clang / > develop + master, but they are *very* slow (20hrs?). I've also got a > RISC-V SBC that I want to get this going on, but haven't found the time yet. > Architecture *shouldn't* matter for most of what we do, but there are a > couple edge cases where it can be useful. > > > > I don't spend a lot of time on caring and feeding of this, so would be > happy to keep it going in the future...but the down side of that is that > there have been (and I'm sure will continue to be) instances where things > break and go unnoticed for weeks. (I just noticed MSVC has been failing > all the develop runs for weeks, almost certainly a config issue on my end) > I wouldn't think this would be too difficult to address. Maybe we can get someone to write some sort of watchdog, ... if it doesn't exist already. > > All that said, I'm not sure where this fits into the picture going forward. > > Andrey's points above (esp. 2&3) are very valid. I wouldn't depend on a CI > system like this in my day-job. > > There are plenty more issues with the system as well...specifically: > * Tons of time wasted re-building things that haven't changed (sometimes > for years!) > * No history saved beyond the most recent build > * Processing of results a centralized point of failure > > > > I'm happy to go with whatever the community is looking to do on this front. > Some options as I see it: > > * Keep the current test matrix as a compliment to the various CI systems > starting to roll out. > * Merge my runner system in with the new C++ Alliance CI system > * Shutdown the test matrix and move fully to C++ Alliance cloud CI > Contrary to information reported on this list, the current CI system does not work. For typical example see: https://github.com/boostorg/serialization/pull/282 So your work is currently irreplaceable. If we have resources, I'd like to see some enhancements in the current test matrix.. a) I made my own version of the test matrix html generator which organizes the test results by compiler/static vs dynamic/debug vs release, etc. etc. https://github.com/robertramey/library_status#library_status It's derived from the current test matrix display code. I'd like to see it evaluated as a replacement. b) accumulate past test results for a time. Permit them to be queried by compiler, date range, static vs dynamic, etc... c) Permit test results run on user machines to be uploaded to the results database. Note that b) and c) are what Cmake test does and it's very useful. This permits test results on configurations actually being used to be included in the matrix. Of course I'm not expecting you to do this. I'm suggesting that "someone" do this this. Thanks again for all your work. Robert Ramey > Tom > > > [1]https://github.com/teeks99/boost-build/blob/master/Regression/README.md > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Re: [boost] The Future of Boost - CI
by Vinnie Falco 09 May '23

09 May '23

On Tue, May 9, 2023 at 2:04 PM Tom Kent via Boost <boost(a)lists.boost.org> wrote: > I'm happy to go with whatever the community is looking to do on this front. > Some options as I see it: > > * Keep the current test matrix as a compliment to the various CI systems > starting to roll out. > * Merge my runner system in with the new C++ Alliance CI system > * Shutdown the test matrix and move fully to C++ Alliance cloud CI We haven't put any thought or effort into how our CI might interface with the test matrix, so I think for now the best strategy is no strategy: Keep things as they are. But... since we are talking about it, my inner tech geek is tickled by the idea of a decentralized network of runners using authors', maintainers', and contributors' already existing commodity hardware to run a specially prepared docker container that tests some configurations of boost libraries and reports the results to a central server. While the execution of the current test matrix is somewhat flawed, I think the idea behind it is actually rather brilliant. In exchange for much longer turnaround times we get a depth of coverage that cannot be matched on cloud systems. And it is basically "free" since the computing model is inverted: the expensive compilation and testing is performed by numerous cheap developer machines with spare cycles, while the cheap collation and presentation of the results is handled by the cloud. If we are going to improve the test matrix I think the way to do it is to treat it like any other software project. Assemble a team and start writing maintainable code with documentation. We probably want to use some off the shelf solution for deploying runners on people's PCs and laptops, and then write our own set of scripts and dockerfiles (?) which spread around the testing of all the different configurations of the libraries. The most important part of this software project is to address the headaches of the current system: when there is a failure, it is difficult (and often impossible) to diagnose from the logs. There are many false positives and noisy things like warnings which have no possible resolution, and so on. In other words we will need to be able to open issues on the test matrix software, triage them, get the fixes for them in, have them tested, and then deploy a new version just like every other software project. Thanks

1 0

Re: [boost] The Future of Boost - CI
by Tom Kent 09 May '23

09 May '23

On Mon, May 8, 2023 at 5:22 PM Andrey Semashev via Boost < boost(a)lists.boost.org> wrote: > On 5/8/23 20:40, John Maddock via Boost wrote: > > > Machine time could well be donated by volunteers and perhaps replace the > > current test/status matrix, which is fine, but requires you to go off > > seeking for results, which may or may not have cycled yet. Plus that > > matrix relies on a "build the whole of Boost" approach which > > increasingly simply does not scale. > > I'm really grateful to the volunteers that run the tests and maintain > the official test matrix, but honestly, I'm not paying attention to it > anymore. I have three main issues with it: > > 1. Slow turnaround. From my memory, it could take weeks or more for the > runners to run the tests over a commit I made. With this order of times, > it is impossible to perform continued development while maintaining code > in working state. > > 2. Lack of notifications. > > 3. Problematic debugging. It was not uncommon that a test run failed > because of some misconfiguration on the runner's side. And it was also > not uncommon that build logs were unavailable. > > So, while, again, I'm most grateful to the people that made public > testing possible at all before we had the current CI services, today we > do have CI services with the above problems fixed (more or less), and > I'm spoiled by them. It is true that the public CI resources are limited > and insufficient at times, so, IMHO, the way forward would be towards > fixing this problem without losing the convenience of the CI services > we've become used to. > As the person responsible for most (currently all) of the test runners in the official test matrix, I thought I'd throw a couple cents in here. I currently have three machines running these tests. These machines were purchased by boost (then from SFC) in 2017, and are a bit old but still running well. One of the machines is running windows server, it cycles running through the last six versions of visual studio (plus the latest one with `/std:c++latest`) for develop + master. The two other machines are linux runners. One of them just runs the latest version of clang + gcc for develop + master, at about 2hr a pop there should never be a commit that goes more than ~8hr without one of these configurations running. The other machine runs a *huge* number (>150) of gcc/clang configs. This takes approximately a week to get through all of them, but provides a breadth of testing that isn't available anywhere else. See the table in this readme [1] for the full list, as well as a bit more about the runners. To address a bit of #3 above, these are fully running on docker containers, I'd be more than happy to add other users configs to this list. I've also got a couple raspberry pi machines running gcc + clang / develop + master, but they are *very* slow (20hrs?). I've also got a RISC-V SBC that I want to get this going on, but haven't found the time yet. Architecture *shouldn't* matter for most of what we do, but there are a couple edge cases where it can be useful. I don't spend a lot of time on caring and feeding of this, so would be happy to keep it going in the future...but the down side of that is that there have been (and I'm sure will continue to be) instances where things break and go unnoticed for weeks. (I just noticed MSVC has been failing all the develop runs for weeks, almost certainly a config issue on my end) All that said, I'm not sure where this fits into the picture going forward. Andrey's points above (esp. 2&3) are very valid. I wouldn't depend on a CI system like this in my day-job. There are plenty more issues with the system as well...specifically: * Tons of time wasted re-building things that haven't changed (sometimes for years!) * No history saved beyond the most recent build * Processing of results a centralized point of failure I'm happy to go with whatever the community is looking to do on this front. Some options as I see it: * Keep the current test matrix as a compliment to the various CI systems starting to roll out. * Merge my runner system in with the new C++ Alliance CI system * Shutdown the test matrix and move fully to C++ Alliance cloud CI Tom [1]https://github.com/teeks99/boost-build/blob/master/Regression/README.md

1 0

Re: [boost] The Future of Boost - CI
by Boris Kolpackov 09 May '23

09 May '23

At the risk of sounding like a broken record (if nothing else, this could serve as a confirmation that these things are indeed possible): John Maddock via Boost <boost(a)lists.boost.org> writes: > * The library author does nothing more than list (maybe in json or something > similarly popular) the systems they want to test on - and these would be > abstract Boost-wide names like "core", "bleeding edge", "legacy-msvc" etc. Yes, we call them "target configuration classes", such as: latest: https://ci.cppget.org/?build-configs=latest default: https://ci.cppget.org/?build-configs=default legacy: https://ci.cppget.org/?build-configs=legacy You can intersect them with other classes (platforms, compiler, debug/release etc) to end up with something like your "legacy-msvc": https://build2.org/stage/bpkg/doc/build2-package-manager-manual.xhtml#manif… > * Updates and changes to CI would be announced here first, if in doubt new > compilers *might* go in "bleeding-edge" first and "core" a release later. Right, our current policy, for example, is to retain at least two latest versions of each compiler on each platform with the latest version tested in the optimized, ndebug, and static variants. Andrey Semashev via Boost <boost(a)lists.boost.org> writes: > While I can see the appeal of treating the CI as a black box, I > personally want the opposite. That is, I want to know *exactly* what I'm > testing and how I'm testing. This goes beyond listing specific compilers > or even their versions; it is not uncommon for me to configure > environment, including installing additional packages or setting up > environment variables and compiler switches as part of the CI run. I don't think one necessarily precludes the other. In our case you get the vanilla build by default but you can do all of the above declaratively in the manifest (well, perhaps except the environment variables, but we could add that): https://build2.org/stage/bpkg/doc/build2-package-manager-manual.xhtml#manif… > 2. Lack of notifications. We have email notifications, which can be configured (per package) for all build results, warning or error only, or error only: https://build2.org/stage/bpkg/doc/build2-package-manager-manual.xhtml#manif… > 3. Problematic debugging. It was not uncommon that a test run failed > because of some misconfiguration on the runner's side. And it was also > not uncommon that build logs were unavailable. We have interactive CI where you can login into the machine and investigate the issue directly.

1 0

Full-Text Boost Search
by Mohammad Nejati [Ashtum] 09 May '23

09 May '23

Hi, I'm Mohammed Nejati: a C++ enthusiast, Boost aficionado, and a respecter of good implementation and documentation. I have recently been hired by The C++ Alliance and I am glad that I have a chance to dedicate my time to contribute to the C++ community. We have recently begun to design a new website for boost.org and Boost library documentation: https://github.com/cppalliance/site-docs I am on a quest to add full-text search functionality for the new Boost library documentation website. Now, users can conveniently search in a specific Boost library documentation or all Boost libraries without using an external search engine. A great search experience helps users of libraries quickly refer to the documentation during development. Reference documentation can become more discoverable with a customized search engine. This is as new for me as it likely is for you, and any help and feedback would be appreciated. In the following, I'll explain what we have done and what are our findings so far: We deployed the Antora Lunr Extension on our in-development site docs: https://docs.cppalliance.org/user-guide/index.html Two deployment options exist for search: * In the client. With this model, the index is downloaded to the browser, and the search algorithm is executed using the resources of the browser’s host machine. * In the server. Here the index is hosted in the cloud, and the search algorithm runs on the computing resources of the cloud provider. The client-side strengths: * It is very responsive because there is no request/response involved in the search process. * There is no need for a server-side search engine and keep it updated with new content. * Low maintenance cost because there is no load on the server to respond to search queries. * It can work offline (considering that we can locally build reference documentation). A good example of a client-side search is https://docs.rs/ It is used for searching in the reference documentation for each crate. Here is an example of the search page (searching `socket` in the `Tokio` library): https://docs.rs/tokio/1.28.0/tokio/?search=socket The metadata in these search results is applicable to C++ as well. The server-side strengths: * Wider search scopes: server-hosted search indices can be huge. * Better results: because of more powerful cloud-computing resources. * The possibility of semantic search. * Analytics: server-collected statistics can be used to better serve users. These deployment options are not mutually exclusive; both are deployable, each where appropriate. We are working on a design document for search functionality: https://github.com/cppalliance/site-docs/blob/develop/doc/search-functional…. Please feel free to provide feedback by opening an issue in GitHub or asking questions on the list. We are also currently exploring the possibility of fine-tuning a large language model (LLM) specifically for C++ and Boost-related content. This will be fine-tuned on a vast corpus of code snippets, tutorials, and documentation. Our long-term goal is to create an interactive learning platform where users can ask complex questions in natural language and receive accurate and high-quality answers in return. While this project is still in the experimental stage, we believe that we can create a more engaging and interactive learning experience for users, making it easier for them to learn and use libraries effectively. Thank you for your time, and I look forward to your suggestions and feedback. Best regards, Mohammad Nejati

1 0

Mailgun: Switch back PLEASE
by Vinnie Falco 09 May '23

09 May '23

The lack of threading has surprisingly really bothered me. I didn't realize how important it was until it was broken from the move to Amazon SES. I get that the Boost Foundation is saving some money every month but the mailing list is intolerable now. If the Boost Foundation can authorize Sam Darwin to switch things back to Mailgun, I would be more than happy for them to send us the monthly bill. Vinnie

1 0

Re: [boost] The Future of Boost - deprecating libraries
by Daniele Lupo 09 May '23

09 May '23

Hi from a lurker. Just my two cents about deprecation: I totally agree with deprecation: some libraries are basically not used anymore because they were included in the standard libraries, or because there are better alternatives. Removing them means more focusing on more useful libraries. If a software is stuck with a very old library, they will continue to use that version of boost. It's simple. At least it should be possible to create a bugfix release if needed (i.e. 1.80.1 if the library is removed in 1.81). It's necessary anyway to set some rule about deprecation, so users can handle them properly. The main rule in my opinion is to define the number of releases between the deprecation and the deletion of the library from boost. I.e. it's possible to say that when a library is deprecated, it will be removed from three to five future releases. This gives the users a clear view on the future use of that library: "I'm finishing the project in six months, so it's ok to continue to use it", or "The project will last for three years, maybe is better to remove it and find an alternative". I've seen projects that are stucks to very old libraries because the were not well organized about deprecation for lack of information about them, and then libraries will be removed without any warning and people was not able to organize the code to handle the deletion of that library in time. Also, when a library will be deprecated, at least other two information will be needed: * The reason (lack of maintenance, alternatives in modern c++ etc). * At least one alternative to the library, if any (i.e. use std::thread instead of boost::thread). This will give to us the needed information to handle the deprecated library that we are using in our projects. I don't agree with "zombies" libraries. If a library is deprecated, should be deprecated also for boost developers. If you want to remove it also boost libraries that use that should be updated as well. If not, there's no reason to deprecate a library since it will continue to be used. Boost developers can use the deprecation time range defined before to organize the switch in order to remove that dependency. If it's not possible for any reason, the library should not be deprecated. Unmantained libraries are also dangerous. If you continue to ship a unmaintained library, is possible to find a bug that will last for much time, and there's the risk that boost will not be seen as stable as they usually are. No library should be marked as "unmaintained": if noone can handle it maybe it's better to think to deprecate it (usually a unmaintained library is a old one in my experience), or it's better to maintain a public bug tracking system in the main site, so everyone can contribute with a patch if he wants (also the bugs that are present in a specific release should be notified in the changelog). During the boost development then you can take an eye to the bug tracking system, and maybe sometime it's better to stop the development of new libraries and features, and focus the effort on a bugfixing release. I don't expect that there will be many bugs, because there are very few of them at the moment, but there must be a specific time during development in which you should decide about what to do on that dozen of bugs in "unmaintained" libraries, that no one will fix because there are no maintainers. This is only my point of view. I hope it can help. Regards Daniele Lupo On 08/05/2023 20:15, John Maddock via Boost wrote: > >> Stagnation >> * There are fewer new libraries proposed. >> * Formal reviews get less participation. >> * Review managers are typically scarce now. >> * The mailing list volume is thinning; younger folks don’t use lists. >> * There is no second order effect: new libraries rarely use Boost. >> >> Quality >> * Some libraries are unmaintained and create a negative user experience. >> * Users open issues, and no one replies to them. >> * Pull requests are submitted to abandoned repositories. >> * Scant financial resources for infrastructure or staff. > > I think this is correct. I have somewhat suggested this before (as > others have suggested a Boost-2), and for various perfectly good > reasons nothing has ever happened. > > I think at this point we should be somewhat aggressive in deprecating > and then removing libraries which are unmaintained and no longer up to > scratch. Call it a once in a decade spring clean ;) > > So far I think we have only removed one library - one of mine (TR1) > under my direction and even getting that done was a bit of a rigmarole > as I remember :( > > So, how about something like this: > > We have three categories: > > "Deprecated" libraries are marked for removal at some specific future > date in time. This gives users/developers who care about those > libraries time to step up to the plate and a) complain, and b) do some > actual maintenance. After deprecation, libraries that are actually > removed go into a separate zip, probably on their own github page, and > this is the last release they ever get. > > "Zombie" libraries are deprecated, but are still used within Boost. A > good example would be static_assert, which should not now be used in > new libraries, but may still be needed by existing code. Zombie > libraries would still be shipped with Boost, but their documentation > would not be listed in our main index. We might however, have a > separate index for them just in case anyone still needs to find them. > Should we have a new Boost.Compat there could be quite a few of these > in time. > > "Unmaintained": speaks for itself, the library is important enough to > keep around, but has no maintainer. We need a procedure for acquiring > new maintainers, but traditionally we've recruited from existing > authors who are a small, and rather busy pool of people. The > alternative is to recruit from outside, but we often get enthusiastic, > but not very experienced people coming forward. Getting them to submit > PR's and having an experienced old hand check them through is very > time consuming and unsatisfactory for both parties. So how about > this: anyone that wants to step up and enhance/maintain an > unmaintained library can do so - *in their own fork of the github > repro* - then when they're ready for a release, they ask for something > akin to a mini-review - if it's positive they get to merge to Boost > and become an official maintainer, if not they get feedback on what > they need to change. Who knows, maybe this will even stimulate some > discussion and innovation again as well as bringing in new blood? > > Just thinking out loud here, John. > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Re: [boost] The Future of Boost
by Vinnie Falco 09 May '23

09 May '23

On Mon, May 8, 2023 at 10:44 AM John Maddock via Boost <boost(a)lists.boost.org> wrote: > I wish you the very best of luck, Thanks! > ...I also note wryly that all your motivations match exactly > those behind choosing Docbook and then adding quickbook on top ;) You lost me there.. MrDox extracts comments and declarations from C++ programs, while Dockbook and Quickbook are document format and markdown systems respectively...I'm not seeing the connection? Thanks

1 0

Re: [boost] The Future of Boost
by Andrey Semashev 08 May '23

08 May '23

On 5/8/23 18:46, Vinnie Falco via Boost wrote: > > Documentation Improvement > > Our vision for documentation is to ensure that every Boost library has > the option to adopt a well-maintained toolchain that is easily > deployed, produces high-quality output befitting the Boost brand, is > itself well-documented and easy to use, and has behind it full-time > staff working continuously to make improvements and provide technical > support. > > After researching the domain extensively (by just asking Peter Dimov) > we have discovered that the markdown format Asciidoc is a very popular > format with a simple and well maintained toolchain. Several regularly > active Boost authors have already switched their libraries to using > Asciidoctor. The authors of the Asciidoctor tool are also the authors > of “Antora,” a modular, multi-repository documentation site generator: > > https://docs.antora.org/antora/latest/ > > We have built a new, modern set of additional scripts capable of > building the Boost release and documentation, including the capability > of rendering “Antora-enabled Boost library repositories” using this > Antora system. The results are beautiful and modern, and the > Asciidoctor / Antora toolchain holds the promise of being popular and > well-maintained for a long time. The use of Asciidoc or Antora is > optional; this is just an additional choice. I don't know about Antora, but Asciidoc is a too low-level tool for writing docs. In particular, the fact that one Asciidoc document translates to one HTML page is a problem. I'm aware of AsciiDoxy, but I got the impression that it is a bit half-baked and not a widespread solution. > Peter Turcan is our full-time Senior Technical Writer who is > modernizing the instructions for users, maintainers, contributors, and > formal review participants. You can see Peter’s work along with the > quality of Antora’s output here (note that the user-interface is stock > and will be restyled soon): > > https://docs.cppalliance.org/ > > The website above has a new full-text search feature (try it!). We are > investing in a search experience which includes the site docs, > library docs, library references, and even the public header files. We > are also investing in the deployment of a large language model > (ChatGPT-style AI) trained in Boost and C++ specifics to answer > questions for users. We have a new talented and eager staff engineer > working full-time exclusively on this, and I don’t want to steal his > thunder so I will let him explain further soon. I'm not an expert in AI technology by any means, but judging by the ChatGPT-related news I come across it looks like AI as a consultant is more harm than good, at least at the current state of affairs. That is, it is more likely that it will give useless or harmful advice than a useful one. I got a similar impression from the AI-assisted code writers, BTW. Maybe I'm biased, I don't know. All this is not to say that AI technology could not be useful. For example, it could help as part of a search engine. Though we could probably just reuse Google search or something. > Some Boost libraries currently generate their documentation reference > pages using Doxygen combined with other obscure tools such as xsltproc > or Saxon-HE to render into Boost Quickbook, an obsolete form of > markdown which only we use. This Quickbook is rendered into BoostBook, > which is a flavor of DocBook. The BoostBook is converted into HTML by > a DocBook renderer. This rapidly obsolescing toolchain is painful to > work with and is a form of technical debt which costs us. I think you are painting an overly dark picture here. Feature-wise, there simply is no alternative to QuickBook+Doxygen currently. There just isn't. Yes, there are quirks in this toolchain, but once it is set up and working, there really is no problem using it. I have configured QuickBook/BoostBook/Doxygen on my system decades ago and didn't have to touch it ever since, it just works(tm). (Well, I did recompile QuickBook from time to time, but that was mostly out of boredom and had zero issues.) Also, I'm not sure what state it is in, but I think there was some work in QuickBook to directly generate HTML as output. I imagine, there would be limitations with this, as QuickBook supports injecting BoostBook bits in it, but for the most part it seems doable. > I have begun work on a new command-line tool called MrDox (“mister > docs”) which uses the unstable clang libtooling API to extract the > documentation comments and declarations from C++ programs, and turn > them into beautiful Asciidoc reference pages. You can see that work > here: > > https://github.com/cppalliance/mrdox > > The core principles of the design of MrDox is to always understand the > very latest C++ constructs and extract them with high fidelity. For > example it recognizes conditional noexcept, constexpr, deduction > guides, all attributes, and many other things that other documentation > toolchains cannot fathom. In a nutshell I intend to bring the same > level of Boost quality to the documentation toolchain that Boost has > brought to the C++ libraries themselves. > > MrDox intends to completely replace Doxygen, xsltproc, Saxon-HE, > Quickbook, Boostbook, and Docbook, as the only requirement to render > its results is to run the Asciidoctor tool, which has no other > dependencies. This toolchain offers modernization and simplification > for anyone who opts-in to it, which reduces long-term risks and > improves results. This unfortunately delays the development of my > other libraries, but enhancements in the documentation toolchain are a > force multiplier; many Boost libraries can benefit. >From the readme page it seems like there is a fair bit of NIH syndrome in there. :) But, if MrDox will transparently replace Doxygen (that is, it will understand comments in Doxygen format and generate output in various formats, including XML) then it may make a very good alternative. I sincerely wish you luck with it.

1 0

Re: [boost] The Future of Boost - CI
by Andrey Semashev 08 May '23

08 May '23

On 5/8/23 20:40, John Maddock via Boost wrote: > > Vinnie, > > First of all, let me thank you for taking the time to write all this up, > and put into words, probably what we've all been thinking! > >>Continuous Integration > > CI is wonderful, and horrible! > > The main issues I see are that: > > a) It needs continual maintenance, as the host runner upgrades/changes > the systems they support. > > b) Stuff breaks without notice because we never know when the hosting CI > service will change something. > > c) Knowledge of fairly obscure scripting is required to make the most of > it. > > Strictly IMO, the issues that Robert Ramey was complaining about in CI > recently were due to the above rather than anything wrong with the > concept, or indeed Boost. > > So... in my ideal world Boost CI would look something like this: > > * The library author does nothing more than list (maybe in json or > something similarly popular) the systems they want to test on - and > these would be abstract Boost-wide names like "core", "bleeding edge", > "legacy-msvc" etc. Exactly what these map to would be defined > elsewhere. But the point is that now, library authors would almots > never need to update their CI script *and* all Boost libraries get > tested on the same "core" which would also form our release criteria. While I can see the appeal of treating the CI as a black box, I personally want the opposite. That is, I want to know *exactly* what I'm testing and how I'm testing. This goes beyond listing specific compilers or even their versions; it is not uncommon for me to configure environment, including installing additional packages or setting up environment variables and compiler switches as part of the CI run. This is one of the reasons why I'm not using Boost.CI in my libraries. > * Updates and changes to CI would be announced here first, if in doubt > new compilers *might* go in "bleeding-edge" first and "core" a release > later. I think, making such lists of compilers commonly accepted is unrealistic. One compiler or a list of compiler options might be important for one library and not important at all for another one (meaning, it would be a waste of CI resources to run that configuration for that library). The only practical use case for such a list would be the list of the compilers we declare as "officially tested" in our Boost-wide release notes. > Machine time could well be donated by volunteers and perhaps replace the > current test/status matrix, which is fine, but requires you to go off > seeking for results, which may or may not have cycled yet. Plus that > matrix relies on a "build the whole of Boost" approach which > increasingly simply does not scale. I'm really grateful to the volunteers that run the tests and maintain the official test matrix, but honestly, I'm not paying attention to it anymore. I have three main issues with it: 1. Slow turnaround. From my memory, it could take weeks or more for the runners to run the tests over a commit I made. With this order of times, it is impossible to perform continued development while maintaining code in working state. 2. Lack of notifications. 3. Problematic debugging. It was not uncommon that a test run failed because of some misconfiguration on the runner's side. And it was also not uncommon that build logs were unavailable. So, while, again, I'm most grateful to the people that made public testing possible at all before we had the current CI services, today we do have CI services with the above problems fixed (more or less), and I'm spoiled by them. It is true that the public CI resources are limited and insufficient at times, so, IMHO, the way forward would be towards fixing this problem without losing the convenience of the CI services we've become used to.

1 0

Re: [boost] The Future of Boost - deprecating libraries
by Peter Dimov 08 May '23

08 May '23

Vinnie Falco wrote: > This is all very nice but why didn’t you reply to my post instead of starting a > new thread? Someone hasn't read the thread about Amazon SES breaking threads.

1 0

Re: [boost] The Future of Boost - deprecating libraries
by Vinnie Falco 08 May '23

08 May '23

On Mon, May 8, 2023 at 11:08 AM John Maddock via Boost < boost(a)lists.boost.org> > … This is all very nice but why didn’t you reply to my post instead of starting a new thread? > -- Regards, Vinnie Follow me on GitHub: https://github.com/vinniefalco

1 0

Re: [boost] The Future of Boost - deprecating libraries
by Robert Ramey 08 May '23

08 May '23

On 5/8/23 11:08 AM, John Maddock via Boost wrote: > I think at this point we should be somewhat aggressive in deprecating > and then removing libraries which are unmaintained and no longer up to > scratch. Call it a once in a decade spring clean ;) > I don't see this could be done without having any information on library usage. No one has figured out how to get this. Robert Ramey > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Re: [boost] Problem with homegrown. porting to ipv6
by Georg Gast 08 May '23

08 May '23

Am Mon, 8 May 2023 10:47:02 +0000 schrieb Tarun Batra via Boost <boost(a)lists.boost.org>: > What I wanted to ask is, is there any way in boost by which we can > first try things on ipv6 and if that doesn't work fall to ipv4. Do you want to test if IPv6 is supported on this machine or do you want test if it has public IPv6 address or if it can connect by IPv6 to some address? There are things like NAT66, ULAs and other stuff that happens not on this machine .... Local IPv6 might be available for most of all "modern" platforms. Bye Georg

1 0

Re: [boost] The Future of Boost - deprecating libraries
by Peter Dimov 08 May '23

08 May '23

John Maddock wrote: > "Unmaintained": speaks for itself, the library is important enough to keep > around, but has no maintainer. We need a procedure for acquiring new > maintainers, but traditionally we've recruited from existing authors who are a > small, and rather busy pool of people. The alternative is to recruit from > outside, but we often get enthusiastic, but not very experienced people > coming forward. Getting them to submit PR's and having an experienced old > hand check them through is very time consuming and unsatisfactory for both > parties. Taking over unmaintained libraries is a problem that, in my opinion, has no solution. Even an experienced person such as myself has trouble evolving existing libraries without the deep knowledge of the design decisions that resulted in their current state. In addition, every new maintainer inevitably wants (and needs) his work to matter, whereas maintaining a legacy library is thankless work that leaves no room for creative expression.

1 0

Re: [boost] The Future of Boost - deprecating libraries
by John Maddock 08 May '23

08 May '23

> Stagnation > * There are fewer new libraries proposed. > * Formal reviews get less participation. > * Review managers are typically scarce now. > * The mailing list volume is thinning; younger folks don’t use lists. > * There is no second order effect: new libraries rarely use Boost. > > Quality > * Some libraries are unmaintained and create a negative user experience. > * Users open issues, and no one replies to them. > * Pull requests are submitted to abandoned repositories. > * Scant financial resources for infrastructure or staff. I think this is correct. I have somewhat suggested this before (as others have suggested a Boost-2), and for various perfectly good reasons nothing has ever happened. I think at this point we should be somewhat aggressive in deprecating and then removing libraries which are unmaintained and no longer up to scratch. Call it a once in a decade spring clean ;) So far I think we have only removed one library - one of mine (TR1) under my direction and even getting that done was a bit of a rigmarole as I remember :( So, how about something like this: We have three categories: "Deprecated" libraries are marked for removal at some specific future date in time. This gives users/developers who care about those libraries time to step up to the plate and a) complain, and b) do some actual maintenance. After deprecation, libraries that are actually removed go into a separate zip, probably on their own github page, and this is the last release they ever get. "Zombie" libraries are deprecated, but are still used within Boost. A good example would be static_assert, which should not now be used in new libraries, but may still be needed by existing code. Zombie libraries would still be shipped with Boost, but their documentation would not be listed in our main index. We might however, have a separate index for them just in case anyone still needs to find them. Should we have a new Boost.Compat there could be quite a few of these in time. "Unmaintained": speaks for itself, the library is important enough to keep around, but has no maintainer. We need a procedure for acquiring new maintainers, but traditionally we've recruited from existing authors who are a small, and rather busy pool of people. The alternative is to recruit from outside, but we often get enthusiastic, but not very experienced people coming forward. Getting them to submit PR's and having an experienced old hand check them through is very time consuming and unsatisfactory for both parties. So how about this: anyone that wants to step up and enhance/maintain an unmaintained library can do so - *in their own fork of the github repro* - then when they're ready for a release, they ask for something akin to a mini-review - if it's positive they get to merge to Boost and become an official maintainer, if not they get feedback on what they need to change. Who knows, maybe this will even stimulate some discussion and innovation again as well as bringing in new blood? Just thinking out loud here, John.

1 0

Re: [boost] The Future of Boost
by John Maddock 08 May '23

08 May '23

> Documentation Improvement > > Our vision for documentation is to ensure that every Boost library has > the option to adopt a well-maintained toolchain that is easily > deployed, produces high-quality output befitting the Boost brand, is > itself well-documented and easy to use, and has behind it full-time > staff working continuously to make improvements and provide technical > support. > > After researching the domain extensively (by just asking Peter Dimov) > we have discovered that the markdown format Asciidoc is a very popular > format with a simple and well maintained toolchain. Several regularly > active Boost authors have already switched their libraries to using > Asciidoctor. The authors of the Asciidoctor tool are also the authors > of “Antora,” a modular, multi-repository documentation site generator: > > https://docs.antora.org/antora/latest/ > > We have built a new, modern set of additional scripts capable of > building the Boost release and documentation, including the capability > of rendering “Antora-enabled Boost library repositories” using this > Antora system. The results are beautiful and modern, and the > Asciidoctor / Antora toolchain holds the promise of being popular and > well-maintained for a long time. The use of Asciidoc or Antora is > optional; this is just an additional choice. > > Peter Turcan is our full-time Senior Technical Writer who is > modernizing the instructions for users, maintainers, contributors, and > formal review participants. You can see Peter’s work along with the > quality of Antora’s output here (note that the user-interface is stock > and will be restyled soon): > > https://docs.cppalliance.org/ > > The website above has a new full-text search feature (try it!). We are > investing in a search experience which includes the site docs, > library docs, library references, and even the public header files. We > are also investing in the deployment of a large language model > (ChatGPT-style AI) trained in Boost and C++ specifics to answer > questions for users. We have a new talented and eager staff engineer > working full-time exclusively on this, and I don’t want to steal his > thunder so I will let him explain further soon. > > Some Boost libraries currently generate their documentation reference > pages using Doxygen combined with other obscure tools such as xsltproc > or Saxon-HE to render into Boost Quickbook, an obsolete form of > markdown which only we use. This Quickbook is rendered into BoostBook, > which is a flavor of DocBook. The BoostBook is converted into HTML by > a DocBook renderer. This rapidly obsolescing toolchain is painful to > work with and is a form of technical debt which costs us. > > I have begun work on a new command-line tool called MrDox (“mister > docs”) which uses the unstable clang libtooling API to extract the > documentation comments and declarations from C++ programs, and turn > them into beautiful Asciidoc reference pages. You can see that work > here: > > https://github.com/cppalliance/mrdox > > The core principles of the design of MrDox is to always understand the > very latest C++ constructs and extract them with high fidelity. For > example it recognizes conditional noexcept, constexpr, deduction > guides, all attributes, and many other things that other documentation > toolchains cannot fathom. In a nutshell I intend to bring the same > level of Boost quality to the documentation toolchain that Boost has > brought to the C++ libraries themselves. > > MrDox intends to completely replace Doxygen, xsltproc, Saxon-HE, > Quickbook, Boostbook, and Docbook, as the only requirement to render > its results is to run the Asciidoctor tool, which has no other > dependencies. This toolchain offers modernization and simplification > for anyone who opts-in to it, which reduces long-term risks and > improves results. This unfortunately delays the development of my > other libraries, but enhancements in the documentation toolchain are a > force multiplier; many Boost libraries can benefit. I wish you the very best of luck, I may even convert some of my stuff over. But I also note wryly that all your motivations match exactly those behind choosing Docbook and then adding quickbook on top ;)

1 0

Re: [boost] The Future of Boost - CI
by John Maddock 08 May '23

08 May '23

Vinnie, First of all, let me thank you for taking the time to write all this up, and put into words, probably what we've all been thinking! >Continuous Integration CI is wonderful, and horrible! The main issues I see are that: a) It needs continual maintenance, as the host runner upgrades/changes the systems they support. b) Stuff breaks without notice because we never know when the hosting CI service will change something. c) Knowledge of fairly obscure scripting is required to make the most of it. Strictly IMO, the issues that Robert Ramey was complaining about in CI recently were due to the above rather than anything wrong with the concept, or indeed Boost. So... in my ideal world Boost CI would look something like this: * The library author does nothing more than list (maybe in json or something similarly popular) the systems they want to test on - and these would be abstract Boost-wide names like "core", "bleeding edge", "legacy-msvc" etc. Exactly what these map to would be defined elsewhere. But the point is that now, library authors would almots never need to update their CI script *and* all Boost libraries get tested on the same "core" which would also form our release criteria. * Updates and changes to CI would be announced here first, if in doubt new compilers *might* go in "bleeding-edge" first and "core" a release later. Machine time could well be donated by volunteers and perhaps replace the current test/status matrix, which is fine, but requires you to go off seeking for results, which may or may not have cycled yet. Plus that matrix relies on a "build the whole of Boost" approach which increasingly simply does not scale. I'm hoping that approach might even allow us to diversify our testing somewhat - to pick a random example - Intel used to be very generous in proving us with compiler-licences to test with, but these are sadly incompatible with CI, but I suspect they would be compatible with individual testers acting as CI hosts though. I'm sure there are other examples: MSVC/GCC/Clang are not the only games in town. Best, John.

1 0

The Future of Boost
by Vinnie Falco 08 May '23

08 May '23

Greetings! I’m Vinnie Falco, Boost library author, C++ enthusiast, and the founder of The C++ Alliance, a 501(c)(3) non-profit. While some of you are enjoying the C++Now conference this week, I’d like to share some background on our organization, provide some history, outline a vision and goals for C++ and Boost, and solicit your feedback and support. How It Started I took notice of the C++ Standards Committee (“WG21”) while I was writing Boost.Beast in 2016. Howard Hinnant, a co-workers at Ripple, taught me about writing papers and committee meetings. Beast used Boost.Asio (portable networking for C++) and I was and still am a huge fan of this network library. I learned that Asio was being proposed for standardization. There was even a “Networking TS” document: Asio was very close to becoming part of C++ officially! But the author Christopher Kohlhoff always seemed to not have the time to attend the meetings and push this proposal though. Something which should not surprise anyone is that I despise paying taxes. In 2017, I had an idea: create a charitable organization which I can donate pre-tax income to, and then I could hire Christopher Kohlhoff as a “staff engineer” to work full time on C++ standardization, and Boost things! I would find the very best C++ people who are already doing open source work, then hire them full-time so they could focus on their open source C++ open work from home, instead of traveling to a boring job in order to make a living. A Few Setbacks In 2018 I offered this opportunity to Chris and he surprisingly turned it down. He actually liked going into an office and interacting with customers and users. He explained that the evolution of Asio and his WG21 work is not bottlenecked by time. Instead, he prefers to “think deeply about things over a long period, and then write something.” Basically the opposite of my strategy, which is to write a bunch of code quickly and then throw out the bad parts. This is a setback but I am not so easily deterred so I offered the same opportunity to Peter Dimov, an engineer of immense talent whose libraries are legendary. He also declined, explaining that taking a salary would transform a hobby into an obligation, affecting the quality and enjoyment of the work. Now I’m thinking, well this is a disaster! We had the non-profit in operation officially since March of 2018 (the IRS approved us in September of 2019). We had the C++ language Slack workspace as of November of 2017, transitioned to a paid plan with full history. Our strategy shifted to focus on supporting the Boost Library Collection directly. We hired our first Staff Engineer, Marshall Clow, in April of 2018. Fast forward and today we have 11 staff members. We have a great CTO/DevOps genius Sam Darwin. And we have Louis Tatta, our CEO that keeps things running smoothly and helps get the most out of every dollar donated. At some point I’ll share a complete list of everything that The C++ Alliance has done since the beginning, but that is the subject of another missive. Today I would like to talk about a vision for Boost. The Boost Library Collection Long-timers know Boost’s history but for those that don’t, Beman Dawes and Robert Klarer came up with the idea of a website offering curated, high quality C++ libraries in May of 1998. They described the “Formal Review,” a social technology where a group of peers would go over a proposed library at an agreed-upon time. They could interrogate the author about the library on the mailing list, and debate things. The outcome is a collection of posts where each reviewer summarizes their critique of the library, including whether or not to “accept” the library (sometimes with conditions). The founding documenting evokes a feeling of something big: https://www.boost.org/users/proposal.pdf The collection was named “Boost” and received many great contributions. The authors and reviewers were active in the standardization committee. In December of 2005, Boost.Asio was added after being developed since 2003. In September of 2011 the C++11 standard was published, containing many library components modeled closely or identically to their Boost counterparts. In my opinion, Asio’s efforts at standardization were thwarted by the growth of politics; an inevitable consequence of the bureaucratic ISO structure. Boost launched its own conference called BoostCon in 2007 on the heels of its success. Speakers included Scott Meyers, Dave Abrahams, Eric Niebler, Howard Hinnant, and other juggernauts of C++. A new conference called CppCon was launched in 2014 and attracted even larger crowds, as it was focused on C++ in general. Trouble Brewing With the release of C++11, there were now components in Boost which were duplicated in the Standard Library. The C++ committee became more popular and valuable owing to the success of C++11, made possible in part by years of lead-up from the talented Boost engineers. The conferences turned some people into the equivalent of pop stars, appearing as staple keynote speakers. Library writers discovered it was easier to get a proposal into the C++ standard than it was to get a library through the Formal Review process. They discovered that there was more glory to have a proposal accepted into the official C++ language, than to have their library accepted into Boost. And once their proposal became part of C++, they no longer had to “maintain their code” the way they would if their library got in Boost. A Formal Review evaluates the author somewhat in addition to the library. Because once a library is accepted, it must be maintained and evolved. When an author abandons their Boost library, the community is impoverished as the knowledge and expertise leaves with them. And someone else must take over the maintenance. In December of 2020, Beman Dawes passed away and Boost suffered a loss which can never be replaced. Beman had an enormous impact on not just the libraries but also C++. He was in WG21 from the very beginning, chaired LWG (the “Library Working Group”) for quite some time, and achieved a long history of open source contributions. Boost had other problems. Fewer libraries were being proposed, and it took longer to find a volunteer review manager. Mailing list volume declined steadily. At 160+ libraries, users complained that “Boost is too large.” They complained that “many of the libraries are outdated”, that “the documentation is of varying quality”, and that “Boost takes too long to compile.” They complained about the obscure build system and lack of cmake support. The archetype of “never Booster” appeared: individuals or corporations who ban the use of Boost entirely. Beman was the closest thing resembling a leader, despite Boost being a federation of authors with each having final word over their own library. Beman would solve problems, help with the direction of things, and even “beat the bushes” when it was time for a review by reaching out to his network of contacts and soliciting their participation. Without Beman, Boost lost its leader. Boost lost its Great Founder. And no one has since filled the role. The C++ Alliance At this point, a vision for what our non-profit could do crystallized. We would help C++ in general by refreshing the foundations of Boost, restoring Boost’s prominence in the community, and helping Boost become a leader once again as innovators in C++. To do this, I'll share what we feel are the problems facing Boost, and ways to address some of them. Finally I'd like you to weigh in on all of this and help figure out what is important and what successful execution might look like. We believe Boost faces these obstacles: Stagnation * There are fewer new libraries proposed. * Formal reviews get less participation. * Review managers are typically scarce now. * The mailing list volume is thinning; younger folks don’t use lists. * There is no second order effect: new libraries rarely use Boost. Quality * Some libraries are unmaintained and create a negative user experience. * Users open issues, and no one replies to them. * Pull requests are submitted to abandoned repositories. * Scant financial resources for infrastructure or staff. Documentation * The quality of documentation varies greatly across libraries. * The rendered pages and content of some documentation looks dated. * Some toolchains used are obscure and unmaintained. Perception * Boost causes long compile times. * The libraries have too many interdependencies * Supporting old C++ versions is a weakness not a strength. * The duplication of std components is wasteful and causes friction. * The “Monolithic” distribution of Boost is obsolete. Messaging * The website is outdated and never receives updates. * Boost’s value proposition is not clear (“why use boost?”) * There is no clear voice countering misconceptions and irrational phobias. * Users receive no guidance about the future, or what is maintained. * The libraries have no representation at conferences. Some users have also weighed in with thoughts on Boost: https://www.reddit.com/r/cpp/comments/gfowpq/why_you_dont_use_boost/ A Plan I love C++, supporting users, and the Boost author experience. I think these problems can be solved. But not by demanding that “everyone who maintains a Boost library must do X.” In Boost culture when you want something done you need to do it yourself, then convince the mailing list of the merits of your proposal. As a library author and contributor, I know that whatever I do will never rise to the same level as the original act of the creation of the Boost Library Collection. But I will be satisfied if I can stoke its fires and bring them back to a roar. To this end the resources of the non-profit are directed into projects we believe will positively affect Boost: Website Renovation Our vision for an updated Boost website is clean and stylish, which speaks to a large and diverse audience. This site will have a design and content that effectively communicates the value proposition of using the Boost Library Collection: that you will write better C++ code, become more productive, and achieve greater success in your career or personal projects. Features will foster participation and revisits, with content updated regularly. The library presentation is elevated with a new visual design language that evokes distinction and appeal, and credits the authors, maintainers, and contributors that bring it to life. To achieve this vision, you have probably heard that we contracted an outside software firm to build something precisely tailored for our needs. We care too much about Boost to use an ill-fitted, off the shelf product. This website has a lot of software behind it (written in Python as part of a Django framework application) and like most software projects it is late and over budget. I’ll refrain from saying “it’ll be ready soon” and just post a link to the new site instead, hopefully in a few weeks. I have been personally involved in the design, presentation, and execution of the features of the website, most of which have been cut from the initial release in order to speed things along. The goal is to show the library collection in a way that highlights its strengths and speaks to a desire of every C++ programmer: to find the perfect library they can add as a dependency to help complete their next project. The Boost website and the site documentation can be illustrated by retaining a talented digital artist to produce custom assets that are unified in style, colors, and messaging, so that the entire site feels purposeful. This artist will also provide imagery used for our social media campaigns such as the announcements we make on Twitter which some of you might have already seen https://twitter.com/Boost_Libraries. I strive to give every tweet an image to enhance the Boost brand (tweets with images have significantly increased engagement). Recently an animated discussion on the mailing list took place about adding a forum which does not replace the mailing list but is integrated to work with it. Posts in the forum become posts to the mailing list, and vice versa. Users of the mailing list and users of the forum will have no idea they are interacting, even though they are. This can only be possible if we write the software ourselves, from the ground up, with exactly one constraint: the mailing list will continue to operate exactly as it does today, on an unmodified version of Mailman 3. The mailing list users stay happy, and we can attract new people who prefer a web-based interface. The C++ Alliance prioritizes its allocation of resources to ensure not only the website’s completion, but also dedicated staff for ongoing maintenance and improvement. The Boost website will rise over time to the same level of quality expected of every Boost library. Community members should feel free to open issues on the website repository with bugs or features, knowing that every issue will be looked at, triaged, and addressed appropriately. Documentation Improvement Our vision for documentation is to ensure that every Boost library has the option to adopt a well-maintained toolchain that is easily deployed, produces high-quality output befitting the Boost brand, is itself well-documented and easy to use, and has behind it full-time staff working continuously to make improvements and provide technical support. After researching the domain extensively (by just asking Peter Dimov) we have discovered that the markdown format Asciidoc is a very popular format with a simple and well maintained toolchain. Several regularly active Boost authors have already switched their libraries to using Asciidoctor. The authors of the Asciidoctor tool are also the authors of “Antora,” a modular, multi-repository documentation site generator: https://docs.antora.org/antora/latest/ We have built a new, modern set of additional scripts capable of building the Boost release and documentation, including the capability of rendering “Antora-enabled Boost library repositories” using this Antora system. The results are beautiful and modern, and the Asciidoctor / Antora toolchain holds the promise of being popular and well-maintained for a long time. The use of Asciidoc or Antora is optional; this is just an additional choice. Peter Turcan is our full-time Senior Technical Writer who is modernizing the instructions for users, maintainers, contributors, and formal review participants. You can see Peter’s work along with the quality of Antora’s output here (note that the user-interface is stock and will be restyled soon): https://docs.cppalliance.org/ The website above has a new full-text search feature (try it!). We are investing in a search experience which includes the site docs, library docs, library references, and even the public header files. We are also investing in the deployment of a large language model (ChatGPT-style AI) trained in Boost and C++ specifics to answer questions for users. We have a new talented and eager staff engineer working full-time exclusively on this, and I don’t want to steal his thunder so I will let him explain further soon. Some Boost libraries currently generate their documentation reference pages using Doxygen combined with other obscure tools such as xsltproc or Saxon-HE to render into Boost Quickbook, an obsolete form of markdown which only we use. This Quickbook is rendered into BoostBook, which is a flavor of DocBook. The BoostBook is converted into HTML by a DocBook renderer. This rapidly obsolescing toolchain is painful to work with and is a form of technical debt which costs us. I have begun work on a new command-line tool called MrDox (“mister docs”) which uses the unstable clang libtooling API to extract the documentation comments and declarations from C++ programs, and turn them into beautiful Asciidoc reference pages. You can see that work here: https://github.com/cppalliance/mrdox The core principles of the design of MrDox is to always understand the very latest C++ constructs and extract them with high fidelity. For example it recognizes conditional noexcept, constexpr, deduction guides, all attributes, and many other things that other documentation toolchains cannot fathom. In a nutshell I intend to bring the same level of Boost quality to the documentation toolchain that Boost has brought to the C++ libraries themselves. MrDox intends to completely replace Doxygen, xsltproc, Saxon-HE, Quickbook, Boostbook, and Docbook, as the only requirement to render its results is to run the Asciidoctor tool, which has no other dependencies. This toolchain offers modernization and simplification for anyone who opts-in to it, which reduces long-term risks and improves results. This unfortunately delays the development of my other libraries, but enhancements in the documentation toolchain are a force multiplier; many Boost libraries can benefit. Continuous Integration Our vision for continuous integration is to bring the most talented individuals together and combine that with state of the art technology and resources to ensure that every library has at its disposal, access to robust cloud services for continuous integration. These services are the lifeblood of maintaining and communicating the quality of a library. We aim to provide dedicated staff and technical support to fortify Boost in the ever-shifting landscape of free CI services for open source projects. The infrastructures providing our continuous integration services are the lifeblood of maintaining the high quality of the Boost collection. Library authors test against many versions of C++ and many different compiler versions. And we have many libraries; over 160 of them which all compete for the finite public resources offered by GitHub through GHA, through Azure Pipelines, or Appveyor. When Travis discontinued its free service, our CTO Sam Darwin deployed Drone (https://www.drone.io/) instances and offered every Boost library a pull request which compiles and runs their tests on our new infrastructure. Although this service is still active and offered today, we are not content to leave it at that. CI services are volatile over time. Some come, some go, and some become overloaded which is the current situation with the public GitHub Actions runners during peak times. The Boost organization GitHub account has over one hundred and sixty libraries each submitting sometimes enormous numbers of jobs which take multiple hours to complete. Although the GHA environment resources are subjected to recurring oversubscription, we feel that it offers the best framework for composable actions and flexibility. Sam is exploring the possibility of having self-hosted C++ Alliance runners dedicated only to Boost jobs during peak times. Ensuring high availability of CI resources is an ongoing project for us, and we are always evaluating existing and new solutions to provide the best-of-class choices for libraries. Library Enhancements Our vision for the libraries themselves is to preserve unchanged the amazing social technologies invented by the Boost founders which include the Formal Review process, the Release Schedule, the mailing list discussions, and the federated library ownership model. We want to ensure that no library is unmaintained and that every opened issue receives a response. We want the community to respect and admire the formal review process and participate with eagerness not only as reviewers but also as volunteer review managers and participants in the sometimes-heated list discussions. Library membership in the Boost library collection should be seen as the highest level of honor and recognition of effort. The C++ Alliance has ongoing direct investments in improving existing Boost libraries and writing new ones to be submitted for formal review. Many folks are already aware of the optimization efforts being applied to the Boost.Unordered library, whose plan was written up by Peter Dimov. Joaquín M López Muñoz is providing his mathematical expertise and container experience, while Christian Mazakas (one of our full-time staff engineers) is writing the implementation, tests, and documentation according to specification. People following Boost.Math might recognize Matt Borland as a regular contributor. He has joined us as a staff engineer and is currently working on a new library to be proposed for Boost: charconv, which is a C++11 port of the eponymous C++17 feature. This library will help libraries and users who may not have access to C++17 enjoy the same features through Boost instead. Messaging and Direction Our vision for Boost includes clear messaging to inform the public on the status of the libraries, the challenges we are facing, and what our future direction might be. We believe in robust two-way communication between library authors and maintainers, and the stakeholders which are largely the people and companies which use the Boost libraries. We believe in having a social media presence that helps convey the prestige and status that comes with the quality Boost libraries offer. Currently we have only anecdotal evidence of Boost’s adoption (or lack thereof) in various companies and projects. We only hear from the people who complain or open issues, or post to the mailing list. We do not have a concise list of companies using Boost, when new companies adopt Boost, or when companies stop using Boost. We do not have feedback from stakeholders about which Boost libraries they rely on the most, what they would like to see in future versions, or in some cases even if they are having problems with a library or its documentation. The decentralized model of Boost library development works great for the problems it tries to solve but offers no overall directional guidance for Boost. Today the C++ language is facing unprecedented challenges: the popularity of Rust, the demands for “memory safety”, the rise of Artificial Intelligence capable of writing software independently, and possibility that the bureaucratic structure of WG21 renders it incapable of meeting these challenges in a lively or effective manner. We believe that Boost can offer the greatest value by focusing in the areas where C++ is strong and without meaningful competition. These include space exploration, game development, high-performance computing, embedded systems, the Internet of Things, robotics and industrial process control, financial services, computer vision and graphics, scientific simulation, and more. Furthermore the stunning and continued lack of networking in the standard library creates an opportunity for Boost to offer full-stack solutions in areas that speak to the strengths of C++. This is made possible because Boost already offers portable networking through Asio, HTTP and Websocket through Beast, excellent JSON parsing and serialization tailored for network programs, URLs, and more recently a Redis client (Boost.Aedis) and even a MySQL / MariaDB client. We intend to sponsor the development of non-Boost, open source applications and services that target specific underserved markets that would benefit from C++ solutions which use the excellent libraries that exist in Boost. Where Do You Fit In? Our vision, our activity, and our deployed solutions are all “opt-in.” No one controls Boost or its libraries. Change is only possible with consensus of the folks that matter: authors, maintainers, and release managers. If Robert Ramey wants to keep his documentation in hand-written HTML that is entirely his choice; no one dictates what libraries do. We can only offer choices, and hope they will be seen as valuable. This has been a long read, and I appreciate your investment of time. How do you feel about this vision? What would you change, or add, and what needs work? We welcome feedback, and value the volunteers who share our vision and help us execute it. I invite you to stay tuned for more great news, coming soon! Respectfully Yours Vinnie Falco

1 0

Problem with homegrown. porting to ipv6
by Tarun Batra 08 May '23

08 May '23

Hi, I am doing a homegrown project, which i am adding support to ipv6 where i 2 different codes: *First code:* my_Acceptor = new tcp::acceptor(myService, tcp::endpoint(boost::asio::ip::address_v4::loopback(),port)); *Second code:* my_acceptor = new tcp::acceptor(myContext, tcp::endpoint(ifallowed ? boost::asio::ip::address_v4::any() : boost::asio::ip::address_v4::loopback(),port)); What I wanted to ask is, is there any way in boost by which we can first try things on ipv6 and if that doesn't work fall to ipv4. *Since it is just loopback address, is it a better way than this, for the first code* try{ my_Acceptor = new tcp::acceptor(myService, tcp::endpoint(boost::asio::ip::address_v6::loopback(),port)); } catch(boost::system::system_error& e) { printf("Error Starting on v6, trying on v4: %s\n", e.what()); } try{ my_Acceptor = new tcp::acceptor(myService, tcp::endpoint(boost::asio::ip::address_v4::loopback(),port)); } catch(boost::system::system_error& e) { printf("Error Starting on v4,: %s\n", e.what()); return; }

1 0

Re: [boost] Boost CI Infrastructure
by Ruben Perez 07 May '23

07 May '23

> > > 2. Standard "CI script"[2] that is used by all the C/C++ projects > instead of each projects doing their own thing. > Out of curiosity, would this allow me to run my integration tests, which require to set up a DB instance and load data before running tests? Regards, Ruben

2 2

Re: [boost] Amazon SES
by Sam Darwin 05 May '23

05 May '23

In retrospect it was an irresistible experiment to try out Amazon SES. The service seems to offer a large cost savings while also providing reliable mail delivery. However, here is a reply from the mailman-users list: "Amazon SES rewrites the Message-ID. Yep and for this reason I don't use it. The problem is worse in Mailman3 because it has a much more superior archive display which gets ruined when people reply to messages with different Message-Id headers and the threading can't be observed. I also had to use the anonymous mode with my list as Amazon didn't like me using random addresses in the From: header. I'm still looking for a tolerant mail gateway to use with Mailman." On Thu, May 4, 2023 at 5:27 PM Gavin Lambert via Boost <boost(a)lists.boost.org> wrote: > > Mere moments ago, quoth I: > > There's not too much problem if the first message id is rewritten > > (provided both mailman and SES agree on what it is, but that seems hard > > if mailman is earlier in the traffic chain, as appears to be the case). > > Actually, I take that back. Messages might be cross-posted to multiple > lists, in which case it's important that these all have the same message > id too. While *usually* they would all be Boost lists, that's not > necessarily the case, so the only correct choice is to not alter the > original message id. > > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Re: [boost] Amazon SES
by Gavin Lambert 04 May '23

04 May '23

Mere moments ago, quoth I: > There's not too much problem if the first message id is rewritten > (provided both mailman and SES agree on what it is, but that seems hard > if mailman is earlier in the traffic chain, as appears to be the case). Actually, I take that back. Messages might be cross-posted to multiple lists, in which case it's important that these all have the same message id too. While *usually* they would all be Boost lists, that's not necessarily the case, so the only correct choice is to not alter the original message id.

1 0

Re: [boost] Amazon SES
by Gavin Lambert 04 May '23

04 May '23

On 5/05/2023 04:40, Sam Darwin wrote: > Checking original messages locally in my inbox messages, it appears > mailgun doesn't rewrite the ID. SES rewrites the ID. Not an option to > disable it. I will open a discussion with mailman and see if they have > any suggestions. I think the only solution would be to get SES to stop doing that. Or to stop using SES if it can't. There's not too much problem if the first message id is rewritten (provided both mailman and SES agree on what it is, but that seems hard if mailman is earlier in the traffic chain, as appears to be the case). But for second and subsequent messages in the same thread, replies are often sent both to the list and to individual participants, and it's critically important that both of these copies have the identical message id both so that servers and clients recognise them as duplicates (and that one is safe to discard) and so that it doesn't matter which copy is replied to next. Changing the id is just poor netiquette, and it should only be done if the incoming email had a malformed id.

1 0

Boost::Regex support with ICU for unicode characters.
by Neha Patil 04 May '23

04 May '23

Hello, We are working with boost::regex library to have unicode support. I want to form a regex for validating unicode characters so I'm trying this with boost library. I am facing an issue with a boost library with ICU support so please suggest me how to proceed with the boost with ICU support. PFA for this. 1. *has_icu_builds* is used to enable icu support. [image: image.png] 2. on *b2 install* no icu is there, please let me know the procedure of how to enable icu. [image: image.png] Also I tried attaching the ICU library externally but it gives incorrect results for regex having character classes. PFA for this. [image: image.png][image: image.png] *NOTE *: Using 'Lo' character class as this class supports unicase alphabets. Kind Regards, Neha Patil.

1 1

Re: [boost] Q1 2023 Update: C++ Alliance's Efforts (PDF Attached)
by Daniela Engert 04 May '23

04 May '23

Am 04.05.2023 um 01:49 schrieb Gavin Lambert via Boost: > On 4/05/2023 03:55, Andrey Semashev wrote: >> The fact that the initial message is not part of the thread now is a >> relatively recent issue. This is the mailman archive from a year ago: >> >> https://lists.boost.org/Archives/boost/2022/04/index.php >> >> Threading is fine there. In fact, threading was working correctly as >> recently as in February 2023: >> >> https://lists.boost.org/Archives/boost/2023/02/index.php >> >> and has been broken in March: >> >> https://lists.boost.org/Archives/boost/2023/03/index.php >> >> If the system works (and worked) the way you describe, mailman was able >> to associate the initial message with the thread before and now it >> isn't. I suspect, this may have something to do with the headers that >> are added by SES to the messages it sends to the subscribers. > > Threading only sometimes works in the gmane view as well. Usually > it's not the mailing list itself at fault, but due to the mail client > used by the person posting -- or sometimes that they're replying to a > digest rather than the original mail, so the context headers are lost > (even if they edit it to look like it was a reply to a single post). > > I have noticed an apparent increase recently in the number of posts > that appear "flat" or semi-flat (still showing as a reply, but to a > grandparent post rather than the real parent post) -- but other recent > threads still do appear normally nested, so I don't think it's a > systemic issue. > I get the posts on the ML delivered as individual emails to my client (Thunderbird) and I can see the routing. Threading was fine until the end of February (through mailgun.net) and is broken since the beginning of March (through amazonses.com) The transition can be seen in the thread "Has testing on msvc been dropped?) in Tom Kent's posts. Dani -- PGP/GPG: 2CCB 3ECB 0954 5CD3 B0DB 6AA0 BA03 56A1 2C4638C5

1 0

Re: [boost] Boost.Compat
by Ruben Perez 04 May '23

04 May '23

> > > > So my suggestion is to create a separate library/repo, Boost.Compat > (boostorg/compat, namespace boost::compat) for them. > > Thoughts? (Be sure to read the discussion in the PR as well.) > I'm in favor of this. I agree with not allowing extensions, too. I think a light review should take place before inclusion. Regards, Ruben.

1 0

Re: [boost] Amazon SES
by Sam Darwin 04 May '23

04 May '23

Checking original messages locally in my inbox messages, it appears mailgun doesn't rewrite the ID. SES rewrites the ID. Not an option to disable it. I will open a discussion with mailman and see if they have any suggestions. On Thu, May 4, 2023 at 10:30 AM Andrey Semashev via Boost <boost(a)lists.boost.org> wrote: > > On 5/4/23 18:54, Sam Darwin via Boost wrote: > > The comments about Message-ID: , References: , and In-Reply-To: > > headers are very interesting. "The Amazon Simple Email Service (AWS > > SES) rewrites the Message-ID header of outgoing emails." > > Consider the very first email of a thread. It arrives at the mailman > > server with a Message-ID that mentions "gmail", for example, and is > > added to the Archives. The message is sent out to all list members, > > who see a new Message-id of > > ...010f0187dca41ec8(a)us-east-2.amazonses.com Later replies can set > > the In-Reply-To header to refer the "@us-east-2.amazonses.com" > > Message-ID. But the first archived message didn't yet have that ID, > > since it arrived directly at the server, not through SES. The mailman > > archives on lists.boost.org organize that first message in a separate > > thread, presumably based on the original Message-ID. > > Can we disable Message-ID rewriting? > > Do we know how mailgun works wrt. Message-ID and other headers? > > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Re: [boost] Amazon SES
by Andrey Semashev 04 May '23

04 May '23

On 5/4/23 18:54, Sam Darwin via Boost wrote: > The comments about Message-ID: , References: , and In-Reply-To: > headers are very interesting. "The Amazon Simple Email Service (AWS > SES) rewrites the Message-ID header of outgoing emails." > Consider the very first email of a thread. It arrives at the mailman > server with a Message-ID that mentions "gmail", for example, and is > added to the Archives. The message is sent out to all list members, > who see a new Message-id of > ...010f0187dca41ec8(a)us-east-2.amazonses.com Later replies can set > the In-Reply-To header to refer the "@us-east-2.amazonses.com" > Message-ID. But the first archived message didn't yet have that ID, > since it arrived directly at the server, not through SES. The mailman > archives on lists.boost.org organize that first message in a separate > thread, presumably based on the original Message-ID. Can we disable Message-ID rewriting? Do we know how mailgun works wrt. Message-ID and other headers?

1 0

Re: [boost] Amazon SES
by Sam Darwin 04 May '23

04 May '23

The comments about Message-ID: , References: , and In-Reply-To: headers are very interesting. "The Amazon Simple Email Service (AWS SES) rewrites the Message-ID header of outgoing emails." Consider the very first email of a thread. It arrives at the mailman server with a Message-ID that mentions "gmail", for example, and is added to the Archives. The message is sent out to all list members, who see a new Message-id of ...010f0187dca41ec8(a)us-east-2.amazonses.com Later replies can set the In-Reply-To header to refer the "@us-east-2.amazonses.com" Message-ID. But the first archived message didn't yet have that ID, since it arrived directly at the server, not through SES. The mailman archives on lists.boost.org organize that first message in a separate thread, presumably based on the original Message-ID.

1 0

Re: [boost] Q1 2023 Update: C++ Alliance's Efforts (PDF Attached)
by Vinnie Falco 04 May '23

04 May '23

On Wed, May 3, 2023 at 11:44 PM Julien Blanc via Boost <boost(a)lists.boost.org> wrote: > the "replacing the ML with a forum" That's not happening, no one is replacing the ML, and our efforts to renovate the Boost website have exactly one overarching principle: "Do not fuck with the mailing lists" The mailing lists must not be touched, they need to work exactly the way they did before (with working threading). Thanks

1 0

Re: [boost] Q1 2023 Update: C++ Alliance's Efforts (PDF Attached)
by Julien Blanc 04 May '23

04 May '23

Le 2023-05-03 15:02, Sam Darwin via Boost a écrit : > Mailgun has been in production for many years. It costs $500 per month > to send smtp messages. It's a reasonable idea to try out another > service that's only 5% of the cost. Thanks for the detailed answer. From what is seen, it does indeed looks like amazon ses is sending emails with different message ids to each participant in the mailing list. Mailgun, on the other hand, was keeping the original message id in the email. > But at the same time, it's not impossible to switch back to mailgun, > if threading is partially disrupted, and we can't find a solution. Now that the source of the problem has been identified, i hope a solution can be found. Like Phil noted, mailgun is indeed very expensive. Best regards, Julien

1 0

Re: [boost] Q1 2023 Update: C++ Alliance's Efforts (PDF Attached)
by Andrey Semashev 04 May '23

04 May '23

On 5/4/23 10:20, Gavin Lambert via Boost wrote: > On 4/05/2023 18:34, Julien Blanc wrote: >> You're luckier than me. The current thread is semi-broken, but the >> "replacing the ML with a forum" one is completely broken for me. > > Sorry, that was sloppy reporting on my part. There was a large tree of > posts that were all together so I foolishly assumed that this was the > whole thread. > > There were *also* a bunch of disconnected replies earlier on, but since > these were completely disconnected they didn't "follow" the parent > higher in the list since I'm sorting by date. This meant they were out > of sight at the time I was thinking about this and writing my message. > >> I'm starting to wonder if we all receive the same emails (in the sense >> that they may not contain the same set of headers). For me, the >> initial message of Vinnie in the "replacing the ML with a forum" >> thread contains the following: >> >> Message-ID: >> <010f0187bde5599a-e76c27f2-225d-4d7e-b2c8-887e3a07ecb8-000000(a)us-east-2.amazonses.com> >> >> But Mashshall's answer, on the other side, contains the following >> headers : >> >> References: >> <010f0187bde530fb-ff3c1911-df7d-4399-b5d2-82f8062bf18c-000000(a)us-east-2.amazonses.com> >> In-Reply-To: >> <010f0187bde530fb-ff3c1911-df7d-4399-b5d2-82f8062bf18c-000000(a)us-east-2.amazonses.com> >> >> The "In-Reply-To" should match the Id of the initial message, for >> threading to work correctly. This is too obvious to be a client bug. >> Can someone check the Message-ID he has for the initial message of >> Vinnie in the "replacing the ML with a forum" thread? If it's >> different from mine, then that's probably the source of the issues. > > For me (via gmane), Vinnie's original message has: > > Message-ID: > <010f0187bde523cc-f60c3688-3843-44d4-b848-f37b2fd6a598-000000(a)us-east-2.amazonses.com> > > And Marshall's reply (did not thread properly) has: > > Message-ID: > <010f0187bde8bc2e-bebb94d1-2dfb-4165-ad8d-6af8e9b41381-000000(a)us-east-2.amazonses.com> > References: > <010f0187bde530fb-ff3c1911-df7d-4399-b5d2-82f8062bf18c-000000(a)us-east-2.amazonses.com> > In-Reply-To: > <010f0187bde530fb-ff3c1911-df7d-4399-b5d2-82f8062bf18c-000000(a)us-east-2.amazonses.com> > > Robert's reply (did thread properly) has: > > Message-ID: > <010f0187bf4b951d-1f6d7af8-3f2e-458b-9ffd-ca91ecfe04f9-000000(a)us-east-2.amazonses.com> > References: > <010f0187bde523cc-f60c3688-3843-44d4-b848-f37b2fd6a598-000000(a)us-east-2.amazonses.com> > In-Reply-To: > <010f0187bde523cc-f60c3688-3843-44d4-b848-f37b2fd6a598-000000(a)us-east-2.amazonses.com> > > These do indeed seem to be different from yours, which is unfortunate. > > It would be good if someone else not using gmane could check both > results as well (although that shouldn't be a factor, as I have other > groups that don't appear to be getting flattening). I'm reading the ML in Thunderbird. Vinnie's initial message has: Message-ID: <010f0187bde531b6-2cd00e40-57e1-476f-b30d-896ff8eab806-000000(a)us-east-2.amazonses.com> Marshall's reply: References: <010f0187bde530fb-ff3c1911-df7d-4399-b5d2-82f8062bf18c-000000(a)us-east-2.amazonses.com> In-Reply-To: <010f0187bde530fb-ff3c1911-df7d-4399-b5d2-82f8062bf18c-000000(a)us-east-2.amazonses.com> Message-ID: <010f0187bde8ccef-31042da0-3d20-4f4a-95e8-74cd3770cc89-000000(a)us-east-2.amazonses.com> Robert's reply: Message-ID: <010f0187bf4ba591-77f55894-1b8b-40d4-b8ac-0d6af2b9ba6d-000000(a)us-east-2.amazonses.com> References: <010f0187bde523cc-f60c3688-3843-44d4-b848-f37b2fd6a598-000000(a)us-east-2.amazonses.com> In-Reply-To: <010f0187bde523cc-f60c3688-3843-44d4-b848-f37b2fd6a598-000000(a)us-east-2.amazonses.com> For me, both Marshall's and Robert's replies, which are direct replies to the initial Vinnie's post, start their own threads with their subtrees of replies. The only descendant of the Vinnie's initial post is my own reply to it, which has this: Message-ID: <187be1c7608.280f.fb49792bc380c7e55e30f872b414f11c(a)gmail.com> In-Reply-To: <010f0187bde531b6-2cd00e40-57e1-476f-b30d-896ff8eab806-000000(a)us-east-2.amazonses.com> References: <010f0187bde531b6-2cd00e40-57e1-476f-b30d-896ff8eab806-000000(a)us-east-2.amazonses.com> So basically, every direct reply to the original post, except my own one, is a separate subtree (or a single out-of-tree message if there were no replies to it).

1 0

Re: [boost] Q1 2023 Update: C++ Alliance's Efforts (PDF Attached)
by Gavin Lambert 04 May '23

04 May '23

On 4/05/2023 18:34, Julien Blanc wrote: > You're luckier than me. The current thread is semi-broken, but the > "replacing the ML with a forum" one is completely broken for me. Sorry, that was sloppy reporting on my part. There was a large tree of posts that were all together so I foolishly assumed that this was the whole thread. There were *also* a bunch of disconnected replies earlier on, but since these were completely disconnected they didn't "follow" the parent higher in the list since I'm sorting by date. This meant they were out of sight at the time I was thinking about this and writing my message. > I'm starting to wonder if we all receive the same emails (in the sense > that they may not contain the same set of headers). For me, the initial > message of Vinnie in the "replacing the ML with a forum" thread contains > the following: > > Message-ID: > <010f0187bde5599a-e76c27f2-225d-4d7e-b2c8-887e3a07ecb8-000000(a)us-east-2.amazonses.com> > > But Mashshall's answer, on the other side, contains the following headers : > > References: > <010f0187bde530fb-ff3c1911-df7d-4399-b5d2-82f8062bf18c-000000(a)us-east-2.amazonses.com> > In-Reply-To: > <010f0187bde530fb-ff3c1911-df7d-4399-b5d2-82f8062bf18c-000000(a)us-east-2.amazonses.com> > > The "In-Reply-To" should match the Id of the initial message, for > threading to work correctly. This is too obvious to be a client bug. Can > someone check the Message-ID he has for the initial message of Vinnie in > the "replacing the ML with a forum" thread? If it's different from mine, > then that's probably the source of the issues. For me (via gmane), Vinnie's original message has: Message-ID: <010f0187bde523cc-f60c3688-3843-44d4-b848-f37b2fd6a598-000000(a)us-east-2.amazonses.com> And Marshall's reply (did not thread properly) has: Message-ID: <010f0187bde8bc2e-bebb94d1-2dfb-4165-ad8d-6af8e9b41381-000000(a)us-east-2.amazonses.com> References: <010f0187bde530fb-ff3c1911-df7d-4399-b5d2-82f8062bf18c-000000(a)us-east-2.amazonses.com> In-Reply-To: <010f0187bde530fb-ff3c1911-df7d-4399-b5d2-82f8062bf18c-000000(a)us-east-2.amazonses.com> Robert's reply (did thread properly) has: Message-ID: <010f0187bf4b951d-1f6d7af8-3f2e-458b-9ffd-ca91ecfe04f9-000000(a)us-east-2.amazonses.com> References: <010f0187bde523cc-f60c3688-3843-44d4-b848-f37b2fd6a598-000000(a)us-east-2.amazonses.com> In-Reply-To: <010f0187bde523cc-f60c3688-3843-44d4-b848-f37b2fd6a598-000000(a)us-east-2.amazonses.com> These do indeed seem to be different from yours, which is unfortunate. It would be good if someone else not using gmane could check both results as well (although that shouldn't be a factor, as I have other groups that don't appear to be getting flattening). The threads that are semi-flat appear to be because it did match one of the References but not all of them. For example, in this thread, your reply was: Message-ID: <010f0187e5785f8e-23fd3577-ced2-4f4a-a235-6b7a24d0022c-000000(a)us-east-2.amazonses.com> References: <010f0187d80eb0dd-93bebdd9-cabf-4ad6-a7f4-b5515bd22d31-000000(a)us-east-2.amazonses.com> <010f0187dca41ec8-478dfff5-d27d-4879-ab72-072be2f76176-000000(a)us-east-2.amazonses.com> <010f0187e09fef87-f959fd75-f882-47dc-b20c-f103c943383d-000000(a)us-east-2.amazonses.com> <010f0187e141f8b1-75bb05d0-8b61-4190-af34-2efb57ce70df-000000(a)us-east-2.amazonses.com> <CANEqPjFF80D2dp5pAZfo1aF7YHt73_cs5wFgENNZ40_piTZnvA(a)mail.gmail.com> <010f0187e2536549-44ef0b67-13ba-420a-8c95-50e5212ccbf5-000000(a)us-east-2.amazonses.com> <010f0187e400f951-96bb316d-68ca-4d38-a08a-6f9cfb56ec78-000000(a)us-east-2.amazonses.com> In-Reply-To: <010f0187e400f951-96bb316d-68ca-4d38-a08a-6f9cfb56ec78-000000(a)us-east-2.amazonses.com> Replying to my message: Message-ID: <010f0187e400b04d-bdb05955-7e9a-4aae-b4f5-cde46033a981-000000(a)us-east-2.amazonses.com> References: <010f0187d80eb0dd-93bebdd9-cabf-4ad6-a7f4-b5515bd22d31-000000(a)us-east-2.amazonses.com> <010f0187dca41ec8-478dfff5-d27d-4879-ab72-072be2f76176-000000(a)us-east-2.amazonses.com> <010f0187e09fef87-f959fd75-f882-47dc-b20c-f103c943383d-000000(a)us-east-2.amazonses.com> <010f0187e141f8b1-75bb05d0-8b61-4190-af34-2efb57ce70df-000000(a)us-east-2.amazonses.com> <CANEqPjFF80D2dp5pAZfo1aF7YHt73_cs5wFgENNZ40_piTZnvA(a)mail.gmail.com> <010f0187e2536549-44ef0b67-13ba-420a-8c95-50e5212ccbf5-000000(a)us-east-2.amazonses.com> In-Reply-To: <010f0187e2536549-44ef0b67-13ba-420a-8c95-50e5212ccbf5-000000(a)us-east-2.amazonses.com> Which was a reply to Andrey's: Message-ID: <010f0187e2536549-44ef0b67-13ba-420a-8c95-50e5212ccbf5-000000(a)us-east-2.amazonses.com> References: <010f0187d80eb0dd-93bebdd9-cabf-4ad6-a7f4-b5515bd22d31-000000(a)us-east-2.amazonses.com> <010f0187dca41ec8-478dfff5-d27d-4879-ab72-072be2f76176-000000(a)us-east-2.amazonses.com> <010f0187e09fef87-f959fd75-f882-47dc-b20c-f103c943383d-000000(a)us-east-2.amazonses.com> <010f0187e141f8b1-75bb05d0-8b61-4190-af34-2efb57ce70df-000000(a)us-east-2.amazonses.com> <CANEqPjFF80D2dp5pAZfo1aF7YHt73_cs5wFgENNZ40_piTZnvA(a)mail.gmail.com> In-Reply-To: <CANEqPjFF80D2dp5pAZfo1aF7YHt73_cs5wFgENNZ40_piTZnvA(a)mail.gmail.com> And yet I'm seeing both my message and your reply to it as siblings under Andrey's, because you appear to have a different id for my message than I do.

1 0

Re: [boost] Q1 2023 Update: C++ Alliance's Efforts (PDF Attached)
by Julien Blanc 04 May '23

04 May '23

Le 2023-05-04 01:44, Gavin Lambert via Boost a écrit : > This is what I'm seeing -- note that the current thread appears > semi-flat (even though most of these sibling messages were actually a > reply chain), but the "replacing the ML with a forum" thread appears > mostly normal. > https://imgur.com/a/GfTS6ig You're luckier than me. The current thread is semi-broken, but the "replacing the ML with a forum" one is completely broken for me. I'm starting to wonder if we all receive the same emails (in the sense that they may not contain the same set of headers). For me, the initial message of Vinnie in the "replacing the ML with a forum" thread contains the following: Message-ID: <010f0187bde5599a-e76c27f2-225d-4d7e-b2c8-887e3a07ecb8-000000(a)us-east-2.amazonses.com> But Mashshall's answer, on the other side, contains the following headers : References: <010f0187bde530fb-ff3c1911-df7d-4399-b5d2-82f8062bf18c-000000(a)us-east-2.amazonses.com> In-Reply-To: <010f0187bde530fb-ff3c1911-df7d-4399-b5d2-82f8062bf18c-000000(a)us-east-2.amazonses.com> The "In-Reply-To" should match the Id of the initial message, for threading to work correctly. This is too obvious to be a client bug. Can someone check the Message-ID he has for the initial message of Vinnie in the "replacing the ML with a forum" thread? If it's different from mine, then that's probably the source of the issues. Regards, Julien

1 0

Re: [boost] Q1 2023 Update: C++ Alliance's Efforts (PDF Attached)
by Gavin Lambert 03 May '23

03 May '23

On 4/05/2023 03:55, Andrey Semashev wrote: > The fact that the initial message is not part of the thread now is a > relatively recent issue. This is the mailman archive from a year ago: > > https://lists.boost.org/Archives/boost/2022/04/index.php > > Threading is fine there. In fact, threading was working correctly as > recently as in February 2023: > > https://lists.boost.org/Archives/boost/2023/02/index.php > > and has been broken in March: > > https://lists.boost.org/Archives/boost/2023/03/index.php > > If the system works (and worked) the way you describe, mailman was able > to associate the initial message with the thread before and now it > isn't. I suspect, this may have something to do with the headers that > are added by SES to the messages it sends to the subscribers. Threading only sometimes works in the gmane view as well. Usually it's not the mailing list itself at fault, but due to the mail client used by the person posting -- or sometimes that they're replying to a digest rather than the original mail, so the context headers are lost (even if they edit it to look like it was a reply to a single post). I have noticed an apparent increase recently in the number of posts that appear "flat" or semi-flat (still showing as a reply, but to a grandparent post rather than the real parent post) -- but other recent threads still do appear normally nested, so I don't think it's a systemic issue. This is what I'm seeing -- note that the current thread appears semi-flat (even though most of these sibling messages were actually a reply chain), but the "replacing the ML with a forum" thread appears mostly normal. https://imgur.com/a/GfTS6ig

1 0

Re: [boost] Q1 2023 Update: C++ Alliance's Efforts (PDF Attached)
by Sam Darwin 03 May '23

03 May '23

Amazon SES is a basic SMTP gateway service. It has fewer features and options than mailgun. Incoming and outgoing mail are handled differently. When emails are sent out from the mailman server, they are proxied through SES. Only verified identities may send mail. Notice the sender says "boost(a)lists.boost.org", since lists.boost.org is a verified domain that is working, otherwise it would be blocked. Incoming emails go directly to mailman, not through any intermediary. SES is not involved with incoming emails to the mail server. This is the same situation as before. - Are emails being sent out? Almost certainly all the emails are being sent as shown by the mail logs on the mail server, and on SES it says "0.01% bounce rate", which is very good. - Is threading working? checking lists.boost.org, messages are organized into threads. However, it may be that threading is only partially correct. If that is what you are reporting. There are only a few settings exposed in the gateway to be able to adjust. One of them which hasn't been added yet is "Custom MAIL FROM domain", that could be modified from the default of amazonses.com to "a subdomain of lists.boost.org". As an experiment, I will set that today, and observe if it helps. Mailgun has been in production for many years. It costs $500 per month to send smtp messages. It's a reasonable idea to try out another service that's only 5% of the cost. But at the same time, it's not impossible to switch back to mailgun, if threading is partially disrupted, and we can't find a solution. On Wed, May 3, 2023 at 4:56 AM Andrey Semashev via Boost <boost(a)lists.boost.org> wrote: > > On 5/3/23 10:59, Julien Blanc via Boost wrote: > > Le 2023-05-02 15:25, David Sankel via Boost a écrit : > >> I wanted to call out Sam Darwin's work on this: > >> > >>> Transitioned boost mailing list gateway from mailgun to Amazon SES > >> > >> This transition has resulted in a $575 per month cost reduction in Boost > >> Foundation hosting expenses. Sam did an excellent job here. > > > > Did that happen around end of february / start of march? I've noticed > > that threaded view was broken around that date (and still is). At first, > > i blamed my client (evolution) but i see the same issue with another > > (roundcube). > > > > A quick look at mail headers seems to show wrong values in the > > References: header (but that is far beyond my expertise). > > I can see the threaded view is indeed broken in the mailman archive, for > example see here: > > https://lists.boost.org/Archives/boost/2023/04/index.php > > You can see the initial post is not grouped with the following thread. > > I should also mention that I was not totally correct when I said I don't > use threaded view when I read Boost ML. On my mobile email app that I > forgot about, I do use threaded view, and I did notice that some > messages were not grouped with the rest of the discussion. It didn't > occur to me until now whether those messages were the initial ones in > the discussion, but it may have been so. > > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

Re: [boost] Q1 2023 Update: C++ Alliance's Efforts (PDF Attached)
by David Sankel 03 May '23

03 May '23

I wanted to call out Sam Darwin's work on this: > Transitioned boost mailing list gateway from mailgun to Amazon SES This transition has resulted in a $575 per month cost reduction in Boost Foundation hosting expenses. Sam did an excellent job here. Thanks Sam and C++ Alliance for this valuable work! David Boost Foundation

2 1

Re: [boost] Boost CI Infrastructure
by Boris Kolpackov 03 May '23

03 May '23

Vinnie Falco via Boost <boost(a)lists.boost.org> writes: > I guess what I'm trying to say here is that we care deeply about long > turnaround times on CI ("they suck) have been working on the problem. This email may give an impression that the CI suckage is an inherent problem that one just has to live with so I want to provide a different perspective. As part of the build2 project we have implemented our own CI infrastructure from the grounds up: from managing our own hardware, to VM-based CI job handling, to custom web interface for result viewing. This was based on concluding that all the existing off- the-shelf solutions are primarily focused on "web development" and will result in the subpar experience for large C/C++ projects (Boost, Qt, etc). Some key differences of our approach compared to the commonly used setups (e.g., GitHub Actions): 1. "Push CI" explicitly triggered during development as opposed to "pull CI" triggered on commit/PR/etc. This allows specifying the target configurations to build in, alternative project configurations, etc.[1] 2. Standard "CI script"[2] that is used by all the C/C++ projects instead of each projects doing their own thing. This "CI script" is written in C++ and has evolved to cover a fairly elaborate set of scenarios, including: 1. Testing of preparation of source distributions (to make sure there are no missing files, etc). 2. Testing of libraries as installed (to make sure no public headers were omitted during installation, etc). 3. Ability to test projects with build-time dependencies (e.g., source code generators, build system modules, etc) in cross- compiled environments. 3. Interactive CI support. The push CI can request an interactive session where the above "CI script" is stopped at one of the pre-defined breakpoints allowing the user to login into the machine via VNC or SSH and investigate the problem. 4. Large number of build configurations covering all the major platforms/compilers/versions[3] with a well-defined obsolescence policy. To give a sense of how this works in practice, here is my typical workflow: 1. Hack on some feature in a branch, build and test locally. 2. When need to test on other platforms, push the branch to remote and submit the CI request. Normally it's just: $ bdep ci The result is a URL with the interface like this: https://ci.stage.build2.org/@04e5ffb7-cf96-42f9-bc91-94d3ffe48de1 One nice touch is that it detects compiler warnings, as can be seen in this result: https://ci.stage.build2.org/@23da340d-cb4d-4105-8474-bb870e1a1380 (Drop the UUID from the above URL to see some other CI jobs.) 3. Say everything works fine except on Windows with an old MSVC version. If the fix is clear, I push it and re-CI but just on this specific configuration (this is both faster for me and saves resources for others): $ bdep ci --build-config windows_10-msvc_14.3 If the fix is not clear and I need to play with it or run the debugger, I can request an interactive CI session: $ bdep ci --interactive windows_10-msvc_14.3/error That `/error` part is a breakpoint, meaning that the CI job will execute the standard "CI script" until the first error (compile error, test failure, etc) and pause. 4. Once all is good I clean up my feature branch (squash commits, etc), rebase on master, CI one more time for good measure, and merge to master. When I push my changes to master, there can be a hook that submits a "verification" CI job. [1] https://build2.org/bdep/doc/bdep-ci.xhtml [2] https://build2.org/bbot/doc/build2-build-bot-manual.xhtml#arch-worker [3] https://ci.cppget.org/?build-configs

1 0

Re: [boost] Q1 2023 Update: C++ Alliance's Efforts (PDF Attached)
by Andrey Semashev 03 May '23

03 May '23

On 5/3/23 10:59, Julien Blanc via Boost wrote: > Le 2023-05-02 15:25, David Sankel via Boost a écrit : >> I wanted to call out Sam Darwin's work on this: >> >>> Transitioned boost mailing list gateway from mailgun to Amazon SES >> >> This transition has resulted in a $575 per month cost reduction in Boost >> Foundation hosting expenses. Sam did an excellent job here. > > Did that happen around end of february / start of march? I've noticed > that threaded view was broken around that date (and still is). At first, > i blamed my client (evolution) but i see the same issue with another > (roundcube). > > A quick look at mail headers seems to show wrong values in the > References: header (but that is far beyond my expertise). I can see the threaded view is indeed broken in the mailman archive, for example see here: https://lists.boost.org/Archives/boost/2023/04/index.php You can see the initial post is not grouped with the following thread. I should also mention that I was not totally correct when I said I don't use threaded view when I read Boost ML. On my mobile email app that I forgot about, I do use threaded view, and I did notice that some messages were not grouped with the rest of the discussion. It didn't occur to me until now whether those messages were the initial ones in the discussion, but it may have been so.

1 0

Re: [boost] Mailing Lists For The Win!
by Hans Dembinski 03 May '23

03 May '23

> On 2. May 2023, at 17:52, Vinnie Falco via Boost <boost(a)lists.boost.org> wrote: > > This will take additional time so it probably won't make it into the > initial cut of the website, but we will at least be showing read-only > archives for now. And the mailing list will remain as-is, forever. This sounds like a pretty neat solution. I like the mailing list to participate in the communication, but I don't like to browse the ML archive to dig up old conversations. I think that's going to be easier with the forum. Hans

1 0

Re: [boost] Q1 2023 Update: C++ Alliance's Efforts (PDF Attached)
by Julien Blanc 03 May '23

03 May '23

Le 2023-05-02 15:25, David Sankel via Boost a écrit : > I wanted to call out Sam Darwin's work on this: > >> Transitioned boost mailing list gateway from mailgun to Amazon SES > > This transition has resulted in a $575 per month cost reduction in > Boost > Foundation hosting expenses. Sam did an excellent job here. Did that happen around end of february / start of march? I've noticed that threaded view was broken around that date (and still is). At first, i blamed my client (evolution) but i see the same issue with another (roundcube). A quick look at mail headers seems to show wrong values in the References: header (but that is far beyond my expertise). > Thanks Sam and C++ Alliance for this valuable work! Yes, thanks for all this invisible work. Julien

1 0

Re: [boost] Replacing the ML with a forum
by Dominique Devienne 02 May '23

02 May '23

On Mon, May 1, 2023 at 8:15 AM Vinnie Falco via Boost <boost(a)lists.boost.org> wrote: > On Sun, Apr 30, 2023 at 8:56 PM Rainer Deyke via Boost > <boost(a)lists.boost.org> wrote: > > The SDL mailing list moved from true mailing list on gmane to Discourse > > web forum with email notification (but no gmane) a while back > > Good thing that's not happening to Boost > I've already mentioned it, but I feel compelled to re-iterate, given the lets-built-it direction, although I know it's most likely in vein. SQLite made the transition from ML to a custom-built Forum, and it went/was OK. I and several others were against it. In the end, the community survived and thrived. I've used Discord in the past. I've used Basecamp. I've used News (Google Reader, RIP). And of course I've used MLs too, these ones included. [The Fossil Forums][1] are low-key, fast, i.e. good enough. And very low resources on the backend. The Forums integrate with [Pikchr][2] for text-based diagramming. Email notification is implemented, but replies by emails are not. You don't need to use Fossil SCM to use them. Many people use Fossil just for the Forums. Unlike SQLite, Fossil is open to contributions too, although the community is opinionated. I have no stake in Fossil. I'm just a happy user. FWIW. --DD [1]: https://www.fossil-scm.org/home/doc/trunk/www/forum.wiki [2]: https://fossil-scm.org/home/doc/trunk/www/pikchr.md

2 1

Re: [boost] The History of Boost
by Vinnie Falco 02 May '23

02 May '23

On Mon, May 1, 2023 at 1:44 PM Andrey Semashev via Boost <boost(a)lists.boost.org> wrote: > I think, you can start by copying all the existing information on the > current site and then improve on it. I don't see the point in > registering issues requesting adding information that is already there > on the current website. Yep! Well, maybe just one issue with links to all the existing info? > IMO, this style of navigation is too obscure. I would have never thought > to click on "User Guide" in the bottom corner of the screen to switch to > other documents. That UI is temporary, it is what comes with the "Antora Default UI." In the actual website there will be a nice looking page showing a handful of cards, one for each document, with information about what is inside the document and a small sample of the most important topics inside. And you will always be able to get to this page just by clicking "Learn" in the top level navigation. > The navigation line at the top is useless because > "home" leads to "User Guide" and not a landing page with contents. Yes, that top level navigation area is temporary. In the actual website one of the top level navigation items says "Learn" and this takes you to a landing page that has beautiful cards which link to each individual document. No matter where you are on the website (which includes individual Boost library documentation) it will be possible to reach the landing page with the site-docs in a single click (by pressing "Learn" at the top). The restyling of the Antora UI to match the website is not a trivial undertaking; all of the Asciidoc CSS classes have to be styled with it, and there are a LOT of them. Lists, tables, admonitions, source code boxes (especially those because we want them to be awesome the whole focus of our website is on source code). This is happening in parallel with the authoring of the exposition. Thanks!

1 0

Re: [boost] Boost CI - a modest proposal
by Hans Dembinski 02 May '23

02 May '23

> On 30. Apr 2023, at 17:37, Robert Ramey via Boost <boost(a)lists.boost.org> wrote: > > the implementation of Boost CI follows the normal pattern for the implementation of this functionality. This entails download the latest version of the library to be tested and it's dependencies (or maybe all of boost?) from the repo, Building everything from scratch, running all the tests and logging the output there of. This is done for each compiler / environment to be tested. Other than the raw console logs, there is no presentation of the tests results (e.g boost test matrix). > > This is extremely unsatisfactory. > > a) It's ridiculously resource intensive. Rebuilding everything all the time. > > b) takes forever unless one has many more servers than we have. These two points can be addressed somewhat by cutting down the matrix and by using ccache. You don't really need to test all versions of all compilers. For daily work it is sufficient to use the lowest and highest compiler versions you want to support. If the main time is spend in compiling the test instead of running them, Boost.CI could be sped up by using ccache. If have used ccache in other projects, where it sped up the CI considerably. Best regards, Hans

1 0

Re: [boost] Boost.Compat
by Hans Dembinski 02 May '23

02 May '23

> On 30. Apr 2023, at 01:06, Andrey Semashev via Boost <boost(a)lists.boost.org> wrote: > > I really don't like us having > multiple copies of the same components for the sole purpose of reducing > dependencies (in the case of latch - reducing tests dependencies, not > even library dependencies). Me neither, but like everything in life it is a trade-off. I want to both reduce duplication and dependencies in Boost.Histogram, which is a rather high-level library that builds on a lot of low-level Boost functionality. To reduce dependencies, I used to have my own implementation of stuff like variant or span, which I eventually replaced with boost::span in Boost.Core and Boost.Variant2. This is partially repeating what others have said: I see utility in Boost.Compat, because the scope of Boost.Compat is well-defined, while the scope of Boost.Core isn't. I have had discussions with the Boost.Core devs over what should be in Boost.Core or not. Knowing the scope of a boost library helps both with making requests that have a chance to be accepted and also makes it more clear for users what to expect from this library. Regarding the reviewing of Boost.Compat: A light review is sufficient, since we can skip the discussion of the design/scope/etc, but it looks like we want to have some initial review. We are currently discussing scope and rules for this library, these should be approved by a formal review. Just my two cents, Hans

1 0

Re: [boost] Boost CI Infrastructure
by Niall Douglas 01 May '23

01 May '23

On 30/04/2023 18:31, Vinnie Falco via Boost wrote: > Alan de Freitas has done a considerable amount of good work in this > area so if you would like to ask specific questions on the list or in > the Slack workspace that is also a good choice (or you can ask me or > Sam). Alan contributed a whole bunch of GHA CI for Boost.Outcome. It runs very well, it usually completes before the Drone CI does for Outcome. People here may be interested in studying it and how it works. My thanks to Alan for doing all the heavy lifting there. And to Peter Dimov for identifying things which had become broken in Boost.Outcome due to changes elsewhere in Boost but hadn't registered on CI, and therefore needed much wider CI testing (which Alan then implemented). Also, thanks to Vinnie for asking Alan to do that work for Outcome. I haven't had the time recently (spent the last three days driving around a six tonne digger lifting 'lego' concrete blocks, it has been very tedious). Niall

1 0

Re: [boost] Boost.Compat
by Christian Mazakas 01 May '23

01 May '23

> It doesn't really matter how many dependencies Boost.Thread adds. What > matters is how expensive <boost/thread/latch.hpp> is. Personally, I > would have no problem depending on it, if I really needed this component. One problem here is that Thread is effectively unmaintained. In general, I'm not a huge fan of depending on libraries like this in my own tests because Unordered has a very strict set of flags and many Boost libraries won't clear the same bar. I remember in the past having a test dependency on one of the bigger Boost libraries and it wasn't exactly painless. I can't remember now if it was Container or Filesystem. Boost.Compat has utility in that it's essentially just a collection of substitutes for all the goodies the committee added that could've been in C++11. This benefits both authors and users massively, instead of purporting that anyone should rely on an unmaintained lib. - Christian

1 0

Re: [boost] The History of Boost
by Andrey Semashev 01 May '23

01 May '23

On 5/1/23 18:36, Vinnie Falco via Boost wrote: > Now I'm not asking anyone to actually write docs, but I notice there > has been basically no participation from anyone on the mailing in the > site-docs that I announced recently, with the exception of a couple of > very helpful people who also happen to be staff engineers at C++ > Alliance. I think, you can start by copying all the existing information on the current site and then improve on it. I don't see the point in registering issues requesting adding information that is already there on the current website. > Reminder: > > Site Documentation (there are 4 docs here, use the control at the > bottom left to switch from User's Guide to the others): > > https://docs.cppalliance.org/doc/user-guide IMO, this style of navigation is too obscure. I would have never thought to click on "User Guide" in the bottom corner of the screen to switch to other documents. The navigation line at the top is useless because "home" leads to "User Guide" and not a landing page with contents.

1 0

Q1 2023 Update: C++ Alliance's Efforts (PDF Attached)
by Louis Tatta 01 May '23

01 May '23

Dear Boost Libraries Mailing List, I am writing to share with you a summary of the efforts of our team at C++ Alliance to enhance the Boost Libraries during Q1 2023. Please find attached a PDF document that provides an overview of the work we have done to maintain existing libraries, develop new ones, and improve documentation and support. We are proud of the progress we have made so far and remain committed to improving the Boost Libraries in the future. We believe that these libraries can help C++ developers write more efficient, reliable, and maintainable code. Thank you for your time and attention, and please let us know if you have any feedback or questions. Best regards, Louis C++ Alliance Team

1 0

The History of Boost
by Vinnie Falco 01 May '23

01 May '23

Now I'm not asking anyone to actually write docs, but I notice there has been basically no participation from anyone on the mailing in the site-docs that I announced recently, with the exception of a couple of very helpful people who also happen to be staff engineers at C++ Alliance. Reminder: Site Documentation (there are 4 docs here, use the control at the bottom left to switch from User's Guide to the others): https://docs.cppalliance.org/doc/user-guide GitHub issues for site-docs: https://github.com/cppalliance/site-docs/issues You don't need to submit a pull request; adding information to existing issues, or opening new issues is an enormous help. Now on that subject we want to make sure we have a "History Of Boost" chapter which thoughtfully outlines the founding of Boost and its noteworthy historical events leading to the present day. We want to make sure we get this right and credit everyone who needs crediting, and not miss anything important. Boost is volunteer work and since there is no financial compensation the only other currency is social credit and reputation so this has to be correct. If you could please visit this issue and add any information that you feel is relevant to the history of Boost (it can be notes or shorthand don't worry about grammar, Peter Turcan will edit it down and add it) that would be of enormous help: Issue on The History of Boost: https://github.com/cppalliance/site-docs/issues/37 Of course adding to any other issue or opening new ones is a help too, so feel free! Thanks

1 0

Re: [boost] New Number theory algorithm
by Vinnie Falco 01 May '23

01 May '23

On Mon, May 1, 2023 at 7:59 AM Ottó Virág via Boost <boost(a)lists.boost.org> wrote: > I ... would like to have included in boost my achievement. This sounds exciting! Do you have a link to a GitHub or other git repository that we might look at to see this code? Thanks

1 0

Re: [boost] New Number theory algorithm
by Matt Borland 01 May '23

01 May '23

> On May 1, 2023, at 4:50 PM, Ottó Virág via Boost <boost(a)lists.boost.org> wrote: > > Hello everyone, my name is Ottó. I have done research in mathematical > number theory, and would like to have included in boost my achievement. > It's about fuzziness in beginning and after that you can use it to speed up > solving calculus and other equations in mathematic and physics, even to the > particles degree! > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Otto, The natural home for this would be Boost.Math which can be found here: https://github.com/boostorg/math. Matt

1 0

New Number theory algorithm
by Ottó Virág 01 May '23

01 May '23

Hello everyone, my name is Ottó. I have done research in mathematical number theory, and would like to have included in boost my achievement. It's about fuzziness in beginning and after that you can use it to speed up solving calculus and other equations in mathematic and physics, even to the particles degree!

1 0

Re: [boost] Replacing the ML with a forum
by Vinnie Falco 01 May '23

01 May '23

On Sun, Apr 30, 2023 at 8:56 PM Rainer Deyke via Boost <boost(a)lists.boost.org> wrote: > The SDL mailing list moved from true mailing list on gmane to Discourse > web forum with email notification (but no gmane) a while back Good thing that's not happening to Boost

1 0

Re: [boost] Replacing the ML with a forum
by Rainer Deyke 01 May '23

01 May '23

On 30.04.23 22:58, Ion Gaztañaga via Boost wrote: > On 27/04/2023 2:26, Gavin Lambert via Boost wrote: >> On 27/04/2023 08:40, Robert Ramey wrote: >>> I use a threaded email reader - Thunderbird. >>> >>> I get my mailing list posts via a news reader. >>> >>> This is a perfectly wonderful setup and I'd be loath to change it. >> >> +1 on all three points. Via gmane, specifically. >> > > Same here. Thunderbird with gmane to read the mailing list as a > newsgroup. Works great. I also use gmane. The SDL mailing list moved from true mailing list on gmane to Discourse web forum with email notification (but no gmane) a while back. That's the main reason why I no longer participate in that community. -- Rainer Deyke (rainerd(a)eldwood.com)

1 0