- Boost - lists.preview.boost.org

New home for B2.
by René Ferdinand Rivera Morell 08 Mar '21

08 Mar '21

As some of you may have noticed, B2 has a new home outside the Boost organization at <https://www.bfgroup.xyz/b2/>. The goal of the move is to elevate B2 development above the constraints of the Boost structure. I.e. to make B2 not just the build system that Boost uses. The biggest change to make happen is that last week the B2 fork at < https://github.com/bfgroup/b2> became the base git repo of all existing B2 git repos. And hence it means that the git repo < https://github.com/boostorg/build> is now a fork. What does this mean going forward? This that will not change: * Boost will still get the build system from the same git repo as it does now. * The B2 documentation will still be included in the Boost releases. What will change (eventually), or has already changed: * Development has moved to the new B2 git repo. And hence PRs for B2 will need to be posted to the new repo. * The B2 mail list at < https://lists.boost.org/mailman/listinfo.cgi/boost-build> will be replaced by the GitHub discussion forums at < https://github.com/bfgroup/b2/discussions>. * The B2 version in Boost will be updated from the base git repo for releases of the B2 base only. I.e. a B2 release will get merged to the Boost develop branch. And from there to the master branch. * The Boost testing of B2 reported at < https://www.boost.org/development/tests/develop/developer/summary.html> will stop showing (and hence running) B2 tests.The testing has already moved to cloud CI. And expanded to cover more platforms than Boost usually tests. * The B2 web site at <https://boostorg.github.io/build/> will go away. * The issues at <https://github.com/boostorg/build/issues> will eventually go away (once I deal with enough of them). -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supone Nada -- Robot Dreams - http://robot-dreams.net

2 2

[Describe] Clarification on the library scope
by Andrzej Krzemienski 08 Mar '21

08 Mar '21

Hi Everyone, First of all, I wanted to thank Peter for writing and sharing this library. A number of people already indicated it is useful, and I also have use cases that would be addressed by this library. I would lie to clarify if my understanding of the scope of this library is correct. From the discussion so far, I understood that the goal is to provide a low-level minimum building block that enables writing more elaborate libraries for providing type introspection. The library gives me the following guarantee: if a user used macro BOOST_DESCRIBE_STRUCT for some type T (and there are no ODR violations) than I can use `boost::describe::members` to see what those members are: their name, their type, and a pointer. If I want to use this data in a convenient way, I have to use another library atop of Boost.Describe. For instance, when I need to observe struct X as a tuple of references, I will write my own library, which: 1. Checks if Boost.PFR can figure it out automagically. If so, use this magic 2. If not, resort to Boost.Describe, and based on its interface, form a tuple of references. Did I capture it correctly? In that case, requesting high-level features in Boost.Describe is against its design goals. It is a low-level piece, not necessarily to be used directly. Regard, &rzej;

3 2

[Describe] Boost.Describe vs Boost.Fusion
by Andrzej Krzemienski 08 Mar '21

08 Mar '21

Hi Everyone (but mainly Peter), Boost.Spirit needs to have an index-based access to user defined types, as explained in the tutorial: https://www.boost.org/doc/libs/1_75_0/libs/spirit/doc/x3/html/spirit_x3/tut… Currently Boost.Spirit uses the interface of Boost.Fusion, and users are encouraged to use macros like BOOST_FUSION_ADAPT_STRUCT: https://www.boost.org/doc/libs/1_75_0/libs/fusion/doc/html/fusion/adapted/a… The first question is, can Boost.Describe's interface be plugged into Boost.Spirit? It is not that obvious to me for a couple of reasons. For instance, it would require an interface in Boost.Describe for answering the question, "has describe::members been specialized for type X"? The second question is, can is Boost.Describe capable of replacing the adapter macros in Boost.Fusion? For instance, Boost.Fusion allows the users to define and adapt a user defined type with one macro: https://www.boost.org/doc/libs/1_75_0/libs/fusion/doc/html/fusion/adapted/d… This is similar in concept to what macro BOOST_DEFINE_ENUM does for enums. What is the motivation behind allowing the definition of enums in this way but not classes (at least the aggregate classes). My general observation is that we have a number of libraries with overlapping goals: Boost.Describe, Boost.PFR, Boost.Fusion (the part for adapting UDTs) Maybe it is ok, but does it mean that there are so many incompatible use cases? Maybe there is a way to reduce this number. Regards, &rzej;

3 7

[Boost] [Describe] Review starts Monday 1st March 2021 - 10th March 2021
by Richard Hodges 08 Mar '21

08 Mar '21

