- Boost-users - lists.preview.boost.org

[review] [text] Text review begins June 11
by Glen Fernandes 12 Jun '20

12 Jun '20

The Boost formal review of Zach Laine's Unicode library, Text, commences on June 11th and concludes June 20th. We welcome the participation of Boost developers and users, and the C++ community. Quote: This library includes three layers: - The string layer, a set of types that constitute "a better std::string" - The Unicode layer, consisting of the Unicode algorithms and data - The text layer, a set of types like the string layer types, but providing transparent Unicode support Code: https://github.com/tzlaine/text Docs: https://tzlaine.github.io/text Text requires C++14 or higher, and supports GCC 5+, Clang 3.6+, and MSVC 2017. Zach initially presented the library at C++Now in 2018. He also intends to standardize a library solution for Unicode based on this work. Talk: https://www.youtube.com/watch?v=944GjKxwMBo Slides: https://tinyurl.com/boost-text-slides Try the library today, and please consider submitting a review, or even contributing to the discussion next week. Glen

4 3

[asio] tcp non blocking sync read query (bug?)
by Keith Robinson 11 Jun '20

11 Jun '20

Hi, I'm sending data from one process to another using a tcp connection. Sender use scatter-gather to send the data using 3 buffers (total just over 2000 bytes). The reader uses 2 separate sync reads to read the data (using the asio free function read()) using a non blocking socket. Sometimes everything is fine, the 2 reads return the amount of data requested, but sometimes I see strange behaviour. I'm trying to work out whether I am doing something wrong, or whether I've stumbled across a bug. When it goes wrong for me, the second read always returns less data than I requested, along with the error code 'would_block'. I then loop, performing further reads (using the same buffer as before), eventually (one read, or multiple reads later) the read function returns the remainder of the data, but still with the error code 'would_block' set. However, when I check the contents of the buffer, it is not what I expected. I think, but haven't been able to confirm, that the start of the buffer is not the start of the data. 1. Is it expected that the read() free function, when the socket is non blocking, can return less data than requested, along with the error code 'would_block'? 2. If it is expected, does the buffer passed in subsequent reads have to be adjusted to read only the remaining about of data? 3. If the buffer does have to be changed to only read what is left, how does this work with scatter-gather reads using multiple buffers? As a little bit of extra info, I confirmed using tcpdump that the correct data is sent/received, although it arrives in 2 chunks (MTU size of 1500). This is on Linux using Boost 1.73.0. Cheers, Keith

3 3

[review] [text] Text formal review
by Glen Fernandes 11 Jun '20

11 Jun '20

Dear Boost community, The formal review of Zach Laine's Unicode library, Text, begins today (June 11th) and ends on June 20th. The library provides three layers: - The string layer, a set of types that constitute "a better std::string" - The Unicode layer, consisting of the Unicode algorithms and data - The text layer, a set of types like the string layer types, but providing transparent Unicode support Code: https://github.com/tzlaine/text Docs: https://tzlaine.github.io/text The master branch of the repository will be frozen for the duration of the review. Text requires C++14 or higher, and supports GCC 5+, Clang 3.6+, and MSVC 2017. Zach initially presented the library at C++Now in 2018. He also intends to standardize a library solution for Unicode based on this work. Talk: https://www.youtube.com/watch?v=944GjKxwMBo Slides: https://tinyurl.com/boost-text-slides We encourage your participation in this review. At a minimum, kindly state: - Whether you believe the library should be accepted into Boost * Any conditions for acceptance - Your name and knowledge of the problem domain. You are strongly encouraged to also provide additional information: - What is your evaluation of the library's: * Design * Implementation * Documentation * Tests * Usefulness - Did you attempt to use the library? If so: * Which compiler(s) * What was the experience? Any problems? - How much effort did you put into your evaluation of the review? Even if you are not submitting a formal review, your feedback on the library is welcome. Glen

1 0

Impossible to download a boost source from bintray: 403 Forbidden
by Eisuke Kawashima 08 Jun '20

08 Jun '20

Dear All, I cannot download a boost source from bintray, e.g., https://dl.bintray.com/boostorg/release/1.73.0/source/boost_1_73_0.tar.bz2 returns 403 Forbidden. OTOH, sourceforge works: https://sourceforge.net/projects/boost/files/boost/1.73.0/boost_1_73_0.tar.…. Best -- Eisuke Kawashima e.kawaschima+boost(a)gmail.com

3 4

[review][LEAF] Review period is over
by Michael Caisse 04 Jun '20

04 Jun '20

I apologize for not sending this out earlier. The review period is officially complete. A few people have contacted me about completing reviews that they in the middle of and I will be waiting until after this coming weekend to publish the review results. Thank you to those that joined the conversation and provided a review. michael -- Michael Caisse Ciere Consulting ciere.com

1 0

[SPAM] Boost.Container monotonic_buffer_resource and overaligned types
by Patrick Northon 03 Jun '20

03 Jun '20

Is there a reason why it won't allocated for anything over memory_resource::max_align? Inspecting the code, it seem to me that it would just work.

1 0

[review][LEAF] Review of LEAF starts today : May 22 - May 31
by Michael Caisse 02 Jun '20

02 Jun '20

