- Boost - lists.preview.boost.org

Re: [boost] Q1 2023 Update: C++ Alliance's Efforts (PDF Attached)
by David Sankel 03 May '23

03 May '23

I wanted to call out Sam Darwin's work on this: > Transitioned boost mailing list gateway from mailgun to Amazon SES This transition has resulted in a $575 per month cost reduction in Boost Foundation hosting expenses. Sam did an excellent job here. Thanks Sam and C++ Alliance for this valuable work! David Boost Foundation

2 1

Re: [boost] Boost CI Infrastructure
by Boris Kolpackov 03 May '23

03 May '23

Vinnie Falco via Boost <boost(a)lists.boost.org> writes: > I guess what I'm trying to say here is that we care deeply about long > turnaround times on CI ("they suck) have been working on the problem. This email may give an impression that the CI suckage is an inherent problem that one just has to live with so I want to provide a different perspective. As part of the build2 project we have implemented our own CI infrastructure from the grounds up: from managing our own hardware, to VM-based CI job handling, to custom web interface for result viewing. This was based on concluding that all the existing off- the-shelf solutions are primarily focused on "web development" and will result in the subpar experience for large C/C++ projects (Boost, Qt, etc). Some key differences of our approach compared to the commonly used setups (e.g., GitHub Actions): 1. "Push CI" explicitly triggered during development as opposed to "pull CI" triggered on commit/PR/etc. This allows specifying the target configurations to build in, alternative project configurations, etc.[1] 2. Standard "CI script"[2] that is used by all the C/C++ projects instead of each projects doing their own thing. This "CI script" is written in C++ and has evolved to cover a fairly elaborate set of scenarios, including: 1. Testing of preparation of source distributions (to make sure there are no missing files, etc). 2. Testing of libraries as installed (to make sure no public headers were omitted during installation, etc). 3. Ability to test projects with build-time dependencies (e.g., source code generators, build system modules, etc) in cross- compiled environments. 3. Interactive CI support. The push CI can request an interactive session where the above "CI script" is stopped at one of the pre-defined breakpoints allowing the user to login into the machine via VNC or SSH and investigate the problem. 4. Large number of build configurations covering all the major platforms/compilers/versions[3] with a well-defined obsolescence policy. To give a sense of how this works in practice, here is my typical workflow: 1. Hack on some feature in a branch, build and test locally. 2. When need to test on other platforms, push the branch to remote and submit the CI request. Normally it's just: $ bdep ci The result is a URL with the interface like this: https://ci.stage.build2.org/@04e5ffb7-cf96-42f9-bc91-94d3ffe48de1 One nice touch is that it detects compiler warnings, as can be seen in this result: https://ci.stage.build2.org/@23da340d-cb4d-4105-8474-bb870e1a1380 (Drop the UUID from the above URL to see some other CI jobs.) 3. Say everything works fine except on Windows with an old MSVC version. If the fix is clear, I push it and re-CI but just on this specific configuration (this is both faster for me and saves resources for others): $ bdep ci --build-config windows_10-msvc_14.3 If the fix is not clear and I need to play with it or run the debugger, I can request an interactive CI session: $ bdep ci --interactive windows_10-msvc_14.3/error That `/error` part is a breakpoint, meaning that the CI job will execute the standard "CI script" until the first error (compile error, test failure, etc) and pause. 4. Once all is good I clean up my feature branch (squash commits, etc), rebase on master, CI one more time for good measure, and merge to master. When I push my changes to master, there can be a hook that submits a "verification" CI job. [1] https://build2.org/bdep/doc/bdep-ci.xhtml [2] https://build2.org/bbot/doc/build2-build-bot-manual.xhtml#arch-worker [3] https://ci.cppget.org/?build-configs

1 0

Re: [boost] Q1 2023 Update: C++ Alliance's Efforts (PDF Attached)
by Andrey Semashev 03 May '23

03 May '23

