March 2017 - Boost - lists.boost.org

[quickbook] diagnosing a missing [endsect]?
by Peter Dimov 28 Apr '17

28 Apr '17

I just noticed a missing [endsect] in the middle of one of the .qbk files in the Core documentation. The main .qbk file contains [include addressof.qbk] [include checked_delete.qbk] [include demangle.qbk] [include enable_if.qbk] [include explicit_operator_bool.qbk] [include ignore_unused.qbk] [include is_same.qbk] [include lightweight_test.qbk] [include no_exceptions_support.qbk] [include noncopyable.qbk] [include null_deleter.qbk] [include ref.qbk] [include scoped_enum.qbk] [include swap.qbk] [include typeinfo.qbk] and in the middle of lightweight_test.qbk an [endsect] was missing. The end result of it was that the following includes went into the [section] opened in lightweight_test.qbk, as subsections. This wasn't noticeable from a cursory look so it went unnoticed for a while. Is it worth diagnosing this problem in some way? We probably can't disallow unbalanced sections in an [include], but this could be a warning? (If someone pays it any attention, of course.) Presumably, at the end of the file there'll be a [section] left open? This could be made an error so it'd be harder to miss.

4 23

[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