- Boost - lists.boost.org

CODE_OF_CONDUCT.adoc
by Vinnie Falco 23 Sep '24

23 Sep '24

The subject of a code of conduct has come up a few times, and I think it is worth having a discussion. I hope that everyone will find the following statements uncontroversial: 1. Social spaces have rules, either stated or implied 2. Rules need to state clearly what is allowed and what is disallowed, so that people who may be interested in joining can determine if the culture is the right fit. 3. Rules need to be enforced 4. The Boost mailing lists already have rules 5. The rules for the mailing list are outdated 6. The rules for the mailing list are not particularly visible There is value in refreshing the rules for the Boost mailing list, which are currently described here: https://www.boost.org/community/policy.html I think we should do the following: * Update the rules to be relevant for 2024 * Make the rules visible on the sign-up and administration page for the mailing lists (at https://lists.boost.org) * Consider renaming the rules to something other than "Boost Discussion Policy" * Send a periodic announcement to the mailing lists reminding everyone of the rules. These could be timed to coincide with the releases (three times per year) The community needs to discuss the things above and come to a consensus. And we need to make a final decision on what the changes will look like given the feedback. I don't know that the review process is right for this, because it will likely be an iterative process where we all work on a "shared document" to make edits. The nice thing is that we don't need to wait for the outcome of the Boost Asset Stewardship review to do this, because the content of the website and mailing lists is not controlled by the Boost Foundation, the C++ Alliance, or the proposed Steering Committee. And even before the need to decide which revision of the updated rules will be accepted by the project, discussion can take place with no governing body. There is one hiccup though. Where do we discuss this? The mailing list is one possibility. However, anyone who joins the mailing list late, or is not a member of the mailing list, has the problem that the visibility of the discussion is not very great. They would have to use the archives, and the archives are not very pleasant. One cannot see the entire discussion as a single page. And if someone changes the subject, then new related threads of conversation become more difficult to find. And at the end of the day, our workflow requires GitHub issues to triage and assign work items to staff. Therefore, here is a GitHub issue for this. Everyone can feel free to participate in a discussion there. Alternatively, if you feel that the mailing list is a better place, then reply to this post and have a discussion here. There might be two discussions. Or one. Or none (hopefully not). And when we are done we can compare the pros and cons of GItHub issues versus the mailing list. There could be value here. This is the issue: https://github.com/boostorg/website-v2/issues/1269 What do you think? Thanks

3 4

Asset Stewardship Review
by Adam C Getchell 23 Sep '24

23 Sep '24

I support the C++ Alliance proposal to transfer assets and form a new Steering Committee. I’ve been a downstream user of Boost for more than a decade for my research project, and joined the mailing list to get help on using the project effectively. My initial interactions were to sort out build errors, which were mostly resolved with the adoption of vcpkg (after trying biicode and then Conan) and the work on making Boost compatible with CMake. I have appreciated the C++ Alliance’s sponsorship of tools such as the Slack workspace and CI, and I believe this is necessary to ensure progress. I also learned a lot reading the documentation and code of Louis Dionne’s Boost.Hana and Vinnie Falco’s Boost.Beast. As a side note, my research involves writing low-level simulations of the universe, and unfortunately the various memory errors and other bugs have convinced me to go reluctantly down the path of using Rust to write low-level memory-safe abstractions that I can count on to run for months at a time without segfaults or other issues that compromise the validity of the data. Thus, Circle and the recent Safe C++ proposal are very interesting to me, and if they are ever adopted I might back port them to my current codebase. However, this probably won’t be effective until the libraries I depend on make similar efforts. By then, I will probably have everything I need written in Rust. -- Adam Getchell https://adamgetchell.org <https://adamgetchell.org/>

1 0

Boost.LEAF in Embedded Systems (CppCon)
by Vinnie Falco 23 Sep '24

23 Sep '24

At CppCon 2024 the C++ Alliance sponsored a program to interview conference goers about Boost-related topics. This is the first video in the series: Boost.LEAF in Embedded Systems: Insights from Ex-Google Engineer Khalil Estelle at CppCon https://www.youtube.com/shorts/BksBxnTLltY Enjoy! Thanks

1 0

Boost Asset Stewardship Review begins today (3rd Sept)
by Glen Fernandes 22 Sep '24

22 Sep '24

