- Boost - lists.preview.boost.org

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

Re: [boost] Boost.Compat
by Glen Fernandes 30 Apr '23

30 Apr '23

On Sun, Apr 30, 2023 at 7:54 PM Gavin Lambert via Boost < boost(a)lists.boost.org> wrote: > A Boost implementation *must not* provide a definition appearing in the > std:: namespace. (Except where expressly permitted by std extension > points, such as std::hash. Though those make me sad.) > > Nobody is talking about putting anything inside namespace std. We're talking about writing equivalents of std in namespace boost. Glen

1 0

Re: [boost] library usage statistics
by Gavin Lambert 30 Apr '23

30 Apr '23

On 1/05/2023 03:19, Peter Dimov wrote: > Robert Ramey wrote: >> The basic question that occurs to me is "is this library worth maintaining and >> keeping in boost". If dropping the library would break a lot of users code, >> then the answer is an easy yes. If dropping the library would result in breaking >> no code - the answer is an easy no. >> Otherwise it's a judgement call we can argue about. But in order to do this we >> need to know the answer the question: "How much code would be broken if >> not in Boost. Hopefully this sheds light on this. > > There's probably a way to answer the question "how many Debian (Ubuntu, > Fedora...) packages would be broken if we remove library X from Boost", but > I don't know what it is. You could in principle trawl the package indexes and find how many packages have a direct dependency on "libboost-xyz" (or whatever the local package name for a specific library is), and then recursively work upwards by finding packages that depend on that package, etc. It's harder for the Boost libs that don't produce binary packages -- often there will be a dependency to a readme or something even when there isn't a binary, but not always. You *might* be able to narrow it down if the source packages declare a dependency on specific Boost library source packages rather than a monolithic libboost-dev, though.

1 0

Re: [boost] Boost.Compat
by Gavin Lambert 30 Apr '23

30 Apr '23

On 29/04/2023 02:11, Glen Fernandes wrote: > On Friday, April 28, 2023, Dominique Devienne wrote: >> Of course, Boost.Compat (or Boost.Polyfill) would need to turn >> on/off its std:: alternatives depending on the standard level in use. > > If everyone agrees, this can be one of the tenets of Boost.Compat from the > very beginning. > > The "depending on the standard level in use" might be further clarified to > mean "provides a fully functional std:: version". A Boost implementation *must not* provide a definition appearing in the std:: namespace. (Except where expressly permitted by std extension points, such as std::hash. Though those make me sad.) A Boost implementation *should not* provide a definition that is merely `using std::foo` if it does have its own alternative definition, unless there is no risk of incompatibility (type traits are relatively safe, classes are not). A Boost implementation *may* provide different implementations depending on std level in effect, but *only* in separate namespaces (with alias in the "main" namespace). (i.e. you can define boost::foo::cxx11::myfoo and boost::foo::cxx17::myfoo and then alias boost::foo::myfoo to one or the other based on std level. Ideally, a C++17 compilation would define both and a C++11 compilation would only define one, since it presumably can't define the newer one.) Where both std and boost types exist, an application should be allowed to select whichever one it prefers; including selecting the boost implementation of a type even if an equivalent or better type exists in std. Reasoning: even in this day and age, different compilation units may be compiled with different --std levels, and it is a Very Bad Idea™ to have different ABI definitions visible to different compilation units, as ODR violations are no fun for anyone. If the above is followed then you'll get either working code or a clean link error at the seams, instead of more subtle horribleness. Similarly, an uplevel compilation unit may want to explicitly select a Boost type in its interface to a downlevel compilation unit, expecting that these will be compatible types. (In an ideal world, this would apply to any other ABI-affecting condition as well; though you can usually ignore platform/compiler-level differences not as easily changed as the std level.)

1 0

Re: [boost] Replacing the ML with a forum
by Ion Gaztañaga 30 Apr '23

30 Apr '23

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. Ion

1 0

Boost CI Infrastructure
by Vinnie Falco 30 Apr '23

30 Apr '23

The C++ Alliance has an interest in, and has made ongoing efforts towards, ensuring the availability and quality of the Continuous Integration systems that Boost uses. If you recall, when Travis went pay we deployed our own instances of Drone (https://drone.io) Sam submitted pull requests to every Boost repository offering the option (but not the requirement) to have builds take place on our Drone infrastructure. Now I'm not sure if it could handle every single library doing builds of 20+ targets but it helped some. GitHub Actions became available, and there was the possibility to split the load (or make a redundant script) of targets across both Drone and GHA. However we have noticed that GHA for the Boost GitHub organization kind of sucks because we have 160+ libraries that are all submitting GHA jobs under the same user (the https://github.com/boostorg Organization account). When users submit GHA jobs for their libraries under their own account (for example if I run a GHA CI job for Boost.URL using my fork at https://github.com/vinniefalco/url) we have noticed that the turnaround is much better. Probably because the individual account is not competing with 160+ other jobs. The C++ Alliance upgraded its GHA account status for free, to have elevated access to resources for being a certified non-profit organization. We are in the process of getting the Boost GHA account upgraded as well. However, since we still have 160+ libraries all competing for resources it might still not be enough. Drone offers the possibility of self-hosted runners, but Alan ran into a problem with Drone. That is, that it's scripting language (Starlark) for lack of a better term "sucks balls." The Python version isn't much better. The main problem is that it is very hard to write scripts which are compositions of other scripts, one because of the object model of the CI and two because of these security restrictions which attempt to prevent abuse/spam. Alan de Freitas has done extensive work writing scripts for both Drone and GHA and has concluded that the GHA language and ecosystem is far superior. There is a free marketplace for GHA actions where you can just "include" a program for anything that you need to do: https://github.com/marketplace?type=actions It is very easy to compose new actions out of existing actions, and having the CI dashboard integrated into the repository and pull requests is definitely a plus. The problem still remains that GHA is overloaded during peak times. Sam Darwin (our CTO) is attempting to deploy a network of self-hosted GHA runners for the Boost organization. These are costly and we would like to only activate these runners when GitHub's shared runners are over some threshold of load. Thus Sam is wrestling with various APIs (and reaching out to Microsoft) to see how we can achieve this. The problem is that the GHA action file has to specify which runner to use (our own versus the share) and this complicates things as this file is committed to the repository. 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. I have even been working on this myself before The C++ Alliance became involved, by trying to refactor my libraries to compile faster. To break out things common to tests into their own .lib or .o file so that the same library sources are not compiled more than once. By reducing the amount of stuff in headers, avoiding overly fancy and complex metaprogramming, cutting down on the amount of instantiations of various function templates. Alan and I have also put effort into making the most out of a fixed number of CI targets. For example, by cleverly arranging the settings on the various targets so that we get the most amount of combinations of toolchains and settings out of the least amount of targets. Okay, tl;dr: time. If you are having two hour CI turnarounds, it means quite frankly that you have not put any effort into caring about your CI's workload. Just like you can't expect to keep putting more and more shit into header files and having compilations stay fast, you also cannot expect to just load your CI up with everything and have it always be responsive. You need to continually monitor and adjust your CI scripts to get the most out of the finite CI resources, just like you have to continually refactor and adjust your library to keep compile times down, to keep the number of dependencies on additional Boost libraries down (yes this matters Andrey) We can throw more resources at the problem but C++ authors (especially Boost ones) will always be able to write code and scripts that consume more resources than what is available. We might have a section in the "Contributor's Guide" outlining strategies for cutting down CI workloads and turnaround times (Peter Turcan)?. 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). Thanks

1 0

Re: [boost] Boost CI - a modest proposal
by Peter Dimov 30 Apr '23

30 Apr '23

Robert Ramey wrote: > I would suggest we throw the whole thing out and consider a different > approach. This approach would be more along the lines of that used by > CMake test server. Complete documentation of how CMake does it is > described in the CMake documentation. Basically it works like this. > > I run my CMake tests locally. This means that tests are not run on a server, but > on some users configuration. This spreads the load. Well, the main point of CI is to test your code on platforms other than your local one.

1 0

Re: [boost] Boost CI - a modest proposal
by Peter Dimov 30 Apr '23

30 Apr '23

John Maddock wrote: > It does however require discipline to not trigger useless builds (or cancel them > when they happen), ... For heavy CI workloads, setting up ccache correctly helps a lot in these cases.

1 0

Re: [boost] Boost CI - a modest proposal
by Andrey Semashev 30 Apr '23

30 Apr '23

On 4/30/23 18:37, Robert Ramey via Boost 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. Rebuilding everything is good. Incremental builds are fragile. > b) takes forever unless one has many more servers than we have. > > c) builds/tests even with the most trivial check-in. like adding a > period to a documentation page. You can mark commits to skip CI, if you want. > I would suggest we throw the whole thing out and consider a different > approach. This approach would be more along the lines of that used by > CMake test server. Complete documentation of how CMake does it is > described in the CMake documentation. Basically it works like this. > > I run my CMake tests locally. This means that tests are not run on a > server, but on some users configuration. This spreads the load. > > This means I run a special CMake target which takes the latest results > and posts them to a server. The results are not posted automatically - > I have to ask for it so it only happens when I know that a change is not > trivial. > > It also means that all configurations actually being used (and only > those configurations) are tested and the results logged. > > The server can than be queried to produce a table of results by > configuration, compiler, library, etc on demand. CMake people maintain > a basic server where one can post his results. But it's query facility > isn't really complete enough for boost needs. This facility would need > to be upgraded to boost requirements. Actually we have several > application which might serve as a starting point: my library_status app > which I use to produce a table of results and the app which produces the > boost library test matrix. > > All in all this would produce a system which would actually be useful. As a developer, I would like to know that the commit I pushed works on all configurations I care to support relatively soon (in a matter of minutes to hours), so that I can merge this commit to master. I do not want to wait until someone bothers to checkout and test this commit - on every supported system. You cannot expect this to happen any time soon, and you'll be lucky if you hear a bug report before a release deadline, when it is already too late to fix it.

1 0

Re: [boost] Boost CI - a modest proposal
by John Maddock 30 Apr '23

30 Apr '23

On 30/04/2023 16:44, Robert Ramey via Boost 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). I think you're wrong to call it "Boost.CI", most of what you're complaining about is the stuff that's outside our control - like the way Github actions run and so forth. > > This is extremely unsatisfactory. > > a) It's ridiculously resource intensive. Rebuilding everything all > the time. For github, I believe it can be configured to retain artifacts between builds and therefore perform incremental builds.... but, that is horrendously heavy on storage space, my expectation is that Github would throw us off for excessive usage! > > b) takes forever unless one has many more servers than we have. We have zero servers for CI, it's all Github etc. > > c) builds/tests even with the most trivial check-in. like adding a > period to a documentation page. Put [CI SKIP] in the commit message and nothing will build. > > I would suggest we throw the whole thing out and consider a different > approach. This approach would be more along the lines of that used by > CMake test server. Complete documentation of how CMake does it is > described in the CMake documentation. Basically it works like this. > > I run my CMake tests locally. This means that tests are not run on a > server, but on some users configuration. This spreads the load. > Well that's how we used to do things ;) Run it yourself, and hope for the best! I can tell you that I hated CI when it turned up, I mean what? Disturb my workflow and actually force me to change stuff! I can also tell you that a well set up CI system catches no end of small issues that I would never have spotted otherwise, also tests on platforms which I otherwise have no access to, and I simply would not be without it now! It does however require discipline to not trigger useless builds (or cancel them when they happen), and the need to update what you're testing and on what platforms periodically is a right pain, but I can also see why Github (for example) will need to deprecate and remove outdated distributions from time to time. So we all have to live with change I guess :( John.

1 0

Re: [boost] Boost.Compat
by Peter Dimov 30 Apr '23

30 Apr '23

Andrey Semashev wrote: > It doesn't really matter how many dependencies Boost.Thread adds. But it does. And you even need to build the library in this case.

1 0

Re: [boost] Boost::Regex support with ICU for unicode characters.
by John Maddock 30 Apr '23

30 Apr '23

> 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] ICU is an external dependency, we don't install it: it should already be installed prior to building Boost. Further, if you are using one of the last couple of Boost releases, then Regex is a header only library, and there is no need to build and install anything. You will however, have to link to ICU when you build your program. With regard to not matching specific text, if you can post the actual test code, I'll look at it. John.

1 0

Re: [boost] Boost CI - a modest proposal
by Vinnie Falco 30 Apr '23

30 Apr '23

On Sun, Apr 30, 2023 at 8:44 AM Robert Ramey via Boost <boost(a)lists.boost.org> wrote: > I would suggest we throw the whole thing out No

1 0

std vs boost
by Robert Ramey 30 Apr '23

30 Apr '23

When I'm writing library or user code, I often reach for a library component. Often, the similar/equivalent component exists in both the standard library component and the comparable boost component. I'm never confident about which to choose. Ideally I'd like a simple rule like "if you can choose between two components - prefer the standard library one (or Boost one) because ...". Is it possible to craft such a rule? My main criteria is mainly stability - once I've got something working I hate to be surprised when some "upgrade" breaks my code. Or is no longer supported. In other words, I don't want (and cannot) baby sit the application/library forever. Anyone have thoughts on this? Robert Ramey

1 0

Boost CI - a modest proposal
by Robert Ramey 30 Apr '23

30 Apr '23

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. c) builds/tests even with the most trivial check-in. like adding a period to a documentation page. I would suggest we throw the whole thing out and consider a different approach. This approach would be more along the lines of that used by CMake test server. Complete documentation of how CMake does it is described in the CMake documentation. Basically it works like this. I run my CMake tests locally. This means that tests are not run on a server, but on some users configuration. This spreads the load. This means I run a special CMake target which takes the latest results and posts them to a server. The results are not posted automatically - I have to ask for it so it only happens when I know that a change is not trivial. It also means that all configurations actually being used (and only those configurations) are tested and the results logged. The server can than be queried to produce a table of results by configuration, compiler, library, etc on demand. CMake people maintain a basic server where one can post his results. But it's query facility isn't really complete enough for boost needs. This facility would need to be upgraded to boost requirements. Actually we have several application which might serve as a starting point: my library_status app which I use to produce a table of results and the app which produces the boost library test matrix. All in all this would produce a system which would actually be useful. Robert Ramey

1 0

Re: [boost] library usage statistics
by Peter Dimov 30 Apr '23

30 Apr '23

Robert Ramey wrote: > The basic question that occurs to me is "is this library worth maintaining and > keeping in boost". If dropping the library would break a lot of users code, > then the answer is an easy yes. If dropping the library would result in breaking > no code - the answer is an easy no. > Otherwise it's a judgement call we can argue about. But in order to do this we > need to know the answer the question: "How much code would be broken if > not in Boost. Hopefully this sheds light on this. There's probably a way to answer the question "how many Debian (Ubuntu, Fedora...) packages would be broken if we remove library X from Boost", but I don't know what it is.

1 0

Re: [boost] CI Test time
by Robert Ramey 30 Apr '23

30 Apr '23

On 4/29/23 4:13 PM, Andrey Semashev via Boost wrote: > On 4/29/23 23:45, Robert Ramey via Boost wrote: >> Looks like the CI for the serialization library takes about 200 minutes >> to run (on a good day). When I run it on my local desktop for one >> compiler/configuration it takes 1-2 minutes. It seems to me that the >> way that CI works, it entails a huge waste resources and time. Has >> anyone thought about this? > > If you know where most overhead is coming from, you can work towards > reducing that overhead. For example, you can save time wasted on > environment setup and git checkout if you run tests for different > configurations in one CI job. > > If you want more specific comments then you probably have to provide > more details on your problem. Actually I have made very specific observations regarding the issue. I didn't receive any useful feedback. When I thinking about it's pretty easy to see why - the CI concept as implemented in boost is irretrievably broken. Robert Ramey

1 0

Re: [boost] library usage statistics
by Robert Ramey 30 Apr '23

30 Apr '23

On 4/29/23 3:23 PM, René Ferdinand Rivera Morell via Boost wrote: > On Sat, Apr 29, 2023 at 3:42 PM Robert Ramey via Boost > <boost(a)lists.boost.org> wrote: >> >> Looking at the discussion regarding multi-array, I'm thinking I'd like >> to know how many people/projects are using the current version. > > Define "using", as precisely as you can. Then, maybe, we can figure > out how to measure. > > Good question - I havn't really thought about it enough yet. This is mainly because I haven't figured out how to do it. The basic question that occurs to me is "is this library worth maintaining and keeping in boost". If dropping the library would break a lot of users code, then the answer is an easy yes. If dropping the library would result in breaking no code - the answer is an easy no. Otherwise it's a judgement call we can argue about. But in order to do this we need to know the answer the question: "How much code would be broken if not in Boost. Hopefully this sheds light on this. Robert Ramey

1 0

Re: [boost] Boost.Compat
by Andrey Semashev 30 Apr '23

30 Apr '23

On 4/30/23 15:18, Peter Dimov via Boost wrote: > Andrey Semashev wrote: >> On 4/30/23 02:18, Peter Dimov via Boost wrote: >>> Andrey Semashev wrote: >>>> And lastly. I realize that the proposed Boost.Compat is supposed to >>>> contain direct equivalents of the standard components. But what if we >>>> want to improve on that? Would this be not allowed simply because >>>> this would deviate from the standard? >>> >>> No, it wouldn't be allowed. Improving upon the standard makes it >>> impossible to later replace the compatibility header with a using >>> declaration. We have such a problem today with e.g. Boost.Ratio and >>> Boost.Chrono, where because of extensions we can't simply make them be >> <ratio> and <chrono>. >>> >>> It's fine to want to improve upon the standard, but Compat will not be >>> the place for that. That's what dedicated libraries are for. >> >> This would mean more code duplication, wouldn't it? > > It's a tradeoff as any other. You need <latch>. Since it's trivial to implement > over C++11, you add a private implementation to your library. This duplicates > the one in Boost.Thread. But you don't want to depend on Boost.Thread, > because if you don't need C++03 support or thread interruption, it duplicates > the standard library, and adds 50 dependencies. > > https://pdimov.github.io/boostdep-report/boost-1.82.0/module-weights.html#w… 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. > In addition, the code duplication in Compat will gradually disappear as its > minimum C++ standard level is raised. E.g. shared_mutex.hpp (assuming > we have it) will effectively disappear at 14. latch.hpp will disappear at 20. This will happen when? I don't imagine Boost is raising its minimum C++ version to C++14, let alone 20 any time soon. > We can't clean up Boost.Thread in this manner even if we impose a C++11 > requirement, since it has to provide its own primitives for everything > because of thread interruption. > > But you know this because that's what the Sync intro says. :-) Regarding thread interruption, we could simply deprecate it and remove over time. I think, that was one of the ideas behind Boost.Sync - e.g. boost::mutex from Boost.Thread would get deprecated in favor of boost::sync::mutex from Boost.Sync. It might not be too late to revive Boost.Sync and add a latch implementation there.

1 0

Re: [boost] Boost.Compat
by Peter Dimov 30 Apr '23

30 Apr '23

Andrey Semashev wrote: > On 4/30/23 02:18, Peter Dimov via Boost wrote: > > Andrey Semashev wrote: > >> And lastly. I realize that the proposed Boost.Compat is supposed to > >> contain direct equivalents of the standard components. But what if we > >> want to improve on that? Would this be not allowed simply because > >> this would deviate from the standard? > > > > No, it wouldn't be allowed. Improving upon the standard makes it > > impossible to later replace the compatibility header with a using > > declaration. We have such a problem today with e.g. Boost.Ratio and > > Boost.Chrono, where because of extensions we can't simply make them be > <ratio> and <chrono>. > > > > It's fine to want to improve upon the standard, but Compat will not be > > the place for that. That's what dedicated libraries are for. > > This would mean more code duplication, wouldn't it? It's a tradeoff as any other. You need <latch>. Since it's trivial to implement over C++11, you add a private implementation to your library. This duplicates the one in Boost.Thread. But you don't want to depend on Boost.Thread, because if you don't need C++03 support or thread interruption, it duplicates the standard library, and adds 50 dependencies. https://pdimov.github.io/boostdep-report/boost-1.82.0/module-weights.html#w… In addition, the code duplication in Compat will gradually disappear as its minimum C++ standard level is raised. E.g. shared_mutex.hpp (assuming we have it) will effectively disappear at 14. latch.hpp will disappear at 20. We can't clean up Boost.Thread in this manner even if we impose a C++11 requirement, since it has to provide its own primitives for everything because of thread interruption. But you know this because that's what the Sync intro says. :-)

1 0

Re: [boost] Boost.Compat
by Andrey Semashev 30 Apr '23

30 Apr '23

On 4/30/23 14:58, Peter Dimov via Boost wrote: > Andrey Semashev wrote: >> I didn't say anything against refactoring, in fact I'm arguing that we should >> maintain our existing libraries (which includes refactoring) rather than add >> new libraries with duplicate components. > > You did create the (stillborn) Sync though, which duplicates Thread. Why? It doesn't fully duplicate Boost.Thread. It added new synchronization primitives and added support for different timing libraries besides Boost.Chrono. There was another idea that Boost.Thread became too large and difficult to maintain. So the thread synchronization primitives were supposed to be extracted to a separate library, Boost.Sync, leaving only thread launching and high-level tools like future/promise, async and thread pool in Boost.Thread.

1 0

Re: [boost] Boost.Compat
by Peter Dimov 30 Apr '23

30 Apr '23

