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

[build] No output until an action completes?
by Tom Westerhout 07 Jul '17

07 Jul '17

Greetings! I've run into a problem that a Boost.Build action produces no output until the command returns. For example, in my Jamfile I have rule do-measure ( test-name : sources * : requirements * ) { ... some preparation work ... } actions do-measure { $(COMMAND) $(ARGS) } notfile ha : @do-measure : ... : ... ; COMMAND is a Python script that runs for a long time and produces some debug information. But b2 does not print this output until COMMAND returns. This is really unfortunate because Travis requires a command to produce output at least once per 10 mins or something. Otherwise it thinks the command has stalled and terminates it. Is there some configuration parameter or a trick to make b2 print the debug info COMMAND produces? or maybe some dummy output so that Travis allows it to run longer than 10 mins? Any help is highly appreciated! Tom

2 2

Serialization support for small_vector
by Brian Wood 07 Jul '17

07 Jul '17

Shalom I've added support for small_vector to the C++ Middleware Writer. While testing the support, I got a warning about dereferencing a type-punned pointer breaking strict-aliasing rules. That was on line 340 of small_vector.hpp. I was using g++ 7.1 on FreeBSD/ TrueOS. I used the following "Middle" code for testing: message-lengths variable example_messages -out (message_id_8, ::boost::container::small_vector<int32_t,30>) -in (::boost::container::small_vector<int32_t,30>) } >From what I could tell the serialization/deserialization worked fine. If small_vector were broken out into a separate library that would be helpful from my perspective. It would make it easier for me to add small_vector to my example code. Brian Ebenezer Enterprises - In G-d we trust. http://webEbenezer.net

1 0

[CallableTraits] Review results
by Louis Dionne 07 Jul '17

07 Jul '17

Dear Boost, I am pleased to announce that the CallableTraits library is CONDITIONALLY ACCEPTED into Boost. I counted the following formal reviews: - Bruno Dutra: Yes - Emil Dotchevski: Yes - John P. Fletcher: Yes - Klemens Morgenstern: Yes - Peter Dimov: Yes - Zach Laine: Yes The following people also participated to the review by providing informal feedback: - Edward Diener - Gavin Lambert - Niall Douglas - Paul Fultz II - Tim Song I also based my decision on previous experience I've had using the library, and some issues we faced in the Standard Committee where we could have used CallableTraits. I'd like to thank everyone who participated to the review for their feedback, and also Barrett Adair for his submission. The following lists the conditions for acceptance, and also summarizes the general feedback received during the review. GitHub issues are leveraged to make the tracking of these comments easier. Below, whenever I refer to #XYZ, the corresponding ticket can be found at https://github.com/badair/callable_traits/issues/XYZ To see all the issues that were discussed during the review, you can search for tickets labeled with `review` on GitHub (please allow some time for Barrett to update the new issues I just filed): https://github.com/badair/callable_traits/issues?page=1&q=+label%3Areview Conditions for acceptance ------------------------- The following are points that must be addressed for the library to be accepted. Once all of the associated GitHub issues are closed, I ask that the author post to this list with links to the closed issues. Unless major problems (having to do with the closed issues) are raised at that time, the library will be automatically accepted into Boost, no additional review required. - The library needs to clearly document the advantages of CallableTraits over FunctionTypes. Concrete examples must be given (at least one, preferably two). See #117. - The level of C++ conformance required for the whole library needs to be clearly stated in the documentation. Individual components should only document divergences from that base level of conformance. The current state of things is quite confusing for users. See #118. - The "algorithmic" parts of the library must be removed, since they are out of scope. This has already been partly done in issue #114, but the following algorithms must be discussed too (let's follow up in #114): + args_at + clear_args + pop_front_args + push_front_args + expand_args_right + expand_args_left - The lazy metafunctions and predicate traits should be SFINAE-friendly, just like the aliases are. I think this inconsistency is a big deal, enough to be a condition for acceptance. See #134. Summary of the feedback received -------------------------------- The following is a compilation of other points that were made during the review, but which are not requirements for acceptance. I trust, but do not require, that all of those points will be considered by the author: - There is a loss of information with the `args` metafunction. For example, `void(T)` and `void(T, ...)` both give the same result. See #132. - Consider adding a way of obtaining the parameter list of a function without the type of `*this`. See #133. - The documentation uses the terms of art "implementation defined" and "undefined behavior" incorrectly. See #103 and #131. - The non-reference documentation should present at least one real-world use case. See #116. - The library should handle top-level cv-qualifiers. See #106. - Consider supporting different calling conventions (e.g. `__cdecl`). See #102. - Consider adding a pre-C++17 implementation of `is_invocable` and friends. See #119. - The documentation should clearly state that the library can be used without the rest of Boost. See #99. - Consider combining `expand_args` and `args` into a single metafunction with a default "output" parameter of `std::tuple`. See #126. - Consider adding `make_fn` and `make_mem_fn` metafunctions to construct a signature from a return type and a tuple of the arguments. See #113. - Consider renaming some traits, like `is_reference_member`. See #108. - Reword some parts of the documentation that look odd due to the use of passive tense. See #105. - Consider adding a version of `apply_member_pointer` which carries cv-qualifiers. See #138. - Consider adding `remove_member_cv_ref` and `copy_member_cv_ref`. See #139. - Why does `qualified_parent_class_of` always returns a const& for PMDs? See #112. - Why does `qualified_parent_class_of` return a ref-qualified type even for unqualified PMFs? See #112. A few of my own comments: - Consider using alphabetical order in the table of contents of the reference. See #135. - Consider renaming `apply_member_pointer` to something like `make_member`. See #136. - Consider dropping the `parent_` in `parent_class_of`, or adding a note to justify the name. See #137. Again, thanks to everyone who participated in the review, and congratulations to Barrett for his work! Regards, Louis Dionne

