- Boost - lists.preview.boost.org

[review] Mp11 review starts in one week
by Bjorn Reese 08 Jul '17

08 Jul '17

The formal review of Peter Dimov's Mp11 library is scheduled for July 15 - July 24, 2017 [1]. Mp11 is a C++11 metaprogramming library for compile-time manipulation of data structures that contain types. It’s based on template aliases and variadic templates and implements the approach outlined in the article "Simple C++ metaprogramming" [2] and its sequel [3]. These articles are useful background information for the review. * Mp11 aims to make simple usage simple, and to support complex usage without complicating the simple use cases. * Mp11 works on any type-list, whether its own type-list mp_list, or standard type-lists such as std::tuple and std::variant, or user-defined type-lists. * Mp11 works with any meta-function, such as C++11 or Boost type-traits, or user-defined type-traits. Mp11 can be found here: * Documentation: https://rawgit.com/pdimov/mp11/master/doc/html/mp11.html * Source code: https://github.com/pdimov/mp11/tree/master [1] http://www.boost.org/community/review_schedule.html [2] http://pdimov.com/cpp2/simple_cxx11_metaprogramming.html [3] http://pdimov.com/cpp2/simple_cxx11_metaprogramming_2.html

1 0

[beast] Missing documentation link
by Bjorn Reese 08 Jul '17

08 Jul '17

The link to example/common/file_body.hpp in the Examples section has gone missing. Please fix this ASAP. All links in the Examples section point the the master branch instead of the review branch.

2 2

[bootstrap] [b2] [install] Intel 17.0 & b2 cmd file for intel64 & vs2017
by Robert 07 Jul '17

07 Jul '17

Hello Everyone, I have had zero responses on the boost-build list since posting June 23, 2017. Hopefully there will be some here. This is most definitely not urgent. There is a chance that a solution in this thread may be important enough to add to a 1.65 jam file. There are many details in order to fully describe the situation. Executive Summary: In order to correctly build Boost 1.64 with the Intel 17.0, Update 4, C++ Windows compiler, in conjunction with Visual Studio (VS) 2017, Update 2, a symbolic link is necessary. The link shortens the VS installation root path for b2.exe to execute correctly. There is a question regarding the correct implementation to modify one or more jam files. The b2.exe automatic detection of the new and different Visual Studio 2017 paths is not working correctly. Details: I have succeeded constructing the b2 complete install for Intel 17.0, Update 4 on Windows 8.1 Pro, 64-bit, in conjunction with Visual Studio 2017, Update 2 (e.g. 15.2 (26430.12), in the About Microsoft Visual Studio dialog). The zlib source and Python 2.7 libraries are also incorporated into the x64 Boost by Intel build. In order to achieve a successful outcome, I create a symbolic link with the mklink command to considerably shorten the value for the VS2017INSTALLDIR environment variable. The value VS2017INSTALLDIR is first set to is: C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise The content above triggers two, "input is too long," messages when executing the .\b2 install --prefix=C:\Boost command. The execution never creates the respective b2 cmd file (file name listed below). The Intel supplied batch file is looking for the VS2017INSTALLDIR environment variable, when the vs2017 option is passed to compilervars.bat: compilervars intel64 vs2017 The location of the compilervars.bat is in something similar to: C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2017.4.210\windows\bin Please review https://software.intel.com/en-us/articles/building-boost-with-intel-c-compi… for the recent details from Intel, to build Boost with the Intel compiler on a Windows operating system. The symbolic link is C:\v7 pointing to: C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise When the VS2017INSTALLDIR environment variable is C:\v7, then the execution of b2 install at <boost root>\tools\build creates the 32-bit and 64-bit b2_intel-win_17.0_iclvars... command files in C:\Users\<username>\AppData\Local\Temp. I would like to understand whether the b2 constructed output for the file named: b2_intel-win_17.0_iclvars_intel64 vs2017.cmd should have its internal DevEnvDir variable value as this: DevEnvDir=C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\ or this: DevEnvDir=C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\ If the answer is the latter, then what is the correct modification(s) to the intel-win.jam, user-config.jam, and/or msvc.jam to enable the automatic detection to find the correct location for VS2017's devenv.exe? In order to use the 14.1 Visual Studio version string value, the 1.64 intel-win.jam file has been modified accordingly near the last line: .iclvars-17.0-supported-vcs = "14.1 14.0 12.0 11.0 10.0" ; .iclvars-version-alias-vc14.1 = vs2017 ; I have manually replaced the following strings of the b2_intel-win_17.0_iclvars_intel64 vs2017.cmd file to use the new Visual Studio 2017 paths. For example, the following older VS 2015 paths are equivalent to the following new VS 2017 paths (using the C:\v7 symbolic link above). Note that some paths are very long in VS2015. The VS2017 equivalent can be longer. The replacement string is preceded by the "==>" character combination. C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\VC\ ==> C:\v7\Common7\IDE\VC\ C:\Program Files (x86)\MSBuild\14.0\bin\amd64 ==> C:\v7\MSBuild\15.0\Bin\amd64 C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\amd64 ==> C:\v7\VC\Tools\MSVC\14.10.25017\bin\HostX64\x64 C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\VCPackages ==> C:\v7\Common7\IDE\VC\vcpackages C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE ==> C:\v7\Common7\IDE C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Tools ==> C:\v7\Common7\Tools C:\Program Files (x86)\Microsoft Visual Studio 14.0\Team Tools\Performance Tools\x64 ==> C:\v7\Team Tools\Performance Tools\x64 C:\Program Files (x86)\Microsoft Visual Studio 14.0\Team Tools\Performance Tools ==> C:\v7\Team Tools\Performance Tools\ C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\CommonExtensions\Microsoft\TestWindow ==> C:\v7\Common7\IDE\CommonExtensions\Microsoft\TestWindow C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\PrivateAssemblies\ ==> C:\v7\Common7\IDE\PrivateAssemblies\ The affected cmd variables are: DevEnvDir INCLUDE LIB LIBPATH Path VCIDEInstallDir __VSCMD_PREINIT_INCLUDE __VSCMD_PREINIT_LIBPATH __VSCMD_PREINIT_PATH Thank you for your time and attention. It is greatly appreciated. Sincerely, Robert