Andrey Semashev wrote: > I didn't say anything against refactoring, in fact I'm arguing that we should > maintain our existing libraries (which includes refactoring) rather than add > new libraries with duplicate components. You did create the (stillborn) Sync though, which duplicates Thread. Why?

1 1

Re: [boost] Boost.Compat
by Andrey Semashev 30 Apr '23

30 Apr '23

On 4/30/23 02:18, Peter Dimov via Boost wrote: > Andrey Semashev wrote: >> And lastly. I realize that the proposed Boost.Compat is supposed to contain >> direct equivalents of the standard components. But what if we want to >> improve on that? Would this be not allowed simply because this would deviate >> from the standard? > > No, it wouldn't be allowed. Improving upon the standard makes it impossible > to later replace the compatibility header with a using declaration. We have > such a problem today with e.g. Boost.Ratio and Boost.Chrono, where because > of extensions we can't simply make them be <ratio> and <chrono>. > > It's fine to want to improve upon the standard, but Compat will not be the > place for that. That's what dedicated libraries are for. This would mean more code duplication, wouldn't it?

1 0

Re: [boost] Boost.Compat
by Vinnie Falco 30 Apr '23

30 Apr '23

On Sat, Apr 29, 2023 at 4:06 PM Andrey Semashev via Boost <boost(a)lists.boost.org> wrote: > If we don't want to use the libraries we write and accept during > the review then there must be something wrong with Boost. Nonsense. Large code bases need refactoring at regular intervals, this is no different. Or do you think that Boost libraries are so perfect upon acceptance that they can never be improved? My libraries are certainly not. Thanks

2 1

Re: [boost] Boost.Compat
by Andrzej Krzemienski 30 Apr '23

30 Apr '23

niedz., 30 kwi 2023 o 02:14 Vinnie Falco via Boost <boost(a)lists.boost.org> napisał(a): > On Sat, Apr 29, 2023 at 4:06 PM Andrey Semashev via Boost > <boost(a)lists.boost.org> wrote: > > If we don't want to use the libraries we write and accept during > > the review then there must be something wrong with Boost. > > Nonsense. Large code bases need refactoring at regular intervals, this > is no different. Or do you think that Boost libraries are so perfect > upon acceptance that they can never be improved? My libraries are > certainly not. > I think what Andrey was referring to is the situation where there exists one implementation, say in Boost.Core, and then a duplicate implementation in another Boost library for the purpose of reducing dependencies. Regards, &rzej; > > Thanks > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >

1 0

Re: [boost] Boost.Compat
by Glen Fernandes 29 Apr '23

29 Apr '23

On Sat, Apr 29, 2023 at 7:24 PM Peter Dimov wrote: > Andrey Semashev wrote: > > And lastly. I realize that the proposed Boost.Compat is supposed to > contain > > direct equivalents of the standard components. But what if we want to > > improve on that? Would this be not allowed simply because this would > deviate > > from the standard? > > No, it wouldn't be allowed. Improving upon the standard makes it impossible > to later replace the compatibility header with a using declaration. We have > such a problem today with e.g. Boost.Ratio and Boost.Chrono, where because > of extensions we can't simply make them be <ratio> and <chrono>. > > It's fine to want to improve upon the standard, but Compat will not be the > place for that. That's what dedicated libraries are for. > I agree. If Boost.Compat exists then its components should not deviate from their standard counterparts. It's not the place to innovate, only to provide an implementation (if possible) for a standard library facility.

1 0

Re: [boost] Boost.Compat
by Peter Dimov 29 Apr '23

29 Apr '23

Andrey Semashev wrote: > And lastly. I realize that the proposed Boost.Compat is supposed to contain > direct equivalents of the standard components. But what if we want to > improve on that? Would this be not allowed simply because this would deviate > from the standard? No, it wouldn't be allowed. Improving upon the standard makes it impossible to later replace the compatibility header with a using declaration. We have such a problem today with e.g. Boost.Ratio and Boost.Chrono, where because of extensions we can't simply make them be <ratio> and <chrono>. It's fine to want to improve upon the standard, but Compat will not be the place for that. That's what dedicated libraries are for.

1 0

Re: [boost] CI Test time
by Andrey Semashev 29 Apr '23

29 Apr '23

On 4/29/23 23:45, Robert Ramey via Boost wrote: > Looks like the CI for the serialization library takes about 200 minutes > to run (on a good day). When I run it on my local desktop for one > compiler/configuration it takes 1-2 minutes. It seems to me that the > way that CI works, it entails a huge waste resources and time. Has > anyone thought about this? If you know where most overhead is coming from, you can work towards reducing that overhead. For example, you can save time wasted on environment setup and git checkout if you run tests for different configurations in one CI job. If you want more specific comments then you probably have to provide more details on your problem.

1 0

Re: [boost] Boost.Compat
by Andrey Semashev 29 Apr '23

29 Apr '23

On 4/27/23 18:16, Peter Dimov via Boost wrote: > Newer C++ standards (20) have been adding useful things to the > standard library (<bit>, <latch>, etc) and most of us would like to > use them, both in Boost and outside of it, while still supporting > C++11, or 14, or 17. > > Many of these components are straightforward to implement > using the C++11 standard library, consist of not much than one > relatively small header, don't need many Boost dependencies > beyond the required ones (Assert, ThrowException, Config), and > since their interface is already fixed by the standard, don't need > a design review. > > It would be nice if we had a dedicated place in Boost where to > put these, to avoid the need for everyone reimplementing a > private copy. > > At the moment, some of these have gone into Core, for lack of > anywhere else, and we now have a <latch> contribution (which I > encouraged): > > https://github.com/boostorg/core/pull/144 > > However, Core is not quite the right place for these components. > > 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.) My main concern in the aforementioned PR was increased code duplication, and it isn't fixed by having Boost.Compat. 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). If we don't want to use the libraries we write and accept during the review then there must be something wrong with Boost. This isn't good for Boost (more maintenance required, less overall quality because some parts are left unmaintained) and this isn't good for users (more confusion, more compatibility issues). Secondly, I'm not sure I like the idea of another kitchen sink kind of library a-la Boost.Core and Boost.Utility, as such libraries tend to become bloated over time. Such libraries are also inconvenient for users' consumption, as it is more difficult to find a component in one of such libraries compared to in one of the specialized ones. I would prefer us to keep evolving our existing libraries, where appropriate, and accept new ones, where their functionality is not covered by the existing ones. And lastly. I realize that the proposed Boost.Compat is supposed to contain direct equivalents of the standard components. But what if we want to improve on that? Would this be not allowed simply because this would deviate from the standard? If allowed, would this still not require a review? I think, the "no review required" policy might be a bit too permissive.

1 0

Re: [boost] library usage statistics
by René Ferdinand Rivera Morell 29 Apr '23

29 Apr '23

On Sat, Apr 29, 2023 at 3:42 PM Robert Ramey via Boost <boost(a)lists.boost.org> wrote: > > Looking at the discussion regarding multi-array, I'm thinking I'd like > to know how many people/projects are using the current version. Define "using", as precisely as you can. Then, maybe, we can figure out how to measure. -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supone Nada -- Robot Dreams - http://robot-dreams.net

1 0

Re: [boost] CI Test time
by Vinnie Falco 29 Apr '23

29 Apr '23

On Sat, Apr 29, 2023 at 1:54 PM Robert Ramey via Boost <boost(a)lists.boost.org> wrote: > Has anyone thought about this? Yes.

1 0

CI Test time
by Robert Ramey 29 Apr '23

29 Apr '23

Looks like the CI for the serialization library takes about 200 minutes to run (on a good day). When I run it on my local desktop for one compiler/configuration it takes 1-2 minutes. It seems to me that the way that CI works, it entails a huge waste resources and time. Has anyone thought about this? Robert Ramey

1 0

library usage statistics
by Robert Ramey 29 Apr '23

29 Apr '23

Looking at the discussion regarding multi-array, I'm thinking I'd like to know how many people/projects are using the current version. It's been there for ever and hardly ever gets an update. This indicates to me that the current usage is very small - or that the library is currently close to perfect! I don't have a specific need for this, but I find myself wanting this information all the time and I don't see a way to get it. If anyone has any ideas about how to do this, I'd be curious to hear them. Robert Ramey

1 0

Re: [boost] proposal Multi multidimensional array library
by Vinnie Falco 29 Apr '23

29 Apr '23

On Sat, Apr 29, 2023 at 9:58 AM John Maddock via Boost <boost(a)lists.boost.org> wrote: > That seems to me like the sort of thing that could/should be thrashed > out at review time, and either back-ported to C++14 or not. I'd like people to know where I stand, so I will say that if I thought the library review verdict should be ACCEPTED I would leave it up to the author to decide if and when they want to refactor it to support earlier C++ versions. And if they decide never to support earlier C++ versions that would be perfectly OK with me. I don't have any hard data but I have a hunch that the audience for this library is much more likely to adopt or have already adopted C++17 or later. So there might not be much to gain from supporting earlier versions. Compare and contrast this with a staple such as, Boost.JSON - I think you lose a LOT of users if you require C++17 on that. Thanks

1 0

Re: [boost] proposal Multi multidimensional array library
by John Maddock 29 Apr '23

29 Apr '23

On 29/04/2023 17:51, Vinnie Falco via Boost wrote: > On Wed, Apr 26, 2023 at 2:30 PM Alfredo Correa via Boost > <boost(a)lists.boost.org> wrote: >> https://gitlab.com/correaa/boost-multi. > I've had a look at this repository, and these are my thoughts. It > looks like the author has invested considerable effort to polish > everything about the library up to be Boost quality. The README.md is > comprehensive, well written, and sounds like the kind of things we > care about. I don't know a whole lot about the particular needs of > robust multi-dimensional array users but this has got to be worth > reviewing. > > It seems the library requires C++17 or greater, which is unfortunate. > But especially unfortunate considering that there are no features > which actually require it other than using std::pmr::memory_resource. > But this could have been conditionally enabled on the C++ version. That seems to me like the sort of thing that could/should be thrashed out at review time, and either back-ported to C++14 or not. John.

1 0

Re: [boost] proposal Multi multidimensional array library
by Vinnie Falco 29 Apr '23

29 Apr '23

On Wed, Apr 26, 2023 at 2:30 PM Alfredo Correa via Boost <boost(a)lists.boost.org> wrote: > https://gitlab.com/correaa/boost-multi. I've had a look at this repository, and these are my thoughts. It looks like the author has invested considerable effort to polish everything about the library up to be Boost quality. The README.md is comprehensive, well written, and sounds like the kind of things we care about. I don't know a whole lot about the particular needs of robust multi-dimensional array users but this has got to be worth reviewing. It seems the library requires C++17 or greater, which is unfortunate. But especially unfortunate considering that there are no features which actually require it other than using std::pmr::memory_resource. But this could have been conditionally enabled on the C++ version. That said, there's no rule which says you have to support old versions of C++, and the contents of the repository demonstrate that Alfredo's is likely to be an engineer who reflects the qualities of a good Boost library author. Therefore I endorse this library for review. Thanks

1 0

Re: [boost] BOOST_NO_STD_LOCALE & BOOST_NO_STD_WSTREAMBUF
by Robert Ramey 28 Apr '23

28 Apr '23

On 4/28/23 4:34 AM, John Maddock via Boost wrote: > On 27/04/2023 23:19, Robert Ramey via Boost wrote: >> in boost/config/detail/suffix.hpp What's the specific issue this is causing? Mostly I think it's just confusing me and perhaps someone else fixing a bug. Here is the PR with the chain of discussion. https://github.com/boostorg/serialization/pull/224 Happy to hear anything you have to say. Robert Ramey > > John. > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Re: [boost] Replacing the ML with a forum
by Kenneth Porter 28 Apr '23

28 Apr '23

I use two threaded mailers: Thunderbird and Mulberry. But the main value of threading here is being able to skip to the end of a subthread to see the latest answer. I can do that quickly in a forum without threading. But I do like the threading of Reddit and Slashdot, so a forum that supports that would be nice. My biggest gripe with the mailing list is really with my ISP's mailing system (Xfinity), which doesn't retry a submission to the listserv when the listserv's greylisting bounces the initial submission with a temporary failure. I have to wait a couple minutes for the bounce email and then re-send from my Sent folder. As I'll certainly have to do with this message. So I don't participate as much on this list as I do on others without the greylisting. A forum wouldn't be subject to this problem. It does seem that forums get better search engine spidering than mailing list archives do. So it would be easier to search for answers using a forum. I'd hope to see a forum with a monthly or weekly mailing of a summary of active threads. I get that with a few forums, notably Rocky Linux and Visual Tool Kit. That's a feature of mailing lists: I don't forget to look to see new messages. But I do filter mailing list messages to separate folders (using the List-ID header) so they don't clutter my Inbox. I just glance at the Boost folder to see what new activity is available as part of my regular email regimen.

1 0

Re: [boost] Replacing the ML with a forum
by Robert Ramey 28 Apr '23

28 Apr '23

On 4/27/23 8:11 AM, Vinnie Falco via Boost wrote: > On Thu, Apr 27, 2023 at 7:56 AM Robert Ramey via Boost > <boost(a)lists.boost.org> wrote: >> I fail to see what is to be gained by replacing the current system. > > The current system is not being "replaced" it is being enhanced, with > the OPTION (but not the requirement) to interact with the mailing > lists using a modern, forum-based interface. Just as there are folks > who have expressed that they would not participate in Boost > discussions outside of the mailing list interface, there are as many > (or more) people who have expressed that they will not interact with > Boost through the mailing list at all. You don't hear from them > because well, they don't post to the list (the dog that didn't bark). > > You ask, what is to be gained? > Well, the largest existential threat to > Boost is that we do not refresh the foundations of our social > technology and our membership. I don't believe this. > Library membership in Boost no longer > carries the cachet that it used to. Perhaps - > Authors of new libraries > increasingly prefer to go directly to the C++ standard instead of > being thoroughly vetted in a Boost review. True - Because its much easier to get something into the standard than it is to get it into boost. For one thing Boost requires a working implementation, test suite, and user level documentation. For the standard, all one needs is to convince a small group of one's buddies that the world needs the authors proposal. This is especially effective when the proposal is too opaque for any normal person to understand - thus guarenteeing that there were be no real objections. That is until its features get added into the standard and real people have difficulties implementing and/or using them. If we want to continue to > maintain Boost's extraordinary relevance, we must do the following: > 1. Make the mailing list more appealing to younger generations > (millenials and the TikTok youths) I don't think this is a real problem. I'm trying not to sound like a curmudgeonly old person, but really - are millenias and TikTok youths our target audience? > 2. Increase participation in the Boost Formal Review process To do this we need to attract better libraries and work harder to promote the review. Also the 1-2 week window for reviews is a big problem. I might want to do a review but I can't right now. One of the features of my "Blincubator" project was to permit one to post reviews long in advance of the official review period. In fact. We might delay the formal review period until there are some magic number of reviews already in the queue. > 3. Spark the imagination of the new generations of library authors > - to write new libraries > - to submit their libraries to Boost for review > - to become active maintainers upon acceptanc > > 4. Inspire people to contribute to Boost > - by using the libraries, and providing feedback > - by contributing to individual projects > - by helping with documentation > - by helping other users with questions or problems I think the best way to do this is for boost to create better software. This would mean less bugs/design flaws, better documentation, less quirky tools. Why can't we apply the standards we use for user libraries to boost infrastructure? This would mean: boost tools like the following: a) documentation chain b) build system - Bjam c) build system - CMake integration c) CI d) GitHub integration e) website development and testing f) probably some others I forgot would be subject to similar requirements as boost user libraries. That is, Test suite, documentation, Formal review. None of the boost tools have been subjected to these requirements - and anyone who tries to use them notices. This is probably the single greatest obstacle to continued progress of boost. > The mailing lists must never go away, for as long as there are even a > few people who prefer them. But this cannot be the sole method to > participate in the Boost social space. To stay current we must provide > additional choices. The need for a forum interface is obvious. Don't the #boost and #boost-user forums on Slack currently fulfill this requirement? Robert Ramey

1 0

Re: [boost] Boost.Compat
by Peter Dimov 28 Apr '23

28 Apr '23

Glen Fernandes wrote: > On Friday, April 28, 2023, Dominique Devienne wrote: > > > Of course, Boost.Compat (or Boost.Polyfill) would need to turn on/off > > its std:: alternatives depending on the standard level in use. > > > > > If everyone agrees, this can be one of the tenets of Boost.Compat from the > very beginning. > > The "depending on the standard level in use" might be further clarified to > mean "provides a fully functional std:: version". An implementation in terms of `using std::something` will be allowed, but not required.

1 0

Re: [boost] Boost.Compat
by Glen Fernandes 28 Apr '23

28 Apr '23

On Friday, April 28, 2023, Dominique Devienne wrote: > Of course, Boost.Compat (or Boost.Polyfill) would need to turn > on/off > its std:: alternatives depending on the standard level in use. > > If everyone agrees, this can be one of the tenets of Boost.Compat from the very beginning. The "depending on the standard level in use" might be further clarified to mean "provides a fully functional std:: version". Glen

1 0

Re: [boost] Boost.Compat
by Dominique Devienne 28 Apr '23

28 Apr '23

On Thu, Apr 27, 2023 at 5:16 PM Peter Dimov via Boost <boost(a)lists.boost.org> wrote: > Newer C++ standards (20) have been adding useful things to the > standard library (<bit>, <latch>, etc) and most of us would like to > use them, both in Boost and outside of it, while still supporting > C++11, or 14, or 17. > > Many of these components are straightforward to implement > using the C++11 standard library, consist of not much than one > relatively small header, don't need many Boost dependencies > beyond the required ones (Assert, ThrowException, Config), and > since their interface is already fixed by the standard, don't need > a design review. > > It would be nice if we had a dedicated place in Boost where to > put these, to avoid the need for everyone reimplementing a > private copy. > > At the moment, some of these have gone into Core, for lack of > anywhere else, and we now have a <latch> contribution (which I > encouraged): > > https://github.com/boostorg/core/pull/144 > > However, Core is not quite the right place for these components. > > 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.) > +1. I'm on C++17, and have adopted std::span and others from C++20/23, from various places on GitHub. I'd welcome Boost-provided "polyfills" [1] instead. Of course, Boost.Compat (or Boost.Polyfill) would need to turn on/off its std:: alternatives depending on the standard level in use. --DD PS: Since we update our Boost dependency rarely, I sometimes drop newer Boost libs (e.g. Boost.Describe) in our code-base, and hope for backward-compatibility with our old Boost install. So if Boost.Compat could be similarly backward-compatible, that would increase the likelyhood we could use it sooner rather than later. [1] https://en.wikipedia.org/wiki/Polyfill_(programming)

1 0

Re: [boost] BOOST_NO_STD_LOCALE & BOOST_NO_STD_WSTREAMBUF
by John Maddock 28 Apr '23

28 Apr '23

On 27/04/2023 23:19, Robert Ramey via Boost wrote: > in boost/config/detail/suffix.hpp > > I find this bit of code: > > // > // We can't have a working std::wstreambuf if there is no std::locale: > // > # if defined(BOOST_NO_STD_LOCALE) && !defined(BOOST_NO_STD_WSTREAMBUF) > # define BOOST_NO_STD_WSTREAMBUF > # endif > > and believe it or not. this is now causing me some issues. Is the > statement above true? Do we know that wide char streams cannot exist > without std::locale being present? Can anyone shed light on this? As already mentioned, the original logic (and this dates back to C++98 or maybe even earlier!) was that there was a direct dependency between the "new" iostream operators and std::locale. I'm sure that for 99% of platforms this is redundant now anyway given that everyone supports wchar_t. What's the specific issue this is causing? John.

1 0

Re: [boost] BOOST_NO_STD_LOCALE & BOOST_NO_STD_WSTREAMBUF
by Gavin Lambert 28 Apr '23

28 Apr '23

On 28/04/2023 13:07, Glen Fernandes wrote: >> in boost/config/detail/suffix.hpp >> I find this bit of code: >> // >> // We can't have a working std::wstreambuf if there is no std::locale: >> // >> # if defined(BOOST_NO_STD_LOCALE) && !defined(BOOST_NO_STD_WSTREAMBUF) >> # define BOOST_NO_STD_WSTREAMBUF >> # endif >> >> and believe it or not. this is now causing me some issues. Is the >> statement above true? Do we know that wide char streams cannot exist >> without std::locale being present? Can anyone shed light on this? > > Not just std::wstreambuf but also std::streambuf. ie. std::basic_streambuf > depends on std::locale. But does it really? I could imagine that in some embedded platform std::locale could be omitted (since it's huge, rarely used, insufficient for purpose, and everyone hates it anyway), and in that implementation it could be presumed that no such dependency exists either, so long as you don't try to actually call the omitted methods.

1 0

Re: [boost] BOOST_NO_STD_LOCALE & BOOST_NO_STD_WSTREAMBUF
by Glen Fernandes 28 Apr '23

28 Apr '23

On Thu, Apr 27, 2023 at 6:13 PM Robert Ramey via Boost < boost(a)lists.boost.org> wrote: > in boost/config/detail/suffix.hpp > I find this bit of code: > // > // We can't have a working std::wstreambuf if there is no std::locale: > // > # if defined(BOOST_NO_STD_LOCALE) && !defined(BOOST_NO_STD_WSTREAMBUF) > # define BOOST_NO_STD_WSTREAMBUF > # endif > > and believe it or not. this is now causing me some issues. Is the > statement above true? Do we know that wide char streams cannot exist > without std::locale being present? Can anyone shed light on this? > Not just std::wstreambuf but also std::streambuf. ie. std::basic_streambuf depends on std::locale. Glen