The Boost formal review of Emil Dotchevski's LEAF (Lightweight Error Augmentation Framework) library will take place from May 22 through May 31st. LEAF isn't just another error reporting library in the family of expected-like types. It provides a unique take on error handling which plays into usability, flexibility, and performance. Every software developer must deal with handling errors which makes this review relevant to all. Please participate! I will be grateful to receive a review based on whatever level of effort or time you can devote. LEAF is brought to us by Emil Dotchevski, the author of Boost.Exception. Similar to Boost.Exception, this library allows arbitrary error objects to be returned; however, unlike Boost.Exception it does not require dynamic memory. The library can be used with or without exception handling. The LEAF documentation highlights the following features: * Efficient delivery of arbitrary error objects to the correct error handling scope. * No dynamic memory allocations. * Compatible with std::error_code, errno and any other error code type. * Can be used with or without exception handling. * Support for multi-thread programming. "LEAF is designed with a strong bias towards the common use case where callers of functions which may fail check for success and forward errors up the call chain but do not handle them." LEAF offers a pattern matching facility to specify which errors to handle and how to handle them. Take a look at the 5-minute Introduction. <https://zajo.github.io/leaf/#introduction> You can find the source code to be reviewed here: <https://github.com/zajo/leaf/tree/review> You can find the documentation here: <https://zajo.github.io/leaf/> The documentation includes a tutorial, examples, reference, design rationale, and comparisons to other error handling approaches/libraries. There is a benchmark document also: <https://github.com/zajo/leaf/blob/master/benchmark/benchmark.md> and a whitepaper: <https://github.com/zajo/leaf/blob/master/doc/whitepaper.md> Please provide in your review information you think is valuable to understand your choice to ACCEPT or REJECT including LEAF 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 here: <http://www.boost.org/community/reviews.html> Thank you for your effort in the Boost community. Happy coding - michael -- Michael Caisse Ciere Consulting ciere.com

3 2

[review][LEAF] Additional reviews in progress?
by Michael Caisse 01 Jun '20

01 Jun '20

Anybody in the process of producing a review to submit? Please respond here or contact me directly. -- Michael Caisse Ciere Consulting ciere.com

1 0

[review][LEAF] Review of LEAF
by Sorin Fetche 01 Jun '20

01 Jun '20

On Fri, May 22, 2020 at 2:37 AM Michael Caisse via Boost <boost(a)lists.boost.org> wrote: > > The Boost formal review of Emil Dotchevski's LEAF (Lightweight Error > Augmentation Framework) library will take place from May 22 through May > 31st. I wholeheartedly recommend ACCEPTing LEAF as a Boost library I base my recommendation on both the qualities of the library itself and the responsiveness and openness for feedback of its author. As a background, more than year ago, I evaluated error handling using LEAF in the context of an in-house support library for implementing C++ RESTful services. I consider the error handling for microservices based architectures very important because it needs to cover two, sometimes competing, requirements: - as debug logs are less than ideal in distributed systems, an error condition should capture and carry with it as much context and debug information as possible as it propagates back across the stack (both in-process and across different processes/services); - the end-user of the system should not just get a dump of meaningless debug information when an error condition occurred (but neither just a generic "internal error occurred" one). And, coming from the experience of using Boost.Exception for an earlier version of such a utility library, LEAF seemed a very good candidate. So, as part of this evaluation, I tried to see how it would fit alongside Boost.Asio and Boost.Beast in building this REST oriented scaffolding. Through the course of this experimentation, LEAF improved its support for being used with Asio style asynchronous operations and multi-threading. It also includes now an example built at that time that showcases a possible way for how this integration can be be achieved. > - What is your evaluation of the design? Excellent as it allows bridging multiple error handling strategies and usage patterns in an efficient way. I view it as a clear successor to Boost.Exception and has very good interoperability with Boost.Outcome. > - What is your evaluation of the implementation? I have not studied it in depth but from what I can tell, as a user of the library, it is very solid. > - What is your evaluation of the documentation? Excellent! > - What is your evaluation of the potential usefulness of the library? It might not cover any possible usage scenario with error reporting and handling being such a generic problem space that often has conflicting requirements, but for sure it covers enough of it to warrant its inclusion in Boost. > - Did you try to use the library? With which compiler(s)? Did you > have any problems? Yes, extensively last year. Less so, recently [*] Tried it with Visual Studio 2019, g++ 7.3 and 8.2, clang 7.0 > - How much effort did you put into your evaluation? A glance? A quick > reading? In-depth study? In depth study and usage about an year ago. Following the changes it has suffered since then (nothing significant from what I can tell). > - Are you knowledgeable about the problem domain? > I have used multiple error handling libraries over time. And, I also had to deal with distributed systems that had an improper or lacking error handling design, something simply slapped on as an afterthought. [*] The part of the project requiring C++ based services and by extension the infrastructure to enable writing them has been postponed as we (the team I'm part of) focused more on the environment where these services would run. I expect we'll resume this work sometime later this year. And at that time we'll start using the LEAF library again. Best regards, Sorin Fetche

4 7

[review][LEAF] Review period ending soon - May 31
by Michael Caisse 30 May '20

30 May '20

I'd like to encourage each of you to review Emil's error handling library. We often focus on design or implementation based reviews, and I encourage those but what I would really like to see are more user based reviews. Grab the library and docs and play with it a bit. What works well? What can be improved? As a reminder, some of LEAF's features include: * arbitrary error types * header-only * no dependencies * use without exceptions * use with exceptions * no dynamic memory alloc You can find the documentation here: <https://zajo.github.io/leaf/> and the library source here: <https://github.com/zajo/leaf/tree/review> Thanks! michael -- Michael Caisse Ciere Consulting ciere.com

5 8