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

[stacktrace] Two days remaining before review ends
by Niall Douglas 27 Apr '17

27 Apr '17

Current summary of votes cast so far: * Peter Dimov: Unconditional acceptance * Vladimir Batov: Unconditional acceptance Am I missing any? If you are going to make a review and a recommendation, please do so soon. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

6 9

[Stacktrace] Second review begins today 17th Mar ends 26th Mar
by Niall Douglas 22 Apr '17

22 Apr '17

I am pleased to announce the second review of the proposed Boost.Stacktrace library running from today until Sunday 26th. Stacktrace is an optionally header-only library providing multiple implementation backends. At its very simplest it lets you capture the stack backtrace for the calling thread and to print it to a std::ostream& of your choice. The basic_stacktrace<> class quacks like a STL container of frame object instances. The rest of the API pretty much follows STL design principles for the most part. Use is therefore unsurprising. You can find the documentation at http://apolukhin.github.io/stacktrace/index.html and the github repo at https://github.com/apolukhin/stacktrace. Review guidelines ================= This is a second review of this library with many changes implemented in response to feedback from the previous review. My previous review report can be found at http://lists.boost.org/boost-announce/2017/01/0486.php where I made the following conditions for acceptance: 1. That the documentation more clearly set out what Stacktrace does and especially does not do, and that the default facilities provided are those of the Minimum Viable Product described above i.e. no source file nor line number discovery, no external dependencies on libraries not always provided on the target platform, no invocation of child processes, no async safety during stacktrace parsing. Stacktrace ought to be pared back to the minimum viable product featureset with no external dependencies at all. 2. That suitable predefined macros opt in to additional functionality such as serialisation of offset translated backtraces, retrieval of source code path and line number etc. Enabling these may introduce dependencies on third party libraries not always present on a system such as libunwind, or on third party helper utilities such as addr2line. I would recommend that the APIs the use of which are dependent on such third party items are entirely compiled out of Stacktrace when the macro enabling them is not defined. 3. That the documentation describe ONLY the default minimum viable product functionality in its tutorial and quick start. All extra functionality enabled by macros is to be relocated into a separate documentation section away from the main documentation e.g. "Advanced/optional features". 4. That APIs made available only when a given macro has turned them on are documented as such in the API reference docs. Antony hasn't entirely met my conditions, hence this second review. He has instead implemented this changelog: * Reimplemented boost::stacktrace::basic_stacktrace class to accept allocators and to have a small size * Added outputting of the path to the binary object into the stacktrace, when source location is not available * Allowed to use `libbacktrace` - a defacto standard for GCC/CLANG backtracing that does not fork and has a permissive license * Optimized stacktrace and frames ostreaming * Removed backends and made the default tracing to have only platform basic functionality. Added macros to enable additional functionality. * Fixed (theoretically) MinGW compilation * Added functions for async-safe dumping into memory or descriptor * Changed signal handling example to be async-signal-safe * Allowed users to choose how many frames to skip during stack capture * Removed `boost::stacktrace::stacktrace` functions and other internals from printed stack traces * Updated docs: * examples now use Boost.Exception * removed all the references to "backend" * reduced macro count * "Build, Macros and Backends" section was rewritten and became "Configuration and Build" * added note that library is C++03 * added examples on storing traces into shared memory * updated all the human readable dumps It is up to the Boost community as to whether this revised library is now acceptable without any conditions, or with conditions. Reviews should be submitted to the developer list (boost_at_[hidden]), preferably with '[stacktrace]' in the subject. Or if you don't wish to for some reason or are not subscribed to the developer list you can send them privately to me at 's_sourceforge at nedprod dot com'. If so, please let me know whether or not you'd like your review to be forwarded to the list. For your review you may wish to consider the following questions: - 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 what compiler? 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? And finally, every review should attempt to answer this question: - Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Even if you do not wish to give a full review any technical comment regarding the library is welcome as part of the review period and will help me as the review manager decide whether the library should be accepted as a Boost library. Any questions about the use of the library are also welcome. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

9 44

[release] 1.64.0 post-beta merges
by Rene Rivera 11 Apr '17

11 Apr '17

The master branch is is now open for post-beta merges, but only as described in the Post-Beta Merge Policy. See < https://github.com/boostorg/boost/wiki/Release-Beta-Merge-Policy> -- The Boost Release Team

13 56

[flat_set] When to sort?
by Vladimir Batov 10 Apr '17

10 Apr '17