1 0

BOOST_NO_STD_LOCALE & BOOST_NO_STD_WSTREAMBUF
by Robert Ramey 27 Apr '23

27 Apr '23

in boost/config/detail/suffix.hpp I find this bit of code: // // We can't have a working std::wstreambuf if there is no std::locale: // # if defined(BOOST_NO_STD_LOCALE) && !defined(BOOST_NO_STD_WSTREAMBUF) # define BOOST_NO_STD_WSTREAMBUF # endif and believe it or not. this is now causing me some issues. Is the statement above true? Do we know that wide char streams cannot exist without std::locale being present? Can anyone shed light on this? Robert Ramey

1 0

Re: [boost] Boost.Compat
by Christian Mazakas 27 Apr '23

27 Apr '23

I'm the author of the <latch> PR for Core so I'm also naturally in favor of this addition. What's the protocol for accepting such a library into Boost? Does it still go through formal review? Most of what would go in there exists in already-accepted Boost libraries. For example, the aforementioned Boost.Algorithm and Boost.Core contains several such things as <span>, <bit> and in its detail folder, <string_view>. The good news though is that because we're simply polyfilling standardized practice, there's no need to bikeshed interfaces. Oh, I almost forgot about Boost.Optional. How do we reify all of these existing classes and functions? - Christian

1 0

Re: [boost] Boost.Compat
by Zach Laine 27 Apr '23

27 Apr '23

On Thu, Apr 27, 2023 at 11:21 AM Marshall Clow via Boost <boost(a)lists.boost.org> wrote: > > On Apr 27, 2023, at 8:31 AM, Glen Fernandes via Boost <boost(a)lists.boost.org> wrote: > > > > On Thu, Apr 27, 2023 at 11:24 AM Peter Dimov via Boost < > > boost(a)lists.boost.org> wrote: > > > >> It would be nice if we had a dedicated place in Boost where to > >> put these, to avoid the need for everyone reimplementing a > >> private copy. > >> > >> At the moment, some of these have gone into Core, for lack of > >> anywhere else, and we now have a <latch> contribution (which I > >> encouraged): > >> > >> https://github.com/boostorg/core/pull/144 > >> > >> However, Core is not quite the right place for these components. > >> > >> 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.) > >> > > > > > > For the rest of the list: I'm in favor of this (as my response in the > > Core thread indicates). > > There’s a lot of this kind of stuff in Boost.Algorithm > > Boost/algorithm/cxx11, for example. Ha. Read first, then post, Zach. Zach

1 0

Re: [boost] Boost.Compat
by Zach Laine 27 Apr '23

27 Apr '23

On Thu, Apr 27, 2023 at 10:16 AM Peter Dimov via Boost <boost(a)lists.boost.org> wrote: > > Newer C++ standards (20) have been adding useful things to the > standard library (<bit>, <latch>, etc) and most of us would like to > use them, both in Boost and outside of it, while still supporting > C++11, or 14, or 17. > > Many of these components are straightforward to implement > using the C++11 standard library, consist of not much than one > relatively small header, don't need many Boost dependencies > beyond the required ones (Assert, ThrowException, Config), and > since their interface is already fixed by the standard, don't need > a design review. > > It would be nice if we had a dedicated place in Boost where to > put these, to avoid the need for everyone reimplementing a > private copy. > > At the moment, some of these have gone into Core, for lack of > anywhere else, and we now have a <latch> contribution (which I > encouraged): > > https://github.com/boostorg/core/pull/144 > > However, Core is not quite the right place for these components. > > 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 like this idea a lot. I want to mention that there are lots of places currently that do a partial job of this. One conspicuous one is Algorithm. There are probably lots of others. Having one place to get all the compatibility bits would be very welcome. Zach

1 0

Re: [boost] Boost.Compat
by Marshall Clow 27 Apr '23

27 Apr '23

On Apr 27, 2023, at 8:31 AM, Glen Fernandes via Boost <boost(a)lists.boost.org> wrote: > > On Thu, Apr 27, 2023 at 11:24 AM Peter Dimov via Boost < > boost(a)lists.boost.org> wrote: > >> It would be nice if we had a dedicated place in Boost where to >> put these, to avoid the need for everyone reimplementing a >> private copy. >> >> At the moment, some of these have gone into Core, for lack of >> anywhere else, and we now have a <latch> contribution (which I >> encouraged): >> >> https://github.com/boostorg/core/pull/144 >> >> However, Core is not quite the right place for these components. >> >> 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.) >> > > > For the rest of the list: I'm in favor of this (as my response in the > Core thread indicates). There’s a lot of this kind of stuff in Boost.Algorithm Boost/algorithm/cxx11, for example. — Marshall

1 0

Re: [boost] Boost.Compat
by Glen Fernandes 27 Apr '23

27 Apr '23

On Thu, Apr 27, 2023 at 11:24 AM Peter Dimov via Boost < boost(a)lists.boost.org> wrote: > It would be nice if we had a dedicated place in Boost where to > put these, to avoid the need for everyone reimplementing a > private copy. > > At the moment, some of these have gone into Core, for lack of > anywhere else, and we now have a <latch> contribution (which I > encouraged): > > https://github.com/boostorg/core/pull/144 > > However, Core is not quite the right place for these components. > > 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.) > For the rest of the list: I'm in favor of this (as my response in the Core thread indicates). Glen

1 0

Re: [boost] Boost.Compat
by Niall Douglas 27 Apr '23

27 Apr '23

On 27/04/2023 16:16, Peter Dimov via Boost wrote: > However, Core is not quite the right place for these components. > > So my suggestion is to create a separate library/repo, Boost.Compat > (boostorg/compat, namespace boost::compat) for them. I'd prefer if those polyfills were categorised according to C++ standard, so: Boost.CXX11 Boost.CXX14 Boost.CXX17 Boost.CXX20 Boost.CXX23 ... Then when a person upgrades the minimum C++ standard for a codebase, what needs to be switched to std:: is very easy to identify. Niall

1 0

Boost.Compat
by Peter Dimov 27 Apr '23

27 Apr '23

Newer C++ standards (20) have been adding useful things to the standard library (<bit>, <latch>, etc) and most of us would like to use them, both in Boost and outside of it, while still supporting C++11, or 14, or 17. Many of these components are straightforward to implement using the C++11 standard library, consist of not much than one relatively small header, don't need many Boost dependencies beyond the required ones (Assert, ThrowException, Config), and since their interface is already fixed by the standard, don't need a design review. It would be nice if we had a dedicated place in Boost where to put these, to avoid the need for everyone reimplementing a private copy. At the moment, some of these have gone into Core, for lack of anywhere else, and we now have a <latch> contribution (which I encouraged): https://github.com/boostorg/core/pull/144 However, Core is not quite the right place for these components. 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.)

1 0

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

27 Apr '23

On Thu, Apr 27, 2023 at 7:56 AM Robert Ramey via Boost <boost(a)lists.boost.org> wrote: > Boost has a history making it's own tools: > ... > It's not a great history. In fact, I spend more time getting boost > tools to work than I do working on boost software. The difference here is that our efforts are powered by staff engineers who draw a salary and external corporations who have, as a condition of payment, the accomplishment of our goals. Thanks

1 0

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

27 Apr '23