Dear Boost community, The Boost Asset Stewardship Review begins today, 3rd September and ends on 22nd September. For reference, the review schedule is: https://www.boost.org/community/review_schedule.html The submission which initiated the review is the following proposal from the C++ Alliance: https://cppalliance.org/pdf/Fiscal-Sponsorship-Proposal.pdf It proposes a Fiscal Sponsorship which: 1) is a legal agreement where the C++ Alliance holds assets on behalf of the Boost project. It proposes a newly formed (steering) committee that would be composed of Boost developer community members that would determine how the assets are used. 2) donates the assets that it funds to the Boost project (domains, hosting, etc.) The "Boost developer community" here refers to: - Boost library authors - Boost library contributors - Boost release managers For a high level overview of these terms (which I needed) see the following email with definitions: https://lists.boost.org/Archives/boost/2024/09/257579.php The Boost Foundation asks the Boost developer community to consider the following alternative: https://docs.google.com/document/d/1XFt7Bh71e4_uE0iK4jifhR__P0iG5_c1cDfBsMj… The Boost Foundation proposal presents a path forward where it continues to be the steward the assets in question, but offers a change in how these are managed. The assets here refer to the following: - The boost.org domain - Website hosting - Mailing lists - Downloads storage and CDN - Drone CI Currently, the Boost Foundation owns and pays for the following: - Website hosting - Mailing lists The C++ Alliance pays and manages for the following: - The Drone CI - The CDN for the downloads - The download archive - Technical assistance and support for the Boost release process - Backup domain names (in case boost.org expires) - Hosting and downloads for the new website prototype (boost.io) The boost.org domain is absent from both lists above: The Boost Foundation technically does not own it yet. The domain was owned by Beman and he had the credentials. The Boost Foundation is working with Beman's widow and the Dawes Estate to transfer ownership to it. For reference, see Kristen's email: https://lists.boost.org/Archives/boost/2024/08/257563.php Note that the content of the current boost.org site and the new boost.io website is still the province of the Boost developer community. To be clear, the review is not about deciding governance over Boost C++ library development. That remains in the hands of the Boost developer community. Please send all reviews to the Boost developer mailing list. If you do not want to create an account, you can email me at glenfe -at- boost.org with your review and I will post it to the list for you. Include "Asset Stewardship Review" or "Asset Stewardship" in your email subject. In your review do disclose any affiliation to either the C++ Alliance or Boost Foundation groups. Please state any connection you have to Boost (developer, user, package manager etc.) Thank you, Glen

15 26

Boost Asset Stewardship Review concludes 09/22
by Glen Fernandes 21 Sep '24

21 Sep '24

Everyone, Tomorrow (September 22) is the last day to submit a review. To date there have been no requests for an extension. I have received suggestions for potential reviewers I should reach out to, and I believe only one review is forthcoming. Thank you to everyone who has submitted a review, or has otherwise contributed to the discussion. Glen (I was reminded that there are still answers pending from certain members of the Boost Foundation. I understand that CppCon is ongoing and they might not be able to reply yet).

1 0

Re: [boost] Boost Digest, Vol 7346, Issue 1
by Alfredo Correa 20 Sep '24

20 Sep '24

Hi Seth, On Fri, Sep 20, 2024 at 5:00 AM <boost-request(a)lists.boost.org> wrote: > > Date: Thu, 19 Sep 2024 16:28:28 +0200 > From: Seth <bugs(a)sehe.nl> > > On Thu, Sep 19, 2024, at 1:13 PM, Artyom Beilis via Boost wrote: > > 1. You haven't mentioned even once OpenCV > > [...] > > 4. If you do implement many high performance algorithms this library by > any > > means shouldn't be header only. > > > > What is not clear to me is why should I use one over some existing > solution > > like OpenCV? > > All of the points raised are actually a single one, and seem to > misunderstand the scope of the library? I suppose it should be seen as a > successor to Boost MultiArray, leveraging modern language features and > side-stepping some of the pitfalls. > yes, exactly. You seem to understand exactly what I am talking about. (Also a big fan of your Stackoverflow answers). I just gave a long answer to Artyom's message in the list. > That's not at all useless, and interop examples would be very valuable. > However, not all code needs vectorization (beyond what the compiler will > automatically do). I'm more interested in the relation to > https://en.cppreference.com/w/cpp/container/mdspan - which seems to fill > the same space: building block for flexibly indexed contiguous storage. > >From this section: https://gitlab.com/correaa/boost-multi#substitutability-with-standard-vecto… "Multi-dimensinal arrays can interoperate with C++23's non-owning mdspan. Preliminarily, Multi's subarrays (arrays) can be converted (viewed as) mdspan." https://godbolt.org/z/aWW3vzfPj Also see https://gitlab.com/correaa/boost-multi#appendix-comparison-to-other-array-l… Thank you, Alfredo

1 0

Video on Boost.Cobalt available
by Richard 20 Sep '24

20 Sep '24

