- Boost - lists.preview.boost.org

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

10 May '23

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

2 1

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

10 May '23

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

1 0

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

10 May '23

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

1 0

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

10 May '23

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

1 0

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

10 May '23

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

2 1

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

10 May '23

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

1 0

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

10 May '23

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

1 0

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

10 May '23

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

2 1

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

09 May '23

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

1 0

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

09 May '23

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

1 0

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

09 May '23

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

1 0

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

09 May '23

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

1 0

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

09 May '23

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

1 0

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

09 May '23

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

1 0

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

09 May '23

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

1 0

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

09 May '23

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

1 0

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

08 May '23

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

1 0

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

08 May '23

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

1 0

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

08 May '23

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

1 0

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

08 May '23

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

1 0

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

08 May '23

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

1 0

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

08 May '23

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

1 0

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

08 May '23

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

1 0

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

08 May '23

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

1 0

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

08 May '23

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

1 0