- Boost - lists.preview.boost.org

[Stacktrace] Review Manager report
by Niall Douglas 02 Jan '17

02 Jan '17

Firstly happy new year to everyone, and many thanks to all those who participated in the peer review of proposed Boost.Stacktrace before Christmas. I received the following formal reviews: 1. Vladimir Batov (YES) 2. Klemens Morgenstern (YES) 3. Andrey Semashev (NO) 4. Nat Goodspeed (YES) 5. Artyom Beilis (NO) 6. Barrett Adair (YES) Extensive comments without a formal acceptance recommendation were also made by: 1. Peter Dimov 2. Edward Diener There was a very noticeable lack of consensus on the strengths and weaknesses of the proposed library which has made summarising all these reviews into a coherent report with concrete conditions for acceptance very difficult. Antony also responded to many of the concerns throughout the review, agreeing with some points, disagreeing with others. I think this lack of consensus stemmed from multiple opinions on what a stacktrace library ought to provide: Minimum viable product: A portable backtrace() and backtrace_symbols() implementation with a C++ STL idiomatic API. The stack backtrace capture implementation must not allocate memory and be "fast". Note that backtrace_symbols() does NOT symbolise into strings containing source file name and line number. It also allocates memory (backtrace_symbols_fd() does not). Opinion 1: Portable serialisation of the stacktrace with instruction pointers converted to offsets into SO/DLL binary paths so a later external process can use those in combination with their debug symbols to retrieve source file names and line numbers. Ideally the serialisation formats supported would include those consumable by well known tooling for this purpose e.g. addr2line or llvm-symbolizer. Opinion 2: That Stacktrace can in process use debug symbols to retrieve source file names and line numbers. This could be implemented by invoking addr2line or equivalent as a child process which has the enormous advantage of being async safe, but has disadvantages in almost every other area. Or it could be implemented by one's own DWARF parser but with the huge caveat that memory could be badly corrupted by now. Opinion 3: That Stacktrace be "async safe" in that backtraces can be safely captured and parsed from a signal handler or SEH/TEH handler callback or point of C++ exception throw. *This implies no memory allocation during the execution of the handler*. >From the reviews, I think there is consensus that the minimum viable product is achieved in Stacktrace though many mentioned that improvements are needed to the documentation and most of the negative feedback was on features not in the minimum viable product described above. I therefore recommend the ACCEPTANCE of proposed Boost.Stacktrace into Boost with the following conditions: 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. I'd like to congratulate Antony on getting yet another library of his into Boost. I hope some of his magic rubs off on me when I bring Outcome to review later this year! Regards, Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

3 3

Re: [boost] documentation 1.63 not up to date
by Oliver Kowalke 02 Jan '17

02 Jan '17

Hello Daniel, I'm referring to http://www.boost.org/doc/libs/1_63_0/libs/fiber/doc/html/fiber/performance.… . The page should contain three tables (the one related to threads is missing) - my modification s date from end of November. Oliver Am 27.12.2016 1:35 nachm. schrieb "Daniel James" <dnljms(a)gmail.com>: On 27 December 2016 at 08:59, Oliver Kowalke <oliver.kowalke(a)gmail.com> wrote: > Hi, > could you update the documentation of boost-1.63 please - it is not up to > date. > For instance in boost.fiber commit 648de6a66544c5d03e5595cb25ed76 5ee0cd40d2 > (17.12.2016) is missing. > Thank you in advance, > Oliver The documentation on the website should just be whatever is in the release. It's a bit hard to know without a link to the page where that change is meant to be. I think what you're seeing on the website are the html files that are checked into git. I guess the documentation build isn't replacing them. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost

3 4

Re: [boost] [Bulk] Voronoi
by ayse 30 Dec '16

30 Dec '16

