August 2024 - Boost - lists.preview.boost.org

Alumni Program
by Vinnie Falco 09 Aug '24

09 Aug '24

All: I've been engaged more with long-time members of the Boost community, and something which I now realize is the extraordinary level of camaraderie and brotherhood which sprang from the early years of Boost evolution. Boost was a family and like all families, it has changed. People left, new people joined, priorities shifted, and such. Contribution to the libraries is something special, so I would like to introduce an idea. The "Boost Alumni Program." Like a college alumni program this is designed to help Boost contributors stay in touch over the years. There could be a mailing list, and a program administrator who is tasked to keep track of everyone, including their email and phone number. They can keep contact and track changes in careers, new projects, and so on. The goal here is to help maintain the relationships of contributors over time, even when they have moved on from the project for various reasons such as a new job or new life circumstances. I don't know all the details, but would anyone find value in such a program? Would anyone want to participate? Would anyone be against this? Thanks

3 2

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

[release] Master branch is closed for ALL changes
by Marshall Clow 08 Aug '24

08 Aug '24

Please do not commit anything to the master branch. Other branches are always fine. The 1.86.0 release is scheduled for next Wednesday, 15-Aug. — Marshall

2 1

How to use the O(1) remove_edge(typename Config::out_edge_iterator iter)
by hermann＠stamm-wilbrandt.de 08 Aug '24

08 Aug '24

I looked at runtime statements here: https://www.boost.org/doc/libs/1_85_0/libs/graph/doc/using_adjacency_list.h… Fore remove_edge() there is no O(1) option listed. On the other hand in Boost graph code I see this O(1) remove_edge() in boost/graph/detail/adjacency_list.hpp: template < class Config > struct directed_edges_helper { ... // O(1) inline void remove_edge(typename Config::out_edge_iterator iter) { std::cerr << "foobar" << std::endl; typedef typename Config::graph_type graph_type; graph_type& g = static_cast< graph_type& >(*this); typename Config::edge_descriptor e = *iter; typename Config::OutEdgeList& el = g.out_edge_list(source(e, g)); el.erase(iter.base()); } }; So my questions is for which graph and how I can make use of that O(1) function to remove an edge. It seems to be for directed graph only. While I need it for undirected graph, being able to use that O(1) function for directed graph would be a first step. Regards, Hermann Stamm-Wilbrandt.

1 2

GPU Library Utilities
by Matt Borland 07 Aug '24

07 Aug '24

By popular demand Boost.Math has begun adding support for CUDA (NVCC and NVRTC) and SYCL. Unfortunately to use all of these platforms you can not really use std:: as CUDA has utilities (e.g. <type_traits>) in cuda::std::, containers (e.g. tuple) in thrust:: and mathematical functions in the global namespace. There are also completely missing features like <limits>. To work with this we have started creating new headers that implement these features and workarounds such as: 1) limits: https://github.com/boostorg/math/blob/develop/include/boost/math/tools/nume… 2) Tuple: https://github.com/boostorg/math/blob/develop/include/boost/math/tools/tupl… 3) General configuration: https://github.com/boostorg/math/blob/develop/include/boost/math/tools/conf… Now in the code base for example instead of using std::pair you use boost::math::pair which aliases to either thrust::pair or std::pair depending on context. As we continue to build out this support we know we are going to create more headers for compatibility, and feature completeness. I thought these could be useful to other libraries so I asked John Maddock about adding copies of them to Boost.Config. He said that's not an unreasonable home for them, but I should consult the ML. My questions then are: 1) Would these utilities be useful to you? 2) If yes, do you think that Boost.Config is the right home for them? I posted a similar question on Slack yesterday and Joaquin suggested Boost.Compute. I don't think that's the right fit because these would be out of scope, the library is extremely heavy, and it's been over 5 years since the last commit from a maintainer. I would also rather not propose and go through review on a Boost.GPU_Utils, but with sufficient demand it could be worth the effort. Please let us know what you think, and thanks for your time. Matt

4 5

