- Boost - lists.boost.org

[release] Boost 1.85.0 Release Candidate 1 is available.
by Marshall Clow 12 Mar '24

12 Mar '24

Available at: <https://boostorg.jfrog.io/artifactory/main/beta/1.85.0.beta1/source/> The SHA256 checksums are as follows: fa31215de3a4d2d010c0bc6e42cc63da76be82899f145ea6a6034b5bf3e6e297 boost_1_85_0_b1_rc1.zip 3b16d693acd4ee1745b0d9267555f7e34387527a02817f0c81bf8ec963b7c569 boost_1_85_0_b1_rc1.tar.bz2 20c7d2ccbbddeb56e618aa80960ea4dd38cbc4912b9a05fefef31c290519154e boost_1_85_0_b1_rc1.7z 7a28cd03e8e48b59a898900c953a9194b8f1efbb8c6149703b7faf08642c0cf7 boost_1_85_0_b1_rc1.tar.gz As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. -- The Release Managers

8 17

Reminder: Review for Zach's parsing library starts on Feb 19th
by Marshall Clow 11 Mar '24

11 Mar '24

That’s a week from now. Github: https://github.com/tzlaine/parser Docs: https://tzlaine.github.io/parser — Marshall

14 54

[release] Request to merge B2
by René Ferdinand Rivera Morell 11 Mar '24

11 Mar '24

Can I merge the latest, 5.1.0 (a), release of B2 to master at the next opportunity? By next opportunity I mean whenever the release managers think it's appropriate. :-) [a] Release notes: <https://github.com/bfgroup/b2/releases/tag/5.1.0> -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supone Nada -- Robot Dreams - http://robot-dreams.net

2 1

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