March 2024 - Boost - lists.boost.org

New Website: State of the review / pending issues
by Ion Gaztañaga 07 Mar '24

07 Mar '24

Hi to all, We've had quite an intense debate regarding the proposed new website. I've tried to extract the main technical comments expressed in the ML to to determine the current state, fix any misunderstanding and try to establish a constructive thread: ------------------------- ------------------------- 1) Repository: the website code was hosted in cppalliance's github. It was transferred to boostorg. I understand this as an improvement as it's in the same level as other boost libraries. 2) License: Before transferring it to boostorg, a request to change the license to BSL was made. The license change was announced on February 21, and boost.io says it's BSL, so I guess it's solved now. Source files in the repo (https://github.com/boostorg/website-v2) have no copyright notice, I don't think it's something that is required, but usually all Boost source files have the notice and point to the license. I'm not a lawyer, but if the site is open source, anyone can fork and improve it, and ownership and copyright of the source code follows the standard Boost practices (BSL). Anyone with enough technical expertise can put up a server with the original or forked code and re-run the site in case of cpp.al goes away or if there are disagreements. 3) Privacy Policy: There was a comment about information from third parties and the use of Google Analytics, location data... AFAIK there is a new privacy policy page (https://www.boost.io/privacy/) which does not mention any location data and says a notification will be sent to registered users on any change. There is a issue to implement account deletion (https://github.com/boostorg/website-v2/issues/965) opened by Vinnie, so it should be implemented soon. 4) Terms of use: It was suggested that there needed to be a page like "Terms of Use" composed with help of a lawyer. AFAIK there is a new page (https://www.boost.io/terms-of-use/) that is much simpler and easier to read than the original. I'm not sure if Andrey's comments are addressed with the new TOU. Andrey, it's ok now? 5) GDPR: A issue was filed (https://github.com/boostorg/website-v2/issues/960) and there was a discussion in the ML about not having any analytics tool to avoid cookie banners or a couple of analytic tools that were compliant with GDPR. The github issue was resolved stating that: - Google Analytics was removed and Plausible was deployed (e.g. no cookies. IP addresses are anonymized with a hash function and rotating salt value), - YouTube Embed on the homepage was changed to an external link to the video. I understand that with those changes the site is GDPR-compliant. Is that right? 6) Moderation: We had a discussion about how moderation should be performed in the site (mainly as an anti-spam mechanism) and how it's implemented now in the mailing list (volunteers). My understanding is that the new website has some moderation tools so that anyone can submit news, etc... and that the same ML method (volunteers blessed in the ML) should be used to appoint the moderators for the site (not necessarily the same people that moderate the ML). ------------------------- ------------------------- I don't know if this summary is accurate, the aim was synthesize several ML threads into a single post, certainly I could be wrong on several points, please correct me in that case. Now the next question is: *What's missing technically so that the new website can to live?* If technically we have an agreement or we are near that, then we can: - Know if there are non-technical aspects that need to be ironed out. - Know if there is any alternative to be discussed and compared with the proposed website. If so, let's put it on the table, review and compare it. - Schedule a plan so that Boost can have a new modern website soon. Does this make sense? Best, Ion

8 10

[release] The Master branch is now CLOSED for the 1.85.0 beta.
by Marshall Clow 07 Mar '24

07 Mar '24

Please do not commit anything to ‘master’. — Marshall

1 0

Boost.Parser review result delayed
by Marshall Clow 06 Mar '24

06 Mar '24

I had to go out of town for a couple of days, and appear to have brought hone a cold. Sorry for the delay. — Marshall

2 1

[release] Master Branch closes for the release TOMORROW
by Marshall Clow 06 Mar '24

06 Mar '24

As always, the calendar is here: https://www.boost.org/development/ — Marshall

1 0

Boost.Parser Question about digit separator support
by Olaf Peter 04 Mar '24

04 Mar '24

Hi all, In the past I had some attempts with Spirit.x3. C++, VHDL and other languages support literal digit separators. On Stackoverflow.com there are some workarounds (in the context of VHDL's digit separator '_' ) for X3, which works but are unattractive and to unwieldy/unflexible. Is there a native/direct support for it at Boost.Parser? Thanks, Olaf

2 1

Reminder: Master branch closes for the 1.85.0 beta release on WEDNESDAY
by Marshall Clow 03 Mar '24

03 Mar '24

Calendar is here: https://www.boost.org/development/ — Marshall

1 0

Re: [boost] Reminder: Review for Zach's parsing library starts on Feb 19th
by Peter Dimov 02 Mar '24

02 Mar '24

Zach Laine wrote: > On Fri, Mar 1, 2024 at 2:15 AM Peter Dimov <pdimov(a)gmail.com> wrote: > > > > Zach Laine wrote: > > > > > I'm not sure what the tests reported earlier were doing, but I > > > > > definitely don't see orders of magnitude difference. > > > > > > > > I used this file: > > > > > > > > https://github.com/boostorg/json/blob/develop/bench/data/twitter.j > > > > son > > > > > > Using that file, I get similar results to what I already posted (the > > > numbers are different, but the ratios between them are the same). > > > > > > I managed to make a change that was much smaller -- no template > > > parameter required. I consistenty see 1.5x slowdown for Parser vs. > > > Boost.JSON for files around this size, and 2x or so for much larger > > > files (~25MB). > > > > That's probably because you are measuring I/O in addition to parsing. > > > > https://github.com/cmazakas/parser-review/blob/main/test/json.cpp > > > > only measures the parsing part. > > Quite right! After building it locally, I do see an advantage to the template > parameter approach -- that is, controlling the contents of scoped_trace_t with > an NTTP that is true/false when trace is enabled/disabled. scoped_trace_t is > specialized to be empty when the NTTP is false. I'll be committing the template > param-based approach soon. > > For those keeping track, with Christian's test framework, I get 35X worse > performance of the JSON parser example vs. Boost.JSON. This seems like a > reasonable factor to me. I wrote that example in a single, and made no > attempt to optimize it in any way; it is an example. Boost.JSON is a dedicated > JSON parser emphasizing efficiency. There's probably some room for Boost.Parser automatically applying certain optimizations to "naively" written parsers. For example, a lot of the time here is spent in skipping whitespace, using this rule: auto const ws_def = '\x09'_l | '\x0a' | '\x0d' | '\x20'; This generates an or_parser that contains four separate omit_parsers, each with a char_ inside. If I change it by hand to auto const ws_def = bp::omit[ bp::char_( "\x09\x0a\x0d\x20" ) ]; which I assume is equivalent, time improves from 365ms to 316ms (*). And that's still far from optimal, because (1) skipping whitespace can in principle be done with the equivalent of `find_first_not_of` and (2) the characters are a runtime value in the above, but something like `cxchar<'\0x09', '\0x0a', '\0x0d', '\x20'>` could be even faster. It should be possible for the library to automatically turn the "naive" ws_def into something more optimal, and then special-case `skip` for this common case. In the general case this is complicated by the existence of attributes and semantic actions; transforming parsers should take care to preserve those. But in this specific case none are present. (*) Under clang-cl. GCC -O3 has different views of the world and times there are 165ms and 181ms, respectively.

1 0

Late review of Boost.Parser
by David Sankel 02 Mar '24

02 Mar '24

# Are you knowledgeable about the problem domain? Yes. I've written several parser combinator libraries in C++ and used still more in C++ (Spirit v1, v2, and qi) and other programming langauges (Haskell's Parsec, attoparsec, and others). # How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I read through the tutorial documentation and some of the reference documentation. I also tried to create several examples with the library and made comparisons to Haskell's Parsec. # What is your evaluation of the potential usefulness of the library? Very # What is your evaluation of the documentation? The documentation isn't great. Consider char_ <https://tzlaine.github.io/parser/doc/html/boost/parser/char_.html>'s documentation. It includes no examples and fails to mention it can be used without arguments. It seems strange that the tutorial focuses so much on semantic actions. It seems like the more common case would be to parse into some kind of abstract syntax tree. # What is your evaluation of the design? Much of the wealth of research into parser combinators wasn't incorporated into this library. I didn't see in the documentation, for example, an easy way to "map" one parser's attribute into another. This kind of thing should be a basis operation provided by the library. # What is your evaluation of the implementation? The usage of has_include is a ODR nightmare for large codebases. It would be better to generate some kind of config.hpp that sets these definitions at compile time. For custom variant/tuple types, user specialization of variable templates is also an ODR nightmare. Again, a config.hpp would be better for this. For this, though, I don't think the configurability is worth the complexity. We have standard types for these so we should use them. # Did you try to use the library? With what compiler? Did you have any problems? Yes, I tried to use the library with a modern compiler on a MacOS machine. I didn't have any problems building. # Do you think the library should be accepted as a Boost library? No, I do not think it should be accepted. Overall, I think the syntax has too much focus on magically filling in user-provided structures instead of the basics of monadic parser combinators and basis operations. Consider the following Haskell parser which evaluates simple parenthesized sum expressions. I wasn't able to use Boost.Parser to accomplish this after reading the documentation and several attempts. I'm sure it's possible, but I don't see how it can be done using the combiners and primitives provided. import Text.Parsec.String (Parser)import Text.Parsec integer :: Parser Integerinteger = do n <- many1 digit return (read n) integerPlus :: Parser IntegerintegerPlus = do x <- integer y <- (try $ char '+' >> expression) <|> return 0 return $ x+y parentheses :: Parser Integerparentheses = do char '(' x <- expression char ')' return x expression :: Parser Integerexpression = integerPlus <|> parentheses

5 9

Boost Tools
by Robert Ramey 01 Mar '24

01 Mar '24

For some time I've felt that our Boost tooling could be improved. By boost tooling I mean things like b2, boost unit testing and integration testing, documentation generation, reports like dependencies, website, etc. Currently we rely on certain privileged authors to develop these things then then upload them to the boost directories. This has worked, but it could be better. We spend what seems to me an inordinate amount of time chasing down anomalies, researching errors, responding for requests for help, etc. I think design, robustness, documentation could be improved. I think that the the most natural way for us to do that would be to adopt the practices that we have used successfully for decades to develop superior quality libraries to the design and development of tooling. That is: a) Someone proposes a new tool or improvement in an existing one on this list. His proposal includes a working though likely incomplete prototype, documentation, tests, demo etc. b) This is subjected to the same formal review process that libraries are. c) Subject to this review, the proposal is either rejected, accepted or accepted with conditions. Of course this would only apply to new tools and updates of existing ones. Robert Ramey

1 0

The Review for Zach's parser library has concluded
by Marshall Clow 01 Mar '24

01 Mar '24

Thanks to everyone who participated, and especially to those to submitted reviews. (And Zach, of courser) I’ll have results soon. — Marshall

1 0