- Boost - lists.boost.org

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 01 May '23

01 May '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 01 May '23

01 May '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 01 May '23

01 May '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