On Thu, Apr 27, 2023 at 7:56 AM Robert Ramey via Boost <boost(a)lists.boost.org> wrote: > I fail to see what is to be gained by replacing the current system. The current system is not being "replaced" it is being enhanced, with the OPTION (but not the requirement) to interact with the mailing lists using a modern, forum-based interface. Just as there are folks who have expressed that they would not participate in Boost discussions outside of the mailing list interface, there are as many (or more) people who have expressed that they will not interact with Boost through the mailing list at all. You don't hear from them because well, they don't post to the list (the dog that didn't bark). You ask, what is to be gained? Well, the largest existential threat to Boost is that we do not refresh the foundations of our social technology and our membership. Library membership in Boost no longer carries the cachet that it used to. Authors of new libraries increasingly prefer to go directly to the C++ standard instead of being thoroughly vetted in a Boost review. If we want to continue to maintain Boost's extraordinary relevance, we must do the following: 1. Make the mailing list more appealing to younger generations (millenials and the TikTok youths) 2. Increase participation in the Boost Formal Review process 3. Spark the imagination of the new generations of library authors - to write new libraries - to submit their libraries to Boost for review - to become active maintainers upon acceptance 4. Inspire people to contribute to Boost - by using the libraries, and providing feedback - by contributing to individual projects - by helping with documentation - by helping other users with questions or problems The mailing lists must never go away, for as long as there are even a few people who prefer them. But this cannot be the sole method to participate in the Boost social space. To stay current we must provide additional choices. The need for a forum interface is obvious. Thanks

1 0

Re: [boost] Replacing the ML with a forum
by Robert Ramey 27 Apr '23

27 Apr '23

On 4/26/23 8:02 AM, Vinnie Falco via Boost wrote: > - No existing solution meets our needs, so we have to write it ourselves The above sentence is a huge red flag. Boost has a history making it's own tools: a) documentation chain b) build system - Bjam c) build system - CMake integration c) CI d) GitHub integration d) probably some others I forgot It's not a great history. In fact, I spend more time getting boost tools to work than I do working on boost software. Like most computer projects, it turns out to be a lot of work which drags on forever and is constantly fiddled with to make work. When the work becomes tedious enthusiasm peters out and were stuck with something that "can be made to work". I fail to see what is to be gained by replacing the current system. Robert Ramey

1 0

Re: [boost] Replacing the ML with a forum
by Gavin Lambert 26 Apr '23

26 Apr '23

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. Thus far a newsreader has been the only successful way I can follow a community -- flat mailing lists are too disjointed and hard to follow context, and websites are "out of sight, out of mind"; I might keep up for a few weeks but inevitably forget for a while and then I'm 1k messages behind and I just ignore it forever.

1 0

proposal Multi multidimensional array library
by Alfredo Correa 26 Apr '23

26 Apr '23

Hi all, My name is Alfredo. I would like to propose this library called Multi for inclusion in Boost. Multi is a container and views library for (dynamic) multidimensional arrays. The library is available here, https://gitlab.com/correaa/boost-multi. The Boost prefix is purely aspirational at this point, of course. As I understand the process, the important step at this point is to find someone(s) to endorse the library and later a review manager. If you want to be an endorser, please let me know. If anyone has feedback or tips to prepare it for a review, please let me know as well. I will be at the Aspen CPPNOW conference if someone wants to discuss it in person. I am in the C++ Slack channel #boost for discussions as well. Here is a link to try it quickly online https://godbolt.org/z/KerbxW6WK. Thank you, Alfredo

1 0

Re: [boost] Replacing the ML with a forum
by Robert Ramey 26 Apr '23

26 Apr '23

On 4/26/23 7:08 AM, Vinnie Falco via Boost wrote: > Before we replace the mailing list with a forum (and implement a mail > gateway) can I get feedback on how you use the mailing list from your > email client? > > Are you using a threaded e-mail reader? If so, do you care if > discussions are changed to be flat (like Discourse)? What is important > to you (besides that you can continue to use your email client)? > 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. Robert Ramey

1 0

Re: [boost] Replacing the ML with a forum
by Mateusz Loskot 26 Apr '23

26 Apr '23

On Wed, 26 Apr 2023 at 19:26, Nikita Kniazev via Boost <boost(a)lists.boost.org> wrote: > > There is GitHub Discussion. What is wrong to enable Discussions on > https://github.com/boostorg/boost and use it? Indeed, why not try GitHub Discussions as a new space to evaluate interest in a Web-based forum. I'm happy with the current mailman, but if any migration is considered, then IMHO it should improve integration of comm, and not distribute it further. I'm not saying I'm a die-hard fan of GHD, but I am willing to trade some of my personal preferences for single place I go to. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0

Re: [boost] Replacing the ML with a forum
by Mateusz Loskot 26 Apr '23

26 Apr '23

On Wed, 26 Apr 2023 at 16:08, Vinnie Falco via Boost <boost(a)lists.boost.org> wrote: > > Are you using a threaded e-mail reader? Gmail, flat. I occasionally appreciate threaded view on lists.boost.org. > What is important to you (besides that you can continue to use your email client)? Usable search. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0

Re: [boost] Replacing the ML with a forum
by Nikita Kniazev 26 Apr '23

26 Apr '23

> Are you using a threaded e-mail reader? If so, do you care if discussions are changed to be flat (like Discourse)? I use Gmail which I think supports threads, but I subscribed to digests so no threads for me. > as no one in their twenties or earlier wants to use a mailing list I'm not from that demographic but I also don't want to use mailing lists. But I'm not a fan of 'forums' either. > What is important to you (besides that you can continue to use your email client)? 1. Main reason why I can't use the mail list: I don't want to subscribe to everything happening there. Probably there are email clients that make that easier, but that already excludes people who don't use such a client. 2. I subscribed to a digest and there is still no way to post to a thread without being subscribed to the mail list before it had been started. And even for one who had been subscribed it gives a wrong address to post to. 3. There is no way to link a post or thread. Inside the mail list itself or anywhere else. What are the options for a person who is not on the mail list? https://lists.boost.org? https://lists.boost.org is a user experience nightmare: 1. You can't post, only may create a new thread by mailing to the mail list. 2. You have to click on every message to read it. 3. In a threaded view you also can see only one message at a time, and it is easy to miss parts of the thread by clicking the wrong button. 4. Google and other search engines for some reason have indexing issues with it. Even if I know something was on the mail list or there is a comment in Boost's code with a link to a dead Gmane I had great luck finding absolutely nothing with multiple web search engines. 5. There is no code snippet syntax highlighting. 6. It doesn't interact with itself, or anything else either. > implement our own web-based forum I don't think it's a good idea. > The other alternative is to do a clean break and deploy something completely new, which would be Discourse. The downside of Discourse is that it does not support threaded discussions, and because of their philosophical objection to hierarchical conversations >From my experience with Discourse a post will contain a list of replies to it which you can jump back and forth. I don't see a great value in highly branched discussions, it is impossible to follow even on things like Hacker News or Reddit, just create a new thread. And... There is GitHub Discussion. What is wrong to enable Discussions on https://github.com/boostorg/boost and use it? AFAIK it supports posting from a mail client and subscribing to it to receive everything or just subscribed threads by emails? > * Written in Ruby, a dying language GitHub is written in Ruby :-)

1 0

Re: [boost] Replacing the ML with a forum
by Niall Douglas 26 Apr '23

26 Apr '23

On 26/04/2023 15:43, Vinnie Falco via Boost wrote: > On Wed, Apr 26, 2023 at 7:12 AM Marshall Clow via Boost > <boost(a)lists.boost.org> wrote: >>> Are you using a threaded e-mail reader? If so, do you care if >>> discussions are changed to be flat (like Discourse)? >> >> Yes, and Yes. > > The current situation is this. For various reasons, we have no forum > for the new website. And a new forum is crucial for attracting new > people, as no one in their twenties or earlier wants to use a mailing > list. Twenty somethings don't use discussion forums either. Too passe. Re: Implementation last time this was discussed here and options investigated we found that https://fossil-scm.org/forum/forum implemented a web discussion forum with mailing list interface. One could use either interface, they were equivalent, and the UI seemed to meet approval here. I remember there were also other web discussion forum implementations with mailing list interface, but Fossil was the least unacceptable of them according to here, back in the day. Now, as to whether it could be improved upon, surely yes. However ever since Google stopped indexing discussion forms, I don't think they're the draw of users that they were. Nowadays if you can't find it on TikTok, it doesn't really exist for the under thirties. Niall

1 0

Re: [boost] Replacing the ML with a forum
by Andrea Bocci 26 Apr '23

26 Apr '23

On Wed, 26 Apr 2023 at 16:09, Vinnie Falco via Boost <boost(a)lists.boost.org> wrote: > Before we replace the mailing list with a forum (and implement a mail > gateway) can I get feedback on how you use the mailing list from your > email client? > > Are you using a threaded e-mail reader? If so, do you care if > discussions are changed to be flat (like Discourse)? What is important > to you (besides that you can continue to use your email client)? > Very simply, if you replace the mailing list(s) with a forum (or fora), I will stop following any Boost discussion. Best of luck, .Andrea -- Dr. Andrea Bocci Applied Physicist, CMS Experiment <https://cms.cern/>EP-CMD, CERN <https://home.cern/>168990 (+41 75 411 8990) CERN 40/1-B01 <https://maps.cern.ch/mapsearch/mapsearch.htm?n=['40/1-B01']> E27810 Esplanade des particules, 1, CH-1211 Geneve 23, Switzerland <https://goo.gl/maps/AMjHdhXzYk2itSu7A>

2 2

Re: [boost] Replacing the ML with a forum
by Stefan Seefeld 26 Apr '23

26 Apr '23

On Wed, Apr 26, 2023 at 10:53 AM Vinnie Falco via Boost < boost(a)lists.boost.org> wrote: > > Pros of Writing It Ourselves > > * Uses Python, a popular language > * Preserved mailing list experience > * Threaded discussions > * Customized to suit our needs > > Cons of Writing it Ourselves > > * More expensive long-term > * Takes longer to reach feature parity > * We have to maintain it > > Note, the C++ Alliance is covering all of the expenses for development > so the expense issue is not of particular importance, our priority is > on getting things done perfectly for users even if it costs a bit > more. > Perhaps there is a middle-way: layering whatever customization you need on top of existing infrastructure (e.g. Mailman) ? This could even be submitted upstream, if there is enough common interest, so Boost wouldn't have to own and maintain it in the long term... ...ich hab' noch einen Koffer in Berlin...

2 3

Re: [boost] Replacing the ML with a forum
by Andrey Semashev 26 Apr '23

26 Apr '23

On April 26, 2023 5:08:49 PM Vinnie Falco via Boost <boost(a)lists.boost.org> wrote: > Before we replace the mailing list with a forum (and implement a mail > gateway) can I get feedback on how you use the mailing list from your > email client? > > Are you using a threaded e-mail reader? If so, do you care if > discussions are changed to be flat (like Discourse)? What is important > to you (besides that you can continue to use your email client)? Personally, I don't group posts by threads and read everything flat. But I recognize that others may have different preference, and one of the advantages of ML is that everyone can configure their mail client the way they want. I think this liberty should be preserved.

1 0

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

26 Apr '23

On Wed, Apr 26, 2023 at 7:12 AM Marshall Clow via Boost <boost(a)lists.boost.org> wrote: > > Are you using a threaded e-mail reader? If so, do you care if > > discussions are changed to be flat (like Discourse)? > > Yes, and Yes. The current situation is this. For various reasons, we have no forum for the new website. And a new forum is crucial for attracting new people, as no one in their twenties or earlier wants to use a mailing list. However, we also recognize the importance of preserving the mailing list interface and threaded discussion model. After spending months of doing tests and looking at existing solutions, we have reached the conclusion that the only way to bring maximal satisfaction to the community is for us to implement our own web-based forum which supports threaded discussion and also has a mailing list interface, such that the mailing list experience is unchanged for those who still want to use it (which seems to be quite a few people). The other alternative is to do a clean break and deploy something completely new, which would be Discourse. The downside of Discourse is that it does not support threaded discussions, and because of their philosophical objection to hierarchical conversations, it most certainly never will. Check this out: https://community.lsst.org/t/understanding-and-using-discourses-flat-thread… This rationale sounds very good on paper and it probably works for things such as support fourms. But it is poorly suited for the specific nature of the Boost mailing list where discussions can rage for months (I miss that). Enormous discussions were the bread and butter of the social experience and that needs to be revitalized. Anyway... Pros of Discourse: * Already written * Has an email interface * Can be restyled to match the site (mostly) * Probably cheaper long-term Cons of Discourse: * No threaded discussion * Written in Ruby, a dying language --- Pros of Writing It Ourselves * Uses Python, a popular language * Preserved mailing list experience * Threaded discussions * Customized to suit our needs Cons of Writing it Ourselves * More expensive long-term * Takes longer to reach feature parity * We have to maintain it Note, the C++ Alliance is covering all of the expenses for development so the expense issue is not of particular importance, our priority is on getting things done perfectly for users even if it costs a bit more.

1 0

Re: [boost] Replacing the ML with a forum
by René Ferdinand Rivera Morell 26 Apr '23

26 Apr '23

On Wed, Apr 26, 2023 at 9:08 AM Vinnie Falco via Boost <boost(a)lists.boost.org> wrote: > > Are you using a threaded e-mail reader? I use Gmail, so no? > What is important> to you (besides that you can continue to use your email client)? Good, email/forum specific search. -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supone Nada -- Robot Dreams - http://robot-dreams.net

1 0

Re: [boost] Replacing the ML with a forum
by Stefan Seefeld 26 Apr '23

26 Apr '23

On Wed, Apr 26, 2023 at 10:08 AM Vinnie Falco via Boost < boost(a)lists.boost.org> wrote: > Before we replace the mailing list with a forum (and implement a mail > gateway) can I get feedback on how you use the mailing list from your > email client? > > Are you using a threaded e-mail reader? If so, do you care if > discussions are changed to be flat (like Discourse)? What is important > to you (besides that you can continue to use your email client)? > yes !! Boost discussions sometimes go on for months, so having a structured view of the whole conversation is essential not to get lost. ...ich hab' noch einen Koffer in Berlin...

1 0

Re: [boost] Replacing the ML with a forum
by Marshall Clow 26 Apr '23

26 Apr '23

On Apr 26, 2023, at 7:08 AM, Vinnie Falco via Boost <boost(a)lists.boost.org> wrote: > > Before we replace the mailing list with a forum (and implement a mail > gateway) can I get feedback on how you use the mailing list from your > email client? > > Are you using a threaded e-mail reader? If so, do you care if > discussions are changed to be flat (like Discourse)? Yes, and Yes. — Marshall

1 0

Replacing the ML with a forum
by Vinnie Falco 26 Apr '23

26 Apr '23

Before we replace the mailing list with a forum (and implement a mail gateway) can I get feedback on how you use the mailing list from your email client? Are you using a threaded e-mail reader? If so, do you care if discussions are changed to be flat (like Discourse)? What is important to you (besides that you can continue to use your email client)? Thanks

1 0

Re: [boost] Help Boost, Please!
by David Sankel 25 Apr '23

25 Apr '23

On Mon, Apr 24, 2023 at 2:03 PM Louis Tatta via Boost <boost(a)lists.boost.org> wrote: > Issues can be opened against the documentation for anything at all by > pressing the “Report an Issue” button located at the top right of every > documentation page, or simply by visiting > https://github.com/cppalliance/site-docs/issues I added https://github.com/cppalliance/site-docs/issues/17 for *The 'Getting Started Doc' should use CMake as the primary way to build and use Boost.* I think one of the key areas to focus on is new user success. Whatever we can do to prevent folks from giving up when they attempt using Boost for the first time will have a substantial impact. -- David

1 0

Re: [boost] Help Boost, Please!
by Kostas Savvidis 24 Apr '23

24 Apr '23

> On Apr 24, 2023, at 21:03, Louis Tatta via Boost <boost(a)lists.boost.org> wrote: > > The more that people help out, the better the results will be. I just asked GPT-4 to do it! Of course, without too much context it produces nonsense, see below, but providing it with more detailed instructions and previously existing documentation on this and asking to change this and that can possibly do the job. Below the contributor guide I am posting an even more exotic "beginner's guide to asio". I suspect it might be complete nonsense too, but enjoy! Cheers, Kostas =============================================================================== Boost Library Contributor Guide Thank you for your interest in contributing to the Boost library collection. The following guide outlines the requirements and guidelines for submitting a library to Boost. Requirements To ensure a smooth submission process and avoid rejection, the library you submit must meet the following requirements: License requirements: The license must be simple to read and understand. The license must grant permission without fee to copy, use, and modify the software for any use (commercial and non-commercial). The license must require that the license appear on all copies of the software source code. The license must not require that the license appear with executables or other binary uses of the library. The license must not require that the source code be available for execution or other binary uses of the library. The license may restrict the use of the name and description of the library to the standard version found on the Boost website. Restricted licenses like the GPL and LGPL are not acceptable. Copyright ownership: The copyright ownership of the library must be clear. Include a copyright notice in all the important files you submit. Portability requirements: The library's interface must be portable and not restricted to a particular compiler or operating system. The library's implementation must, if possible, be portable and not restricted to a particular compiler or operating system. If a portable implementation is not possible, non-portable constructions are acceptable if reasonably easy to port to other environments. Implementations must be provided for at least two popular operating systems (such as UNIX and Windows). The library must run on at least two C++ compilers implementing the latest ISO C++ standard. Boost contributors often try to ensure their libraries work with popular compilers. Use the boost/config.hpp configuration header to work around compiler deficiencies. Organization requirements: The library must be generally useful. The library must adhere to the Boost standard library organization upon acceptance. The author must be willing to participate in discussions on the mailing list and refine the library accordingly. Guidelines To increase the chances of your library being accepted and to maintain consistency within the Boost library collection, follow these guidelines: Backwards compatibility: Provide a stable interface for your library, and avoid breaking changes unless absolutely necessary. If you must introduce breaking changes, provide a clear and easy migration path for users. Design and programming: Follow the C++ standard library conventions and idioms whenever possible. Avoid overly complex designs and keep the library simple and easy to use. Filenames: Use lowercase filenames, with words separated by underscores. Use the .hpp extension for header files, and the .cpp extension for implementation files. Naming consistency: Use consistent naming conventions for classes, functions, and other identifiers. Follow the Boost naming conventions as closely as possible. Documentation: Provide thorough and clear documentation for your library. Use Doxygen-style comments in your header files to document interfaces and functions. Provide examples and usage scenarios to demonstrate how to use your library. Rationale For a detailed explanation of the reasons behind these requirements and guidelines, refer to the Boost Library Requirements and Guidelines document. Acknowledgements We appreciate your contribution to the Boost library collection and thank you for following these requirements and guidelines. If you have any questions or concerns, please don't hesitate to ask for help on the Boost developers mailing list. ============================================================================================= could you write a new user guide for the boost.asio library? Sure, I can provide a beginner's guide to using the Boost.Asio library. Here it is: Boost.Asio is a library for network and low-level I/O programming in C++. It provides a set of abstractions for dealing with sockets, timers, and other I/O objects. Boost.Asio is designed to be portable across operating systems and platforms and is built on top of the Boost C++ libraries. To use Boost.Asio, you'll need to have the Boost libraries installed on your system. You can download the latest version of Boost from the Boost website, and follow the instructions for installation. Once you have Boost installed, you can include the Boost.Asio header file in your C++ code: cpp #include <boost/asio.hpp> This gives you access to the Boost.Asio library. Here's a basic example that demonstrates how to use Boost.Asio to create a TCP server that listens for incoming connections and sends a simple message to the client: cpp #include <iostream> #include <boost/asio.hpp> using boost::asio::ip::tcp; int main() { boost::asio::io_context io_context; tcp::acceptor acceptor(io_context, tcp::endpoint(tcp::v4(), 8888)); while (true) { tcp::socket socket(io_context); acceptor.accept(socket); std::string message = "Hello, World!"; boost::system::error_code error; boost::asio::write(socket, boost::asio::buffer(message), error); } return 0; } In this example, we create an io_context object, which is the central object that drives the Boost.Asio library. We then create a tcp::acceptor object, which listens for incoming TCP connections on port 8888. Inside the while loop, we accept incoming connections using the acceptor.accept() method, which blocks until a new connection is established. We then create a new tcp::socket object to handle the communication with the client. Finally, we send a simple message to the client using the boost::asio::write() method, which writes the message to the socket. This is just a basic example, but Boost.Asio provides a wide range of abstractions for handling network and low-level I/O programming in C++. You can find more information in the Boost.Asio documentation. Here are a few tips for using Boost.Asio: Use asynchronous I/O operations whenever possible. This can help you avoid blocking and maximize the throughput of your application. Use the io_context object to manage the lifecycle of your I/O objects, such as sockets and timers. Use the deadline_timer object to schedule timeouts for I/O operations. Use the streambuf object to handle variable-length data, such as incoming messages over a socket. Be aware of thread safety issues when using Boost.Asio in a multi-threaded environment. The library provides a number of synchronization primitives, such as mutexes and condition variables, to help you manage concurrency. With a little practice, you should be able to use Boost.Asio to build complex network and low-level I/O applications in C++. Good luck! > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Re: [boost] Help Boost, Please!
by Vinnie Falco 24 Apr '23

24 Apr '23

On Mon, Apr 24, 2023 at 11:03 AM Louis Tatta via Boost <boost(a)lists.boost.org> wrote: > Issues can be opened against the documentation for anything at all by > pressing the “Report an Issue” button located at the top right of every > documentation page, or simply by visiting > https://github.com/cppalliance/site-docs/issues In case this wasn't clear - if YOU (the person reading this) want to have ANYTHING changed or added in the site documentation, all you need to do is open an issue and it will be triaged and attended to: https://github.com/cppalliance/site-docs/issues Thanks

1 0

Re: [boost] Help Boost, Please!
by Ruben Perez 24 Apr '23

24 Apr '23

> Peter Turcan is a new face at The C++ Alliance but a veteran at Technical > Writing. He needs your help to make these pages shine. Specifically, we > need volunteers for the following: > > Check the documentation for accuracy > Make suggestions for improvements or changes > Contribute directly to the documentation (pull requests VERY welcomed) > Review pull requests that are awaiting merge > Report problems with links or styling > I'm happy to help. Ruben.

1 0

Help Boost, Please!
by Louis Tatta 24 Apr '23

24 Apr '23

To improve Boost we are writing new documentation for the website, divided into four documentation projects: User’s Guide https://docs.cppalliance.org/doc/user-guide/ Contributor’s Guide https://docs.cppalliance.org/doc/contributor-guide/ Formal Review Manual: https://docs.cppalliance.org/doc/formal-reviews/ Release Process Book https://docs.cppalliance.org/doc/release-process/ (“develop” branch versions of these docs can be viewed at the corresponding https://stage.docs.cppaliance.org URL). The source code repository for the documentation is located here and will be moved to the Boost organization after final approval: https://github.com/cppalliance/site-docs Peter Turcan is a new face at The C++ Alliance but a veteran at Technical Writing. He needs your help to make these pages shine. Specifically, we need volunteers for the following: Check the documentation for accuracy Make suggestions for improvements or changes Contribute directly to the documentation (pull requests VERY welcomed) Review pull requests that are awaiting merge Report problems with links or styling Issues can be opened against the documentation for anything at all by pressing the “Report an Issue” button located at the top right of every documentation page, or simply by visiting https://github.com/cppalliance/site-docs/issues The more that people help out, the better the results will be. Note that the current stylesheets for these documentation pages are using the “Antora default UI” but before this goes on to https://www.boost.org it will be restyled to match the look and feel of the site. If you wish to help out please respond to this message on-list so that others know you are pitching it, that we might get a snowball effect. Best Regards, Louis Tatta The C++ Alliance

1 0

Re: [boost] multiprecision issues
by John Maddock 23 Apr '23

23 Apr '23

On 22/04/2023 22:48, Gero Peterhoff via Boost wrote: > Hi John, > i stumbled over some more issues https://godbolt.org/z/x5srG9eof : > - the unary operator- does not work with > boost::multiprecision::cpp_bin_float_N on nan > - operator<<(boost::multiprecision::float128) does not support > std::showpos with std::hexfloat > - operator<<(boost::multiprecision::cpp_bin_float_N) does not support > std::hexfloat and in the case of nan does not support std::showpos > > I also miss C++17 from_chars/to_chars. > I realize that this is extremely tedious work, but multiprecision > should be as compatible to the standard as possible. > If you want, I'll be happy to look for various issues and report them > to you, but you'll have to fix them yourself. Can you please report these as separate issues on github (https://github.com/boostorg/multiprecision/issues) so we have something to track? Thanks! John.

1 0

multiprecision issues
by Gero Peterhoff 22 Apr '23

22 Apr '23

Hi John, i stumbled over some more issues https://godbolt.org/z/x5srG9eof : - the unary operator- does not work with boost::multiprecision::cpp_bin_float_N on nan - operator<<(boost::multiprecision::float128) does not support std::showpos with std::hexfloat - operator<<(boost::multiprecision::cpp_bin_float_N) does not support std::hexfloat and in the case of nan does not support std::showpos I also miss C++17 from_chars/to_chars. I realize that this is extremely tedious work, but multiprecision should be as compatible to the standard as possible. If you want, I'll be happy to look for various issues and report them to you, but you'll have to fix them yourself. cu Gero

1 0

Re: [boost] ccmath::copysign/signbit
by Matt Borland 22 Apr '23

22 Apr '23

Gero, > 1) copysign uses abs, which is wrong. copysign/signbit may *only* change/check the sign (https://en.cppreference.com/w/cpp/numeric/math/copysign https://en.cppreference.com/w/cpp/numeric/math/signbit) I think you are conflating signbit and copysign here. Copysign is to return the magnitude of the first argument (which by definition is the absolute value) with the sign of the second argument. We use signbit in the implementation of this because copysign can be used to manipulate the signs of NaNs. > 2) In signbit.hpp you implement struct IEEEfN2bits. But these are incomplete: > - long double can be 16/12/10 bytes depending on platform/compiler option. You do not take this into account. > - Correct types are already available in boost/math/cstdfloat/cstdfloat_types.hpp. You will find implementations of IEEEl2bits here https://github.com/boostorg/math/blob/develop/include/boost/math/ccmath/sig…. They account for 64, 80, and 128 bit long doubles based on LDBL_MANT_DIG and LDBL_MAX_EXP. If for instance you use compiler flags on GCC to alter the size of a long double those macros are changed accordingly. > PS > gcc13 is about to be released (https://gcc.gnu.org) so it is high time to support std::floatN_t as well. Yes, the release of GCC 13 is scheduled for next week. Once it’s available for download I will open issues/PRs to fix any breakages that come from the new types. In the interim I believe, but cannot confirm that if you use a policy that disables promotion you should be fine. Matt

2 1

Re: [boost] ccmath implementations
by John Maddock 21 Apr '23

21 Apr '23

On 21/04/2023 15:05, Gero Peterhoff via Boost wrote: > Hi Matt, > the ccmath functions must/could only work with std types. Is this > assumption correct? > The constexpr code path is almost certainly for std types only. However, they can be used in generic functions declared constexpr, which are not necessarily used in a constexpr context: in that case the argument could be any suitable type. John.

1 0

ccmath::copysign/signbit
by Gero Peterhoff 20 Apr '23

20 Apr '23

Hi Matt, I see the following problems in your implementations for ccmath::copysign/signbit: 1) copysign uses abs, which is wrong. copysign/signbit may *only* change/check the sign (https://en.cppreference.com/w/cpp/numeric/math/copysign https://en.cppreference.com/w/cpp/numeric/math/signbit) 2) In signbit.hpp you implement struct IEEEfN2bits. But these are incomplete: - long double can be 16/12/10 bytes depending on platform/compiler option. You do not take this into account. - Correct types are already available in boost/math/cstdfloat/cstdfloat_types.hpp. Therefore, I provide the complete structures in ccmath/bits.hpp. This also contains structures for std::(b)float16_t and can be extended if needed. Extended type-traits for floats To minimize completely sprawling manual checks (#if + std::is_same) I provide more advanced TTs in type_traits/is_floating_point_more.hpp. This way ccmath::copysign/signbit can be implemented correctly. Possibly other functions are affected. thx Gero PS gcc13 is about to be released (https://gcc.gnu.org) so it is high time to support std::floatN_t as well.

1 0

ccmath implementations
by Gero Peterhoff 20 Apr '23

20 Apr '23

Hi Matt, the ccmath functions must/could only work with std types. Is this assumption correct? If true: Wouldn't it make sense to do such a check for CT? This way errors can be detected early and it generally simplifies error handling. namespace boost::math::ccmath { namespace detail { template <typename type> inline constexpr auto foo_impl(const Type x) noexcept { return x; } } // detail template <typename Type> constexpr auto foo(const Type x) noexcept { BOOST_IF_CONSTEXPR (std::is_arithmetic_v<Type>) { if (BOOST_MATH_IS_CONSTANT_EVALUATED(x)) { BOOST_IF_CONSTEXPR (std::is_integral_v<Type>) { return detail::foo_impl(double(x)); } else { return detail::foo_impl(x); } } else { using ::std::foo; return foo(x); } } else { static_assert(boost::dependent_false_v<Type>, "foo is not supported with this type or platform"); return 0; } } } // boost::math::ccmath 1) In particular, this approach is useful for functions that require BOOST_MATH_BIT_CAST in their implementation. To be honest, I don't like your implementations of signbit/copysign (buggy) - I'll write you something more on that. 2) The idiom "always false" (dependent_false) guarantees that static_assert is only used for Type!=is_arithmetic. cu Gero

1 0

Re: [boost] Master is open for merges
by Vinnie Falco 19 Apr '23

19 Apr '23

On Sat, Apr 15, 2023 at 7:37 AM Marshall Clow via Boost <boost(a)lists.boost.org> wrote: > Next milestone: June 21 Boost 1.83.0 closed for new libraries and breaking changes Are we going to do a bugfix update for the overly aggressive inline function issue? Thanks

1 0

Re: [boost] using boost::multiprecision functions
by Seth 19 Apr '23

19 Apr '23

This is what ADL (argument dependent lookup) is for: https://en.cppreference.com/w/cpp/language/adl See e.g. https://compiler-explorer.com/z/oej1ehhnY template <typename T> T foo(T x) { using std::sin; return sin(x) * 42; } int main() { using A = double; using B = boost::multiprecision::cpp_bin_float_oct; A a = foo(A(23)); // ok B b = foo(B(23)); // ok std::cout << std::setprecision(32); std::cout << "a: " << a << "\n"; std::cout << "b: " << b << "\n"; using std::abs; std::cout << "|b-a|: " << abs(b-a) << "\n"; } As you'd expect, b is more precise than a: a: -35.541256975357164549222943605855 b: -35.541256975357166680135703420035 |b-a|: 2.1309127598141799216575314028644e-15 Seth On Sun, Apr 16, 2023, at 9:02 PM, Gero Peterhoff via Boost wrote: > Hello John, > * problem description > The functions of boost::multiprecision are not available in std, e.g. > template <typename type> > Type foo(const Type x) noexcept > { > return std::sin(x) * 42; > } > > using A = double; > A a = foo(A(23)); // ok > > using B = boost::multiprecision::cpp_bin_float_oct; > B b = foo(B(23)); // error > > > > As a workaround you currently have to write > template <typename Type> > Type bar(const Type x) noexcept > { > using ::std::sin; > using ::boost::multiprecision::sin; > return sin(x) * 42; > } > > using A = double; > A a = bar(A(23)); // ok > > using B = boost::multiprecision::cpp_bin_float_oct; > B b = bar(B(23)); // ok > > > This contradicts the template idea and is time-consuming/error-prone. > > > thx > Gero > > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > > Attachments: > * OpenPGP_signature

1 0

Re: [boost] Typo in Mysql URL on release page
by Ruben Perez 18 Apr '23

18 Apr '23

Hi Tim, Thanks for reporting! That's now fixed. Regards, Ruben. On Fri, 14 Apr 2023 at 21:27, Tim Haines via Boost <boost(a)lists.boost.org> wrote: > > The link to Mysql on the release page ( > https://www.boost.org/users/history/version_1_82_0.html) points to > > https://www.boost.org/doc/libs/1_82_0/libs/msyql/ > ^^ > > Thanks. > - Tim > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Re: [boost] using boost::multiprecision functions
by John Maddock 17 Apr '23

17 Apr '23

On 16/04/2023 19:52, Gero Peterhoff via Boost wrote: > Hello John, > * problem description > The functions of boost::multiprecision are not available in std, e.g. > template <typename type> > Type foo(const Type x) noexcept > { > return std::sin(x) * 42; > } > > using A = double; > A a = foo(A(23)); // ok > > using B = boost::multiprecision::cpp_bin_float_oct; > B b = foo(B(23)); // error > > > > As a workaround you currently have to write > template <typename Type> > Type bar(const Type x) noexcept > { > using ::std::sin; > using ::boost::multiprecision::sin; > return sin(x) * 42; > } > > using A = double; > A a = bar(A(23)); // ok > > using B = boost::multiprecision::cpp_bin_float_oct; > B b = bar(B(23)); // ok > > > This contradicts the template idea and is time-consuming/error-prone. > We are not allowed to overload anything in namespace std, so the correct incantation for any generic code is: template <typename Type> Type bar(const Type x) // cannot be noexcept if used in multiprecision case { using ::std::sin; return sin(x) * 42; // potentially found via ADL } John.

1 0

using boost::multiprecision functions
by Gero Peterhoff 16 Apr '23

16 Apr '23

Hello John, * problem description The functions of boost::multiprecision are not available in std, e.g. template <typename type> Type foo(const Type x) noexcept { return std::sin(x) * 42; } using A = double; A a = foo(A(23)); // ok using B = boost::multiprecision::cpp_bin_float_oct; B b = foo(B(23)); // error As a workaround you currently have to write template <typename Type> Type bar(const Type x) noexcept { using ::std::sin; using ::boost::multiprecision::sin; return sin(x) * 42; } using A = double; A a = bar(A(23)); // ok using B = boost::multiprecision::cpp_bin_float_oct; B b = bar(B(23)); // ok This contradicts the template idea and is time-consuming/error-prone. thx Gero

1 0

Master is open for merges
by Marshall Clow 15 Apr '23

15 Apr '23

Master is open again, with no restrictions. Boost version numbers bumped (boost, config, more), and new release notes stubbed (website). Next milestone: June 21 Boost 1.83.0 closed for new libraries and breaking changes Release calendar: https://boost.org/development <https://boost.org/development> — Marshall

1 0

Re: [boost] [scope] scope_fail is unimplementable
by Andrzej Krzemienski 14 Apr '23

14 Apr '23

niedz., 9 kwi 2023 o 03:11 Andrey Semashev via Boost <boost(a)lists.boost.org> napisał(a): > On 4/9/23 03:20, Andrzej Krzemienski wrote: > > > > Well, in my experience, the scope fail/success is exclusively about > > exceptions, so I will still focus on exceptions. > > Here is a small benchmark comparing the deactivation-based mechanism > > of a scope_guard with uncaught_exception-based mechanism of > scope_fail. > > The former performed like 36 times faster, as it doesn't have to > > perform the calls to the runtime. > > > > Sorry. Forgot the link. Here it is: > > https://quick-bench.com/q/0InBohGrnD5-soYT_GwvaCEaG74 > > <https://quick-bench.com/q/0InBohGrnD5-soYT_GwvaCEaG74> > > The thing with manually dismissing (or activating) the scope guard > before leaving the scope diminishes the usefulness of the scope guard. > The first and foremost reason to use a scope guard is to automate > execution of the action upon exiting the scope. If you now have to > manually ensure this at every point where you might leave the function, > what's the point of using it in the first place? > To "automate" is just one goal. A more modest one is to "make it manageable". Like in the case where you want to push_back into two vectors in a transactional-like fashion: vec1.push_back(Connection{params}); scope_guard pushGuard {[&]{ vec1.pop_back(); }} vec2.push_back(Storage{params}); pushGuard.deactivate(); The problem is contained, so I do not mind the call to deactivate(). But without the scope_guard, I would have to define my own class that does a pop-back in the destructor. > > Yes, you can manually (de)activate the guard in small and contained > cases, but in general I would very much prefer it to work automatically. > Otherwise, it quickly becomes a maintenance nightmare that it was > supposed to fix. > True. Therefore in my code I would contain the code that requires a guard. (In general, I prefer RAII.) But even contained cases need a scope guard. So, the trade-off is this: scope_fail: - requires no manual deactivate scope_guard with deactivate(): - works uniformly and unsurprisingly in all contexts, including coroutines - is fast. I would recommend that this trade-off is documented. Regards, &rzej; > > > Regarding failure conditions other than exceptions, the problem with > > coroutines may still appear if a thread-local storage is used, such > > as errno. > > errno is volatile (not in core C++ terms but in terms of it changing its > value in various non-obvious ways), so you would normally read its value > into a local variable immediately after a syscall for testing before > returning. It is that local variable that you check in the scope guard, > not errno itself. > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >

2 2

Typo in Mysql URL on release page
by Tim Haines 14 Apr '23

14 Apr '23

The link to Mysql on the release page ( https://www.boost.org/users/history/version_1_82_0.html) points to https://www.boost.org/doc/libs/1_82_0/libs/msyql/ ^^ Thanks. - Tim

1 0

Re: [boost] about boost::math
by Matt Borland 14 Apr '23

14 Apr '23

> a) __STDCPP_FLOAT80_T__ > With C++23 we get std::floatN_t-types, which are displayed by the macros __STDCPP_FLOATn_T__. However I miss __STDCPP_FLOAT80_T__, which has its justification/relevance. One could retrofit this > #if defined(BOOST_CSTDFLOAT_FLOAT80_NATIVE_TYPE) > #define __STDCPP_FLOAT80_T__ > namespace std > { > using float80_t = boost::float80_t; > } > #endif > Would this be useful/wanted like this? From the proposal the fixed width types are not allowed to be typedefs of the existing types https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p1467r9.html#exten…. Sections 5.3 - 5.5 also cover a whole host of conversion rules that would be unsupported. I do not believe this is something we can do at the library level. > b) complex-functions > Since C++11 there are the functions abs, asin/h, acos/h, atan/h. These are also defined in boost/math/complex.hpp. But now with 1.82 boost::math is based on C++14, which makes these manual implementations obsolete -> boost/math/complex.hpp can be removed. These functions are all explicitly marked deprecated, but we do not have a timeline for removal. > c) constexpr > I want to upgrade some functions in boost::math. How should/can I handle constexpr there? My problem is: > - in gcc almost all math functions are constexpr > - otherwise only some math functions with C++23 are constexpr > Now it would be suboptimal not to use constexpr just because it is currently not in the standard. > - If I don't define the additional functions as constexpr or stick strictly to the standard, performance might be wasted, which I don't want. > - Can I simply define the additional functions with constexpr/BOOST_CXX14_CONSTEXPR? In case of an error there will be the standard-error "not constexpr". All of the cmath functions that are specified to be constexpr in C++23 can be used with C++17 here: https://github.com/boostorg/math/tree/develop/include/boost/math/ccmath. If you would like to submit PRs for additional functions they are welcome. With the transcendental functions accuracy quickly becomes an issue: https://members.loria.fr/PZimmermann/papers/accuracy.pdf > d) implementation > In https://www.boost.org/doc/libs/1_82_0_beta1/libs/math/doc/html/math_toolkit… you describe how to implement a new math function. Is this still up to date or is it necessary for simple functions? E.g. cot -> 1/tan. That is generally correct. If this is for the implementation of constexpr cmath functions I would follow the implementations that can be found in the linked ccmath folder. Matt

2 3

Recent videos on boost.asio from Utah C++ Programmers
by Richard 14 Apr '23

14 Apr '23

Hi Team, I sent these to boost-users, but they've been held up in moderation. It was suggested that I should also share them on this list. Cheers, -- Richard =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Subject: New video: Getting Started with Boost.Asio: Timers and Serial Ports --------- Utah Cpp Programmers has released a new video Getting Started with Boost.Asio: Timers and Serial Ports <https://www.youtube.com/watch?v=XB3uEit5R_Y> I/O operations are inherently asynchronous -- we don't know when input will arrive and when output will be generated. Network I/O can be particularly bothersome because of the long delays between sending a request and obtaining the response. Boost.Asio is a cross-platform C++ library for network and low-level I/O programming that provides developers with a consistent asynchronous model using a modern C++ approach. Boost.Asio covers timers, serial ports, files, pipes and TCP/IP networking. This month, Richard Thomson will give us an introduction to Boost.Asio concepts and asynchronous programming with this library. We'll look at how to use timers to notify our application of time passing and how to talk to serial ports asynchronously. Other Utah Cpp Programmers videos: <https://www.youtube.com/@UtahCppProgrammers> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Subject: New video on TCP/IP Networking with Boost.Asio --------- Utah C++ Programmers has released a new video TCP/IP Networking with Boost.Asio <https://www.youtube.com/watch?v=tyDWXT8-Ykc> Boost.Asio is a cross-platform C++ library for network and low-level I/O programming that provides developers with a consistent asynchronous model using a modern C++ approach. This month, Richard Thomson will continue our look at Boost.Asio with a look at TCP/IP networking. We'll look at how to implement an NNTP (Network News Transport Protocol) client using Boost.Asio. NNTP is a line-oriented protocol for reading usenet news articles. This will give us insight into all the typical issues involved in a TCP/IP networking application: - How do we resolve a host name into an IP address? - How do we establish a long-lived connection to an NNTP server? - How do we handle the arbitrarily large amounts of data from an NNTP server that arrives asynchronously? - How do we coordinate user input with NNTP I/O? - How do we handle unexpected network errors? -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Terminals Wiki <http://terminals-wiki.org> The Computer Graphics Museum <http://ComputerGraphicsMuseum.org> Legalize Adulthood! (my blog) <http://LegalizeAdulthood.wordpress.com>

1 0

Re: [boost] quadmath as distinct library?
by Gero Peterhoff 14 Apr '23

14 Apr '23

Am 12.04.23 um 15:18 schrieb Christopher Kormanyos via Boost: > >>>> * problem description >>>>> In boost::math::cstdfloat AND boost::multiprecision::float128>>>> identical functions for __float128 (quadmath) are provided. >>>>> >>>>> This is unnecessary overhead. I think it would make sense>>>> to "pull out" the quadmath library as a distinct library >> Chris Kormanyos and I have discussed writing a software> implementation of binary128 that could be used cross> platform. That would be more valuable as a separate library. > It is good to read this discussion. > Historically, it all went like this... > > When we started <boost/cstdfloat.hpp>, we wereinterested in specifying floating-point types havingfixed-widths. This proposal was abandoned in the2013 timeframe, but recently picked up and broughtinto C++23 with some new stuff. > Around that time, we also "invented" Multiprecision,which came into Boost 1.53, basically with the numberbackend and cpp_dec_float only. We went on(with lots and lots of work primiarly by John) toadd several backends to Multiprecision, one ofthem being Multiprecision's float128 backend. > So indeed, we have two 128 bit floats hangingaround, yet form some platforms such as thepopular MSVC, we have zero 128-bit floatimplementations. > Writing a uniform, cross-platform implementationcombined with aliases and/or seamless use inMultiprecision is, I believe, something of interestto us all. But i believe we need some specifyingwork and a few trial implementations in order tosee how all of this should fit in together nicelain a post C++23 domain. > This is good discussion and I think we will followup on it. > Chris > > On Wednesday, April 12, 2023 at 01:12:01 PM GMT+2, Matt Borland via Boost <boost(a)lists.boost.org> wrote: > > > On Apr 11, 2023, at 8:09 PM, Gero Peterhoff via Boost <boost(a)lists.boost.org> wrote: >> >> Am 13.03.23 um 13:33 schrieb John Maddock via Boost: >> >>> On 13/03/2023 02:43, Gero Peterhoff via Boost wrote: >>> >>>> Hello, >>>> * problem description >>>> In boost::math::cstdfloat AND boost::multiprecision::float128 identical functions for __float128 (quadmath) are provided. >>>> >>>> This is unnecessary overhead. I think it would make sense to "pull out" the quadmath library as a distinct library. I did this once canonically, but it doesn't work yet because boost::math::cstdfloat/boost::multiprecision::float128 have to be adapted for this. This is a prototype where there is still a lot of work to be done. But the beginning is done. >>> >>> If you mean https://github.com/boostorg/multiprecision/blob/develop/include/boost/multi… then it's a trivially small header, and spinning stuff out into a separate library has a significant maintenance overhead. >> >> I mean this canonically. >> Advantages: >> - For both compilers (gcc/intel) the functions/limits can be provided directly, without the mass #define/#undef function-macros. >> - Clean separation and/or Konsolidierugn of the __float128 types: >> a) gcc: __float128 > > GCC also provides support for __ibm128 on PowerPC platforms. We don’t have any support for it because there has been no demand signal. > >> b) intel: Windows _Qaud -> __float128, !Windows -> __float128 (https://community.intel.com/t5/Intel-C-Compiler/C-Compiler-128-bit-floating…) >> So there is only one type __float128. >> - Clean/mature standard functions can be provided for IO. > >> Disadvantages: >> - One-time(!) effort to update dependent libs. > > Boost.Multiprecision is already available without the rest of Boost: https://github.com/boostorg/multiprecision/releases so there isn’t much bloat in the way it can be consumed now. Chris Kormanyos and I have discussed writing a software implementation of binary128 that could be used cross platform. That would be more valuable as a separate library. > > Matt Hi Matt, Hi Chris, Thanks for your comments. However, I didn't want this to be that elaborate, I just wanted to define a unique C++ interface for __float128. Right now, IO functions are spread across different header files with divergent functionality, for example: 1) boost/math/cstdfloat/cstdfloat_cmath.hpp: non-template operator<< 2) boost/math/cstdfloat/cstdfloat_iostream.hpp: operator<< operator>> 3) There are quite a few forward declarations/defines in boost/multiprecision/float128.hpp, although they are available in boost/math/cstdfloat/cstdfloat_cmath.hpp. Also, float128_backend::str seems to support std::hexfloat, which 1+2 do not. Therefore it would make sense to provide quadmath for __float128 (or intel _Quad) as a sub-library of boost.math to unify this and provide more functions (e.g. C++17 from_chars/to_chars, to_w/string). boost/multiprecision/float128.hpp could then simply use this (#include <boost/math/quadmath.hpp>). I've started with this before (see attachment); for gcc it's halfway ok, intel doesn't work. cu Gero

1 0

Re: [boost] [scope] Proposing Boost.Scope
by Andrzej Krzemienski 14 Apr '23

14 Apr '23

czw., 13 kwi 2023 o 10:43 Andrey Semashev via Boost <boost(a)lists.boost.org> napisał(a): > On 4/13/23 06:08, Darrell Wright via Boost wrote: > > One thing I learned in my own replacement is that exit_success is > heavily penalized on MSVC, even when there is no possible exception, > because of the call to uncaught_exceptions that isn’t optimized. It’s a > good thing to document, if not already, as it is surprising. > > Well, a certain amount of overhead is expected, since the added > condition is there and not likely to be optimized away. However, I would > expect uncaught_exceptions() to be cheap, as it should simply read an > integer from TLS. It looks like the call to std::uncaught_exceptions() is not optimized out, even in -O3: https://godbolt.org/z/PYEjP5PYY > I wonder how std::uncaught_exceptions() compares to > our custom implementation in boost::core::uncaught_exceptions(). > Perhaps, I should benchmark it. > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >

1 0

Master branch is NOT yet open
by Marshall Clow 14 Apr '23

14 Apr '23

I have some more work to do to start the 1.83.0 release cycle. I will post here when the master branch is open (sometime tomorrow) Thank you for your patience. — Marshall

1 0

[release] Boost 1.82.0
by Marshall Clow 14 Apr '23

14 Apr '23

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

1 0

Re: [boost] Reducing dependency on Boost.Regex
by Andrey Semashev 13 Apr '23

13 Apr '23

On 4/13/23 06:07, Francois Kritzinger via Boost wrote: > On 2023/03/13 14:07, Andrey Semashev via Boost wrote: >> On 3/13/23 15:00, Boris Kolpackov via Boost wrote: >>> A quick note on our experience reducing dependency on Boost.Regex >>> (and thus ICU) in build2 packages for Boost 1.81.0. Now only the >>> following (leaf) libraries unconditionally depend on Boost.Regex: >>> >>> * Boost.Convert >>> * Boost.DLL >>> * Boost.Log >> >> Boost.Log can be configured to use std::regex or Boost.Xpressive as an >> alternative to Boost.Regex. > > However Boost.Log also depends on Boost.Spirit which depends on > Boost.Regex so that's a hard dependency. To my knowledge, Boost.Log doesn't use the bits of Boost.Spirit that use Boost.Regex. This means, if you build Boost.Log that uses e.g. std::regex internally, it will not link with Boost.Regex.

1 0

Re: [boost] [scope] Proposing Boost.Scope
by Andrey Semashev 13 Apr '23

13 Apr '23

On 4/13/23 06:08, Darrell Wright via Boost wrote: > One thing I learned in my own replacement is that exit_success is heavily penalized on MSVC, even when there is no possible exception, because of the call to uncaught_exceptions that isn’t optimized. It’s a good thing to document, if not already, as it is surprising. Well, a certain amount of overhead is expected, since the added condition is there and not likely to be optimized away. However, I would expect uncaught_exceptions() to be cheap, as it should simply read an integer from TLS. I wonder how std::uncaught_exceptions() compares to our custom implementation in boost::core::uncaught_exceptions(). Perhaps, I should benchmark it.

1 0

Re: [boost] Boost configuration problem
by Peter Dimov 13 Apr '23

13 Apr '23

Дмитрий Архипов wrote: > How did you install Boost? This > > boost_filesystem.lib (shared, Boost_USE_STATIC_LIBS=ON) > > Seems like you're trying to use a static library, but only a shared library was > installed. https://anaconda.org/conda-forge/boost-cpp would be my guess. > чт, 13 апр. 2023 г., 06:17 Raivo Rebane via Boost <boost(a)lists.boost.org>: ...

1 0

Re: [boost] Boost configuration problem
by Дмитрий Архипов 13 Apr '23

13 Apr '23

How did you install Boost? This > boost_filesystem.lib (shared, Boost_USE_STATIC_LIBS=ON) Seems like you're trying to use a static library, but only a shared library was installed. чт, 13 апр. 2023 г., 06:17 Raivo Rebane via Boost <boost(a)lists.boost.org>: > Hello, > > May be I am in wrong list, but I didnt get answer for week from bugs list. > > May be anybody can help me ? > > I got following error from boost configuration and I can't go forward > > CMake gives configuration errors : > > CMake Error at > C:/Users/Raivo/miniconda3/Library/lib/cmake/Boost-1.78.0/BoostConfig.cmake:141 > > (find_package): > Found package configuration file: > > C:/Users/Raivo/miniconda3/Library/lib/cmake/boost_filesystem-1.78.0/boost_filesystem-config.cmake > > > > but it set boost_filesystem_FOUND to FALSE so package > "boost_filesystem" is > considered to be NOT FOUND. Reason given by package: > > No suitable build variant has been found. > > The following variants have been tried and rejected: > > * boost_filesystem.lib (shared, Boost_USE_STATIC_LIBS=ON) > > Still Boost is useless for me as I wanted to build Point CLoud Lib, bud > CMake stops on these errors. > > How to overcome of this error or what I have to do to go forwwsrd ? > > Regards > Raivo > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >

1 0

Re: [boost] Boost configuration problem
by Peter Dimov 13 Apr '23

13 Apr '23

Raivo Rebane wrote: > Hello, > > May be I am in wrong list, but I didnt get answer for week from bugs list. > > May be anybody can help me ? > > I got following error from boost configuration and I can't go forward > > CMake gives configuration errors : > > CMake Error at > C:/Users/Raivo/miniconda3/Library/lib/cmake/Boost- > 1.78.0/BoostConfig.cmake:141 > (find_package): > Found package configuration file: > > C:/Users/Raivo/miniconda3/Library/lib/cmake/boost_filesystem- > 1.78.0/boost_filesystem-config.cmake > > > but it set boost_filesystem_FOUND to FALSE so package "boost_filesystem" > is > considered to be NOT FOUND. Reason given by package: > > No suitable build variant has been found. > > The following variants have been tried and rejected: > > * boost_filesystem.lib (shared, Boost_USE_STATIC_LIBS=ON) The error is exactly as it says. The Boost package that you're using only has shared libraries (e.g. bin/boost_filesystem.dll and its corresponding import library lib/boost_filesystem.lib), but the CMake variable Boost_USE_STATIC_LIBS is set to ON, requesting static libraries (such as lib/libboost_filesystem.lib, which you don't have.)

1 0

[release] Boost 1.82.0 Release Candidate 2 is available
by Löw, Tobias (Iqony Solutions GmbH) 13 Apr '23

13 Apr '23

Compiling the range mfc-iterators with msvc 143 (VS2022) results in a compilation error. It would be nice, if https://github.com/boostorg/range/pull/144 was addressed before the final release. Compilation error with msvc 143, std=c++latest: 1>D:\boost\range\detail\microsoft.hpp(626,33): error C2440: 'return': cannot convert from 'const void *' to 'const void *&' 1>D:\boost\range\detail\microsoft.hpp(624,1): message : while compiling class template member function 'const void *&boost::range_detail_microsoft::list_iterator<const X,const void *,boost::use_default,boost::use_default>::dereference(void) const' 1> with 1> [ 1> X=CPtrList 1> ] 1>D:\boost\iterator\iterator_facade.hpp(631,11): message : see reference to function template instantiation 'const void *&boost::range_detail_microsoft::list_iterator<const X,const void *,boost::use_default,boost::use_default>::dereference(void) const' being compiled 1> with 1> [ 1> X=CPtrList 1> ] 1>D:\boost\range\mfc.hpp(881,1): message : see reference to class template instantiation 'boost::range_detail_microsoft::list_iterator<const X,const void *,boost::use_default,boost::use_default>' being compiled 1> with 1> [ 1> X=CPtrList 1> ] Thanks Tobias

1 0

Re: [boost] quadmath as distinct library?
by Christopher Kormanyos 12 Apr '23

12 Apr '23

>>>> * problem description >>>> In boost::math::cstdfloat AND boost::multiprecision::float128>>>> identical functions for __float128 (quadmath) are provided. >>>> >>>> This is unnecessary overhead. I think it would make sense>>>> to "pull out" the quadmath library as a distinct library > Chris Kormanyos and I have discussed writing a software> implementation of binary128 that could be used cross> platform. That would be more valuable as a separate library. It is good to read this discussion. Historically, it all went like this... When we started <boost/cstdfloat.hpp>, we wereinterested in specifying floating-point types havingfixed-widths. This proposal was abandoned in the2013 timeframe, but recently picked up and broughtinto C++23 with some new stuff. Around that time, we also "invented" Multiprecision,which came into Boost 1.53, basically with the numberbackend and cpp_dec_float only. We went on(with lots and lots of work primiarly by John) toadd several backends to Multiprecision, one ofthem being Multiprecision's float128 backend. So indeed, we have two 128 bit floats hangingaround, yet form some platforms such as thepopular MSVC, we have zero 128-bit floatimplementations. Writing a uniform, cross-platform implementationcombined with aliases and/or seamless use inMultiprecision is, I believe, something of interestto us all. But i believe we need some specifyingwork and a few trial implementations in order tosee how all of this should fit in together nicelain a post C++23 domain. This is good discussion and I think we will followup on it. Chris On Wednesday, April 12, 2023 at 01:12:01 PM GMT+2, Matt Borland via Boost <boost(a)lists.boost.org> wrote: > On Apr 11, 2023, at 8:09 PM, Gero Peterhoff via Boost <boost(a)lists.boost.org> wrote: > > Am 13.03.23 um 13:33 schrieb John Maddock via Boost: > >> On 13/03/2023 02:43, Gero Peterhoff via Boost wrote: >> >>> Hello, >>> * problem description >>> In boost::math::cstdfloat AND boost::multiprecision::float128 identical functions for __float128 (quadmath) are provided. >>> >>> This is unnecessary overhead. I think it would make sense to "pull out" the quadmath library as a distinct library. I did this once canonically, but it doesn't work yet because boost::math::cstdfloat/boost::multiprecision::float128 have to be adapted for this. This is a prototype where there is still a lot of work to be done. But the beginning is done. >> >> If you mean https://github.com/boostorg/multiprecision/blob/develop/include/boost/multi… then it's a trivially small header, and spinning stuff out into a separate library has a significant maintenance overhead. > > I mean this canonically. > Advantages: > - For both compilers (gcc/intel) the functions/limits can be provided directly, without the mass #define/#undef function-macros. > - Clean separation and/or Konsolidierugn of the __float128 types: > a) gcc: __float128 GCC also provides support for __ibm128 on PowerPC platforms. We don’t have any support for it because there has been no demand signal. > b) intel: Windows _Qaud -> __float128, !Windows -> __float128 (https://community.intel.com/t5/Intel-C-Compiler/C-Compiler-128-bit-floating…) > So there is only one type __float128. > - Clean/mature standard functions can be provided for IO. > Disadvantages: > - One-time(!) effort to update dependent libs. Boost.Multiprecision is already available without the rest of Boost: https://github.com/boostorg/multiprecision/releases so there isn’t much bloat in the way it can be consumed now. Chris Kormanyos and I have discussed writing a software implementation of binary128 that could be used cross platform. That would be more valuable as a separate library. Matt _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

[release] Boost 1.82.0 Release Candidate 2 is available
by don la dieu 12 Apr '23

12 Apr '23

It would be nice if https://github.com/boostorg/functional/pull/21 was addressed before final release. Alternatively see the below error. $ brew info boost llvm | grep bottled ==> boost: stable 1.81.0 (bottled), HEAD ==> llvm: stable 16.0.1 (bottled), HEAD [keg-only] $ clang++ --version Homebrew clang version 16.0.1 Target: arm64-apple-darwin21.6.0 Thread model: posix InstalledDir: /opt/homebrew/opt/llvm/bin $ cat functional_is_b0rk.cc #include <boost/functional.hpp> int main() {} $ clang++ -O0 -g -I/opt/homebrew/include -c functional_is_b0rk.cc In file included from functional_is_b0rk.cc:1: /opt/homebrew/include/boost/functional.hpp:45:24: error: no member named 'unary_function' in namespace 'std'; did you mean '__unary_function'? using std::unary_function; ~~~~~^~~~~~~~~~~~~~ __unary_function /opt/homebrew/opt/llvm/bin/../include/c++/v1/__functional/unary_function.h:46:1: note: '__unary_function' declared here using __unary_function = __unary_function_keep_layout_base<_Arg, _Result>; ^ In file included from functional_is_b0rk.cc:1: /opt/homebrew/include/boost/functional.hpp:46:24: error: no member named 'binary_function' in namespace 'std'; did you mean '__binary_function'? using std::binary_function; ~~~~~^~~~~~~~~~~~~~~ __binary_function /opt/homebrew/opt/llvm/bin/../include/c++/v1/__functional/binary_function.h:49:1: note: '__binary_function' declared here using __binary_function = __binary_function_keep_layout_base<_Arg1, _Arg2, _Result>; ^ In file included from functional_is_b0rk.cc:1: /opt/homebrew/include/boost/functional.hpp:180:45: error: no template named 'unary_function' in namespace 'boost::functional::detail'; did you mean '__unary_function'? : public boost::functional::detail::unary_function<typename unary_traits<Predicate>::argument_type,bool> ~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~ __unary_function /opt/homebrew/include/boost/functional.hpp:45:24: note: '__unary_function' declared here using std::unary_function; ^ /opt/homebrew/include/boost/functional.hpp:214:45: error: no template named 'binary_function' in namespace 'boost::functional::detail'; did you mean '__binary_function'? : public boost::functional::detail::binary_function< ~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~ __binary_function /opt/homebrew/include/boost/functional.hpp:46:24: note: '__binary_function' declared here using std::binary_function; ^ /opt/homebrew/include/boost/functional.hpp:252:45: error: no template named 'unary_function' in namespace 'boost::functional::detail'; did you mean '__unary_function'? : public boost::functional::detail::unary_function< ~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~ __unary_function /opt/homebrew/include/boost/functional.hpp:45:24: note: '__unary_function' declared here using std::unary_function; ^ /opt/homebrew/include/boost/functional.hpp:299:45: error: no template named 'unary_function' in namespace 'boost::functional::detail'; did you mean '__unary_function'? : public boost::functional::detail::unary_function< ~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~ __unary_function /opt/homebrew/include/boost/functional.hpp:45:24: note: '__unary_function' declared here using std::unary_function; ^ /opt/homebrew/include/boost/functional.hpp:345:57: error: no template named 'unary_function' in namespace 'boost::functional::detail'; did you mean '__unary_function'? class mem_fun_t : public boost::functional::detail::unary_function<T*, S> ~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~ __unary_function /opt/homebrew/include/boost/functional.hpp:45:24: note: '__unary_function' declared here using std::unary_function; ^ /opt/homebrew/include/boost/functional.hpp:361:58: error: no template named 'binary_function' in namespace 'boost::functional::detail'; did you mean '__binary_function'? class mem_fun1_t : public boost::functional::detail::binary_function<T*, A, S> ~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~ __binary_function /opt/homebrew/include/boost/functional.hpp:46:24: note: '__binary_function' declared here using std::binary_function; ^ /opt/homebrew/include/boost/functional.hpp:377:63: error: no template named 'unary_function' in namespace 'boost::functional::detail'; did you mean '__unary_function'? class const_mem_fun_t : public boost::functional::detail::unary_function<const T*, S> ~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~ __unary_function /opt/homebrew/include/boost/functional.hpp:45:24: note: '__unary_function' declared here using std::unary_function; ^ /opt/homebrew/include/boost/functional.hpp:393:64: error: no template named 'binary_function' in namespace 'boost::functional::detail'; did you mean '__binary_function'? class const_mem_fun1_t : public boost::functional::detail::binary_function<const T*, A, S> ~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~ __binary_function /opt/homebrew/include/boost/functional.hpp:46:24: note: '__binary_function' declared here using std::binary_function; ^ /opt/homebrew/include/boost/functional.hpp:438:61: error: no template named 'unary_function' in namespace 'boost::functional::detail'; did you mean '__unary_function'? class mem_fun_ref_t : public boost::functional::detail::unary_function<T&, S> ~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~ __unary_function /opt/homebrew/include/boost/functional.hpp:45:24: note: '__unary_function' declared here using std::unary_function; ^ /opt/homebrew/include/boost/functional.hpp:454:62: error: no template named 'binary_function' in namespace 'boost::functional::detail'; did you mean '__binary_function'? class mem_fun1_ref_t : public boost::functional::detail::binary_function<T&, A, S> ~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~ __binary_function /opt/homebrew/include/boost/functional.hpp:46:24: note: '__binary_function' declared here using std::binary_function; ^ /opt/homebrew/include/boost/functional.hpp:470:67: error: no template named 'unary_function' in namespace 'boost::functional::detail'; did you mean '__unary_function'? class const_mem_fun_ref_t : public boost::functional::detail::unary_function<const T&, S> ~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~ __unary_function /opt/homebrew/include/boost/functional.hpp:45:24: note: '__unary_function' declared here using std::unary_function; ^ /opt/homebrew/include/boost/functional.hpp:487:68: error: no template named 'binary_function' in namespace 'boost::functional::detail'; did you mean '__binary_function'? class const_mem_fun1_ref_t : public boost::functional::detail::binary_function<const T&, A, S> ~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~ __binary_function /opt/homebrew/include/boost/functional.hpp:46:24: note: '__binary_function' declared here using std::binary_function; ^ /opt/homebrew/include/boost/functional.hpp:533:73: error: no template named 'unary_function' in namespace 'boost::functional::detail'; did you mean '__unary_function'? class pointer_to_unary_function : public boost::functional::detail::unary_function<Arg,Result> ~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~ __unary_function /opt/homebrew/include/boost/functional.hpp:45:24: note: '__unary_function' declared here using std::unary_function; ^ /opt/homebrew/include/boost/functional.hpp:557:74: error: no template named 'binary_function' in namespace 'boost::functional::detail'; did you mean '__binary_function'? class pointer_to_binary_function : public boost::functional::detail::binary_function<Arg1,Arg2,Result> ~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~ __binary_function /opt/homebrew/include/boost/functional.hpp:46:24: note: '__binary_function' declared here using std::binary_function; ^ 16 errors generated.

1 0

Re: [boost] quadmath as distinct library?
by Matt Borland 12 Apr '23

12 Apr '23

> On Apr 11, 2023, at 8:09 PM, Gero Peterhoff via Boost <boost(a)lists.boost.org> wrote: > > Am 13.03.23 um 13:33 schrieb John Maddock via Boost: > >> On 13/03/2023 02:43, Gero Peterhoff via Boost wrote: >> >>> Hello, >>> * problem description >>> In boost::math::cstdfloat AND boost::multiprecision::float128 identical functions for __float128 (quadmath) are provided. >>> >>> This is unnecessary overhead. I think it would make sense to "pull out" the quadmath library as a distinct library. I did this once canonically, but it doesn't work yet because boost::math::cstdfloat/boost::multiprecision::float128 have to be adapted for this. This is a prototype where there is still a lot of work to be done. But the beginning is done. >> >> If you mean https://github.com/boostorg/multiprecision/blob/develop/include/boost/multi… then it's a trivially small header, and spinning stuff out into a separate library has a significant maintenance overhead. > > I mean this canonically. > Advantages: > - For both compilers (gcc/intel) the functions/limits can be provided directly, without the mass #define/#undef function-macros. > - Clean separation and/or Konsolidierugn of the __float128 types: > a) gcc: __float128 GCC also provides support for __ibm128 on PowerPC platforms. We don’t have any support for it because there has been no demand signal. > b) intel: Windows _Qaud -> __float128, !Windows -> __float128 (https://community.intel.com/t5/Intel-C-Compiler/C-Compiler-128-bit-floating…) > So there is only one type __float128. > - Clean/mature standard functions can be provided for IO. > Disadvantages: > - One-time(!) effort to update dependent libs. Boost.Multiprecision is already available without the rest of Boost: https://github.com/boostorg/multiprecision/releases so there isn’t much bloat in the way it can be consumed now. Chris Kormanyos and I have discussed writing a software implementation of binary128 that could be used cross platform. That would be more valuable as a separate library. Matt

1 0

Re: [boost] [release] Boost 1.82.0 Release Candidate 2 is available
by Glen Fernandes 12 Apr '23

12 Apr '23

On Tue, Apr 11, 2023 at 6:07 PM Andrey Semashev via Boost < boost(a)lists.boost.org> wrote: > On 4/12/23 01:02, Marshall Clow wrote: > > On Apr 11, 2023, at 2:17 PM, Andrey Semashev via Boost < > boost(a)lists.boost.org> wrote: > >> > >> On 4/10/23 17:36, Marshall Clow via Boost wrote: > >>> The second release candidates for the 1.82.0 release are now available > at: > >>> <https://boostorg.jfrog.io/artifactory/main/release/1.82.0/source/ < > https://boostorg.jfrog.io/artifactory/main/release/1.82.0/source/>> > >>> > >>> There is only one change from RC1 - a fix to ASIO that caused some > compile failures. > >>> Thanks to Ruben Perez for the report, and to Chris for the fix. > >>> > >>> > >>> The SHA256 checksums are as follows: > >>> > >>> 66a469b6e608a51f8347236f4912e27dc5c60c60d7d53ae9bfe4683316c6f04c > boost_1_82_0_rc2.tar.gz > >>> f7c9e28d242abcd7a2c1b962039fcdd463ca149d1883c3a950bbcc0ce6f7c6d9 > boost_1_82_0_rc2.zip > >>> a6e1ab9b0860e6a2881dd7b21fe9f737a095e5f33a3a874afc6a345228597ee6 > boost_1_82_0_rc2.tar.bz2 > >>> e72ff100482d4b371327b6c550dbd244d49c0186860ccc3b8c093dd621537e39 > boost_1_82_0_rc2.7z > >>> > >>> > >>> As always, the release managers would appreciate it if you download the > >>> candidate of your choice and give building it a try. Please report both > >>> success and failure, and anything else that is noteworthy. > >> > >> I would like the following last minute fix to be merged to > >> Boost.Filesystem master: > >> > >> > https://github.com/boostorg/filesystem/commit/176fce8e4d2016e864a0b9193cc4e… > >> > >> This should fix compilation on OpenBSD due to broken -Wl,--no-undefined > >> flag on this platform. > >> > >> This problem was reported very late: > >> > >> https://github.com/boostorg/filesystem/issues/283 > > > > Is this a new problem in this release? > > Yes. > If this is the only issue, I think we may put a Filesystem patch for OpenBSD users on the website instead of producing an RC3.

1 0

Re: [boost] [release] Boost 1.82.0 Release Candidate 2 is available
by Marshall Clow 11 Apr '23

11 Apr '23

On Apr 11, 2023, at 2:17 PM, Andrey Semashev via Boost <boost(a)lists.boost.org> wrote: > > On 4/10/23 17:36, Marshall Clow via Boost wrote: >> The second release candidates for the 1.82.0 release are now available at: >> <https://boostorg.jfrog.io/artifactory/main/release/1.82.0/source/ <https://boostorg.jfrog.io/artifactory/main/release/1.82.0/source/>> >> >> There is only one change from RC1 - a fix to ASIO that caused some compile failures. >> Thanks to Ruben Perez for the report, and to Chris for the fix. >> >> >> The SHA256 checksums are as follows: >> >> 66a469b6e608a51f8347236f4912e27dc5c60c60d7d53ae9bfe4683316c6f04c boost_1_82_0_rc2.tar.gz >> f7c9e28d242abcd7a2c1b962039fcdd463ca149d1883c3a950bbcc0ce6f7c6d9 boost_1_82_0_rc2.zip >> a6e1ab9b0860e6a2881dd7b21fe9f737a095e5f33a3a874afc6a345228597ee6 boost_1_82_0_rc2.tar.bz2 >> e72ff100482d4b371327b6c550dbd244d49c0186860ccc3b8c093dd621537e39 boost_1_82_0_rc2.7z >> >> >> As always, the release managers would appreciate it if you download the >> candidate of your choice and give building it a try. Please report both >> success and failure, and anything else that is noteworthy. > > I would like the following last minute fix to be merged to > Boost.Filesystem master: > > https://github.com/boostorg/filesystem/commit/176fce8e4d2016e864a0b9193cc4e… > > This should fix compilation on OpenBSD due to broken -Wl,--no-undefined > flag on this platform. > > This problem was reported very late: > > https://github.com/boostorg/filesystem/issues/283 Is this a new problem in this release? — Marshall

2 1

Re: [boost] [release] Boost 1.82.0 Release Candidate 2 is available
by Andrey Semashev 11 Apr '23

11 Apr '23

On 4/10/23 17:36, Marshall Clow via Boost wrote: > The second release candidates for the 1.82.0 release are now available at: > <https://boostorg.jfrog.io/artifactory/main/release/1.82.0/source/ <https://boostorg.jfrog.io/artifactory/main/release/1.82.0/source/>> > > There is only one change from RC1 - a fix to ASIO that caused some compile failures. > Thanks to Ruben Perez for the report, and to Chris for the fix. > > > The SHA256 checksums are as follows: > > 66a469b6e608a51f8347236f4912e27dc5c60c60d7d53ae9bfe4683316c6f04c boost_1_82_0_rc2.tar.gz > f7c9e28d242abcd7a2c1b962039fcdd463ca149d1883c3a950bbcc0ce6f7c6d9 boost_1_82_0_rc2.zip > a6e1ab9b0860e6a2881dd7b21fe9f737a095e5f33a3a874afc6a345228597ee6 boost_1_82_0_rc2.tar.bz2 > e72ff100482d4b371327b6c550dbd244d49c0186860ccc3b8c093dd621537e39 boost_1_82_0_rc2.7z > > > As always, the release managers would appreciate it if you download the > candidate of your choice and give building it a try. Please report both > success and failure, and anything else that is noteworthy. I would like the following last minute fix to be merged to Boost.Filesystem master: https://github.com/boostorg/filesystem/commit/176fce8e4d2016e864a0b9193cc4e… This should fix compilation on OpenBSD due to broken -Wl,--no-undefined flag on this platform. This problem was reported very late: https://github.com/boostorg/filesystem/issues/283

1 0

Boost docs
by Peter Turcan 11 Apr '23

11 Apr '23

Hi, This week I joined CppAlliance as a technical writer - just introducing myself here! I am pumped to be writing some C++ code after several years hiatus. The last major project I wrote in C++ was a wargame that would cope with battle data from either the Napoleonic wars, or the American Civil War, and was called Battalia. It is still around in archive sites such as: https://archive.org/details/wargamer-depot_battalia Mostly I write developer documentation and tutorials. The work I enjoyed the most was writing the SDK for Microsoft Flight Simulator (and taught myself instrument flying in the process), the User Guides and SDK for WorldWide Telescope (an astronomy viewing program that involved working with NASA on Mars imagery data), and writing a range of developer tutorials for Azure IoT, Azure Search and Azure Maps. I was the main writer at Microsoft for the DirectX 12 documentation - though that was a brutally tough SDK to actually work with. Most developers stuck with DirectX 11 - not sure where Microsoft is now on its graphics APIs. At CppAlliance I hope to add value to the documentation on the libraries where I can - perhaps adding examples, better navigation, and more complete descriptions of parameters, edge-cases, errors - the usual suspects that are often missing from documentation but are sorely needed by developers. Also, I plan on getting hardcore with the introductions to each library. The question that should be answered in introductions to any library (or any SDK) is the "why" question. Why should I be interested in this library? What is the problem that I have that the library is solving? This is often missing. A typical introduction might answer the "What" question - such as "this particular piece of software converts A into B", and the "How" question (what tools and setup is needed), but avoids the why question: "why should I be interested in converting A into B". The answer might be: "this library converts A into B to provide your data with an additional level of security, when the data is communicated over the internet." By answering the why question, any developer will know immediately whether to continue reading, or look elsewhere. Another aspect of documentation to look at is style. For API reference type documentation (interfaces, functions, parameters), mostly a neutral style works well - just say exactly what is going on. For guide or more conceptual material, perhaps a chattier style is more appropriate - short sharp sentences, some wit and wisdom, less formality - like talking to a knowledgeable buddy. You probably have some great ideas too on adding value to the existing Boost documentation - happy to hear any and all feedback! - best Peter

1 0

Re: [boost] quadmath as distinct library?
by Gero Peterhoff 11 Apr '23

11 Apr '23

Am 13.03.23 um 13:33 schrieb John Maddock via Boost: > On 13/03/2023 02:43, Gero Peterhoff via Boost wrote: >> Hello, >> * problem description >> In boost::math::cstdfloat AND boost::multiprecision::float128 identical functions for __float128 (quadmath) are provided. >> >> This is unnecessary overhead. I think it would make sense to "pull out" the quadmath library as a distinct library. I did this once canonically, but it doesn't work yet because boost::math::cstdfloat/boost::multiprecision::float128 have to be adapted for this. This is a prototype where there is still a lot of work to be done. But the beginning is done. > If you mean https://github.com/boostorg/multiprecision/blob/develop/include/boost/multi… then it's a trivially small header, and spinning stuff out into a separate library has a significant maintenance overhead. I mean this canonically. Advantages: - For both compilers (gcc/intel) the functions/limits can be provided directly, without the mass #define/#undef function-macros. - Clean separation and/or Konsolidierugn of the __float128 types: a) gcc: __float128 b) intel: Windows _Qaud -> __float128, !Windows -> __float128 (https://community.intel.com/t5/Intel-C-Compiler/C-Compiler-128-bit-floating…) So there is only one type __float128. - Clean/mature standard functions can be provided for IO. Disadvantages: - One-time(!) effort to update dependent libs. Gero

1 0

about boost::math
by Gero Peterhoff 11 Apr '23

11 Apr '23

a) __STDCPP_FLOAT80_T__ With C++23 we get std::floatN_t-types, which are displayed by the macros __STDCPP_FLOATn_T__. However I miss __STDCPP_FLOAT80_T__, which has its justification/relevance. One could retrofit this #if defined(BOOST_CSTDFLOAT_FLOAT80_NATIVE_TYPE) #define __STDCPP_FLOAT80_T__ namespace std { using float80_t = boost::float80_t; } #endif Would this be useful/wanted like this? b) complex-functions Since C++11 there are the functions abs, asin/h, acos/h, atan/h. These are also defined in boost/math/complex.hpp. But now with 1.82 boost::math is based on C++14, which makes these manual implementations obsolete -> boost/math/complex.hpp can be removed. c) constexpr I want to upgrade some functions in boost::math. How should/can I handle constexpr there? My problem is: - in gcc almost all math functions are constexpr - otherwise only some math functions with C++23 are constexpr Now it would be suboptimal not to use constexpr just because it is currently not in the standard. - If I don't define the additional functions as constexpr or stick strictly to the standard, performance might be wasted, which I don't want. - Can I simply define the additional functions with constexpr/BOOST_CXX14_CONSTEXPR? In case of an error there will be the standard-error "not constexpr". d) implementation In https://www.boost.org/doc/libs/1_82_0_beta1/libs/math/doc/html/math_toolkit… you describe how to implement a new math function. Is this still up to date or is it necessary for simple functions? E.g. cot -> 1/tan. thx Gero

1 0

Re: [boost] [release] Boost 1.82.0 Release Candidate 2 is available
by Ruben Perez 11 Apr '23

11 Apr '23

On Mon, 10 Apr 2023 at 16:37, Marshall Clow via Boost <boost(a)lists.boost.org> wrote: > > The second release candidates for the 1.82.0 release are now available at: > <https://boostorg.jfrog.io/artifactory/main/release/1.82.0/source/ <https://boostorg.jfrog.io/artifactory/main/release/1.82.0/source/>> > > There is only one change from RC1 - a fix to ASIO that caused some compile failures. > Thanks to Ruben Perez for the report, and to Chris for the fix. I have successfully built the libraries under clang-15, on Ubuntu 22.04. I can confirm that there are no problems building Boost.MySQL examples. Regards, Ruben.

1 0

Re: [boost] [release] Boost 1.82.0 Release Candidate 2 is available
by Tom Kent 10 Apr '23

10 Apr '23

On Mon, Apr 10, 2023 at 9:36 AM Marshall Clow via Boost < boost(a)lists.boost.org> wrote: > The second release candidates for the 1.82.0 release are now available at: > <https://boostorg.jfrog.io/artifactory/main/release/1.82.0/source/ < > https://boostorg.jfrog.io/artifactory/main/release/1.82.0/source/>> > > There is only one change from RC1 - a fix to ASIO that caused some compile > failures. > Thanks to Ruben Perez for the report, and to Chris for the fix. > > > The SHA256 checksums are as follows: > > 66a469b6e608a51f8347236f4912e27dc5c60c60d7d53ae9bfe4683316c6f04c > boost_1_82_0_rc2.tar.gz > f7c9e28d242abcd7a2c1b962039fcdd463ca149d1883c3a950bbcc0ce6f7c6d9 > boost_1_82_0_rc2.zip > a6e1ab9b0860e6a2881dd7b21fe9f737a095e5f33a3a874afc6a345228597ee6 > boost_1_82_0_rc2.tar.bz2 > e72ff100482d4b371327b6c550dbd244d49c0186860ccc3b8c093dd621537e39 > boost_1_82_0_rc2.7z > > > As always, the release managers would appreciate it if you download the > candidate of your choice and give building it a try. Please report both > success and failure, and anything else that is noteworthy. > > -- The Release managers > Looks good for Windows/Visual Studio. toolset arch compile Link Execute msvc-10.0 32 X X X msvc-10.0 64 X X X msvc-11.0 32 X X X msvc-11.0 64 X X X msvc-12.0 32 X X X msvc-12.0 64 X X X msvc-14.0 32 X X X msvc-14.0 64 X X X msvc-14.1 32 X X X msvc-14.1 64 X X X msvc-14.2 32 X X X msvc-14.2 64 X X X msvc-14.3 32 X X X msvc-14.3 64 X X X Compile means that the b2 command completed without errors Link means that visual studio was able to link a sample executable to a library (libboost_thread-vcXXX-mt[-gd]-1_XX.lib) generated Execute means that the linked program executed without errors. Full log here: https://gist.github.com/teeks99/3ffee2d9d3b93ec996f47ad7c38f64c1 Tom

1 0

Re: [boost] [release] Boost 1.82.0 Release Candidate 2 is available
by Matt Borland 10 Apr '23

10 Apr '23

> > As always, the release managers would appreciate it if you download the > candidate of your choice and give building it a try. Please report both > success and failure, and anything else that is noteworthy. > > -- The Release managers > > I have successfully built the libraries using Homebrew Clang 16.0.1 on an M1 Mac running macOS Ventura 13.3.1. Matt

1 0

Re: [boost] [release] Boost 1.82.0 Release Candidate 2 is available
by Marshall Clow 10 Apr '23

10 Apr '23

On Apr 10, 2023, at 7:36 AM, Marshall Clow via Boost <boost(a)lists.boost.org> wrote: > > The second release candidates for the 1.82.0 release are now available at: > <https://boostorg.jfrog.io/artifactory/main/release/1.82.0/source/ <https://boostorg.jfrog.io/artifactory/main/release/1.82.0/source/>> > > There is only one change from RC1 - a fix to ASIO that caused some compile failures. > Thanks to Ruben Perez for the report, and to Chris for the fix. > > > The SHA256 checksums are as follows: > > 66a469b6e608a51f8347236f4912e27dc5c60c60d7d53ae9bfe4683316c6f04c boost_1_82_0_rc2.tar.gz > f7c9e28d242abcd7a2c1b962039fcdd463ca149d1883c3a950bbcc0ce6f7c6d9 boost_1_82_0_rc2.zip > a6e1ab9b0860e6a2881dd7b21fe9f737a095e5f33a3a874afc6a345228597ee6 boost_1_82_0_rc2.tar.bz2 > e72ff100482d4b371327b6c550dbd244d49c0186860ccc3b8c093dd621537e39 boost_1_82_0_rc2.7z > > > As always, the release managers would appreciate it if you download the > candidate of your choice and give building it a try. Please report both > success and failure, and anything else that is noteworthy. I have successfully built the libraries in Mac OS 12.6.4, with "Apple clang version 14.0.0 (clang-1400.0.29.202)” and C++ 03/11/14/17/20/2b, on both x86 and ARM. — Marshall

1 0

[release] Boost 1.82.0 Release Candidate 2 is available
by Marshall Clow 10 Apr '23

10 Apr '23

The second release candidates for the 1.82.0 release are now available at: <https://boostorg.jfrog.io/artifactory/main/release/1.82.0/source/ <https://boostorg.jfrog.io/artifactory/main/release/1.82.0/source/>> There is only one change from RC1 - a fix to ASIO that caused some compile failures. Thanks to Ruben Perez for the report, and to Chris for the fix. The SHA256 checksums are as follows: 66a469b6e608a51f8347236f4912e27dc5c60c60d7d53ae9bfe4683316c6f04c boost_1_82_0_rc2.tar.gz f7c9e28d242abcd7a2c1b962039fcdd463ca149d1883c3a950bbcc0ce6f7c6d9 boost_1_82_0_rc2.zip a6e1ab9b0860e6a2881dd7b21fe9f737a095e5f33a3a874afc6a345228597ee6 boost_1_82_0_rc2.tar.bz2 e72ff100482d4b371327b6c550dbd244d49c0186860ccc3b8c093dd621537e39 boost_1_82_0_rc2.7z As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. -- The Release managers

1 0

Re: [boost] [scope] scope_fail is unimplementable
by Andrzej Krzemienski 09 Apr '23

09 Apr '23

niedz., 9 kwi 2023 o 00:28 Andrey Semashev via Boost <boost(a)lists.boost.org> napisał(a): > On 4/7/23 18:42, Andrey Semashev wrote: > > On 4/7/23 15:55, Andrzej Krzemienski wrote: > >> czw., 6 kwi 2023 o 23:51 Andrey Semashev via Boost > >> <boost(a)lists.boost.org <mailto:boost@lists.boost.org>> napisał(a): > >> > >> Thus I > >> wouldn't say scope_success/scope_fail are unimplementable - they > clearly > >> are - but that they are incompatible with coroutines. That is, these > >> scope guards will work as expected as long as you don't switch > >> coroutines within the guarded scope. > >> > >> Maybe this is just a question of the choice of words. > >> But the docs do not present the situation in this way. > >> > >> "Although it is possible to specify arbitrary condition function > >> objects, typically |scope_success > >> < > https://lastique.github.io/scope/libs/scope/doc/html/boost/scope/scope_succ…>| > invokes its action when the scope is left normally (i.e. not via an > exception) and |scope_fail < > https://lastique.github.io/scope/libs/scope/doc/html/boost/scope/scope_fail…>| > should typically be used to handle errors, including exceptions." > >> > >> This guarantee (when scope is exited not normally) cannot be satisfied > >> in general. One cannot use it in a coroutine: directly or indirectly. > >> One might not even know the context. > >> > >> "By default, |scope_success > >> < > https://lastique.github.io/scope/libs/scope/doc/html/boost/scope/scope_succ…>| > will invoke its action if it is destroyed normally, |scope_fail < > https://lastique.github.io/scope/libs/scope/doc/html/boost/scope/scope_fail…>| > - if it is destroyed due to an exception being thrown." > > > > Note the "typically". :) In this documentation I tried to describe these > > facilities in more or less simple language, describing the most typical > > use cases. For this simplicity, I had to omit some formalities and > > corner cases that would detract the reader from the main purpose and > > intended use case of the components. Perhaps, I should improve the > > wording, but I would still like the docs to be easily readable. > > > > And, as I admitted earlier, I completely forgot about coroutines. I will > > add a note about coroutenes in relation to the default failure condition > > used by scope_success/scope_fail. > > > >> (BTW, The synopsis in > >> > https://lastique.github.io/scope/libs/scope/doc/html/boost/scope/scope_fail… > < > https://lastique.github.io/scope/libs/scope/doc/html/boost/scope/scope_fail… > > > >> does not indicate that there is any default Cond.) > > > > Hmm, for some reason Doxygen removed the default template arguments for > > scope_success/scope_fail. I'll see if I can fix this. Thanks for > noticing. > > I have updated the docs to fix those issues and added the note re. > coroutines. I've also improved wording so that the general discussion > does not focus on exceptions as much but rather failure and non-failure > conditions. > Thanks. Well, in my experience, the scope fail/success is exclusively about exceptions, so I will still focus on exceptions. Here is a small benchmark comparing the deactivation-based mechanism of a scope_guard with uncaught_exception-based mechanism of scope_fail. The former performed like 36 times faster, as it doesn't have to perform the calls to the runtime. Regarding failure conditions other than exceptions, the problem with coroutines may still appear if a thread-local storage is used, such as errno. Regards, &rzej; > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >

2 2

Re: [boost] [scope] scope_fail is unimplementable
by Andrzej Krzemienski 08 Apr '23

08 Apr '23

czw., 6 kwi 2023 o 23:51 Andrey Semashev via Boost <boost(a)lists.boost.org> napisał(a): > On 4/6/23 21:26, Andrzej Krzemienski via Boost wrote: > > Hi Everyone, > > It is my understanding that the reason scope_fail was left to die in the > > C++ Extensions for Library Fundamentals v3 was that it is not > > implementable. > > I'm not sure what you mean in the "left to die" part. Do you mean that > these facilities are being deprecated? > There are two motivations for putting something into a TS. One is to encourage vendors to implement the feature and gather usage and deployment experience. The other is to postpone the addition of the feature or to politely say that it is not wanted in the Standard. I *believe* this is the case with the subset of scope guards. I have seen no movement towards moving scope_fail into the Standard. and not moving them into the standard in reality means abandoning them. > > > One cannot detect if the scope is being left due to an > > exception thrown from within the scope. Observing the number of uncaught > > exceptions in the constructor and in the destructor will not work, given > > that we now have coroutines that can be suspended and then resumed in > > another thread (with a different number of uncaught exceptions), or even > in > > the same thread but at some later point, when the number of uncaught > > exceptions has changed. > > > > The enclosed example illustrates how a scope_fail fails to call the > > callback when an exception is thrown from a coroutine. It uses Lewis > > Baker's CppCoro implementation of a generator. > > > > The only reliable way to call a callback when the scope is left due to an > > exception is through using the explicit call to `deactivate()` function. > It > > is more verbose, but reliable. > > I must say I have no experience with coroutines, but my understanding is > that they are basically incompatible with any mechanism that relies on > thread-specific state, including the uncaught exceptions counter. Indeed. Note that the example I provided uses just one thread. The problem is the suspension itself. > Thus I > wouldn't say scope_success/scope_fail are unimplementable - they clearly > are - but that they are incompatible with coroutines. That is, these > scope guards will work as expected as long as you don't switch > coroutines within the guarded scope. > Maybe this is just a question of the choice of words. But the docs do not present the situation in this way. "Although it is possible to specify arbitrary condition function objects, typically scope_success <https://lastique.github.io/scope/libs/scope/doc/html/boost/scope/scope_succ…> invokes its action when the scope is left normally (i.e. not via an exception) and scope_fail <https://lastique.github.io/scope/libs/scope/doc/html/boost/scope/scope_fail…> should typically be used to handle errors, including exceptions." This guarantee (when scope is exited not normally) cannot be satisfied in general. One cannot use it in a coroutine: directly or indirectly. One might not even know the context. "By default, scope_success <https://lastique.github.io/scope/libs/scope/doc/html/boost/scope/scope_succ…> will invoke its action if it is destroyed normally, scope_fail <https://lastique.github.io/scope/libs/scope/doc/html/boost/scope/scope_fail…> - if it is destroyed due to an exception being thrown." (BTW, The synopsis in https://lastique.github.io/scope/libs/scope/doc/html/boost/scope/scope_fail… does not indicate that there is any default Cond.) This is not true when a scope guard is used across coroutine suspensions: by default [...] scope_fail is not destroyed due to exception being thrown. The reality is, it is destroyed based on the comparison of two measurements of the number of uncaught exceptions, potentially measured in different threads. > I admit this is a notable limitation, and I will document it. But I do > not consider this limitation fatal, as there is plenty code out there > that doesn't use coroutines - I'd even say, much more code than that does. > This is one way of looking at it: that the problem is rare. A different way is to say that if something works in 99% of the cases and fails only in 1%, we have a dangerous situation, as we are unprepared when the 1% case happens. > Also, I forgot to mention that Boost.Scope's scope_success/scope_fail > support custom failure predicates which may not rely on the exception > state at all. Can it be used to fix the coroutine case? (That is to detect that the scope is left due to an exception being thrown?) Regards, &rzej;

2 2

Re: [boost] [scope] scope_fail is unimplementable
by Andrzej Krzemienski 07 Apr '23

07 Apr '23

pt., 7 kwi 2023 o 17:43 Andrey Semashev via Boost <boost(a)lists.boost.org> napisał(a): > On 4/7/23 15:55, Andrzej Krzemienski wrote: > > > > > > czw., 6 kwi 2023 o 23:51 Andrey Semashev via Boost > > <boost(a)lists.boost.org <mailto:boost@lists.boost.org>> napisał(a): > > > > On 4/6/23 21:26, Andrzej Krzemienski via Boost wrote: > > > Hi Everyone, > > > It is my understanding that the reason scope_fail was left to die > > in the > > > C++ Extensions for Library Fundamentals v3 was that it is not > > > implementable. > > > > I'm not sure what you mean in the "left to die" part. Do you mean > that > > these facilities are being deprecated? > > > > There are two motivations for putting something into a TS. One is to > > encourage vendors to implement the feature and gather usage and > > deployment experience. The other is to postpone the addition of the > > feature or to politely say that it is not wanted in the Standard. I > > *believe* this is the case with the subset of scope guards. I have seen > > no movement towards moving scope_fail into the Standard. and not moving > > them into the standard in reality means abandoning them. > > My understanding is that the TS exist to gather practical usage > experience in real world with the components before including (or not > including) them into the main standard. In fact, this very thread is a > piece of this real world feedback. I see no point in including something > into a TS only to abandon it afterwards. That said, I have no close > knowledge of the standard committee processes and may be wrong. > > In any case, the problem you highlighted may well be a reason for > reluctance to include scope_success/scope_fail into the standard, at > least not with the current wording that is given in the TS. But I think > the components can be defined differently, with coroutines in mind. That > new definition would not use uncaught_exceptions() as a criteria for > detecting failure but some other, possibly "implementation-defined" or > otherwise undisclosed mechanism that allows to implement the correct > semantics wrt. coroutines. > That would be nice. > > > I must say I have no experience with coroutines, but my > understanding is > > that they are basically incompatible with any mechanism that relies > on > > thread-specific state, including the uncaught exceptions counter. > > > > Indeed. Note that the example I provided uses just one thread. The > > problem is the suspension itself. > > The problem is that the uncaught exceptions counter does not correspond > to the current coroutine, but to the current thread. > > > Thus I > > wouldn't say scope_success/scope_fail are unimplementable - they > clearly > > are - but that they are incompatible with coroutines. That is, these > > scope guards will work as expected as long as you don't switch > > coroutines within the guarded scope. > > > > Maybe this is just a question of the choice of words. > > But the docs do not present the situation in this way. > > > > "Although it is possible to specify arbitrary condition function > > objects, typically |scope_success > > < > https://lastique.github.io/scope/libs/scope/doc/html/boost/scope/scope_succ…>| > invokes its action when the scope is left normally (i.e. not via an > exception) and |scope_fail < > https://lastique.github.io/scope/libs/scope/doc/html/boost/scope/scope_fail…>| > should typically be used to handle errors, including exceptions." > > > > This guarantee (when scope is exited not normally) cannot be satisfied > > in general. One cannot use it in a coroutine: directly or indirectly. > > One might not even know the context. > > > > "By default, |scope_success > > < > https://lastique.github.io/scope/libs/scope/doc/html/boost/scope/scope_succ…>| > will invoke its action if it is destroyed normally, |scope_fail < > https://lastique.github.io/scope/libs/scope/doc/html/boost/scope/scope_fail…>| > - if it is destroyed due to an exception being thrown." > > Note the "typically". :) In this documentation I tried to describe these > facilities in more or less simple language, describing the most typical > use cases. For this simplicity, I had to omit some formalities and > corner cases that would detract the reader from the main purpose and > intended use case of the components. Perhaps, I should improve the > wording, but I would still like the docs to be easily readable. > > And, as I admitted earlier, I completely forgot about coroutines. I will > add a note about coroutenes in relation to the default failure condition > used by scope_success/scope_fail. > > > (BTW, The synopsis in > > > https://lastique.github.io/scope/libs/scope/doc/html/boost/scope/scope_fail… > < > https://lastique.github.io/scope/libs/scope/doc/html/boost/scope/scope_fail… > > > > does not indicate that there is any default Cond.) > > Hmm, for some reason Doxygen removed the default template arguments for > scope_success/scope_fail. I'll see if I can fix this. Thanks for noticing. > > > This is not true when a scope guard is used across coroutine > > suspensions: by default [...] scope_fail is not destroyed due to > > exception being thrown. The reality is, it is destroyed based on the > > comparison of two measurements of the number of uncaught exceptions, > > potentially measured in different threads. > > > > I admit this is a notable limitation, and I will document it. But I > do > > not consider this limitation fatal, as there is plenty code out there > > that doesn't use coroutines - I'd even say, much more code than that > > does. > > > > This is one way of looking at it: that the problem is rare. A different > > way is to say that if something works in 99% of the cases and fails only > > in 1%, we have a dangerous situation, as we are unprepared when the 1% > > case happens. > > Well, every technology has its limits. And if a utility is not usable in > 1% of use cases, I don't see why it shouldn't exist to benefit the rest > 99%. > Let me clarify my point here a bit. We can distinguish two situations here. The first is this. A tool compiles and works fine in 99% of the cases, and in the remaining 1% it fails to compile, or signals an error. The second is this. A tool compiles and works fine in 99% of the cases, and in the remaining 1%it compiles fine, reports no error, and works against the user's expectations or the declared intent. In the first case, this is an acceptable trade-off. In the second case, it may be debatable, but I personally would find it a bad trade-off. My claim is that the situation with scope_fail is closer to the second one. Especially, given that a 100% alternative exists: just explicitly deactivate an active guard. Regards, &rzej; > > Also, I forgot to mention that Boost.Scope's scope_success/scope_fail > > support custom failure predicates which may not rely on the exception > > state at all. > > > > Can it be used to fix the coroutine case? (That is to detect that the > > scope is left due to an exception being thrown?) > > To my knowledge, not in pure C++. With current real coroutine > implementations? I don't know, probably not either. You could use this > feature with your own error reporting mechanism, like checking an error > code. > > I could imagine a mechanism that would capture the unhandled exceptions > count upon entering a coroutine. Throwing and catching exceptions from > the coroutine would then update this cached counter the same way as it > does for the thread-specific counter. Resuming the coroutine would > maintain its own counter regardless of the caller's state. Then > scope_success/scope_fail could use some internal API to use this counter > (say, co_unhandled_exceptions()) instead of unhandled_exceptions() to > detect a thrown exception. > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >

2 1

Re: [boost] [release] Boost 1.82.0 Release Candidate 1 is available
by Matt Borland 07 Apr '23

07 Apr '23

> On Apr 6, 2023, at 4:25 PM, Marshall Clow via Boost <boost(a)lists.boost.org> wrote: > > The first release candidates for the 1.82.0 release are now available at: > <https://boostorg.jfrog.io/artifactory/main/release/1.82.0/source/> > > The SHA256 checksums are as follows: > > b6bfc8adc9056bdb01083680b77ecdd7ad4a59a7425a3a42e15a1fe7f6c4f459 boost_1_82_0_rc1.7z > 891aa0d522f80d79ecf622378961ceec882025d55b8aa85f61847db602056d57 boost_1_82_0_rc1.zip > bcdf29d00ade098140ef6934849f27273ad655fcb1e172a4f25660ae0f930d33 boost_1_82_0_rc1.tar.gz > 17d717a04d81e4e23bf0b527bae894f36db72c75976224ddedea9ffddfcd1fbd boost_1_82_0_rc1.tar.bz2 > > > As always, the release managers would appreciate it if you download the > candidate of your choice and give building it a try. Please report both > success and failure, and anything else that is noteworthy. > > -- The Release managers > > I have successfully built the libraries using Homebrew Clang 16.0.1 on an M1 Mac running macOS Ventura 13.3. Matt

1 0

Re: [boost] [scope] scope_fail is unimplementable
by Andrey Semashev 07 Apr '23

07 Apr '23

On 4/6/23 21:26, Andrzej Krzemienski via Boost wrote: > Hi Everyone, > It is my understanding that the reason scope_fail was left to die in the > C++ Extensions for Library Fundamentals v3 was that it is not > implementable. I'm not sure what you mean in the "left to die" part. Do you mean that these facilities are being deprecated? > One cannot detect if the scope is being left due to an > exception thrown from within the scope. Observing the number of uncaught > exceptions in the constructor and in the destructor will not work, given > that we now have coroutines that can be suspended and then resumed in > another thread (with a different number of uncaught exceptions), or even in > the same thread but at some later point, when the number of uncaught > exceptions has changed. > > The enclosed example illustrates how a scope_fail fails to call the > callback when an exception is thrown from a coroutine. It uses Lewis > Baker's CppCoro implementation of a generator. > > The only reliable way to call a callback when the scope is left due to an > exception is through using the explicit call to `deactivate()` function. It > is more verbose, but reliable. I must say I have no experience with coroutines, but my understanding is that they are basically incompatible with any mechanism that relies on thread-specific state, including the uncaught exceptions counter. Thus I wouldn't say scope_success/scope_fail are unimplementable - they clearly are - but that they are incompatible with coroutines. That is, these scope guards will work as expected as long as you don't switch coroutines within the guarded scope. I admit this is a notable limitation, and I will document it. But I do not consider this limitation fatal, as there is plenty code out there that doesn't use coroutines - I'd even say, much more code than that does. Thanks for pointing this out.

1 1

Re: [boost] [release] Boost 1.82.0 Release Candidate 1 is available
by Tom Kent 06 Apr '23

06 Apr '23

On Thu, Apr 6, 2023 at 9:25 AM Marshall Clow via Boost < boost(a)lists.boost.org> wrote: > The first release candidates for the 1.82.0 release are now available at: > <https://boostorg.jfrog.io/artifactory/main/release/1.82.0/source/> > > The SHA256 checksums are as follows: > > b6bfc8adc9056bdb01083680b77ecdd7ad4a59a7425a3a42e15a1fe7f6c4f459 > boost_1_82_0_rc1.7z > 891aa0d522f80d79ecf622378961ceec882025d55b8aa85f61847db602056d57 > boost_1_82_0_rc1.zip > bcdf29d00ade098140ef6934849f27273ad655fcb1e172a4f25660ae0f930d33 > boost_1_82_0_rc1.tar.gz > 17d717a04d81e4e23bf0b527bae894f36db72c75976224ddedea9ffddfcd1fbd > boost_1_82_0_rc1.tar.bz2 > > > As always, the release managers would appreciate it if you download the > candidate of your choice and give building it a try. Please report both > success and failure, and anything else that is noteworthy. > > -- The Release managers > Looks good on Windows/Visual Studio. toolset arch compile Link Execute msvc-10.0 32 X X X msvc-10.0 64 X X X msvc-11.0 32 X X X msvc-11.0 64 X X X msvc-12.0 32 X X X msvc-12.0 64 X X X msvc-14.0 32 X X X msvc-14.0 64 X X X msvc-14.1 32 X X X msvc-14.1 64 X X X msvc-14.2 32 X X X msvc-14.2 64 X X X msvc-14.3 32 X X X msvc-14.3 64 X X X Compile means that the b2 command completed without errors Link means that visual studio was able to link a sample executable to a library (libboost_thread-vcXXX-mt[-gd]-1_XX.lib) generated Execute means that the linked program executed without errors. Full build log can be found here: https://gist.github.com/teeks99/77a2334d7cf0f893366a40d8be5eb4e9 Tom

1 0

[scope] scope_fail is unimplementable
by Andrzej Krzemienski 06 Apr '23

06 Apr '23

Hi Everyone, It is my understanding that the reason scope_fail was left to die in the C++ Extensions for Library Fundamentals v3 was that it is not implementable. One cannot detect if the scope is being left due to an exception thrown from within the scope. Observing the number of uncaught exceptions in the constructor and in the destructor will not work, given that we now have coroutines that can be suspended and then resumed in another thread (with a different number of uncaught exceptions), or even in the same thread but at some later point, when the number of uncaught exceptions has changed. The enclosed example illustrates how a scope_fail fails to call the callback when an exception is thrown from a coroutine. It uses Lewis Baker's CppCoro implementation of a generator. The only reliable way to call a callback when the scope is left due to an exception is through using the explicit call to `deactivate()` function. It is more verbose, but reliable. Regards, &rzej;

1 0

Re: [boost] [release] Boost 1.82.0 Release Candidate 1 is available
by Ruben Perez 06 Apr '23

06 Apr '23

I have successfully built the RC in Ubuntu 22.04 and clang-15. I'd like however to flag commit https://github.com/boostorg/asio/commit/19cff007b0e9bf78dad921fe2a390d34589… that was merged into Boost.Asio's master branch on the 5th of April and hasn't gone into this RC as breaking existing code (concretely, this prevents some Boost.MySQL examples from compiling). It was caught by chance by a CI run. If this commit gets merged into any subsequent 1.82 RC, Boost.MySQL (and potentially other user code) will contain flaws. This commit breaks the following code: // Token declaration constexpr auto token = asio::as_tuple(asio::use_awaitable); // In a C++20 coroutine co_await socket.async_read(buffer, token); I don't know if this was meant to be legal or not, but used to build and run fine until yesterday. I can provide a fix if this commit gets merged into any subsequent RC, but other client code may get affected. Regards, Ruben. On Thu, 6 Apr 2023 at 16:54, Marshall Clow via Boost <boost(a)lists.boost.org> wrote: > > On Apr 6, 2023, at 7:25 AM, Marshall Clow via Boost <boost(a)lists.boost.org> wrote: > > > > The first release candidates for the 1.82.0 release are now available at: > > <https://boostorg.jfrog.io/artifactory/main/release/1.82.0/source/> > > > > The SHA256 checksums are as follows: > > > > b6bfc8adc9056bdb01083680b77ecdd7ad4a59a7425a3a42e15a1fe7f6c4f459 boost_1_82_0_rc1.7z > > 891aa0d522f80d79ecf622378961ceec882025d55b8aa85f61847db602056d57 boost_1_82_0_rc1.zip > > bcdf29d00ade098140ef6934849f27273ad655fcb1e172a4f25660ae0f930d33 boost_1_82_0_rc1.tar.gz > > 17d717a04d81e4e23bf0b527bae894f36db72c75976224ddedea9ffddfcd1fbd boost_1_82_0_rc1.tar.bz2 > > > > > > As always, the release managers would appreciate it if you download the > > candidate of your choice and give building it a try. Please report both > > success and failure, and anything else that is noteworthy. > > > I have successfully built the libraries in Mac OS 12.6.4, > with "Apple clang version 14.0.0 (clang-1400.0.29.202)” > and C++ 03/11/14/17/20/2b, on both x86 and ARM. > > — Marshall > > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Re: [boost] [release] Boost 1.82.0 Release Candidate 1 is available
by Marshall Clow 06 Apr '23

06 Apr '23

On Apr 6, 2023, at 7:25 AM, Marshall Clow via Boost <boost(a)lists.boost.org> wrote: > > The first release candidates for the 1.82.0 release are now available at: > <https://boostorg.jfrog.io/artifactory/main/release/1.82.0/source/> > > The SHA256 checksums are as follows: > > b6bfc8adc9056bdb01083680b77ecdd7ad4a59a7425a3a42e15a1fe7f6c4f459 boost_1_82_0_rc1.7z > 891aa0d522f80d79ecf622378961ceec882025d55b8aa85f61847db602056d57 boost_1_82_0_rc1.zip > bcdf29d00ade098140ef6934849f27273ad655fcb1e172a4f25660ae0f930d33 boost_1_82_0_rc1.tar.gz > 17d717a04d81e4e23bf0b527bae894f36db72c75976224ddedea9ffddfcd1fbd boost_1_82_0_rc1.tar.bz2 > > > As always, the release managers would appreciate it if you download the > candidate of your choice and give building it a try. Please report both > success and failure, and anything else that is noteworthy. I have successfully built the libraries in Mac OS 12.6.4, with "Apple clang version 14.0.0 (clang-1400.0.29.202)” and C++ 03/11/14/17/20/2b, on both x86 and ARM. — Marshall

1 0

[release] Boost 1.82.0 Release Candidate 1 is available
by Marshall Clow 06 Apr '23

06 Apr '23

The first release candidates for the 1.82.0 release are now available at: <https://boostorg.jfrog.io/artifactory/main/release/1.82.0/source/> The SHA256 checksums are as follows: b6bfc8adc9056bdb01083680b77ecdd7ad4a59a7425a3a42e15a1fe7f6c4f459 boost_1_82_0_rc1.7z 891aa0d522f80d79ecf622378961ceec882025d55b8aa85f61847db602056d57 boost_1_82_0_rc1.zip bcdf29d00ade098140ef6934849f27273ad655fcb1e172a4f25660ae0f930d33 boost_1_82_0_rc1.tar.gz 17d717a04d81e4e23bf0b527bae894f36db72c75976224ddedea9ffddfcd1fbd boost_1_82_0_rc1.tar.bz2 As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. -- The Release managers

1 0

[release] Master Branch is closed for all changes
by Marshall Clow 06 Apr '23

06 Apr '23

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

1 0

Re: [boost] I need help with clang libtooling
by Boris 05 Apr '23

05 Apr '23

On 2023-04-05 6:43 PM, Vinnie Falco via Boost wrote: > On Wed, Apr 5, 2023 at 1:00 AM Boris via Boost <boost(a)lists.boost.org> wrote: >> I have some experience, I created https://github.com/scapix-com/scapix >> with clang libtooling. You can ask me directly or in the list. > Can we please set up some kind of screen share / zoom / chat or something? Sure, I will email you directly to set it up.

1 0

Re: [boost] I need help with clang libtooling
by Vinnie Falco 05 Apr '23

05 Apr '23

On Wed, Apr 5, 2023 at 1:00 AM Boris via Boost <boost(a)lists.boost.org> wrote: > I have some experience, I created https://github.com/scapix-com/scapix > with clang libtooling. You can ask me directly or in the list. Can we please set up some kind of screen share / zoom / chat or something? Thanks

1 0

[release] Reminder: The master branch will be closing for the 1.82.0 release TODAY
by Marshall Clow 05 Apr '23

05 Apr '23

… and don’t forget your release notes! — Marshall

1 0

Re: [boost] I need help with clang libtooling
by Boris 05 Apr '23

05 Apr '23

On 2023-04-05 3:09 AM, Vinnie Falco via Boost wrote: > Does anyone know clang libtooling at all who can possibly help me? I > have my program mostly working but there are a few fine details I am > missing... > > Thanks > I have some experience, I created https://github.com/scapix-com/scapix with clang libtooling. You can ask me directly or in the list. Boris.

1 0

I need help with clang libtooling
by Vinnie Falco 05 Apr '23

05 Apr '23

Does anyone know clang libtooling at all who can possibly help me? I have my program mostly working but there are a few fine details I am missing... Thanks -- Regards, Vinnie Follow me on GitHub: https://github.com/vinniefalco

1 0

Re: [boost] [scope] Proposing Boost.Scope
by Andrzej Krzemienski 03 Apr '23

03 Apr '23

śr., 22 mar 2023 o 02:49 Andrey Semashev via Boost <boost(a)lists.boost.org> napisał(a): > Hi, > > I'm proposing a Boost.Scope library for review and potential inclusion > into Boost. > > Boost.Scope is a small library implementing utilities defined in > <experimental/scope> from C++ Extensions for Library Fundamentals v3 > with a few extensions. Namely, the library contains: > > * A number of scope guards for various use cases. > * A unique resource wrapper that automatically frees the resource on > destruction. > * Utilities for wrapping POSIX-like file descriptors in the unique > resource wrapper. > > Compared to <experimental/scope>, some notable extensions are: > > * A new scope_final scope guard, which is a more lightweight alternative > to scope_exit. It is accompanied with the BOOST_SCOPE_FINAL macro that > allows to simplify scope guard declaration syntax. > * Scope guards can be activated/deactivated multiple times. > * Scope guards can be created inactive initially. > * Scope guard factory functions, for compatibility with C++11. > * Support for optional resource traits in unique_resource wrapper, which > improves usage with resources having unallocated values. > * unique_resource supports swapping. > * unique_resource supports dereferencing for any resource types that > support dereferencing, not only pointers. > * More flexible constructors for unique_resource. > > The library requires C++11 at the minimum and will significantly benefit > from C++17. > > Source: > > https://github.com/Lastique/scope > > Docs: > > https://lastique.github.io/scope/libs/scope/doc/html/index.html > > Current state: Feature complete, tested in the CI. > > I'm asking for a review manager and endorsements. > > I'm also looking forward for any pre-review comments. In particular, I'm > interested in community opinion on the following: > > * Is there interest in this library at all? > * Should it be merged with Boost.ScopeExit, which is currently > unmaintained? More on this below. > * Should some/all of the library components be lifted to namespace > boost? Such is the practice with most vocabulary types in Boost, e.g. > boost::atomic, boost::shared_ptr, boost::any, boost::string_view, etc. > Currently, the library defines its names in namespace boost::scope. > * Comments on the resource traits feature are especially welcome. > > Re. Boost.ScopeExit. There is significant functionality overlap with it > in the scope guards department. The docs contain comparison with it. I > believe there is room for both libraries because Boost.ScopeExit > supports C++03 and Boost.Scope provides better syntax and more features, > and both can be useful in their own regards, although I expect > Boost.Scope to be more appealing in newer code bases. However, if the > community decides there's too much overlap, I'm not opposed to merging > the two libraries, although Boost.ScopeExit currently depends on > Boost.Function, Boost.Preprocessor and Boost.TypeOf, which are > unnecessary for Boost.Scope. > Is there a single-header version of this library? So that we could easily test it in the Compiler Explorer? Regards, &rzej;

2 1

Re: [boost] Master branch is now open for bug fixes
by Marshall Clow 03 Apr '23

03 Apr '23

On Apr 3, 2023, at 2:38 AM, Andrey Semashev via Boost <boost(a)lists.boost.org> wrote: > > On 4/1/23 14:06, Andrey Semashev wrote: >> On 3/16/23 18:38, Marshall Clow via Boost wrote: >>> The master branch is now open for bug fixes and documentation changes. >>> Other changes by release manager permission, as described in >>> https://github.com/boostorg/wiki/wiki/Releases%3A-Beta-Merge-Policy <https://github.com/boostorg/wiki/wiki/Releases%3A-Beta-Merge-Policy> >>> >>> The next deadline: On April 5th, master closes for all changes. >>> >>> As always, the calendar is at https://www.boost.org/development/ <https://www.boost.org/development/> >> >> I would like to merge the following commit to Boost.Filesystem master: >> >> https://github.com/boostorg/filesystem/commit/1db4474d1ae7512af06f63156352f… >> >> It works around a problem on Windows caused by incorrect reporting of >> file attributes for directories in SMBv1 shares. > > Ping? Go ahead — Marshall

1 0

Re: [boost] Master branch is now open for bug fixes
by Andrey Semashev 03 Apr '23

03 Apr '23

On 3/16/23 18:38, Marshall Clow via Boost wrote: > The master branch is now open for bug fixes and documentation changes. > Other changes by release manager permission, as described in > https://github.com/boostorg/wiki/wiki/Releases%3A-Beta-Merge-Policy <https://github.com/boostorg/wiki/wiki/Releases%3A-Beta-Merge-Policy> > > The next deadline: On April 5th, master closes for all changes. > > As always, the calendar is at https://www.boost.org/development/ <https://www.boost.org/development/> I would like to merge the following commit to Boost.Filesystem master: https://github.com/boostorg/filesystem/commit/1db4474d1ae7512af06f63156352f… It works around a problem on Windows caused by incorrect reporting of file attributes for directories in SMBv1 shares.

1 1

Re: [boost] Master branch is now open for bug fixes
by Marshall Clow 03 Apr '23

03 Apr '23

On Apr 2, 2023, at 12:43 PM, Дмитрий Архипов via Boost <boost(a)lists.boost.org> wrote: > > I would like to merge the following commits to Boost.JSON master: > > Updated documentaion: > https://github.com/boostorg/json/commit/ee01580cfde818e31d8ea41c2e4056bcff9… > 1.82.0 release notes > https://github.com/boostorg/json/commit/94c5d74710ee68301a524e3bc0ed50ec7bd… > document string SBO > https://github.com/boostorg/json/commit/33088c958a635db87299e9c26db12c3c689… > example of using string::grow > https://github.com/boostorg/json/commit/aa77d906396394177b1b34620bd47d9763e… > provide example of parsing several values from several buffers > https://github.com/boostorg/json/commit/32e1d52cdd3f30266a29b99bd4ef456e8a7… > document supported JSON > https://github.com/boostorg/json/commit/4a7a2034d9a5c3d2f3798a5b352e7946504… > fix overview sectioning > https://github.com/boostorg/json/commit/b6a6c83dc740700d74a2f1a38a44c1cb9f1… > document potential linking requirements > https://github.com/boostorg/json/commit/7cf7f107f6913dd3ae61428c7314a19c459… > mention RFC in overview and README > https://github.com/boostorg/json/commit/87b97a09903b37673b2ceb2ae3a2b6ff031… > a JSON to a JSON text You don’t need permission for documentation fixes. > https://github.com/boostorg/json/commit/274901f3488e6ed7cf180f9167dccb22118… > fix template parameter docs for make_shared_resource This is fine. > https://github.com/boostorg/json/commit/89bc551d8214b6c32fa6d161f13e3aaad84… > clarify what default memory resource is > https://github.com/boostorg/json/commit/d7b0580befd3d7fe8ee0b093b96edbfb259… > mention how to disable autolinking These are doc fixes - no permission necessary. > > Bug fix: > https://github.com/boostorg/json/commit/9b06d4a4107f7df58a516987474705fef88… > fix suspend inside escape This is fine. > > Silencing a warning: > https://github.com/boostorg/json/commit/d79336bbb7cb49e396db37c8547daca1e61… > Fix -Wdeprecated-declarations for sprintf This is fine. — Marshall > > > > чт, 16 мар. 2023 г. в 18:38, Marshall Clow via Boost <boost(a)lists.boost.org >> : > >> The master branch is now open for bug fixes and documentation changes. >> Other changes by release manager permission, as described in >> >> https://github.com/boostorg/wiki/wiki/Releases%3A-Beta-Merge-Policy < >> https://github.com/boostorg/wiki/wiki/Releases%3A-Beta-Merge-Policy> >> >> The next deadline: On April 5th, master closes for all changes. >> >> As always, the calendar is at https://www.boost.org/development/ < >> https://www.boost.org/development/> >> >> — Marshall >> >> >> _______________________________________________ >> Unsubscribe & other changes: >> http://lists.boost.org/mailman/listinfo.cgi/boost >> > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Re: [boost] Master branch is now open for bug fixes
by Дмитрий Архипов 02 Apr '23

02 Apr '23

1 0

Reminder: Release Notes
by Marshall Clow 30 Mar '23

30 Mar '23

If you’ve been meaning to write release notes for your library for the 1.82.0 release, now is the time to do it. ;-) — Marshall

1 0

Re: [boost] Master branch is now open for bug fixes
by Ruben Perez 30 Mar '23

30 Mar '23

On Thu, 16 Mar 2023 at 16:38, Marshall Clow via Boost <boost(a)lists.boost.org> wrote: > > The master branch is now open for bug fixes and documentation changes. I'd like to merge a UB fix to master for Boost.MySQL. It affects only debug builds. Not critical, but may hit some platforms. Discovered during development of new code. https://github.com/boostorg/mysql/pull/136 Thanks, Ruben.

2 1

Re: [boost] Master branch is now open for bug fixes
by Mojca Miklavec 30 Mar '23

30 Mar '23

On Thu, 16 Mar 2023 at 16:38, Marshall Clow via Boost <boost(a)lists.boost.org> wrote: > > The master branch is now open for bug fixes and documentation changes. > Other changes by release manager permission, as described in > https://github.com/boostorg/wiki/wiki/Releases%3A-Beta-Merge-Policy <https://github.com/boostorg/wiki/wiki/Releases%3A-Beta-Merge-Policy> I would be really grateful if the following patch (or an alternative resolution for the reported warning/error) could be included in the final release: https://github.com/boostorg/thread/pull/382 (The only other warning we get in our project is https://github.com/boostorg/container/issues/234, but I'm not sure if one is allowed to modify dlmalloc_ext_2_8_6.c.) Quite some other warnings that we've been running into in 1.80 have disappeared in the meantime: thank you very much for that. Thank you very much, Mojca

1 0

Re: [boost] boost-1.82.0.beta1 tag looks wrong
by Marshall Clow 30 Mar '23

30 Mar '23

On Mar 29, 2023, at 8:57 AM, Peter Dimov via Boost <boost(a)lists.boost.org> wrote: > > commit ee18548b1eb68a592d0980611b5f96216ee71a2d (tag: boost-1.82.0.beta1) > Author: Automated Commit <automated(a)calamity.org.uk> > Date: Thu Mar 9 00:00:15 2023 +0000 > > Update multiprecision from develop > > Looks like the boost-1.82.0.beta1 tag points to develop rather than master. I think you’re right. The tag on the super project points to develop, and the one(s) on the sub-project all point to master. — Marshall

1 0