- Boost - lists.preview.boost.org

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