Thank you, I will watch it. Belowing code gives "floating point divide by zero" error std::vector<Segment>segments; segments.push_back(Segment(40, 0, 40, 100)); segments.push_back(Segment(40, 0, 100, 0)); segments.push_back(Segment(40, 100, 100, 100)); segments.push_back(Segment(100, 0, 100, 30)); segments.push_back(Segment(70, 30, 100, 30)); segments.push_back(Segment(70, 30, 70, 70)); segments.push_back(Segment(70, 70, 100, 70)); segments.push_back(Segment(100, 70, 100, 100)); // Construction of the Voronoi Diagram. voronoi_diagram<double>vd; * construct_voronoi(segments.begin(), segments.end(), &vd); // it gives floating point divide by zero error* My drawing, [image: Inline image 2]

1 1

[sandia] Intel compiler testers fail
by Andrey Semashev 29 Dec '16

29 Dec '16

Hi, Most of the Sandia-intel-* testers currently fail with the error saying /tmp is full. See here, for example: http://www.boost.org/development/tests/develop/developer/output/Sandia-inte… Could this be fixed? Thanks.

2 1

Voronoi
by ayse 29 Dec '16

29 Dec '16

Hi, Is boost-voronoi able to calculate voronoi diagram of closed polygons, if yes how? When I insert segments connected , it gives "floating point dividing by zero" error. Any help would be appreciated. Best regards, Ayşe.

3 2

Boost 1.63.0 is released!
by Marshall Clow 29 Dec '16

29 Dec '16

Release 1.63.0 of the Boost C++ Libraries is now available. These open-source libraries work well with the C++ Standard Library, and are usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use. This release contains numerous enhancements and bug fixes for existing libraries. For details, including download links, see http://www.boost.org/users/news/version_1.63.0 You can also download directly from SourceForge: https://sourceforge.net/projects/boost/files/boost/1.63.0/ To install this release on your system, see http://www.boost.org/doc/libs/release/more/getting_started/index.html Thanks to everyone who participated in this release. Thanks, --The Boost release team Vladimir Prus Rene Rivera Marshall Clow Eric Niebler Daniel James Beman Dawes

4 3

Re: [boost] Variadic append for std::string
by Nat Goodspeed 29 Dec '16

29 Dec '16

On Dec 28, 2016 7:20 PM, "Yakov Galka" <ybungalobill(a)gmail.com> wrote: On Tue, Dec 27, 2016 at 4:47 PM, Olaf van der Spek <ml(a)vdspek.org> wrote: > One frequently needs to append stuff to strings, but the standard way > (s += "A" + "B" + to_string(42)) isn't optimal due to temporaries. > Can't we already write it through (((s += "A") += "B") += to_string(42))? This is the time I think that assignment operators, other than =, should have had left associativitiy... pity they don't. I think what's desired here is a two-pass approach in which append() or concat() or whatever first figures out the final length required, allocates that much storage, then appends into it with no further expansion. When we say it should understand two kinds of string_view, etc., I assume that the catch-all case for each arg would be "anything that can be treated as a range of char_type."

2 1

[conversion] Release build error..
by Rene Rivera 29 Dec '16

29 Dec '16

Please fix this ASAP: error: Unable to find file or target named error: 'conversion' error: referred to from project at error: '/home/ubuntu/boost/libs/conversion/doc' Failed: 'b2' '--debug-configuration' '-j2' '-q' '-d0' '--build-dir=/home/ubuntu/build' '--distdir=/home/ubuntu/build/dist' '--release-build' 'auto-index=off' ERROR = 1 -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

2 2

[root_ptr] Into consideration by Qt & QtQuickCompiler
by Phil Bouchard 28 Dec '16

28 Dec '16

Greetings, I did my homework and the Qt Project is considering root_ptr despite the fact that there is no paper written on it: http://lists.qt-project.org/pipermail/development/2016-December/028222.html So there is a big demand out there. I am not sure what else is required to find a review manager but everything is on a silver plate now. Sincerely, -Phil

1 0

[Beast] Implementing the Asio deallocation guarantees
by Vinnie Falco 27 Dec '16

27 Dec '16

A user wrote up this detailed bug report on Beast. The problem is that Beast does not guarantee that all temporary memory allocations will be freed before the handler is invoked during the upcall. I'd like to fix it, but all the fixes are quite ugly. I am wondering if anyone has any experience, suggestions, or advice to add to the conversation before I try to pick the least distasteful option: https://github.com/vinniefalco/Beast/issues/215 Thanks

1 0