On 5/3/23 10:59, Julien Blanc via Boost wrote: > Le 2023-05-02 15:25, David Sankel via Boost a écrit : >> I wanted to call out Sam Darwin's work on this: >> >>> Transitioned boost mailing list gateway from mailgun to Amazon SES >> >> This transition has resulted in a $575 per month cost reduction in Boost >> Foundation hosting expenses. Sam did an excellent job here. > > Did that happen around end of february / start of march? I've noticed > that threaded view was broken around that date (and still is). At first, > i blamed my client (evolution) but i see the same issue with another > (roundcube). > > A quick look at mail headers seems to show wrong values in the > References: header (but that is far beyond my expertise). I can see the threaded view is indeed broken in the mailman archive, for example see here: https://lists.boost.org/Archives/boost/2023/04/index.php You can see the initial post is not grouped with the following thread. I should also mention that I was not totally correct when I said I don't use threaded view when I read Boost ML. On my mobile email app that I forgot about, I do use threaded view, and I did notice that some messages were not grouped with the rest of the discussion. It didn't occur to me until now whether those messages were the initial ones in the discussion, but it may have been so.

1 0

Re: [boost] Mailing Lists For The Win!
by Hans Dembinski 03 May '23

03 May '23

> On 2. May 2023, at 17:52, Vinnie Falco via Boost <boost(a)lists.boost.org> wrote: > > This will take additional time so it probably won't make it into the > initial cut of the website, but we will at least be showing read-only > archives for now. And the mailing list will remain as-is, forever. This sounds like a pretty neat solution. I like the mailing list to participate in the communication, but I don't like to browse the ML archive to dig up old conversations. I think that's going to be easier with the forum. Hans

1 0

Re: [boost] Q1 2023 Update: C++ Alliance's Efforts (PDF Attached)
by Julien Blanc 03 May '23

03 May '23

Le 2023-05-02 15:25, David Sankel via Boost a écrit : > I wanted to call out Sam Darwin's work on this: > >> Transitioned boost mailing list gateway from mailgun to Amazon SES > > This transition has resulted in a $575 per month cost reduction in > Boost > Foundation hosting expenses. Sam did an excellent job here. Did that happen around end of february / start of march? I've noticed that threaded view was broken around that date (and still is). At first, i blamed my client (evolution) but i see the same issue with another (roundcube). A quick look at mail headers seems to show wrong values in the References: header (but that is far beyond my expertise). > Thanks Sam and C++ Alliance for this valuable work! Yes, thanks for all this invisible work. Julien

1 0

Re: [boost] Replacing the ML with a forum
by Dominique Devienne 02 May '23

02 May '23

On Mon, May 1, 2023 at 8:15 AM Vinnie Falco via Boost <boost(a)lists.boost.org> wrote: > On Sun, Apr 30, 2023 at 8:56 PM Rainer Deyke via Boost > <boost(a)lists.boost.org> wrote: > > The SDL mailing list moved from true mailing list on gmane to Discourse > > web forum with email notification (but no gmane) a while back > > Good thing that's not happening to Boost > I've already mentioned it, but I feel compelled to re-iterate, given the lets-built-it direction, although I know it's most likely in vein. SQLite made the transition from ML to a custom-built Forum, and it went/was OK. I and several others were against it. In the end, the community survived and thrived. I've used Discord in the past. I've used Basecamp. I've used News (Google Reader, RIP). And of course I've used MLs too, these ones included. [The Fossil Forums][1] are low-key, fast, i.e. good enough. And very low resources on the backend. The Forums integrate with [Pikchr][2] for text-based diagramming. Email notification is implemented, but replies by emails are not. You don't need to use Fossil SCM to use them. Many people use Fossil just for the Forums. Unlike SQLite, Fossil is open to contributions too, although the community is opinionated. I have no stake in Fossil. I'm just a happy user. FWIW. --DD [1]: https://www.fossil-scm.org/home/doc/trunk/www/forum.wiki [2]: https://fossil-scm.org/home/doc/trunk/www/pikchr.md

2 1

Re: [boost] The History of Boost
by Vinnie Falco 02 May '23

02 May '23