The Boost formal review of the Describe starts Monday, taking place from March 1st, 2021 to March 10th, 2021 (inclusive). The library is authored by Peter Dimov. Documentation: https://pdimov.github.io/describe/doc/html/describe.html Source: https://github.com/pdimov/describe The library provides a simple means of providing reflection for structures and enums in C++. The documentation contains a number of common motivating examples, including: - A universal print function https://pdimov.github.io/describe/doc/html/describe.html#example_print_func… - JSON serialisation https://pdimov.github.io/describe/doc/html/describe.html#example_to_json Please provide in your review information you think is valuable to understand your choice to ACCEPT or REJECT including Describe as a Boost library. Please be explicit about your decision (ACCEPT or REJECT). Some other questions you might want to consider answering: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With which compiler(s)? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? More information about the Boost Formal Review Process can be found at: http://www.boost.org/community/reviews.html The review is open to anyone who is prepared to put in the work of evaluating and reviewing the library. Prior experience in contributing to Boost reviews is not a requirement. Thank you for your efforts in the Boost community. They are very much appreciated. Richard Hodges - review manager of the proposed Boost.Describe library Peter is often available in the CppLang Slack #boost channel should you require any clarification not covered by the documentation, as am I. -- Richard Hodges hodges.r(a)gmail.com office: +442032898513 home: +376841522 mobile: +376380212

9 19

[spirit] Custom error on rule level?
by Serguei TARASSOV 08 Mar '21

08 Mar '21

Hello, is it possible to have a custom error handler on the rule level (for every rule in the limit) ? Cannot find this point in docs/examples. I.e. when parsing following texts (// are inline comments): DO_JOB WITH not_a_opt1; // should raise "Option not_a_opt1 is unknown" DO_JOB WITH opt2 = 123; // should raise "Invalid value 123 for option opt2" Regards,

2 1

[build] Could not open a pull request
by Nikita Kniazev 05 Mar '21

05 Mar '21

It seems that forks of boostorg/build switched their parent automatically and I could not find a way to open a PR against boostorg/build. What is happening and how do I proceed?

6 8

boost.log's text_multifile_backend is not performant on windows - perhaps it should be documented?
by Nicholas Neumann 05 Mar '21

05 Mar '21

I recently moved a project to boost.log from a homemade logger. I had something like text_multifile_backend, so finding that as a drop-in replacement was awesome. Unfortunately, the performance when using text_multifile_backend on windows is really bad, because the repeated file close operations (one per log record) are unusually slow on windows. Repeatedly logging a string to the same file via text_multifile_backend results in throughput of about 200 log entries per second. Just to quickly prove it is unique to windows, I made a simple program that just opens, appends a single line, and then closes, an ofstream in a loop. On a high-end windows machine with nvme ssd, 1000 iterations takes 2600ms. On an older linux box with a sata ssd, the same takes 16ms. What do others think about adding a note in the documentation about this performance issue? It's bad enough that I think anyone on windows would want to avoid the backend. It's not the backend's "fault" at all; I could see some options for improving performance of the backend on windows, but they definitely complicate the simplicity of the current approach. (Side note - in googling the issue, other projects have been bitten - notably mercurial on windows - https://gregoryszorc.com/blog/2015/10/22/append-i/o-performance-on-windows/ )

5 27

[quickbook] Broken links generated in locally built docs
by Andrey Semashev 05 Mar '21

05 Mar '21

Hi, When I'm building QuickBook docs locally for Boost.Log, I'm seeing errors like the following in the end: Error: no ID for constraint linkend: "log.design". and so on for basically any section id that is used in the QuickBook [link] tag. In the resulting HTML documentation all such links point to the root directory where the HTML docs are located. Looking at the bin.v2/libs/log/doc/log_doc.xml file, for example, for the log.detailed.sink_frontends.sync is, it looks like <link> tags use the id that is specified in QuickBook: <link linkend="log.detailed.sink_frontends.sync"> but the actual section has a colon in front of the id: <section id=":log.detailed.sink_frontends.sync"> Is this a known issue and is there a workaround? I'm using DocBook XML from the Kubuntu package, which has version 4.5-9, and a freshly built QuickBook from develop. I used to build docs locally fine before, and did not change the configuration since, but I may have upgraded Kubuntu since I last built the docs. Thanks.

2 5

[release] 1.76.0 closes for major changes TOMORROW
by Marshall Clow 04 Mar '21

04 Mar '21

When: Wednesday, Mar 3, 2021 Description: Release closed for major code changes. Still open for serious problem fixes and docs changes without release manager review. Full calendar at: https://www.boost.org/development/ <https://www.boost.org/development/> — Marshall

3 3

Re: [boost] [Describe] Boost.Describe vs Boost.Fusion
by Nikita Kniazev 02 Mar '21

02 Mar '21

> Or have Spirit perform a check: if `describe::members` is found use it, otherwise fall back to Boost.Fusion. Spirit uses Fusion iterator_range internally, it will require to find/write a replacement that will work with both libraries.

1 0