2 3

[beast] Chunking example
by Bjorn Reese 06 Jul '17

06 Jul '17

How would an example of receiving a chunked transfer using the synchronous API look? In pseudo-code, I want to do as follows: establish connection while not closed read chunk print chunk

4 25

Boost Master branch is now closed for the beta
by Marshall Clow 06 Jul '17

06 Jul '17

Except with explicit permission by a release manager. Do whatever you want on develop, just don't change master. We'll re-open master after the beta. -- Marshall Upcoming release schedule: 8-Jul: Boost 1.65.0 closed for all changes 12-Jul: Boost 1.65.0 beta; master branch re-opened 2-Aug: Release closed for all changes, except by permission of a release manager. 5-Aug: Boost 1.65.0 closed for all changes 9-Aug: Boost 1.65.0 release -- Marshall

4 3

Fwd: [review][beast] Review of Beast
by Michael Caisse 06 Jul '17

06 Jul '17

I received this review as a private email from Stanislav who has indicated that I may share it on the list. -------- Forwarded Message -------- Subject: [boost] [review][beast] Review of Beast Date: Thu, 6 Jul 2017 20:23:26 +0300 From: Stanislav Karchebnyy <hidden> To: mcaisse-lists(a)ciere.com Good day! I'm not a very good writer in english, so i tried to keep it short and to the point. - What is your evaluation of the design? I believe it fits well with asio style. - What is your evaluation of the implementation? I like the modularity and composability of the library, e.g. various buffers that comply with asio interfaces. Also use of helpful typedefs makes code a lot easier to read. Code style is almost declarative (which is a good sign in my book). - What is your evaluation of the documentation? Documentation is good, although some methods are documented a little short and a bit tautologically. This is not specific to beast however, seen it in many other boost libraries. - What is your evaluation of the potential usefulness of the library? It is immensely useful as it is already. See below for the example. - Did you try to use the library? With which compiler(s)? Did you have any problems? Currently I’m developing with Beast on latest OSX with clang. It compiles cleanly and runs quite well. The aim is to later use it also on Linux with gcc. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I’m in process of converting our POCO-based networking code for HTTP/HTTPS client and Websocket client to Beast. I started with Websocket and it was a pleasant and rather quick conversion from POCO-style ActiveDispatcher methods (which are ugly with binds and tuples for argument packs) to truly asynchronous beast websocket implementation. We use own protocol running on top of websocket frames, and with beast it was really easy to implement. That beast is a construction framework and does not have unnecessary boilerplate made it quite easy to plug our own parsing engine directly on top of websocket frames. Code became much cleaner as a result. I did not do speed benchmarking yet, as I’m still in development phase, but I’m much more concerned about maintainability in this project and beast made it a lot better - unfortunately I cannot share the code, but now I can trace the state transitions with a glance, instead of digging through bunch of POCO tuple-ridden methods. Another improvement is the fact that POCO websocket uses a dedicated listener thread for input, while beast utilises proper asio design. Beast comes with quite good examples, that covered about 90% of my questions during transition, the rest was answered by Vinnie himself. He is very responsive and helpful as a library maintainer. - Are you knowledgeable about the problem domain? Yes, I know how http and websocket things are supposed to work. My overall impression with the library and its author helpfulness suggests that ACCEPT to boost is a reasonable move. -- Sr. Software Engineer twilio <http://www.twilio.com/?utm_source=email_signature> EMAIL hidden