I've been using boost::container::flat_set with quite a success until recently when I profiled my app to see that 30-50% of the run-time was spent in insert() for a container of around 50,000 in size. So, I had to replace boost::container::flat_set with a vector variation which inserts as a vector (no sorting). However, when it is the time to call begin(), end(), find(), it sorts once. That shaved the mentioned overhead off. Say, one run is down from 17s to 10s and the likes. I wonder if that should be the boost::container::flat_set default behavior rather than sorting the underlying container with every insert(). After all, as a user I do not care if the underlying container is sorted... until I start using/traversing it, right? Or maybe I am missing something in boost::container::flat_set which already allows me to do something of that sort?

11 37

Announcing CallableTraits' formal review next week (April 3rd)
by Louis Dionne 09 Apr '17

09 Apr '17

Dear Boost community, The formal review of Barrett Adair's CallableTraits library starts Monday, April 3rd and ends on April 12th. CallableTraits is a C++11 library for the inspection, synthesis, and decomposition of callable types. CallableTraits aims to be the "complete type manipulation facility for function types" mentioned in the final paragraph of C++17 proposal P0172, and removes the need for template specializations for different function signatures. You can find the documentation of the library here: http://badair.github.io/callable_traits/doc/html/index.html and the GitHub repository here: https://github.com/badair/callable_traits We encourage your participation in this review. At a minimum, kindly state: - Whether you believe the library should be accepted into Boost - Your name - Your 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? Regards, Louis

4 4

[VS2017][release] vswhere.exe
by Mateusz Loskot 06 Apr '17

06 Apr '17

Hi, This is regarding issues with locating VS 2017 toolset(s). >From CMake ml, I learned about vswhere utility being developed by Microsoft https://github.com/Microsoft/vswhere vswhere.exe (390 KB) is downloadable from https://github.com/Microsoft/vswhere/releases I'm not sure how exactly, but perhaps it would solve some of the Boost.Build's headache (eg. particular PowerShell version required). For example, it can find all VS versions I've got installed (10.0, 11.0, 12.0, 14.0, 15.0): vswhere.exe -legacy find a particular version: vswhere -legacy -version [11.0,12.0) Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

15 38

[mailing list] No Reply-To in messages?
by Andrey Semashev 05 Apr '17

05 Apr '17

