December 2017 - Boost - lists.preview.boost.org

Re: [boost] Boost.HTTPKit, a new library from the makers of Beast!
by Vinnie Falco 01 Jan '18

01 Jan '18

On Sun, Oct 8, 2017 at 5:38 PM, Vinícius dos Santos Oliveira <vini.ipsmaker(a)gmail.com> wrote: > Now, moving on... given that you have __not__ answered how your parser's > design[1] compares to the parser I've developed I'll try to provide more clarity. `beast::basic_parser` is designed with standardization in mind, as I intent to eventually propose Beast for the standard library. Therefore, I have made the interface as simple as possible, exposing only the minimum required necessary to achieve these goals which the majority of users want: * Read the header first, if desired * Feed Asio style buffer sequences into the parser * Set independent limits on the number of header and body octets * Optional fine-grained receipt of chunked body data and metadata The design of basic_parser (the use of CRTP in particular) is meant to support the case where a user implements their own Fields container, or if they want a bit more custom handling of the fields (for example, to avoid storing them). Like all design choices, tradeoffs are made. The details of parsing are exposed only to the derived class. Complexities are hidden from the public-facing interface of `basic_parser`. Implementing a stream algorithm that operates on the parser is a straightforward process: template< class SyncReadStream, class DynamicBuffer, bool isRequest, class Derived> std::size_t read(SyncReadStream& stream, DynamicBuffer& buffer, basic_parser<isRequest, Derived>& parser, error_code& ec) { parser.eager(true); if(parser.is_done()) { ec.assign(0, ec.category()); return 0; } std::size_t bytes_transferred = 0; do { bytes_transferred += read_some( stream, buffer, parser, ec); if(ec) return bytes_transferred; } while(! parser.is_done()); return bytes_transferred; } > [1] at most it hides behind a “multiple people/stakeholders agree with me” > __shield__ There's no hiding going on here. One can only measure the relative success of designs based on the feedback from users. They opened issues, and I addressed their use-cases, sometimes with a considerable amount of iteration and back-and-forth as you have seen in the GitHub issues quoted in the previous message. Now, I don't know if the sampling of users that have participated in Beast's design are representative of the entire C++ community. However, I do know one thing - if GitHub stars are any measure of the sample size of the participants, then Beast is off to a good start. Here's a graph showing the number stars over time received by boostorg/beast, tufao, and Boost.Http (the last 2 libraries having you as the author I believe): <http://www.timqian.com/star-history/#boostorg/beast&BoostGSoC14/boost.http&…> (Note that the HTTP+WebSocket version of Beast was released in May 2016). We need to be careful interpreting results like this of course so perhaps we should look at different metrics. Here are the links to the number of closed issues for Beast, tufao, and Boost.Http: 502 Closed issues in Beast: <https://github.com/boostorg/beast/issues?q=is%3Aissue+is%3Aclosed> 38 Closed issues in tufao <https://github.com/vinipsmaker/tufao/issues?q=is%3Aissue+is%3Aclosed> 13 Closed issues in Boost.HTTP, from 6 unique users not including the author <https://github.com/BoostGSoC14/boost.http/issues?q=is%3Aissue+is%3Aclosed> Again we have to be careful interpreting results like this. But it sure looks like there is a lot of user participation in Beast. If approval from a large number of stakeholders is not a compelling design motivator then what is? > This tutorial is full of “design implications” blocks where I take the time > to dissect what it means to go with each choice. Thus far, no one has asked for more fine grained access to incoming HTTP tokens in the manner of `code::method` and `code::request_target`. If this becomes something that users consistently ask for, it can be done by changing the requirements for the derived class for `basic_parser`. This way, details about HTTP parsing which most people don't care about will not leak into the beast::http:: namespace. Such a change would not affect existing stream algorithms on parsers. Thanks

5 17

Re: [boost] What hash functions should be included in a hypothetical Boost hash-v2 library?
by Bjorn Reese 31 Dec '17

31 Dec '17

