After some weeks of testing and addressing review comments from
authors I have now marked PRs for supporting modular building and use
of 156 Boost libraries. There are 2 libraries (multiprecision and
utility) that are not ready yet, as they depend on other PRs. After
the testing and review I've also concluded that authors (and owners)
can merge all ready PRs without waiting for the tool specific PRs. It
turned out there were no dependency issues between them. Hence the
process is now:
* The 1.…
[View More]86 release happened!!
* Authors further review and merge the ready PRs.
* I fix any fallout from that.
* I create subsequent PRs for the global B2 Boost build infrastructure
to remove the old non-modular dead code.
* I fix any fallout from that.
* The 1.87 release happens.
Thank you everyone for the help so far. In particular Peter Dimov and
Andrey Semashev for the many early comments across various PRs that
helped me work out the kinks of the draft PRs.
--
-- René Ferdinand Rivera Morell
-- Don't Assume Anything -- No Supone Nada
-- Robot Dreams - http://robot-dreams.net
[View Less]
There are many places where the boostbook xml/xsl files make reference
to external files that we have no control of. Here is an example from
modular-boost/tools/boostbook/xsl/docbook.xsl
<?xml version="1.0" encoding="utf-8"?>
<!--
Copyright (c) 2002 Douglas Gregor <doug.gregor -at- gmail.com>
Distributed under the Boost Software License, Version 1.0.
(See accompanying file LICENSE_1_0.txt or copy at
http://www.boost.org/LICENSE_1_0.txt)
-->
<xsl:…
[View More]stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:xi="http://www.w3.org/2001/XInclude"
version="1.0">
<xsl:import
href="http://docbook.sourceforge.net/release/xsl/current/common/common.xsl"/>
<xsl:include href="reference.xsl"/>
...
This means that if something changes in
docbook.sourceforge.net/release/xsl/current/common/common.xsl
We'll have problems when we try to build documentation. This recently
happened to me and it was a bitch to find. I spent some time looking
around for the right way to fix this and came upon the concept of XML
catalogs as explained here:
https://en.wikipedia.org/wiki/XML_catalog#Example_Catalog.xml
Seems to me that the maintainer of boostbook should verify that my
understanding is correct and update boostbook files accordingly.
Actually, I'd be grateful to any insight on this subject that anyone
might provide.
Robert Ramey
[View Less]
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++ …
[View More]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
[View Less]
I believe this is important enough that it needs a thread of discussion
split from the original at
https://lists.boost.org/Archives/boost/2024/08/257347.php
Some important details seem to have been lost in the conversation. I will
summarize the Alliance position in a nutshell:
The Alliance will become Boost's steward. Then, we shall assist the Boost
Software Commons (a new non-profit created on March 1, 2024) to attain
financial independence. Finally we will transfer the shared assets to …
[View More]this
new non-profit.
Also, I love Boost and I would like the opportunity to help it become a
many-generational institution singularly driven to support library
development.
The message below is reposted in its entirety and without modification.
---
I want to start by expressing my gratitude to Kristen, who kept an open and
friendly line of communication with me for the last several months. It is
unpaid volunteer work, difficult at times, and I appreciate her effort.
As a passionate contributor to Boost, I am excited to see renewed growth
and positive change in the project. The Boost Foundation has generously
offered that the community may determine if the Alliance should be the
steward of Boost’s shared resources. The term steward instead of owner is
deliberate, as the former reflects the behavior which respects the Boost
tradition of consensus-driven decisions.
In this communiqué I would like to explore what option 1 looks like from an
operational perspective (wearing my Alliance president hat) and then
outline my opinion as the author of four Boost libraries.
The Alliance is already the largest financial sponsor of the Boost project.
Going with the first option means that our relationship to Boost would
become formal. What would happen is this:
1. The Alliance becomes the registrant of the boost.org domain. This may
take time, but effectively immediately after going with option 1, the
Alliance shall fulfill our Domain Name Purchase Agreement under
substantially similar terms including the launch of the Beman Scholarship
Fund (if there is agreement). The Alliance shall reimburse the Foundation
for any and all reasonable legal expenses incurred for both changes of
domain ownership, including the estate fees.
2. The Alliance assumes all costs and responsibility to ensure that the
boost.org domain registration does not expire, the SSL certificates are
renewed and up to date, and that quarterly transparency reports are
published to the mailing list apprising the community on the status of its
registration.
3. The Alliance assumes all costs and responsibility for maintaining
Boost’s cloud services (“Services”). This includes but is not limited to
the wowbagger server, the new website, the new mailing list service, the
existing mailgun account, and other services which may be required to
support Boost’s infrastructure. The mailing list will be upgraded but
continue to function as it is currently. Quarterly transparency reports
will be published to the mailing list detailing the ongoing expenses and
condition of these resources.
4. While the Alliance is the steward of the domain and cloud services, the
content of the website and related web applications, such as the release
building process, is controlled by the Boost GitHub Organization. Including
but not limited to the repositories here:
https://github.com/boostorg/websitehttps://github.com/boostorg/website-v2https://github.com/boostorg/website-v2-docs
Changes made to these repositories will go through the existing pull
request and review process, which requires community consensus. The Owners,
defined as the set of users in the Boost GitHub Organization which have the
Owner role, maintain the responsibility for determining consensus.
5. When the Boost community cannot achieve consensus, the responsibility
for making a directional decision shall pass to the Boost Software Commons
(“Commons”), a 501(c)(3) non-profit registered in Delaware on March 1,
2024, which is not controlled by the Alliance and whose board currently
consists of Boost authors. The Commons is now in hibernation until it is
needed.
6. The Alliance shall endeavor to help the Commons become capable of
independently financing Boost’s infrastructure. The Services cost about
$13,000 a year to run, excluding wowbagger and the downloads hosting costs.
Our plans include:
* Establishing a Boost Patreon
* Sales of Boost-branded products at conferences and by mail
* Soliciting donations from corporate and private sponsors
* Optimizing the Services to reduce cost
In all cases, proceeds from fundraising shall go directly to the Commons.
7. When fundraising levels reach the threshold necessary to finance the
Services, or earlier upon request by the Commons, the Alliance shall
transfer ownership of the boost.org domain to them. At the Commons’ option,
the Alliance may continue administering the Services.
Why The C++ Alliance?
I believe that the Boost Foundation’s governance rules and board
composition are simply not structured to put the best interests of Boost
first, as can be seen from their own published minutes. The Boost project
has been in decline for several years and the Alliance would like the
opportunity to do something about it, in a way that is consistent with the
project’s values. As our plans require significant financial investments
(which we are happy to make), changes are needed.
Option 1, Alliance stewardship of shared assets, provides Boost with the
opportunity to refresh the foundations of the organization with new ideas,
talent, and resources. It offers rescue from stagnation and the rare
opportunity to restructure itself to better reflect the project’s changing
needs from its inception 26 years ago.
While I am excited at the possibility of realizing a dream to increase
Boost participation, I am also mindful of the enormous responsibility this
comes with. Fortunately I will not have to bear this alone, as there are
many new and existing volunteers who are ready to support Boost going
forward and ensure its longevity.
Thank you for your support!
[View Less]
Release 1.86.0 of the Boost C++ Libraries is now available.
These open-source libraries work well with the C++ Standard Library,
and are usable across a broad spectrum of applications. The Boost
license encourages both commercial and non-commercial use.
The release contains numerous enhancements and bug fixes for existing libraries.
For details, including download links, see
<http://www.boost.org/users/news/version_1.86.0>
You can also download directly from:
<https://archives.…
[View More]boost.io/release/1.86.0/source/>
To install this release on your system, see
<http://www.boost.org/doc/libs/release/more/getting_started/index.html>
Thanks to everyone who participated in this release.
-- The Boost Release Team
Marshall Clow, Glen Fernandes, Ion Ion Gaztañaga
[View Less]
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 …
[View More]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.
[View Less]
Hi all,
I'm planning to start working on a new Web3 project and I'm trying to
decide how I should approach doing concurrency with C++ and Boost.
It seems like using callback-passing style with Asio has been pretty
popular historically. However, having worked with other modern languages
with first-class async support, this feels a bit primitive.
I've heard about C++20 coroutines and it seems like Boost has a library for
it (Cobalt). However, it's relatively new, so I'm curious if anyone had
…
[View More]experience with it and is it mature for production. I see that Asio also
has coroutine support, so what's the difference?
The third option I'm considering is using fibers. I like this option in
principle because the resulting code is very clean and looks like normal
synchronous code. However, I haven't seen many big examples/projects using
Boost.Fiber with Boost.Asio. Is this something people are doing out in the
wild? Does Asio support Fibers well?
Best regards,
Thomas
[View Less]
On Wed, Aug 14, 2024 at 11:46 AM Andrea Bocci <fwyzard(a)gmail.com> wrote:
> Right, because posting to a social network owned by an extremist, fascist, racist and nazi-apologist should do great for improving Boost's image.
I completely understand your concerns about this particular platform.
Please understand that our goal in sharing updates here is simply to
reach more people and make Boost's work visible, not to endorse or
align with any particular ideology. I think a strong online …
[View More]presence
can help us connect with more people who care about our libraries, and
that ultimately benefits everyone involved.
That being said, I appreciate your feedback and in the future we
should definitely consider the nuances of social media platforms when
deciding how to share information. Perhaps we can explore additional
ways to share updates
that still reach a wide audience, while also being mindful of the
values and principles we want to uphold?
Thanks
[View Less]
Hi all,
I want some opinions on the display printout for the GDB pretty-printers
I'm working on, for the Unordered library. I have a sample printout in this
GitHub gist here.
(https://gist.github.com/k3DW/ead86d748aa4c4bba3f9f67f09521ba5)
Everything at this link is already implemented and functional in my branch.
I want opinions on how it looks.
I have a few specific questions for everyone, but I'll take any other
comments that don't belong with these questions below.
1. For the container …
[View More]display format, I matched what the standard library
containers do. Should the beginning be shortened to `boost::unordered_map`
instead of the current display of `boost::unordered::unordered_map`? The
same question applies to all of the other containers. Does the middle
namespace `unordered` cause too much visual noise?
2. For the iterators, is `iterator = {...}` a good enough format? Or should
this iterator also specify the container type it came from instead of just
`iterator`? I prefer it as I wrote it, but I am only one member of the
community.
3. Any suggestions for end iterators other than simply `{ end iterator }`?
Again, I like it this way, but I want to know if other people feel
similarly.
4. To print the stats, I implemented a custom GDB command called
"print_stats" that behaves exactly like "print", except it prints an
open-addressing container's stats instead of its elements. Is the name
"print_stats" alright to use in this scenario? Or should it be something
like "boost_unordered_print_stats" to mitigate against name collisions?
Thanks,
Braden
[View Less]
Re: my previous guide to writing inline GDB pretty printers, it turns
out it had bugs. Here is how to fix them.
Firstly, my thanks to Braden Ganetsky for reporting the bugs, then pair
programming over Slack with me late last night to diagnose and fix the
issues. We have cowritten a conversion script which we now believe is
actually correct -- it takes a Python GDB pretty printer, and emits a C
(not C++) header file with all the correct markup. It can be found at:
https://github.com/ned14/…
[View More]quickcpplib/blob/master/scripts/generate_gdb_print…
The first bug fixed is correct escaping: we need to double escape the
original Python in the right kind of way to cause the escaped inline
assembler block to emit the right escaped text for GDB to load it
correct as Python. Getting the double escaping correct is tricky, but we
think we have it now.
The second bug fixed is correct composure of multiple inline GDB pretty
printers - Braden found only the first was having any effect. It turns
out this is due to a misreading of the GDB docs from
https://sourceware.org/gdb/current/onlinedocs/gdb.html/dotdebug_005fgdb_005…
where this example:
```
asm(
".pushsection \".debug_gdb_scripts\", \"MS\",@progbits,1\n"
".byte " XSTRING (SECTION_SCRIPT_ID_PYTHON_TEXT) "\n"
".ascii \"gdb.inlined-script\\n\"\n"
".ascii \"class test_cmd (gdb.Command):\\n\"\n"
...
```
... does not make it clear that the string "gdb.inlined-script" is
actually the unique identifier of that script used to eliminate
duplicates. It needs to be unique per inlined script unless you
specifically want duplicates, and our Python converter above has
remedied this. Generally you ought to name it after your library and
maybe possibly a git SHA or version depending on how unstable your
library is, and ensure that the pretty printer matches only that version
of your library.
Thanks once again to Braden for his help.
Note that the Outcome GDB pretty printer which has shipped in the
pending Boost release is buggy and will not work properly. The next
Boost release will fix it. You can of course copy the fixed pretty
printer from the github repo over this Boost release.
Niall
[View Less]
