July 2024 - Boost - lists.stage.boost.cppalliance.org

Two mqtt libraries
by Robert Ramey 03 Oct '24

03 Oct '24

I've been contacted by my friend and sometime collaborator Takatoshi Kondo regarding his submission of a boost library: https://github.com/redboltz/async_mqtt. It has received two endorsements. He has asked me to be review manager and I'm inclined to accept this request as he was very helpful to me during the refinement of the boost serialization library. There is also mqtt client library that is proposed to the Boost. https://github.com/mireo/async-mqtt5 It also has endorsements and a review manager. A cursory examination of the git hub pages suggest considerable overlap between the two submissions. In general, boost has discouraged the acceptance of multiple libraries with this much overlap - and for good reason. An accepted library often becomes the canonical implementation in large parts of the C++ world. Having two high quality libraries that do almost the same thing is not where we would like to be. I would like to propose that we review both libraries simultaneously in order to try to reach a consensus as to which, if either we want to accept. I know this is a difficult task, but I think it is important that we do this. It's going to be tough to reject a well written library because a better one has been accepted. But it would be worse to reject a well written library merely because another one was submitted first. Normally I don't participate as a review manager as I'm pretty bogged down in Boost stuff as it is. But I'm willing to make an exception in this case due to the importance of this case and my strong personal ties to Takatoshi. BTW - who is the review wizard these days? I presume that he will be the one making the decision about this. Robert Ramey

10 17

Re: [boost] [compute] Maintenance status
by René Eng 18 Aug '24

18 Aug '24

Hi all I am no expert in OpenCL nor GPGPU, but very interested in this topic and would love to learn more about it. I volunteer to take care of the maintenance of this library. Since I have no experience with the Boost way of handling PRs etc., I guess would need some support from an experienced library maintainer in the beginning. Until now I was a silent reader here, so let me shortly introduce myself: My name is René Eng, 57 years old, living in Switzerland. I am working as a C++ developer for more than 20 years, in the high performance/low latency area. I have experience with some other Boost sub-libraries, in the past also used b2 to build Boost when there were no packages available yet. If there is no-one else with more experience in this topic, who wants to take over this library, I would. This week I am on holiday, so I would actually start to take a closer look into it next week. Best regards René Von meinem iPhone gesendet > Am 21.07.2024 um 17:04 schrieb Joaquin M López Muñoz via Boost <boost(a)lists.boost.org>: > It was brought to my attention that Boost.Compute seems to be all but abandoned: > no updates in three years, more than 100 issues filed, 27 unattended PRs. This is a > shame given that the library looks pretty popular based on GH stars and references > on Internet. Are there volunteers to take on maintenance of the library? > > Best, > > Joaquin M Lopez Munoz > > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 2

[Boost][BGL] new planar_vertex_coloring.hpp ?
by hermann＠stamm-wilbrandt.de 15 Aug '24

15 Aug '24

I have some experience in using BGL and porting my non-BGL graph code to BGL. I want to create pull request for generating random maximal planar graphs. I have 1994 technical report non-BGL implementation on gihub. So before porting that, I want to get some experience on the Boost pull request and review process. I made use of the many planar graph algorithms in straight_line_graphviz.cpp gist: https://gist.github.com/Hermann-SW/99d151a273d290ee0d843c79b2da26a8 So I thought on a providing planar graph vertex coloring algorthm(s) as handson. I would start by taking https://www.boost.org/doc/libs/1_85_0/libs/graph/doc/sequential_vertex_colo… as a template for "planar_vertex_coloring.hpp". My plan is to first port my existing fast linear time "six_coloring()" https://github.com/Hermann-SW/planar_graph_playground/blob/main/c%2B%2B/und… and learn about the review process with it. Later I would implement one of the several linear time "five_coloring()" algorithms: https://en.wikipedia.org/wiki/Five_color_theorem#Linear_time_five-coloring_… And probably the quadratic time "four_coloring()" algorithm mentioned there as well. I looked at commits in Boost graph directory and there is not that much recent activity. Is my plan and the steps outlined the right way to start? Regards, Hermann Stamm-Wilbrandt.

1 3

CMake Announcement from Boost Steering Committee
by Jon Kalb 13 Aug '24

