December 2016 - Boost - lists.preview.boost.org

[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

Merging superproject fb83378 to master
by Peter Dimov 27 Dec '16

27 Dec '16

Can we please merge https://github.com/boostorg/boost/commit/fb8338770e930bca5ba24dbb9240f5c2e4… to master? Without it, Boost.Build requires the tools/inspect submodule to be present, which is otherwise unnecessary in partial Travis checkouts.

1 1

documentation 1.63 not up to date
by Oliver Kowalke 27 Dec '16

27 Dec '16

Hi, could you update the documentation of boost-1.63 please - it is not up to date. For instance in boost.fiber commit 648de6a66544c5d03e5595cb25ed765ee0cd40d2 (17.12.2016) is missing. Thank you in advance, Oliver

3 4

Re: [boost] documentation 1.63 not up to date
by Oliver Kowalke 27 Dec '16

27 Dec '16

OK, thank you - I'll test your suggestions. Am 27.12.2016 2:12 nachm. schrieb "Daniel James" <dnljms(a)gmail.com>: On 27 December 2016 at 12:45, Oliver Kowalke <oliver.kowalke(a)gmail.com> wrote: > Hello Daniel, > I'm referring to > http://www.boost.org/doc/libs/1_63_0/libs/fiber/doc/html/ fiber/performance.html > . > The page should contain three tables (the one related to threads is > missing) - my modification s date from end of November. > Oliver The change you referred to before was from the 17th, but the html file in git was last updated on the 10th. https://github.com/boostorg/fiber/blob/master/doc/html/ fiber/performance.html I guess that's what you're seeing. I'm not sure how the build is set up now, but I'm guessing it wasn't set up to build the fiber documentation because there's already html files there. To build the documentation, I think you need to change the end of your documentation jamfile to something like: alias boostdoc ; explicit boostdoc ; alias boostrelease : fiber ; explicit boostrelease ; Although, I can't test that now, so it might be wrong. I'd also delete the html documentation from the repo, as a broken link is a better indicator that the documentation isn't being built. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost

1 0

Boost Fiber & ASIO CPU spinning
by Daniel Larimer 27 Dec '16

27 Dec '16

I am attempting to combine Boost Fiber with Boost ASIO and am having very poor results. Code: int main() { boost::asio::io_service io; boost::fibers::use_scheduling_algorithm< boost::fibers::asio::round_robin > ( io ); io.run(); return 0; } This code should startup and then sleep, but instead it pegs the CPU at 100%. The code I used for boost::fibers::asio::round_robin can be found here: http://www.boost.org/doc/libs/1_62_0/libs/fiber/examples/asio/round_robin.h… When I inspect the round_robin scheduler it appears to be switching back and forth between two different fibers. If I put a print statement inside asio_rr_service_lambda then it constantly reports that it has ready fibers. I'm looking for a working example. Dan

2 1

PHP error in string_ref docs
by Olaf van der Spek 27 Dec '16

27 Dec '16

Hi, Got a PHP error in the docs.. http://www.boost.org/doc/libs/master/libs/utility/doc/html/string_ref.html /home/www/live.boost.org/common/code/boost.php:16: htmlentities(): Invalid multibyte sequence in argument -- Olaf

2 3

Re: [boost] [stacktrace] review (changing vote to NO)
by Artyom Beilis 26 Dec '16

26 Dec '16

> > 1. use of -rdynamic/-export-dynamic should be noted in "bold face" regarding > > the use of the library. > > Those flags are not required because addr2line can extract information > from debug sections of the binary. Yes.. this is exactly the issue - I don't think that addr2line should be used by default. Getting the stack trace using dladdr works very well - so no need to use add2line unless absolutely required. I also want to hear regarding inefficiency of add2line use - creating the process for each stack frame you wanted to trace. It is very inefficient so I suggest not to use one. Finally reviewing your code once again I realized following: 1. Instead of using adde2line to get the object name you can just call add2line with /proc/12345/exe (works with dynamically loaded shared objects as well - i tested it) 2. Use of addr2line for every each frame must be fixed But what is most important that I understood that you don't even use dladdr to get function names even if you can - which is very bad decision. Additionally I realized that with_trace and traced aren't parts of the library! These should be built in there by default. -------------------------- After using the library and running couple of tests on Linux with GCC.. I have to revoke my "Conditional YES" vote and change it to "NO": And the reason is following: 1. Linux/*nix backend is poor - instead of using dladdr to get function names easily as I do in the backend I written and use on CppCMS [1] you call external exe in very inefficient way. 2. I realized that the library does not provide the basic functionality like collecting strack trace on throw (what I thought was built in but I was mistaken) 3. No answer for non MSVC compilers built in. But the most important reason that the library does not feel mature enough in terms of both backends and frontends. I strongly strongly strongly recommend to continue the work on the library as it provides important functionality. The frontend should be adjusted a little to couple with common cases. The backend must be modified to not to fork/exec by default and optimize one significantly. I clearly understand you to want to use addr2line as it gives more power but it can't be used by default. I searched for a long time for a lightweight solution for converting addresses to the function names for CppCMS including trying to use debug information but couldn't find anything suitable besides dlfunc. However addr2line is by no means can be accepted as "default" solution. I also recommend to take a look on cppcms's backtrace library it is very simple and provides critical information in production environment. Regards, Artyom Beilis [1] https://sourceforge.net/p/cppcms/code/HEAD/tree/framework/trunk/booster/lib… _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

6 11

[root_ptr] Potential support from Qt & QtQuickCompiler
by Phil Bouchard 25 Dec '16

25 Dec '16

Greetings, As you know the WebKit project has a very complex memory manager that cannot be swapped easily but The Qt Project might be interested for a faster alternative than the garbage collector: http://lists.qt-project.org/pipermail/development/2016-December/028199.html This is just a head's up in case anybody is interested into the subject and is aware of Qt. I know by experience garbage collectors will always let you down for complex projects so I think there is no other solution. Thanks & Merry Christmas, -Phil

1 0

Boost 1.63.0 Release Candidate 2
by Marshall Clow 25 Dec '16

25 Dec '16

The second release candidate for the 1.63.0 release is now available at: https://sourceforge.net/projects/boost/files/boost/1.63.0/ The only changes are in Boost.Config, Boost.Context, and Boost.Fiber. The SHA256 checksums are as follows: 25db3956a8d58187ac7a0702cc917e9bab47ff90baafc35e4e789dca1ce5f423 boost_1_63_0_rc2.7z beae2529f759f6b3bf3f4969a19c2e9d6f0c503edcb2de4a61d1428519fcb3b0 boost_1_63_0_rc2.tar.bz2 fe34a4e119798e10b8cc9e565b3b0284e9fd3977ec8a1b19586ad1dec397088b boost_1_63_0_rc2.tar.gz 97ce6635df1f44653a597343cd5757bb8b6b992beb3720f5fc761e3644bcbe7b boost_1_63_0_rc2.zip As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. -- The release managers

5 6

Re: [boost] Boost 1.63.0 Release Candidate 2
by Stephan T. Lavavej 24 Dec '16

24 Dec '16

[Marshall Clow] > The second release candidate for the 1.63.0 release is now available at: > https://sourceforge.net/projects/boost/files/boost/1.63.0/ > As always, the release managers would appreciate it if you download > the candidate of your choice and give building it a try. Please report > both success and failure, and anything else that is noteworthy. 1.63.0 RC2 successfully built for mingw-w64, without any workarounds. (Boost.Fiber is detecting my lack of std::mutex and simply not building, which is fine by me.) Notably, this is the first time that I've ever been able to build Boost without patches or workarounds. This is after bootstrap.sh was fixed for mingw-w64/msys2, Context/Coroutine/Coroutine2 were fixed to build for mingw-w64, and Python auto-detection started working again. Yay! Thanks, STL

2 1

Stacktrace review: concern, probable solution and review news
by Antony Polukhin 23 Dec '16

23 Dec '16

Hi, The biggest concern with the stacktrace library is it's usability in async-signal-handlers. Here are some facts: * users definitely want to use the library in async-signal-handlers to print stacktraces on SIGSEGV/SIGBUS/SIGABRT * the only cross-platform async-signal-safe thing that can be done - is to print function addresses (without names and source line locations) * reviewers wish to have a smaller size of the `stacktrace` class, want to avoid template parameter and have a std::vector<frames> like interface (this is async unsafe because vector does dynamic allocations). So, the solution: * Change `basic_stacktrace<size_t>` to `basic_stacktrace<class Allocator = std::allocator<void*>>` and make it's constructor async-unsafe and add additional runtime parameter for stack depth. * Provide async-safe functions that dump addresses separated by whitespace (format also acceptable by addr2line and atos): * `void dump_stacktrace(int fd)` * `void dump_stacktrace(HANDLE fd)` * `void dump_stacktrace(const char* filename)` * Provide an example with dumping callstack to a file and printing it on program restart Does it seem reasonable? Does it satisfy your needs? Review news: * User named LogicalKnight tested the library on MacOS and it works well. A few issues in examples must be fixed: https://github.com/apolukhin/stacktrace/issues/10 My list of TODOs for the library: * Fix the async unsafe code in signal catching example * ? Provide a low-level API for getting stacktrace as array of void pointers * MinGW fails to compile, because of missing "Dbgeng.h" headers. This must be fixed by manyally forward declaring required functions using the boost.winapi way. * Add a note about the Boost.Exception usage to the example with embedding stack into exception. * Take a look at the llvm-symbolizer, atos and libdwraf; try hard to produce a non-forking solution * ? Deserialization/inspection of stacktrace on other machine * BOOST_NOINLINE inline trick to avoid printing internals in the stacktrace + fix Intel warnings * At github one of the users was complaining about the performance of ostreaming operations. There is a way to significantly speedup ostreaming without changing the interface of the library. I'll do the optimization after the Boost Review. * Improve docs for the "Build, Macros and Backends" sections (say that library is using system headers, no 3rd party libraries must be installed or manually linked; backtrace() is LINUX specific, not POSIX) * Add a note to the docs that library is header only by default and usable in C++98/C++03. Things NOT to do ever: * Integration with BOOST_THROW_EXCEPTION and Boost.Exception - those ideas are out of the library scope * Callbacks to do things on stacktraces - no way to satisfy all the needs and make them optimal on all the platforms. Do some caching instead -- Best regards, Antony Polukhin

5 11

Re: [boost] [Stacktrace] review
by Barrett Adair 23 Dec '16

23 Dec '16

On Wed, Dec 14, 2016 at 2:43 AM, Niall Douglas <s_sourceforge(a)nedprod.com> wrote: > The formal review of the Stacktrace library by Antony Polukhin starts > today 14th Dec and will conclude before Christmas. I appreciate we > are likely a bit tired out from the many library reviews recently and > of course it's Christmas, but given the lack of a portable way to > work with stack backtraces, which you inevitably need to do > eventually in any non-toy production application, Stacktrace needs > your review! > > For your review you may wish to consider the following questions: > > What is your evaluation of the design? I like it. > What is your evaluation of the implementation? I've never implemented a stacktrace reader, so I don't have much to add. The code did not raise any red flags for me, though. > What is your evaluation of the documentation? Documentation is solid. > What is your evaluation of the potential usefulness of the library? Very useful. I will likely use this at work. > Did you try to use the library? With what compiler? Did you have any problems? Yes, GCC 5.3, no problems. This stacktrace made me smile: 0# boost::stacktrace::detail::backend::backend(void**, unsigned long) 1# s::~s() 2# void __gnu_cxx::new_allocator<s>::destroy<s>(s*) 3# void std::allocator_traits<std::allocator<s> >::destroy<s>(std::allocator<s>&, s*) 4# std::_Sp_counted_ptr_inplace<s, std::allocator<s>, (__gnu_cxx::_Lock_policy)2>::_M_dispose() 5# std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release() 6# std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count() 7# std::__shared_ptr<s, (__gnu_cxx::_Lock_policy)2>::~__shared_ptr() 8# std::shared_ptr<s>::~shared_ptr() 9# hello()::{lambda()#1}::~hello() 10# std::_Function_base::_Base_manager<hello()::{lambda()#1}>::_M_destroy(std::_Any_data&, std::integral_constant<bool, false>) 11# std::_Function_base::_Base_manager<hello()::{lambda()#1}>::_M_manager(std::_Any_data&, std::_Function_base::_Base_manager<hello()::{lambda()#1}> const&, std::_Manager_operation) 12# std::_Function_base::~_Function_base() 13# std::function<void ()>::~function() 14# void std::_Destroy<std::function<void ()> >(std::function<void ()>*) 15# void std::_Destroy_aux<false>::__destroy<std::function<void ()>*>(std::function<void ()>*, std::function<void ()>*) 16# void std::_Destroy<std::function<void ()>*>(std::function<void ()>*, std::function<void ()>*) 17# void std::_Destroy<std::function<void ()>*, std::function<void ()> >(std::function<void ()>*, std::function<void ()>*, std::allocator<std::function<void ()> >&) 18# std::vector<std::function<void ()>, std::allocator<std::function<void ()> > >::~vector() 19# hello() 20# main 21# __libc_start_main 22# _start > How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? About 45 minutes total. I skimmed the code, the documentation, and the test cases. Then, I made a little test program. > Are you knowledgeable about the problem domain? No. > Do you think the library should be accepted as a Boost library? Yes, unequivocally. The concerns about async safety are interesting, but ultimately this library is useful to me (and likely many others) regardless of signal support. Barrett

1 0

Re: [boost] [interprocess] Getting boot-up time is unreliable on Windows
by Remi Chateauneu 22 Dec '16

22 Dec '16

Maybe the RDTSC instruction might help for x86 processors, as it returns a number of ticks which is reset at startup. It is also extremely fast. Le 22 déc. 2016 13:04, "Thomas Dahms" <thomas.dahms(a)native-instruments.de> a écrit : Dear developers, dear Ion, We are experiencing issues on Windows where boost::interprocess relies on a certain event in the system event log to get the system's boot-up time. This has proven to be unreliable, because that event is not always present in the log. In that case, initialization of boost::interprocess fails. Several bug reports exist for that issue, e.g. [1, 2]. Report [1] contains a proposed fix to use GetTickCount64() and there is an open PR with an alternative fix to fall back to WMI mechanisms [3]. I understand that the fix [1] would need some polishing, because GetTickCount64() is not available in pre-Vista. Nevertheless, both proposed fixes have been uncommented and unconsidered for a while now. Is there any chance that the maintainers could look into this? Thank you! Regards, Thomas [1] https://svn.boost.org/trac/boost/ticket/12137 [2] https://svn.boost.org/trac/boost/ticket/12232 [3] https://github.com/boostorg/interprocess/pull/18 -- Thomas Dahms Software Developer Native Instruments GmbH www.native-instruments.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost

2 1

[interprocess] Getting boot-up time is unreliable on Windows
by Thomas Dahms 22 Dec '16

22 Dec '16

Dear developers, dear Ion, We are experiencing issues on Windows where boost::interprocess relies on a certain event in the system event log to get the system's boot-up time. This has proven to be unreliable, because that event is not always present in the log. In that case, initialization of boost::interprocess fails. Several bug reports exist for that issue, e.g. [1, 2]. Report [1] contains a proposed fix to use GetTickCount64() and there is an open PR with an alternative fix to fall back to WMI mechanisms [3]. I understand that the fix [1] would need some polishing, because GetTickCount64() is not available in pre-Vista. Nevertheless, both proposed fixes have been uncommented and unconsidered for a while now. Is there any chance that the maintainers could look into this? Thank you! Regards, Thomas [1] https://svn.boost.org/trac/boost/ticket/12137 [2] https://svn.boost.org/trac/boost/ticket/12232 [3] https://github.com/boostorg/interprocess/pull/18 -- Thomas Dahms Software Developer Native Instruments GmbH www.native-instruments.com

1 0

Boost 1.63.0 Release Candidate 1
by Marshall Clow 21 Dec '16

21 Dec '16

The release candidates for the 1.63.0 release are now available at: https://sourceforge.net/projects/boost/files/boost/1.63.0/ The SHA256 checksums are as follows: 010699561c6011e6d97dc453d55bc5e54cdc192622434eff7b8ac559efac846c boost_1_63_0_rc1.7z d8ebf8d90b2f823f04119445ac339d704395d655907333ec0fab863040119d24 boost_1_63_0_rc1.tar.bz2 dabe29b8a60369ae7c15c20681a32717f3c37d97e5dc6d39c5b2fd0494b8e995 boost_1_63_0_rc1.tar.gz 1683942022fd63c205c48fb2155af6094c67ef67aa13ffb3e1db78fecf817efe boost_1_63_0_rc1.zip As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. -- The release managers

12 25

Please update Track config
by Antony Polukhin 21 Dec '16

21 Dec '16

Hi, Please, change the default owner for variant issues from ebf to apolukhin (it's me, I'm taking care of the library for last few years). This change will help me to react faster on variant issues. Also, please add the dll component into the list of components so that people could properly report Boost.DLL issues https://github.com/boostorg/dll. Make me (apolukhin) the default responsible for the issues. Thanks in advance! -- Best regards, Antony Polukhin

1 0

Re: [boost] [Boost] [Stacktrace] review
by Nat Goodspeed 21 Dec '16

21 Dec '16

On Wed, Dec 14, 2016 at 3:43 AM, Niall Douglas <s_sourceforge(a)nedprod.com> wrote: For your review you may wish to consider the following questions: > > - What is your evaluation of the design? > I'm generally pleased with the design. There's a documentation section "Exceptions with stacktrace" that discusses techniques for incorporating stacktrace data into your own exceptions. I see a real possibility for integration with Boost.Exception, perhaps even a mechanism to make BOOST_THROW_EXCEPTION embed the stacktrace at the throw point. This is not an objection to accepting the library, but rather a feature request for when we do. I do have a question about use of a template parameter to constrain the number of entries, rather than a runtime parameter. Presumably that's necessary to permit certain backend implementations to be async-signal-safe? (Whatever the rationale, a note in the documentation explaining it would be nice.) My objection to that is that apparently, with the present design, if I want to write a function that accepts any specialization of basic_stacktrace, that must itself be a template function. If I'm correct about the reason for using a template parameter, would it be reasonable to split the class into a non-template base class supporting all the methods, with a template subclass that provides the storage? The base class could store a (pointer, length) passed by the subclass constructor. Without having looked at the implementation, I expect that you wouldn't even need virtual-function dispatch: the only indirection would be through the data buffer pointer. That would even permit a subclass that provides dynamic storage, for async-signal-unsafe use. Then a processing function could accept reference-to-base-class and handle any stacktrace instance. > - What is your evaluation of the implementation? Sorry, I haven't looked at the implementation. > - What is your evaluation of the documentation? > Generally good. It could stand a cleanup pass; there are a few typos here and there. I do like that each method explicitly states both complexity and async signal safety. The description of the nullary frame() constructor says that source_line() will return both empty string and 0. > - What is your evaluation of the potential usefulness of the > library? > VERY! I want this. > - Did you try to use the library? With what compiler? Did you > have any problems? > No, I haven't tried to use it. (A deadline is coming up fast.) > - How much effort did you put into your evaluation? A glance? A > quick reading? In-depth study? > I read through the documentation. > - Are you knowledgeable about the problem domain? > I have occasionally used platform-specific tactics to try to achieve the same thing, on a couple different platforms. Each time it's been painful enough to make me wish that this problem were solved, once and for all. > And finally, every review should attempt to answer this question: > > - Do you think the library should be accepted as a Boost > library? > Yes I do. I would like to see the non-template base class, but that's not a showstopper: I would rather have this library without than not have it at all. As I mentioned, I would like to see integration with Boost.Exception. That just seems like a natural next step. I see further opportunities for integration with Boost.Context, Boost.Fiber...

11 121

Stacktrace library starts review today 14th Dec
by Niall Douglas 21 Dec '16

21 Dec '16

The formal review of the Stacktrace library by Antony Polukhin starts today 14th Dec and will conclude before Christmas. I appreciate we are likely a bit tired out from the many library reviews recently and of course it's Christmas, but given the lack of a portable way to work with stack backtraces, which you inevitably need to do eventually in any non-toy production application, Stacktrace needs your review! Stacktrace is an optionally header-only library providing four implementation backends, libunwind (POSIX only), windbg (Windows only), backtrace (from the C library on most POSIX implementations) and a null backend. 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 ================= Reviews should be submitted to the developer list (boost(a)lists.boost.org) 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? Most of my personal concerns with this library are with the implementation and I would hugely appreciate feedback from others with substantial experience of using stacktracing "in anger" in non-trivial use case scenarios. - 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. Finally, thanks to Edward whose announcement of the Synapse library review I borrowed heavily from as I thought it very well structured. Hopefully the above is just as clear. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

6 21

Re: [boost] [EXTERNAL] Boost 1.63.0 Release Candidate 1
by Marshall Clow 21 Dec '16

21 Dec '16

On Tue, Dec 20, 2016 at 2:51 PM, Marshall Clow <mclow.lists(a)gmail.com> wrote: > On Tue, Dec 20, 2016 at 12:49 PM, Rene Rivera <grafikrobot(a)gmail.com> > wrote: > >> >> >>>>>> >> >>>>>> As I mentioned to Marshall, the results here: >> >>>>> http://www.boost.org/development/tests/develop/developer/ >> config.html >> >>>>> are >> >>>>> horribly outdated - are they actually being run and updated? >> >>>>> >> >>>>> >> >>>> It appears that all 'develop' tests are at least one week late if not >> >>>> much >> >>>> more. >> >>>> >> >>> >> >>> >> >>> I was not aware of the stalled results.. Investigating now. >> >>> >> >> >> >> I think Sandia testers on Darwin and Linux are cycling okay in both >> >> develop and master, there’s results up there from Dec 20th. Are the >> Sandia >> >> config test results wrong or unexpected? >> >> >> > >> > The latest results from Sandia that I can see are from 12th. The report >> > info[1] also says it was run last time on 12th. >> > >> > [1]: http://www.boost.org/development/tests/develop/developer/ >> index.html >> >> >> The report generation issue is now addressed. The results are current and >> show tests from today. >> >> > I see lots of new results for "master", but none for "develop". (yet) > > Interesting. This page: http://www.boost.org/development/tests/develop/developer/config.html shows new results, but this one http://www.boost.org/development/tests/develop/developer/summary.html does not. -- Marshall

3 3