Hi, Sometimes I can see messages from the mailing list that have no Reply-To header. For example, this is the headers from a recent email from the ML: Delivered-To: andrey.semashev(a)gmail.com Received: by 10.223.171.174 with SMTP id s43csp1184445wrc; Tue, 21 Mar 2017 04:54:11 -0700 (PDT) X-Received: by 10.233.239.75 with SMTP id d72mr28079608qkg.313.1490097251746; Tue, 21 Mar 2017 04:54:11 -0700 (PDT) Return-Path: <andrey.a.davydov(a)gmail.com> Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com. [2607:f8b0:400d:c09::233]) by mx.google.com with ESMTPS id 5si5329794qty.259.2017.03.21.04.54.11 for <andrey.semashev(a)gmail.com> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Mar 2017 04:54:11 -0700 (PDT) Received-SPF: pass (google.com: domain of andrey.a.davydov(a)gmail.com designates 2607:f8b0:400d:c09::233 as permitted sender) client-ip=2607:f8b0:400d:c09::233; Authentication-Results: mx.google.com; dkim=pass header.i=(a)gmail.com; spf=pass (google.com: domain of andrey.a.davydov(a)gmail.com designates 2607:f8b0:400d:c09::233 as permitted sender) smtp.mailfrom=andrey.a.davydov(a)gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com Received: by mail-qk0-x233.google.com with SMTP id y76so54702989qkb.0 for <andrey.semashev(a)gmail.com>; Tue, 21 Mar 2017 04:54:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Az1Qy0ABDDY/isZXuI8r58lTLTG+E/wp0e0IliVZOAk=; b=oPSYU2baFZEWMUKF/s2hay278FTdFBfitQp4TNz5piq0zMWNqePuZaXbUD5SPP0Cnp He9gQzhynjuN/Lf4fpUtqjOWyntF2BSSrdpYbCSmaWnnSQjTz5s53EkOSVgojqHCfmVr A3CSJNK5QdAwkNAm+JQRIShSRO/YpWtK90Lhoa9lKlWF+JtIMwCgFG3h5vN1vw+W1xAB pNoHymY5rZ7Uh0WUHMlpEF/tmkD/tZzDss++3j/lKZNgX66VefCpi510BjKKkFfU2xdy zBba1I5hOOohBUzhlkYf5fSxZ1BkC6FSOizONZr1Mlx8AXLhl2MvmfW6KtR9nt9rjmSa Sfhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Az1Qy0ABDDY/isZXuI8r58lTLTG+E/wp0e0IliVZOAk=; b=OAFamTGJr76H6gmaG7LGcCRyHIp+Kj1SEs188yLqxEQGCvhYYdB8wMs6GsOYL0wYSY 9M1gYeXwexivqs+WF5Reg9CCh2mnkCUWTM6nSu9/B05sXFBUL/sVyEr7OuSXJpzVqOxl cZorectxLhbWqIqClTxYjSDNDKPJB9n+3OntHKp5l2gJY3mMPaILXbXRh6XXCMHxpYIy w1um18ndeJ0Ed7/nkhGKlzD2HvyPpkVPhjM+hhWmb+lxnVNhbpBFsoor28Yx5arAnVWb 0JndOFeqB3tfjv9DA5x/kuSStkSuG2Q439Fvd/2UuWKsqaR4JhaBejrE7jEnJgrN69on 8wfQ== X-Gm-Message-State: AFeK/H24Tvn8HI3rOm/9DXmcPc8Hok/lT3XOC2lfnuuWDiN5TsbtV56nLqNTPypggKQsasFDZvOER50I+HaBMH84 X-Received: by 10.55.15.195 with SMTP id 64mr28730703qkp.131.1490097251370; Tue, 21 Mar 2017 04:54:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.157.129 with HTTP; Tue, 21 Mar 2017 04:54:10 -0700 (PDT) In-Reply-To: <14065012-bde4-142d-eedf-b5fbf1f51d91(a)gmail.com> References: <CAN1iZb7pGGaFe9OKyDKxMB0Nryiqa3pxk5hLQY+1ybUCMNrZBQ(a)mail.gmail.com> <D5F339D7-3F03-4363-A2A5-F611FE8C76F0(a)gmail.com> <CAN1iZb54emhE_G9McfCmO2nN6D-qWqQSgSC-w1HdRqCAh08c8Q(a)mail.gmail.com> <14065012-bde4-142d-eedf-b5fbf1f51d91(a)gmail.com> From: Andrey Davydov <andrey.a.davydov(a)gmail.com> Date: Tue, 21 Mar 2017 14:54:10 +0300 Message-ID: <CAN1iZb6VHEUJvt9h8JN_1EubOcYponiEjdXWQGcGZ+VjU_hKJA(a)mail.gmail.com> Subject: Re: [boost] [smart_ptr] Is there any interest in unique_ptr with type erased deleter? To: boost(a)lists.boost.org Cc: Andrey Semashev <andrey.semashev(a)gmail.com> Content-Type: multipart/alternative; boundary=001a1146f4805976ff054b3c4d27 As a result, when I press Reply, the reply is addressed to the original email sender instead of the mailing list, which is really easy to miss before sending the message. Is it possible to ensure that every email from the ML contains boost(a)lists.boost.org in its Reply-To header? PS: I'm not a guru in email protocols, so if there is another more appropriate way of doing this then that would be fine with me.

13 35

[gsoc17] My proposal
by GuillermoReyes 01 Apr '17

01 Apr '17

Dear Vissarion and Adam, My name is Guillermo- a Computer science student at UCLA. I am excited at the possibility of contributing to such a useful library! My application is not yet complete, but I will post my draft on here to demonstrate my intent to participate in the program. For the competency test, I began to implement a representation of points on earth and used the great-circle formula to calculate the shortest distance between two points. I will have a more in-depth explanation of the code by the final iteration of the draft along with the complete proposal and application. Sincerely, Guillermo R. -- View this message in context: http://boost.2283326.n4.nabble.com/gsoc17-My-proposal-tp4693288.html Sent from the Boost - Dev mailing list archive at Nabble.com.

2 3

[Stacktrace] Review 2 Manager report
by Niall Douglas 31 Mar '17

31 Mar '17

Many thanks to all those who participated in the second review of proposed Boost.Stacktrace. I received the following formal reviews: 1. Peter Dimov (ACCEPT) 2. Vladimir Batov (ACCEPT) 3. Artyom Bellis (CONDITIONAL ACCEPT) 4. Bjorn Reese (ACCEPT) 5. Edward Diener (ACCEPT) Extensive comments without a formal recommendation were also made by: 1. Mark Bartosik 2. Florian Weimer Some of the more important conditions for acceptance as judged by the review manager are: * Problems on FreeBSD (and by inference OS X?). * Per frame execution of addr2line rather than calling it once. * Throw-with-trace was asked for by a lot of people. * One reviewer suggested that the addr2line backend was async signal unsafe. My reading of the code is that it is async signal unsafe to parse a stacktrace (and unavoidably so on any platform), but the capture of backtraces is now fully async signal safe. * Some disliked the bringing in of windows.h and the COM headers on Windows. For a header only library I consider this acceptable, Stacktrace when configured in non-header only mode does not inject windows.h into everything including stacktrace. Congratulations to Antony on getting yet another library of his into Boost! Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

3 2