13 Aug '24

The libraries produced by the Boost community have had a greater impact on the way that the C++ community writes code than any other library implementation. The focus of the Boost community will always be on the libraries, but it is undeniable that we are dependent on and often limited by the infrastructure of our trade. Years ago, the move to Git was contentious; yet, it was required to improve development. In a similar vein our build system has become an impediment for many developers and users, existing and prospective. Therefore, we, the Steering Committee, announce to the Boost community our desire and intent to move Boost’s build system to CMake for users and developers alike. We are soliciting comments and proposals from the community to guide the process and the goals. Our desire is that the community can come to consensus by the end of the calendar year with a vision of supporting users and developers. We understand that the actual process of achieving the end goal will be long, time consuming, and not without its share of conflict. We also recognize that the Boost community is comprised of bright and passionate individuals that are eager to get involved and help get work done. The members of the Steering Committee have been encouraged by the discussions and activity surrounding CMake on the mailing lists over the years and know that many people have voiced visions. We hope that each of you rejoins the discussion to support this initiative and contributes to the common goal of improving Boost’s integration into the broader C++ ecosystem. For the Boost Steering Committee, Jon Kalb, Chair jonkalb(a)boost.org

49 199

[config] First steps towards C++20 modules
by Antony Polukhin 12 Aug '24

12 Aug '24

Hi, C++20 modules seem to be a good tool to improve compile times and to hide the implementation details of the libraries. I've been looking throught the sources of {fmt} library. Looks like the fmt library approach to C++20 modularization seems to fit Boost quite well. How about adding the following macro to Boost: * BOOST_BEGIN_MODULE_EXPORT - starts the scope of things to export if Boost is build as a C++20 module * BOOST_END_MODULE_EXPORT - ends the scope of things to export if Boost is build as a C++20 module * BOOST_MODULE_EXPORT - for a single entity export if Boost is build as a C++20 module As a result, if Boost is build as a module the above macros are defined in the following way: #define BOOST_MODULE_EXPORT export #define BOOST_BEGIN_MODULE_EXPORT export { #define BOOST_END_MODULE_EXPORT } Helper macro BOOST_NO_CXX23_IMPORT_STD for detecting availability of `import std` also seems useful. Macro BOOST_NO_CXX20_MODULES - for notifying the libraries that compiler does not support modules or Boost modules are not compiled. With all the above macros the Boost libraries could look like: /// header #include <boost/library_that_is_known_to_not_support_modules.hpp> #ifdef BOOST_NO_CXX20_MODULES #include <boost/library_that_supports_modules.hpp> #else import Boost.LibraryThatSupportsModules; #endif #ifdef BOOST_NO_CXX23_IMPORT_STD #include <iostream> #else import std; #endif namespace boost { namespace detail { template <class T> bool try_do(const T&); } BOOST_BEGIN_MODULE_EXPORT template <class T, class From> bool try_lexiacal_convert(const From& f, T& to) { /*impl*/ } template <class T, class From> T lexiacal_cast(const From& f) { /*impl*/ } BOOST_END_MODULE_EXPORT } /// module src file export module Boost.MyLibraryName; #ifdef BOOST_NO_CXX20_MODULES #error ??? #endif #include <boost/my_library.hpp> -- Best regards, Antony Polukhin

5 14

Boost Governance?
by René Ferdinand Rivera Morell 09 Aug '24

09 Aug '24

A disclaimer: I write this solely as a Boost Library author. And not in any other capacity or representing any other interest. It's now been at least a year since Boost switched from the Software Freedom Conservancy to the Boost Foundation for its governance organization. But have people noticed any difference? Did you know that switch happened? Did you know that they held an election for the Board of Directors and for the Officers? Do you know when that election happened? Do you know who got elected? Do you know how they were selected? Do you know what their responsibilities are? Do you know what their bylaws are? Do you know their financials? More importantly: Did you answer "no" to any of those questions? As a library author, I can say I definitely answered no to many of those questions. This is a problem. As authors, without asking, we should know those answers from the organization that governs our work. We should have input into how that organization governs. In other words, we deserve open and transparent governance; not the closed and opaque status quo. -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supone Nada -- Robot Dreams - http://robot-dreams.net