Utah C++ Programmers has released a video on the Boost.Cobalt coroutines library: Using Coroutines with Boost.Cobalt <https://www.youtube.com/watch?v=yElSdUqEvME> -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Terminals Wiki <http://terminals-wiki.org> The Computer Graphics Museum <http://ComputerGraphicsMuseum.org> Legalize Adulthood! (my blog) <http://LegalizeAdulthood.wordpress.com>

2 1

Asset Stewardship Review
by Phil Endecott 19 Sep '24

19 Sep '24

I've been a Boost user and subscriber to this mailing list for most of this century, but I'm not a library author. It's tempting to write a long navel-gazing essay about the history of Boost and what it needs to do to remain vital, and then to pretend to forensically study the competing proposals to determine which will give the best result in the longer term. But in this post I'll try to be more honest: isn't this review more like a referendum on whose side we favour in the Vinnie Falco vs. David Sankel clash of personalities? Somehow we've reached a point where "this town ain't big enough for the two of them" and we're being asked to choose who to exile. What do I think about the Boost Foundation? I have always been mystified by why the Foundation, and the Steering Committee before them, have interacted so little with the list. The most extraordinary example of this was that the very establishment of the Foundation was not announced to the developers! Periodic, brief updates on Foundation activities to the mailing list would not have taken much effort could even have resulted in more offers of help. The foundation's present proposal starts by talking about "Transparency"; perhaps they would be more transparent in the future, but that would be a departure from how they have worked in the past. Regarding Vinnie and his C++ Alliance, I've not had a very positive view of them since he posted this back in 2023: "Something which should not surprise anyone is that I despise paying taxes." This statement is repeated in his current proposal. Personally, I'm proud of the tax that my business and I pay as it funds education, health, pensions and other public services that make my community a better place in which to live. In the world I inhabit, this is a mainstream view. It's one thing to despise paying taxes, but I think it's quite another to tell everyone that and assume that they share the same view. When I read that the boost.io domain for the "temporary" website had cost $135,000, my reaction was that you could feed a lot of hungry children with that sort of money. My conclusion is, "a plague on both your houses". I fear that Boost is doomed. This review will result in Vinnie's hostile takeover succeeding, but eventually he'll lose interest - maybe when the "young developers" that he hopes to attract don't materialise, or maybe after another falling-out with someone else. Then the project will sink. I think this is the right time for me to unsubscribe from this list; being here doesn't help me, and my contributions don't seem to help anyone else. I extend my best wishes and thanks to all those whose libraries I have used over the years. Regards, Phil.

6 5

Re: [boost] proposal Multi multidimensional array library
by Artyom Beilis 19 Sep '24

19 Sep '24

Hi, Only now have I noticed this proposal, and here are some of my thoughts. It can be excellent to have something like standard MD arrays like numpy is today for python, but... 1. You haven't mentioned even once OpenCV which today is the de-facto standard for numerical computing in today's C++ world. While it isn't perfect - it actually has similar features in terms of array layout - and what is more important it has a library of high performance algorithms to process the data. You must talk at least about interoperability between cv::Mat and this library 2. While actual ndarry handling is nice, it is basically a tip of an iceberg. You need a decent set of high performance algo combined with it. Looks like there is a basic BLAS but the typical library has way-way more to make it useful. I looked over the code and didn't find include to cblas... Did I miss something? Also I see request to link cblas/openblas or so. I did breef look into implementation and it seems to be lacking of vectorization (use of intrinsics/vector operators) or have I missed? 3. Finally I do want to see comparison with stuff like OpenCV, Eigen and even uBlas (I know it isn't good) 4. If you do implement many high performance algorithms this library by any means shouldn't be header only. What is not clear to me is why should I use one over some existing solution like OpenCV? Artyom On Thu, Apr 27, 2023 at 12:30 AM Alfredo Correa via Boost < boost(a)lists.boost.org> wrote: > Hi all, > > My name is Alfredo. > I would like to propose this library called Multi for inclusion in Boost. > Multi is a container and views library for (dynamic) multidimensional > arrays. > > The library is available here, > https://gitlab.com/correaa/boost-multi. > >

2 1

Boost Asset Stewardship Review begins 09/03 (Updated)
by Glen Fernandes 18 Sep '24

18 Sep '24

Update: The Boost Foundation proposal mentioned in the original announcement has been published. The Boost Foundation proposal is attached to this email: BoostFoundationStewardshipProposal.pdf A link to the above will also be available in the review commencement email that will be posted on September 3rd. For reference, the review schedule is: https://www.boost.org/community/review_schedule.html The C++ Alliance submitted the following proposal: https://cppalliance.org/pdf/Fiscal-Sponsorship-Proposal.pdf The original announcement email included an attachment of the above: https://lists.boost.org/Archives/boost/2024/08/257569.php - Glen

19 47