May 2026 - Boost - lists.boost.org

Fwd: Re: Proposing statsort for Boost.Sort
by Francisco José Tapia 21 May '26

21 May '26

---------- Forwarded message --------- De: Nigel Stewart <nigels.com(a)gmail.com> Date: mié, 20 may 2026 a las 13:14 Subject: Re: [boost] Re: Proposing statsort for Boost.Sort To: Francisco José Tapia <fjtapia(a)gmail.com> Francisco, Thank you so much for saying what needed to be said, and diplomatically. More interesting as a research result perhaps, than for real-world production use. At least so far. - Nigel On Wed, May 20, 2026 at 6:45 PM Francisco José Tapia via Boost <boost(a)lists.boost.org> wrote: > > Hello, > > maybe I didn’t explain myself clearly about how the library works. > > Once you add an algorithm to the library, you can’t remove it later, even > if it’s surpassed by newer algorithms, because there are software programs > and companies that are using it. Hello, Thank you Nigel for your message. Behind my words there is a very clear idea and intention. The results of Peter's algorithm are not good enough to be included in the library. However, his work has my full respect and consideration. Doing something new, breaking new ground where no one has gone before, without knowing clearly whether it leads anywhere, is hard work and, on many occasions, emotionally exhausting. When you are in that situation, even if the result is not what was expected, it is very rewarding to have your effort recognised and valued. That is talent in its purest form. If you take the engineers from the best companies in the world and ask them whether they have done something new, something that has never been done before — whether successful or not — I assure you that very few would remain. That is the kind of talent that is so often talked about and so little understood. Meaningful talent, not nominal talent, nor talent by position or education. At Boost we are a club of geeks, although our manners disguise it and we may come across as conventional people. We have many people whom I sincerely admire for their talent, their vision and their work, and I can assure you that my admiration is not given lightly. We — companies, the world — need people who, like us, like Peter, blaze a trail. The important thing is to keep moving forward. Peter did not succeed on the first attempt; perhaps on the second, something might emerge from his mind that leaves us astonished, and it will be a pleasure to welcome him and other people with new ideas. Looking at him, I see myself, when I joined Boost and proposed a library for creating concurrent sets, multisets, maps and multimaps, allowing multiple threads to work on them concurrently in a safe manner. It was not well received, I suppose due to my clumsiness in presenting it. I ended up in the Sort library, with sorting algorithms that I developed for that library. That is why Peter and people like him matter to me, because they are the hope. For that very reason I am firm in my ideas, but I try to be careful, kind, and to acknowledge the value of that effort. What needs to be done and how to do it I have learned over my more than 30 years of teaching Computer Science. That is all. Yours sincerely, Francisco Tapia fjtapia(a)gmail.com

1 0

Fw: Your message to boost@lists.boost.org awaits moderator approval
by Peter Taraba 20 May '26

20 May '26

1 0

Re: is statsort ready to be part of Boost library?
by Ion Gaztañaga 20 May '26

20 May '26

El 17/05/2026 a las 15:09, Peter Taraba via Boost escribió: > see attachments > cant go further on x axis due to mem limitations on my laptop > Peter > *Sent:* Sunday, May 17, 2026 at 4:36 AM > *From:* "Peter Taraba via Boost" <boost(a)lists.boost.org> > *To:* boost(a)lists.boost.org > *Cc:* "Peter Taraba" <taraba.peter(a)mail.com> > *Subject:* [boost] Re: is statsort ready to be part of Boost library? > i actually lied. spreadsort is slower & uses more memory. sorry about that > Best regards, > Peter Taraba The mailing list has strict rules about attachment (75KB max), so please avoid messages like this, any attachment bigger than this size will be blocked. This message was approved by mistake... I recommend putting your files in some cloud storage/github and point to it from the message. Thanks for your understanding, Ion

1 0

Proposing statsort for Boost.Sort
by Peter Taraba 20 May '26

20 May '26

7 18

is statsort ready to be part of Boost library?
by Peter Taraba 17 May '26

17 May '26

2 3

GitHub reliability
by Vinnie Falco 15 May '26

15 May '26

GitHub has become increasingly unreliable. I suggest the Boost project explore alternatives to be ready in case the need to move to a new hosted provider arises. We (the C++ Alliance) are investigating Codeberg. Regards, Vinnie Follow me on GitHub: https://github.com/vinniefalco

14 33

[Boost.Graph] Survey: minimum C++ standard for Boost.Graph going forward
by Arnaud Becheler 14 May '26

14 May '26

Dear Boost Community, During the Boost Graph Modernization Workshop in Paris co-organized with Jeremy Murphy (BGL principal maintainer), one of the most frequent discussion points was the C++ standard version the Boost Graph Library should require. Some context worth knowing: - Boost.Graph is already C++14 - A lot of API modernization can be done without bumping the minimum. - Some modernization changes would land cleaner on a newer standard - We don't yet have a clear enough picture of our users' constraint space to inform our discussion about a potential baseline bump. For example, it appeared that automotive industry users will be locked in C++17 for a while with MISRA. Consequently we want to ask Boost.Graph users: What's the oldest C++ standard your project needs BGL to keep supporting (i.e. the version past which a bump would break you or force you to pin a version). Answers: C++14 / 17 / 20 / 23. You can answer: - with this simple Github survey: https://github.com/boostorg/graph/discussions/490 - on this reddit poll: https://www.reddit.com/r/cpp/comments/1tc1v6x/comment/olproye/ - or on this thread Also please indicate if you’re a BGL active user or an observer eager to give feedback (both are welcome!) Thank you for your time :D Arnaud

1 0

Fw: Re: Re: GitHub reliability
by Peter Taraba 14 May '26

14 May '26

1 0

Boost.Redis and Corosio
by Ruben Perez 12 May '26

12 May '26

Hi all, You might remember how I had started a prototype on how Boost.Redis would look like if it had a Corosio API some weeks ago. I have been improving the prototype until making it fully functional. You can find it here: Code: https://github.com/boostorg/redis/pull/417 Docs: https://anarthal.github.io/boost-redis-corosio/redis/index.html Marcelo has been performing benchmarks against the Asio API, with pretty good results: client | time ----------------------|-------- boost_redis_asio_co | 1.73 boost_redis_asio_cb | 1.35 boost_redis_corosio | 1.00 The benchmarks live in this repo: https://github.com/mzimbres/redis-cli-comp They measure total CPU time (rather than wall time) because the client is faster than the server, which gets saturated and becomes a bottleneck. Lower is better. Our idea is merging the pull request above to Boost.Redis if Corosio gets into Boost. This would make Boost.Redis support both Capy and Corosio. Because most of our code is written as state machines, the amount of duplication is pretty minimal. If interested readers find the time to have a look at the PR and leave some comments, I'd be thankful. On the other hand, I've also been writing a Corosio-based MySQL library. It is a fork of Boost.MySQL: https://github.com/anarthal/mycosql. It is functional, but still a work in progress. Why fork here instead of adding a new API to the library? Because the original Boost.MySQL is an older library (C++11), and forking would allow it to move to C++20 and update part of the API. But it also means more duplication. If things go well, I may propose it for Boost inclusion at some point. Kind regards, Ruben.

1 0

statsort
by Peter Taraba 09 May '26

09 May '26

1 0