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

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

Boost Asset Stewardship Review from René
by René Ferdinand Rivera Morell 18 Sep '24

18 Sep '24

== Distractions: Before I get to the meat of the review I need to point out that I will not talk about: if Boost needs a new website, whether Boost needs to be revitalized, if policing communications in Boost is a good idea or not, if Boost is relevant any longer, what build system Boost should use, what documentation system Boost should use, if Boost is attractive, if some other project is the new-old Boost, if Discord is better than email. All of those, and more, are distractions to the key questions that we are deciding on: * Who should manage the assets that sustain the development of Boost Libraries? * Who should decide how those assets are managed? == Disclosure, Present Seeing as the C++ Alliance proposal lists me as one of the initial members of a new Committee I thought I'd include additional biographical background for those that may not be aware of what I've done, and do, both in the foreground and background of programming. In case some are not aware I wear many hats in my life. And some of them intersect with the Boost community. Because of the kind of work that I've traditionally done, and still do, in game development and contracting in that domain I have learned to compartmentalize facets of my life. And how to reorient my thinking to each facet as needed. Below is a very brief exposition of current and past involvement arenas. *Chicago Developer Development NFP* I currently serve as a member of the board of the Chicago Developer Development NFP. This is a non-profit that manages the finances of the Chicago C/C++ User Group. Although the non-profit is very new, the user group has been around for almost as long as Boost. And I've helped manage it for just about as long. *Disbelief LLC* My day job for Disbelief is now at about 9.5 years doing AAA game development consulting. Mainly doing Unreal Engine systems and graphics programming. The one intersection with Boost here is that we happen to use Boost in an internal project. And Boost is used in the internals of Unreal Engine (at one point it had at least 4 different copies of Boost in it at once). *C++ Alliance* I currently serve as a member of the board of the C++ Alliance and hold the position of Secretary. As mentioned in the C++ Alliance proposal my duties include advising on the non-profit operation and alignment of initiatives with the goal of advancing the C++ ecosystem. My experience in Boost and running various nonprofits and for-profit corporations is particularly useful. The C++ Alliance also makes it possible for me to participate in WG21 where much of my time has been spent in C++ tooling and the standardization of tool interop. *Boost C++ Libraries* I currently maintain Predef and B2. I am currently working to make the B2 build support in Boost allow for modular usage. With the hope of making it easier to support package managers and the desire from some users to depend on just the Boost libraries they need. In the past I created the current Boost website, which is the second iteration. I provide advice on the development of the new website. I provide advice on the packaging of Boost for Conan. I maintain the B2 Conan package which is separate from the Boost Conan package. In the past I've also served as Boost Documentation Manager during which I helped maintain Quickbook. I also served as Boost Release Manager during which I automated much of the labor using cloud CI. I also served as Boost Testing Manager during which I tried, but failed, to improve the global test matrix but at least kept it running. And long ago I minimally helped to start BoostCon. *Bincrafters* Bincrafters is a group that got started at the early stages of the Conan package manager. We created many packages for libraries of all sorts. I joined at its foundation to do one main task, to create the first modular set of Boost packages. Although that modular Boost packaged release is no longer available it taught me many lessons that I applied to the current modular B2 building. That effort also provided the conceptual model for the current modular vcpkg Boost packages. Currently the group does minimal support of some existing packages. But otherwise we've ported most of the packages we created to the public Conan Index. Of particular relevance is that we organized using the Open Source Collective as a Fiscal Sponsor (https://opencollective.com/bincrafters) == Disclosure, Past As the past is an indicator of the future I thought it important to also include some of the related organizations I've been part of before now. *Redshift Software* I was President of a software development S-Corp that did all kinds of contracting projects during the 16.5 years it operated. We did everything from tools, games, and web sites. It was during the early days here that our need for a build system for the version control system we developed came from and how I came to find Boost. We went on to use Boost heavily during that time. Which necessitated myself fixing bugs across many of the Boost libraries. This is also where I taught myself how to run a corporation, by reading Illinois corporate law books and IRS rules. *Couchworld Games* I was also President of this game development C-corp (minor note, I was "volunteered" for the position in this one and in Redshift). Even though this corp got created to develop some AAA games, we ended up creating some iPhone puzzle games in C++. Which was a rather hard endeavor given the iPhone ecosystem in the early days. And, yes, we used Boost and B2 in the engines we developed for those games. *BoostPro Computing* BoostPro was a consulting company started by Dave Abrahams to support Boost developers by having clients pay for the technical support of their use of Boost and general development for the clients. Some of that work ended up as new Boost libraries. I worked, as a subcontractor, for 3 years alongside Dave, Eric Neibler, and Joel de Guzman. In summary, I've been involved in most aspects of Boost for more than 22 years. == Executive Committee: When I say "Executive Committee" I'm referring to a group that performs actions on behalf of a group. In this case I'm avoiding the "Steering Committee" term as it appears to have additional connotations because of the past use in Boost. I think it's important that I explain what I think how a group (like an Executive Committee but applies to any group claiming an equivalent role) representing Boost developers should operate. For an Executive Committee it is paramount to gain and maintain the trust of the developers. To achieve that, decisions need to have the support of the developers. Actions by an Executive Committee should not come as a surprise to developers. >From the beginning of my interactions in Boost I learned one key fact.. Progress got made by those that acted and obtained buy-in from the Boost developer community. Of the various achievements Boost created early on, the one that made it possible to get such buy-in, has been the community review process. It is a bottom up process that is designed to remove doubt from the ethos of Boost. It is the community review process that we are using now to clarify how Boost moves forward, and hopefully upward. It should be the process that we follow for Boost developers to make decisions about the assets that sustain Boost development. And it should be the results of such a process that the group representing Boost developers accept as binding to make further decisions. I am hopeful that the machinations we are currently following will become the norm. Some have mentioned concerns about conflicts of interest in our governance moving forward. Irrespective of my current inclusion in the proposed composition of the Committee by the Alliance, it is my hope that any future Committee will adopt policies that uses the Boost Community Review process to drive decisions. Any actions the Committee makes, including, but not limited to, its future composition, should have community consensus by the time the Committee votes. It is the only fair, open, and clear way to make decisions. == Inclusivity: As this topic has been mentioned a couple of times I feel like I need to explain my philosophy on this and some related context. I believe that a varied set of ideas and understanding is essential to any life endeavor. As such I believe that keeping doors open to conversation is key in understanding and inclusion. Even though I think that words are important, I place actions above rhetoric. In other words, I think being a decent person is more important than telling others how they should be decent. My philosophy likely stems from learning to live with conflicts in my life. I became an immigrant to the US when I was a teenager. I'm also not an immigrant because I was born in Puerto Rico with US citizenship. English is not my native language. But I am also more fluent in English than my native Spanish. I am a straight man in a field (game development programming) dominated by straight men. I am also Hispanic in a field where they are an underpaid minority. Part of my ancestry is European and originates in Mallorca, Spain and further back in Catalonia. Another part of my ancestry is Native American of the Caribbean Taino Civilization. Even though I came to Boost searching for a build system, that is not what kept me in Boost. And it was not racial, language, biological (I say that one from the perspective of having a name that is often confused as female in the US), theological, or cultural inclusivity that kept me in Boost. It was intellectual inclusivity that has kept me here for more than 2 decades. It was, and in my opinion still is, a community where I can expect an honest consideration and assessment of technical ideas. == Are you knowledgeable about the problem domain? Yes. I have managed for-profit companies. I have helped, and currently help, to manage non-profit companies. I am versed in managing organization assets of those companies. == Proposals: Given all that preamble, below is my review of each proposal. Foundation:: I found this proposal spent most of its wording explaining the ethos it aims to operate within. It is helpful to get that detailed exposition as it has been something that has been missing from the Foundation (and the SC before it) for a long time. What I see in that exposition though is in dissonance with my experience. The mentioned transparency is limited in time, the past two years publishing minutes, and scope, process on how decisions like board membership are made have been lacking. Consensus building is mentioned as a core aspect. But it is unclear how the consensus process is achieved for Foundation decisions that impact Boost. The items mentioned as the actionable parts of this proposal are "Community building", "Improve relevance", and "Adopt governance best practices". Of those, the one that enumerates some steps that apply to the stewardship of Boost assets is the last one. The first three items, as far as I understand, apply to how Boost developers operate and make decisions as envisioned by the Foundation. The fourth and last items pertain to how the Foundation intends to improve its composition with, I can only assume, the intent to increase participation from Boost developers. The fifth item is the only one that directly addresses the aspect of managing Boost assets. Outlining how the Foundation would take control, and possibly ownership, of assets. But it doesn't mention which assets. Is the library source an asset in this model? Who decides which assets? What this proposal lacks throughout is consideration for accountability to Boost developers wishes. While placing all control in the Foundation. This is an arrangement that would require the utmost trust in the Foundation by Boost developers. And given past history I don't see evidence of such a level of trust being merited. Alliance:: The background of the proposal is thoroughly researched and explained in detail. Although there is a fair amount of background information in the proposal I think it can be summarized as "it gives Boost developers control over Boost assets through a Steering Committee". And although this specific proposal is for the Alliance to be the Fiscal Sponsor that is, as we like saying, "an implementation detail". As the control of what happens with the assets goes to the Committee who represents the Boost developers. The proposed Transition Plan recognizes the roles of the various parties and does a good job of remunerating the parties for the work in the transition. The operation of such a Committee and the Agreement match what I know of the requirements for managing non-profit assets. == Conclusion: I support the C++ Alliance proposal to transfer assets to it and to form a new Steering Committee. There are various details to be worked out if the proposal is accepted by the Boost community. For example, the name of the Committee, its final composition, a final contract, and so on. But that's expected, and natural to achieve a structure that the Boost community can grow with. Thank you for reading this far, René

2 1

[cmake] Define CMAKE_PROJECT_VERSION for standalone subprojects
by Lucas Colley 18 Sep '24

18 Sep '24

Dear boost developers, Subprojects like `math` define CMAKE_PROJECT_VERSION in terms of BOOST_SUPERPROJECT_VERSION via: ``` project(boost_math VERSION "${BOOST_SUPERPROJECT_VERSION}" LANGUAGES CXX) ``` This is clearly handy to save a few seconds in the release process, but it means that if one wants to use the subproject standalone (where BOOST_SUPERPROJECT_VERSION is undefined), CMAKE_PROJECT_VERSION is also undefined. This is a problem for me as I am trying to make boost_math a Meson-CMake subproject of SciPy. This would enable us to un-vendor boost_math from SciPy, such that a distro can instead use SciPy with boost_math as a system library. We would only fall back to embedding the boost_math source when it is not installed as a system library. When the boost_math source is embedded, CMAKE_PROJECT_VERSION is parsed to check that we have the correct version to work with SciPy, but we get an error that the version is undefined. This could be solved by defining the version directly in the math subproject instead of in terms of BOOST_SUPERPROJECT_VERSION. The alternative solution of embedding the entire boost source is not suitable for us, since all we need is math. Would it be possible to switch to defining CMAKE_PROJECT_VERSION directly in subprojects? Or is there a more compelling reason to define it in terms of BOOST_SUPERPROJECT_VERSION? Cheers, Lucas — For context: https://github.com/mesonbuild/meson/pull/11730#issuecomment-2351619977, https://github.com/scipy/scipy/pull/21270

3 3

Re: [boost] proposal Multi multidimensional array library
by Andrzej Krzemienski 18 Sep '24

18 Sep '24

śr., 26 kwi 2023 o 23:38 Alfredo Correa via Boost <boost(a)lists.boost.org> napisał(a): > 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. > > The Boost prefix is purely aspirational at this point, of course. > As I understand the process, the important step at this point is to > find someone(s) to endorse the library and later a review manager. > If you want to be an endorser, please let me know. > > If anyone has feedback or tips to prepare it for a review, please let me > know as well. > I will be at the Aspen CPPNOW conference if someone wants to discuss it in > person. > I am in the C++ Slack channel #boost for discussions as well. > > Here is a link to try it quickly online https://godbolt.org/z/KerbxW6WK. > Hi Alfredo, Thank you for sharing your library. This has been more than a year now, and I am sorry for the delayed response. Thank you for reminding us of it in the slack channel. From this, I gather that the game is still afoot. Recently, it was pointed out in this Mailing List, that it is unfair with respect to the authors to give critical feedback without having studied the proposal, yet I am about to do exactly this. I have only read the introductory part of the docs, as well as the "Comparison with other array libraries" appendix, and my feedback is solely based on that. But you can consider me a good representative of a potential user of the library, who is impatient, and can offer only 5-10 minutes to decide if they want to invest more time in studying the library. This is in the spirit of Roert Ramey's advice: https://www.youtube.com/watch?v=ACeNgqBKL7E&ab_channel=CppCon I personally never needed to manipulate big multidimensional arrays, so I cannot immediately appreciate the usefulness of the library. I need a good introductory part. When I read the high-level description, I immediately think, "it is the same as std::mdspan". The docs say that it is different from the std::mdspan, but then I think, "no, it is the same as std::mdspan". >From the comparison table, I gather that Multi offers both the container and the views (sort of references), and that std::mdspan is only a view. Am I right? The docs say that Multi provides value semantics, but I guess it is not a fair statement. I guess (and correct me if I got this wrong) that the container is value-semantic, but the views are not. That is the nature of the views, that you want them *not* to have value semantics. A fair comparison, should compare Multi's views to std::mdspan. Now, the Standard library has also a proposal in flight to add a container for multi-dimensional arrays: std::mdarray: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p1684r2.html Could you also include it in your comparison? And I would expect that std::mdspan and std::mdarray are treated as one in this case. I read that Multi's types have an STL-compatible interface (range). But this is far from obvious what it means in the context of multi-dimensional arrays. The range/iterator interface was tailored for one-dimensional data structures. There is no obvious generalization to multiple dimensions. I wouldn't even expect a multi-dimensional array to give me an STL interface (whatever that means). Maybe, you mean that the library offers a view where you can see the entire multidimensional array as a long string of values? This would make sense, but if it is the case, I expect the introduction to say exactly this. In the case of std::mdspan, it has been said that it has been tailored to efficiently represent both huge datasets as well as tiny 4x4 matrices. I am not sure if this is the case, but I request that the docs for Multi say what use case they have been designed and optimized for. Does the library only represent dense matrices, or can it also represent sparse data? The term "stride-based". It is not clear to me what it means. I cannot see from the introduction if this library will throw exceptions. The comparison between Multi and std::mdspan in the row "const-propagation semantics" is unfair. I guess you are comparing Multi's container with a view. A view is not expected to propagate constness. So this is the very initial feedback, I hope it helps. Regards, &rzej;

4 5

[Asset Stewardship] About the Beman Project
by Andrzej Krzemienski 17 Sep '24

17 Sep '24

Hi Everyone, The review hasn't started yet, but I think there is no harm in starting the discussion earlier. The Fiscal Sponsorship Proposal from C++ Alliance has the following statement. At the C++Now conference in 2024, the Foundation launched a competing > library collection called the Beman Project, describing it as “a new > initiative separate from Boost that gets back to its original purpose of > improvements to the standard library.” Could perhaps directors of the Boost Foundation comment on their affiliation with the Beman Project? The reason I ask is that my perception of the Beman project, given the scarce information about it online, and the observation that C++ proposal authors prefer to avoid Boost, is "Boost doesn't work, let's start something new". Regards, &rzej;

24 56