On Mon, May 1, 2023 at 1:44 PM Andrey Semashev via Boost <boost(a)lists.boost.org> wrote: > I think, you can start by copying all the existing information on the > current site and then improve on it. I don't see the point in > registering issues requesting adding information that is already there > on the current website. Yep! Well, maybe just one issue with links to all the existing info? > IMO, this style of navigation is too obscure. I would have never thought > to click on "User Guide" in the bottom corner of the screen to switch to > other documents. That UI is temporary, it is what comes with the "Antora Default UI." In the actual website there will be a nice looking page showing a handful of cards, one for each document, with information about what is inside the document and a small sample of the most important topics inside. And you will always be able to get to this page just by clicking "Learn" in the top level navigation. > The navigation line at the top is useless because > "home" leads to "User Guide" and not a landing page with contents. Yes, that top level navigation area is temporary. In the actual website one of the top level navigation items says "Learn" and this takes you to a landing page that has beautiful cards which link to each individual document. No matter where you are on the website (which includes individual Boost library documentation) it will be possible to reach the landing page with the site-docs in a single click (by pressing "Learn" at the top). The restyling of the Antora UI to match the website is not a trivial undertaking; all of the Asciidoc CSS classes have to be styled with it, and there are a LOT of them. Lists, tables, admonitions, source code boxes (especially those because we want them to be awesome the whole focus of our website is on source code). This is happening in parallel with the authoring of the exposition. Thanks!

1 0

Re: [boost] Boost CI - a modest proposal
by Hans Dembinski 02 May '23

02 May '23

> On 30. Apr 2023, at 17:37, Robert Ramey via Boost <boost(a)lists.boost.org> wrote: > > the implementation of Boost CI follows the normal pattern for the implementation of this functionality. This entails download the latest version of the library to be tested and it's dependencies (or maybe all of boost?) from the repo, Building everything from scratch, running all the tests and logging the output there of. This is done for each compiler / environment to be tested. Other than the raw console logs, there is no presentation of the tests results (e.g boost test matrix). > > This is extremely unsatisfactory. > > a) It's ridiculously resource intensive. Rebuilding everything all the time. > > b) takes forever unless one has many more servers than we have. These two points can be addressed somewhat by cutting down the matrix and by using ccache. You don't really need to test all versions of all compilers. For daily work it is sufficient to use the lowest and highest compiler versions you want to support. If the main time is spend in compiling the test instead of running them, Boost.CI could be sped up by using ccache. If have used ccache in other projects, where it sped up the CI considerably. Best regards, Hans

1 0

Re: [boost] Boost.Compat
by Hans Dembinski 02 May '23

02 May '23

> On 30. Apr 2023, at 01:06, Andrey Semashev via Boost <boost(a)lists.boost.org> wrote: > > I really don't like us having > multiple copies of the same components for the sole purpose of reducing > dependencies (in the case of latch - reducing tests dependencies, not > even library dependencies). Me neither, but like everything in life it is a trade-off. I want to both reduce duplication and dependencies in Boost.Histogram, which is a rather high-level library that builds on a lot of low-level Boost functionality. To reduce dependencies, I used to have my own implementation of stuff like variant or span, which I eventually replaced with boost::span in Boost.Core and Boost.Variant2. This is partially repeating what others have said: I see utility in Boost.Compat, because the scope of Boost.Compat is well-defined, while the scope of Boost.Core isn't. I have had discussions with the Boost.Core devs over what should be in Boost.Core or not. Knowing the scope of a boost library helps both with making requests that have a chance to be accepted and also makes it more clear for users what to expect from this library. Regarding the reviewing of Boost.Compat: A light review is sufficient, since we can skip the discussion of the design/scope/etc, but it looks like we want to have some initial review. We are currently discussing scope and rules for this library, these should be approved by a formal review. Just my two cents, Hans

1 0

Re: [boost] Boost CI Infrastructure
by Niall Douglas 01 May '23

01 May '23

On 30/04/2023 18:31, Vinnie Falco via Boost wrote: > Alan de Freitas has done a considerable amount of good work in this > area so if you would like to ask specific questions on the list or in > the Slack workspace that is also a good choice (or you can ask me or > Sam). Alan contributed a whole bunch of GHA CI for Boost.Outcome. It runs very well, it usually completes before the Drone CI does for Outcome. People here may be interested in studying it and how it works. My thanks to Alan for doing all the heavy lifting there. And to Peter Dimov for identifying things which had become broken in Boost.Outcome due to changes elsewhere in Boost but hadn't registered on CI, and therefore needed much wider CI testing (which Alan then implemented). Also, thanks to Vinnie for asking Alan to do that work for Outcome. I haven't had the time recently (spent the last three days driving around a six tonne digger lifting 'lego' concrete blocks, it has been very tedious). Niall

1 0