10 9

New Logo Discussion
by Vinnie Falco 09 Aug '24

09 Aug '24

Hi. It is CppCon 2024 season, and the C++ Alliance is working on letting people know all the new and exciting things happening in Boost. We're doing this with Boost labeled conference shirts, and a beautiful brochure. You can see a draft of this promotional piece here (note: work in progress): https://cppalliance.org/pdf/Boost-Brochure-CppCon-2024.pdf The new Boost logo was developed by the Alliance, and a community consensus is needed if we are to fully move forward with its use. I am hoping this will spark the necessary discussion. Here are things to consider: * The logo is professionally designed by https://grainandmortar.com/ at a cost of $12,000 * Peter Dimov likes the image (this should not be construed as his endorsement or opposition to any of the above). * The image is a trademark of The C++ Alliance: https://tsdr.uspto.gov/#caseNumber=98417319&caseSearchType=US_APPLICATION&c… * Usage of the logo is governed by our Logo Usage Policy, a product of legal review at a cost of $4,000: https://www.boost.io/doc/contributor-guide/docs/logo-policy-media-guide.html * The Logo Usage Policy allows free usage without permission in Boost-related contexts. Otherwise, explicit written permission from the Alliance is required. * Trademark ownership by a registered entity with sufficient resources is necessary to protect the mark, which David Sankel alludes to here: https://lists.boost.org/Archives/boost//2024/03/256092.php * Adopting this logo costs Boost nothing. If our proposed arrangement stops working for the community, the libraries can easily adopt a different logo (including the old one, or none). Put simply, I am asking the Boost community to entrust The C++ Alliance.with the responsibility of establishing and maintaining this new Boost logo. Thanks :)

18 63

Paul Bristow
by John Maddock 08 Aug '24

08 Aug '24

I've just heard that Paul Bristow who helped so much with the development of Boost.Math and indeed many other libraries, passed away peacefully last week. RIP Paul. Much missed. John.

6 5

[outcome] Inline GDB pretty printing support
by Niall Douglas 08 Aug '24

08 Aug '24

Dear Boost, The biggest new feature to land into Outcome since it went ABI stable is inline GDB pretty printing support, whereby we embed into all binaries using Outcome the Python script to display the state of `result<>/outcome<>`. As Outcome uses a layered inheritance technique to match triviality of member functions from its configured types, having to click down through the layers to discover the state was always frustrating. MSVC has long shipped with a visualiser to eliminate this, so now support for GDB matches MSVC support. The relevant implementation file can be found at: https://github.com/boostorg/outcome/blob/master/include/boost/outcome/outco… I would appreciate any testing and reporting of any issues or bugs before the 1.86 bugfix window closes. It should "just work" once you have enabled inline script loading in your `.gdbinit`. Thanks, Niall

10 19

A Follow Up to My Original Note Re The Future of Boost
by Kristen Shaker 06 Aug '24

06 Aug '24