[Beast] Redesigned HTTP algorithms and parser!
by Vinnie Falco 31 Mar '17

31 Mar '17

Background: Websocket connections start with an HTTP UPGRADE request/response sequence. Often people want to customize this handshake so I added code in Beast to read and write HTTP messages. Upon reviewing the HTTP RFC (rfc2616 and rfc7230) it seemed to be logical that the HTTP message could be modeled as a single class. And there could be free functions implementing the algorithms to serialize and deserialize these messages in th HTTP/1 format. I took this as far as I could and I was pretty happy with the result. You have functions like read, async_read, write, and async_write which take beast::http::message objects as parameters. Example: http://vinniefalco.github.io/beast/beast/ref/http__read/overload3.html The innovation here is the "Body" template type which controls not only the type of container used to represent the body but also the algorithms used to transfer bytes from the message body on the wire into and out of that container. The Body concept, and its nested Reader and Writer concepts, are documented here: http://vinniefalco.github.io/beast/beast/ref/Body.html http://vinniefalco.github.io/beast/beast/ref/Reader.html http://vinniefalco.github.io/beast/beast/ref/Writer.html Previous efforts and HTTP implementations focused heavily on the representation and parsing of the headers. To my knowledge Beast is the first implementation to provide caller flexibility in the body representation. Now the Beast websocket implementation has a reasonable set of primitives it could use to perform the handshake, and users could get control of that process. The Problem: Unfortunately, while treating the message as an object that can be read/written atomically works great for example programs and trivial use-cases, it fails in the real world. These are issues with it: * The caller must commit to a Body representation before receiving the HTTP Header * No way to properly read and respond to Expect: 100-continue * An efficient HTTP relay function (one that does not buffer the entire body up front) cannot be implemented by the caller * The caller cannot reasonably set a timeout, for example what if the body is 2 gigabytes received over a slow connection? * The parser interface forces algorithms to perform an unnecessary buffer copy for body containers that are entirely stored in memory (e.g std::string or boost::asio::streambuf). These issues sparked quite a bit of discussion on GitHub: https://github.com/vinniefalco/Beast/issues/154 https://github.com/vinniefalco/Beast/issues/265 In October of 2016 these problems became apparent. I tried a lot of different ideas to improve the design to solve it, but none of them worked. Some of my co-workers looked at it but we didn't really find anything great. One user in particular, on GitHub, had strong ideas involving the concept of "completion conditions" to augment the read/parse algorithms but it didn't feel right to me. The Solution: After suffering from writer's block for 5 months inspiration hit and I tried a combination of interface changes that got the design to where it needs to be to solve these problems. * The Reader concept is refined into two types: "indirect" readers, and "direct" readers. This is described here: http://vinniefalco.github.io/stage/beast/beast/ref/Reader.html * The parser exposes a small number of internal states, informing callers of where it is at and giving the caller control over if and when the parser advances to the next state: https://github.com/vinniefalco/Beast/blob/http/include/beast/http/basic_par… * The parser is rewritten to work only on linear buffers (allowing it to be optimized to become 20 times faster if SSE2 instructions are allowed). To facilitate this requirement, the flat_streambuf class is provided which works just like a basic_streambuf except it guarantees a single buffer. If the parser is given multiple buffers, it allocates memory to flatten it: https://github.com/vinniefalco/Beast/blob/http/include/beast/core/flat_stre… * New functions parse_some and async_parse_some allow the caller to perform incremental parsing. This allows for the implementation of relay functions, or reading just the header (for Expect: 100-continue): https://github.com/vinniefalco/Beast/blob/http/include/beast/http/parse.hpp… With these changes callers can get control of the inner loop that reads the body off the socket or stream, so they can do whatever custom steps are necessary if they want. They can set timeouts, and write their own loop that calls parse_some repeatedly. I think it solves all of these issues. I've written some test code which demonstrates how direct and indirect body readers are implemented, and what calling code looks like. I've also written a prototype "relay" function (read a message from one socket and efficiently write it to another socket). And there's an example of how Expect: 100-continue might be implemented. These prototypes are located here: https://github.com/vinniefalco/Beast/blob/http/test/http/design.cpp#L30 How to Help? These are some controversial changes and I think they could use some polish and vetting before I merge it to the master branch. Maybe there is something I haven't thought of, or a use-case it doesn't address. Perhaps there is a better way, or perhaps there are tweaks to make it even more usable and understandable. If some kind soul(s) would look through it and offer some feedback, positive or negative, that would be enormously helpful. The formal review for Beast is now scheduled for the first week of July and like an expectant father I am anxious and would like everything to go just right! My only objective is to polish up the library and its documentation so it is in the best possible shape for review. Thanks for listening!

1 1