On 12/31/17 01:28, Peter Dimov via Boost wrote: > What (non-cryptographic) hash functions should a hypothetical future > Boost hash library contain? Have clear winners emerged by now? Which > ones do people prefer? I vote for FNV hashes: https://en.wikipedia.org/wiki/Fowler%E2%80%93Noll%E2%80%93Vo_hash_function

1 0

What hash functions should be included in a hypothetical Boost hash-v2 library?
by Peter Dimov 31 Dec '17

31 Dec '17

What (non-cryptographic) hash functions should a hypothetical future Boost hash library contain? Have clear winners emerged by now? Which ones do people prefer? SipHash is basically a given, but it's not optimized for speed.

5 6

Removing hash from Boost.Functional broke modules
by James E. King, III 28 Dec '17

28 Dec '17

See: https://github.com/boostorg/type_index/issues/18 There is no forwarding header to keep things compatible. - Jim

2 1

Maintenance of Boost.DateTime
by James E. King, III 28 Dec '17

28 Dec '17

The backlog for Boost.DateTime in trac has over 130 issues; the project is holding on to very old backwards compatibility code (pre-boost-1.33.0 i/o facets), and the CI builds do not currently have appveyor, codecov.io, or coverity scan integration. It needs a proper maintainer in order to resolve these issues, so I would like to ask for that privilege. Thanks, Jim

1 0

Appveyor and Travis CI notifications of Boost library tests
by Edward Diener 26 Dec '17

26 Dec '17

Is there a way to tell Appveyor or Travis CI to send notifications of its Build runs of Boost libraries to someone other than myself ?

4 7

Candidate for 1.66.1, if there is one
by James E. King, III 25 Dec '17

25 Dec '17

In Boost 1.66.0, there was a fix to date_time for the year 2038 problem: https://github.com/boostorg/date_time/pull/35 The serialization code in date_time had no static assertions enforcing the size of data values, and adding proper versioning support was missed in the release by myself and not picked up in the code reviews. As a result, serializing in anything written by earlier boost versions fails for date_time related structures, which might be considered serious enough to justify a 1.66.1 release. (We could also get the latest msvc compatibility in there I suppose...) I'm adding proper versioning right now, however Boost 1.66.0 will remain a problem since it serializes in/out as Version 0 with 64-bit values; and 1.65.1 serializes in/out Version 0 with 32-bit values so I'm not certain there will be a way to detect this issue. The issue is recorded in github here: https://github.com/boostorg/date_time/issues/56 Any additional thoughts are appreciated. I'm looking at adding a test to write out a version 0 and then read it in when the current version is 1, but I don't want to add test-only support code to the headers that get shipped, so if anyone can point me at a current example unit test that writes out a "n-1" version and then reads in a "n" version with boost::serialization I would appreciate it. Thanks, Jim

9 22

Getting Started
by ishan garg 25 Dec '17

25 Dec '17

Hello everyone, I am new to OpenSource Development. I know basics of C++ and acquainted with it's STL. I have basic knowledge of DSA as well as few git commands (clone, push, commit, etc). I wanted to know how can I start contributing to BOOST library? Thanks in Advance -- Regards, Ishan Garg

2 1

library maintainer list
by Robert Ramey 24 Dec '17

24 Dec '17

I'm curious about how I might go about discovering and contacting the person(s) who might be maintaining a particular library. As an example, I have a couple of questions about possible enhancements to the boost interval library (what about making this constexpr?). Ideally, I'd like to see a summary page for each library which steers me to the appropriate links like issues, comments/issues page, maintainence status etc. such as the boost library incubator has. Actually, I considered just adding these pages to the boost library incubator website, but I didn't have the motivation and it might stir a pot I personally don't want to stir right now. Robert Ramey

6 10

regarding mailing list traffic
by Mudit Sharma 22 Dec '17

22 Dec '17

Dear All, I have recently not been receiving the daily Boost mailing list digest, is there some maintenance work going on ? Thanks! M

2 1