Hello Everyone, Thank you for patiently waiting while we had the opportunity to discuss things. Many of you have not heard my name before - this is largely because as a board, we do much of the non - dev work behind the scenes, such as administrative tasks like paying bills. However, I do want to take this opportunity to introduce myself quickly and to emphasize that - should anyone wish to reach out to me directly - I am happy to correspond via phone or email. My name is Kristen - I spent many years at Google on the C++ Core Libraries Team. I am heavily involved as an organizer in CppCon and C++Now. If anyone is curious about what I did at Google, I did give a talk <https://www.youtube.com/watch?v=torqlZnu9Ag> on automated refactoring and Clang Tidies that you can find on Youtube. My duties as Board Chair involve sending out meeting agendas, taking meeting notes, and collating meeting minutes. It is not our role to lead, but rather to support the Boost project. The leadership and direction of the Boost project has and should remain with the Boost Developers. The original Boost Steering Committee home page articulates its purpose as follows: “In the Boost community decisions have always been made by consensus and individual members have shown leadership by stepping forward to do what they felt needed to be done. Boost has not suffered from a lack of leadership or volunteer participation. It is not the role of the Steering Committee to inhibit this kind of spontaneous leadership and action, which has served Boost and the wider C++ community so well. On the contrary, it is the role of the Steering Committee to facilitate community-based leadership and decision making. The role of the Committee is to be able to commit the organization to specific action either where funds are required or where consensus cannot be reached, but a decision must be made.” We generally encourage any Boost Developer who would like to be more involved in administrated or organizational decisions to consider joining the board. We have multiple open board seats. Several Boost Developers are on the board and additional developers have been invited in the past - however they have decided against joining due to their distaste for the type of administrative work we do. We would love to hear more from you. Please reach out. You can reach all of us at once via boostfoundationdirectors(a)boost.org. Additionally, if you’d like to attend one of our board meetings, we regularly host guests. The C++ Alliance and the Boost Board of Directors have had their disagreements. Recently, it has become apparent - in particular via their attempt to purchase the boost.org domain name and the proposed new Boost Logo - that The Alliance would like to exert a greater sense of ownership over Boost Library assets. The desired control over assets is what I was referring to in my original note regarding their attempt to take ownership over the Libraries. While the C++ Alliance is a non profit organization, it is wholly funded and effectively controlled by one individual - Mr. Falco. The Board of Directors has a stewardship responsibility to Boost and we are wary of a single individual exerting such a level of control over the Boost Libraries. The Board has existed for many years and will continue to exist - as new members are regularly on boarded as tenured ones retire. Given the structure of the Board and the nature of the volunteer work, we believe ourselves to be the more permanent entity. Many have mentioned a desire for cool headed coordination between the two organizations. I also believed this to be the most advantageous outcome, so I reached out to Mr. Falco to establish a direct line of communication. Even now I would characterize our personal relationship as quite positive. Due to some pre-existing personality clashes, it is now our understanding that Mr. Falco believes collaboration to be an impossibility. Therefore, a large part of Mr. Falco’s motivation to acquire the domain name stemmed from a desire to cut the Board of Directors out of all future decision making processes. Given that I believed we had made great progress toward greater collaboration, I was personally gutted by this turn of events. Accordingly, we did not see a well lit path forward regarding coordination between the Boost Board and the C++ Alliance. This decision was in no way meant to minimize the great contributions The Alliance has made to the Boost Libraries. We do not want to discourage Alliance members from contributing to Boost. This is fundamentally a question about the stewardship of the Boost Library Assets. As mentioned above, the Boost Board of Directors exists largely to facilitate community based decision making. Accordingly, we feel the most appropriate thing to do at this juncture would be to let the developers make a decision on how they would like to proceed regarding what level of ownership the C++ Alliance should have on Boost Library assets. Here are what we believe to be the available options. 1. The C++ Alliance assumes control of the Boost assets, including the boost.org domain name. The Boost Foundation becomes uninvolved in any decisions related to the Boost Libraries. 2. The Boost Foundation continues to be the stewards of the boost.org domain name and related assets. New assets that are meant to be associated with the Boost Libraries are transferred to the Boost Foundation. In any matters related to the Boost Libraries, the Board will abide by any decisions made by the developers but will no longer vote themselves on issues as they relate to the Boost Libraries unless there truly is no clear consensus or path forward. There was some discussion about the assets being held in a third party non profit controlled by a subset of the Boost Developers. However, given that there are already many Boost Developers on the Boost Foundation Board of Directors, we don’t see this as a meaningful deviation from the status quo. Also as one final note, many on the mailing list expressed a distaste for the political nature of this disagreement. Of course, being involved in political spats is not why you joined Boost! We completely understand this. Believe me when I say we don’t like dealing with political disagreements either - no one does. They’re draining and they can distract from an organization’s larger mission. However, sometimes, they are truly unavoidable. We’re articulating our thought process here, not to annoy you, but so every Boost Developer has a say in how things turn out. Warm Regards, The Boost Board of Directors Also here are some answers to some of the more specific questions. There were a lot of them and I believe some were answered in the preceding paragraph. Sincerest apologies if I missed a question or two. Beman Dawes did pass away in 2020. The Boost Foundation did take action when the domain expired. In fact, Michael Caisse spent many hours on the phone with support figuring out how to pay for the bill so the website would be accessible. Additionally, he invested significant time in procuring the death certificate so we could own the domain. Progress was being made, albeit slowly.

21 41