Issues (and possible fix) with Bimap
by Ignacy Gawedzki 06 Aug '24

06 Aug '24

Hi, I've run into issues with code using Bimap and GCC optimizations. The description has been submitted both as a bug report to GCC (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115767) and as an issue in Boost Bimap (https://github.com/boostorg/bimap/issues/43) While trying to reduce the Bimap code to find a minimal example, I've found what looks like a proper bug in Bimap and have created a pull request (https://github.com/boostorg/bimap/pull/45) It's now been two weeks and the PR is still awaiting approval, so I thought maybe I better write about it here as well. I suspect the issues might come from both a bug in GCC optimizations and from Bimap, because they seem to be gone when I compile with the latest GCC (which received some optimization-related patches lately) and the patched Bimap, both on aarch64 and x86_64, but I can't tell for sure. Cheers, Ignacy

2 1

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

[release] Reminder: Master Branch closes for all changes this WEDNESDAY August 7th
by Marshall Clow 05 Aug '24

05 Aug '24

For the 1.86.0 release. The calendar is here: https://www.boost.org/development/index.html — Marshall P.S. If you have change notes, don’t forget to add them to the website.

1 0

Re: [boost] A Follow Up to My Original Note Re The Future of, Boost
by John Phillips 03 Aug '24

03 Aug '24

On Thur, Aug 1, 2024 at 6:37?AM Vinnie Falco via Boost < boost(a)lists.boost.org> wrote: On Wed, Jul 31, 2024 at 1:52?PM Kristen Shaker via Boost < boost(a)lists.boost.org> wrote: > ...let the developers make a decision on how they would like to proceed Thank you, and this is very much in the Boost tradition. While the Boost Software License is likely to be the project's most impactful contribution, the Formal Review Process is a close second. Therefore, I propose that the question of custodianship be decided by a formal review. It is becoming more and more difficult to find suitable review managers who are not associated with the C++ Alliance (a self-inflicted wound, I suppose) but I nominate these as candidates: Ion Gaztanaga John Maddock Thanks ------------------------------------------------------------------------------------ I understand the desire to use something like the review process for this, but I think we need to be cautious about the differences between a software review and what we need in this case. Not that there is no way to do something similar to a review, but just to make sure we understand what the review process is good at and not good at. The intent of the review process is to let interested developers share ideas and expertise to find the best technical solution. The proposed library is the focus of the discussion but in some cases the conversation can range far from the proposal. The allowed outcomes include fully accepting the proposal, provisional acceptance with stipulations, or rejecting the proposal with constructive commentary about how it could be improved to have a more positive reception. All the participants on this list know this, but consider how the review process compares to what is needed in this conversation. We're trying to solve organizational and legal issues, instead of implementation and documentation issues. We want to decide what path would best allow us to proceed with our core tasks of producing high quality, real world usable libraries for inclusion in a broad spectrum of software uses, leading to refinement of implementation and interface so we can have a solid proposal for inclusion into the C++ standard. What organization would give the work we do the needed visibility so developers and companies around the world want to try the Boost libraries? What leadership would give our developers sufficient insight into the needs of C++ developers at large required to provide for those needs? What what resources will allow us to solve the technical and legal issues in our structure and infrastructure that we need to continue to mature and grow effectively? These aren't questions I personally have the technical and organizational expertise to judge well. Nor are they questions that someone could provide a sample implementation for during a review to illustrate a potential pitfall. They are however questions where some members have a strong personal stake and contention could cause lasting and damaging rifts between the volunteers that are the heart and soul of Boost. It is also true that reviews tend to have just the three outcomes listed above, while this process could come to conclusions no one has even thought of to mention, yet. I also think that to be useful it will need extensive involvement from as many Boost participants as possible. You can have a good technical review of a library that is dominated by half a dozen experts in the problem and techniques to address it. This review will need input from half or more of the Boost community to produce the broad buy in that such organizational decisions should get. This is again not to say it can't be done. I am only trying to make sure that we understand the possible ways a review of this sort will be far different from the normal reviews we perform. John Phillips Review Wizard

1 0