1 0

[beast] Response alias?
by Bjorn Reese 06 Jul '17

06 Jul '17

Is it possible to provide a HTTP 200 response alias for Beast? This is needed for SHOUTcast internet radio servers. See for instance: https://curl.haxx.se/libcurl/c/CURLOPT_HTTP200ALIASES.html

2 1

string_view versus string_ref
by Andrzej Krzemienski 06 Jul '17

06 Jul '17

Hi Everyone, I would like to understand the situation with these two templates: basic_string_view and basic_string_ref. The official, advertised library is string_ref: http://www.boost.org/doc/libs/1_64_0/libs/utility/doc/html/string_ref.html At the same time we have string_view: http://www.boost.org/doc/libs/1_64_0/boost/utility/string_view.hpp But the latter is never mentioned in the documentation, except in Boost.Log: (see http://www.boost.org/users/history/version_1_61_0.html) The support for boost::basic_string_ref and its specializations is > deprecated; users are encouraged to switch to boost::basic_string_view. > The support for boost::basic_string_ref will be removed in future > releases. > My question: is there any official position of Boost about having these two templates? Regards, &rzej;

4 3

[beast] Looking for ongoing Code Review!
by Vinnie Falco 05 Jul '17

05 Jul '17

Time for a realistic self-assessment. The feedback that I've gotten about Beast thus far has been pretty great, thanks to everyone for taking the time to get familiar with it. Seems like people are overall approving of the technical quality, but there is a recurring theme with the complaints. Specifically that there are small quality of life issues and deviations from best practices. For example, the two-phase initialization, missing verification on SSL client, verbose or missing examples, confusing or missing parts of documentation. Someone suggested that I solicit assistance from the list. I would like to have ongoing code review of everything in Beast before it gets merged. It would benefit the library greatly and thus benefit its users. As new features get developed ("in-scope" items such as file_body) having an extra set of eyes to make sure I don't do something silly or obviously unpleasant would be helpful. This also reduces the possibility that a future version of Beast may require a breaking change. I'm looking for volunteers to provide regular ongoing code review of branches in Beast's pull request queue! I realize this is a big ask, especially because I have a knack for producing quite a bit of code and change over time. Still, its worth asking. Ideally this review will come from stakeholders (i.e. users of the library). Any Beast users who are out there, please consider participating in code reviews. Its easy just subscribe to the repository using the button on the right of its GitHub page and then when you see new pull requests jump in there and add comments on anything you love/hate. I'll take whatever I can get though, so anyone is welcome! Email me if you want to discuss it, <vinnie.falco(a)gmail.com> or just open an issue on the repository: <https://github.com/vinniefalco/Beast> Thanks! |

1 0

[beast] Platform proxy settings, SSL verification
by Phil Endecott 05 Jul '17

05 Jul '17

Here are just a few quick comments re Beast: 1. It's a terrible name, but I believe others have already mentioned that. 2. I don't believe there is any integration with platform proxy settings. I'll explain: I have my own basic HTTP client and server code that I've used in a handful of projects. There are a few features that it lacks that have caused me problems. In particular, when I tried to use my HTTP client code in an iOS app, it worked on WiFi networks but not on some cellular networks. After much remote debugging I realised that some cellular carriers in some countries require that HTTP traffic goes via a (non-transparent) proxy. If you use the iOS http client then this is handled for you, but my code knows nothing about it. For me to test a fix for this I would have had to fly to another continent.... This is the sort of thing that is particularly valuable in a Boost library: I try to write portable code, but I don't know the details of every platform that it will run on or even have test systems available to me. Having a library that knows about the platform-specific details, and which has been tested on a wide variety of those platforms, is very valuable. (And a library that instead just does the "easy parts" is something that I could have written, or already have written, myself.) 3. Finally a comment about the SSL example at https://github.com/vinniefalco/Beast/blob/master/example/http-client-ssl/ht… This says stream.set_verify_mode(ssl::verify_none); Please correct me if I'm wrong, but I think that means that it does not do any sort of certificate verification. As a matter of principle, I think that the *first* SSL example should show how to establish a properly-secure connection. See for example http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf (""The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software") and e.g. https://lwn.net/Articles/522111/ for discussion. A quick look at http://www.boost.org/doc/libs/1_47_0/doc/html/boost_asio/overview/ssl.html suggests that this might add as few as two more lines to the code. Regards, Phil.

2 4