1 0

[beast] Review
by Marcel Ebmer 07 Jul '17

07 Jul '17

Here's my Review: DESIGN ====== The design of concepts, data structures and algorithms is mostly done well, with only minor concerns: - The smell of two-phase initialization. Required message properties like method and target have to be set from outside. This makes me as a library user afraid of forgetting something vital. The same holds for prepare_payload(). If I forget to call prepare_payload() or forget to set one of the required message properties or fields, my program may - in the worst case - appear to work correctly. - Inconsequent application of automagic. WebSocket control frames are automagically responded to. Iff there's an active read(). Basically, having an active read() at almost all times is a requirement of any correct program using Beast. Even though I enjoy the help from the library, and the requirement is usually met, I found this specific behaviour to be inconsequent. Also, the very first WebSocket example in the docs makes it clear that while a close from the peer is handled automagically under the above condition, a close from my side is quite tedious to write. There should be a utility in the library to do the draining for me. - The naming of BodyReader and BodyWriter initially got me confused. In my mind, I 'read' a body FROM a stream/buffer, I 'write' it INTO a stream or buffer. The library uses the terms in the reverse sense. This is not incorrect of course, but my initial confusion may be a sign of suboptimal naming. IMPLEMENTATION ============== Didn't look in-depth. DOCUMENTATION ============= The documentation is very well structured. It is complete in many, but not all places. - A minimalistic HTTP server example would have helped me get started. Just something very, very basic. Reply to each request with "your request was". - In some places, non-self-explanatory function names suddenly pop up without being first introduced. For example, in the section "Using WebSocket"."Send and Receive Messages", text() and got_text() could use some explanation. In the same section, the reference to set_option() seems out-of-place and makes me wonder what I missed. - Since the documentation features comparison with other libraries, it may be worth comparing pion (https://github.com/splunk/pion) as well. - Many reference pages could use some prosaic explanation. For example, my uncertainty concerning message.prepare_payload() might have been alleviated, were it more clear what the function is intended for and what the effect of omitting it would be. SCOPE ===== Since the FAQ is quite defensive in regard to the library's scope, I feel this is worth some discussion. I found the scope to be just right for now, but with future potential. As it is, the library takes away all the tedious protocol stuff, while leaving all important design decisions to the user. It feels like an extension to ASIO. However, there's no apparent reason why (e.g.) request targets shouldn't be URL-decoded, and why form data should not be parsed into a map of some kind. The way I see it, none of this added funtionality would interfere with the library's design. It would, however, make the library user's life a whole lot easier, and probably attract more users as well. USEFULNESS ========== See SCOPE. Very valuable, could be even better. HOW MUCH EFFORT & TRIED TO USE ============================== I invested about a day into the review, read the documentation and ported a small REST-like service from pion to Beast. I may be biased towards Beast due to temporal proximity, but I feel the latter made the code easier to reason about and, at the very least, did not hurt performance. I used gcc 7.1 and clang 4.0. On the review branch, none of the two had any issues. I deliberately did NOT follow the discussion on the mailing list, in order to remain as unbiased as practicable. HOW KNOWLEDGABLE AM I? ====================== I have worked on several HTTP servers and experimented with writing an HTTP server library a few years back. I have no practical experience with WebSockets. IN ONE SENTENCE =============== Beast should be ACCEPTED into Boost. Marcel

2 3

[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