- Boost - lists.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

[release] Epic fail: Numeric cast in 1.64 does not match trunk
by Antony Polukhin 26 Apr '17

26 Apr '17

Hello, File https://github.com/boostorg/numeric_conversion/blob/master/include/boost/nu… does not match the one in release 1.64 That file was fixed and merged to master a long time ago, however boost_1_64_0.7z archive still has on outdated version (one with std::unary_function). This looks like an issue within some release scripts. Issue was noted here: https://svn.boost.org/trac/boost/ticket/12972 -- Best regards, Antony Polukhin

4 4

How to contribute??
by Saurabh Singh 25 Apr '17

25 Apr '17

Hey, This is Saurabh from New Delhi, India. I want to contribute to Boost and help you guys in fixing bugs. Can you please help me to get started in doing so. Thanks

3 2

[release] 1.65.0 open for merging
by Rene Rivera 24 Apr '17

24 Apr '17

The master branch is open for merging all stable changes from develop, including bug fixes and major upgrades to existing libraries. Breaking changes should be coordinated via the mailing list with the developers of the other libraries affected. New libraries may be added, but require permission of a release manager. In other words, merging does not require permission from a release manager, except for new libraries. Boost Calendar with the release schedule: http://www.boost.org/development/index.html Release schedule explanation: https://github.com/boostorg/boost/wiki/Release-Schedule Release practices for developers: http://svn.boost.org/trac/boost/wiki/ImprovingPractices -- The Boost Release Team

2 3

[context] - Boost.Context fails to build -> Call of overloaded 'callcc(...) is ambiguous'
by Carlos Ferreira 24 Apr '17

24 Apr '17

I was trying to compile Boost 1.64.0 for OpenWRT when the build failed for Arm Cortex A7 (Raspberry Pi 2) using Gcc 5.2 with Musl 1.1.16. The build output with the error follows. Any ideas on what it could be ? gcc.compile.c++ bin.v2/libs/fiber/build/gcc-arm/release/abi-aapcs/boost.locale.iconv-on/boost.locale.posix-off/link-static/threading-multi/context.o libs/fiber/src/context.cpp: In constructor 'boost::fibers::context::context(boost::fibers::dispatcher_context_t, const boost::context::preallocated&, const default_stack&, boost::fibers::scheduler*)': libs/fiber/src/context.cpp:236:14: error: call of overloaded 'callcc(const std::allocator_arg_t&, const boost::context::preallocated&, const default_stack&, boost::fibers::context::context(boost::fibers::dispatcher_context_t, const boost::context::preallocated&, const default_stack&, boost::fibers::scheduler*)::<lambda(boost::context::continuation&&)>)' is ambiguous }); ^ In file included from ./boost/fiber/context.hpp:28:0, from libs/fiber/src/context.cpp:7: ./boost/context/continuation.hpp:469:1: note: candidate: boost::context::continuation boost::context::callcc(std::allocator_arg_t, StackAlloc, Fn&&, Arg ...) [with StackAlloc = boost::context::preallocated; Fn = const boost::context::basic_fixedsize_stack<boost::context::stack_traits>&; Arg = {boost::fibers::context::context(boost::fibers::dispatcher_context_t, const boost::context::preallocated&, const default_stack&, boost::fibers::scheduler*)::<lambda(boost::context::continuation&&)>}] callcc( std::allocator_arg_t, StackAlloc salloc, Fn && fn, Arg ... arg) { ^ ./boost/context/continuation.hpp:483:1: note: candidate: boost::context::continuation boost::context::callcc(std::allocator_arg_t, boost::context::preallocated, StackAlloc, Fn&&, Arg ...) [with StackAlloc = boost::context::basic_fixedsize_stack<boost::context::stack_traits>; Fn = boost::fibers::context::context(boost::fibers::dispatcher_context_t, const boost::context::preallocated&, const default_stack&, boost::fibers::scheduler*)::<lambda(boost::context::continuation&&)>; Arg = {}] callcc( std::allocator_arg_t, preallocated palloc, StackAlloc salloc, Fn && fn, Arg ... arg) { ^ ./boost/context/continuation.hpp:514:1: note: candidate: boost::context::continuation boost::context::callcc(std::allocator_arg_t, boost::context::preallocated, StackAlloc, Fn&&) [with StackAlloc = boost::context::basic_fixedsize_stack<boost::context::stack_traits>; Fn = boost::fibers::context::context(boost::fibers::dispatcher_context_t, const boost::context::preallocated&, const default_stack&, boost::fibers::scheduler*)::<lambda(boost::context::continuation&&)>] callcc( std::allocator_arg_t, preallocated palloc, StackAlloc salloc, Fn && fn) { ^ ./boost/context/continuation.hpp:457:1: note: candidate: boost::context::continuation boost::context::callcc(Fn&&, Arg ...) [with Fn = const std::allocator_arg_t&; Arg = {boost::context::preallocated, boost::context::basic_fixedsize_stack<boost::context::stack_traits>, boost::fibers::context::context(boost::fibers::dispatcher_context_t, const boost::context::preallocated&, const default_stack&, boost::fibers::scheduler*)::<lambda(boost::context::continuation&&)>}; <template-parameter-1-3> = void] callcc( Fn && fn, Arg ... arg) { ^ -- Carlos Miguel Ferreira Researcher at Telecommunications Institute Aveiro - Portugal Work E-mail - cmf(a)av.it.pt Skype & GTalk -> carlosmf.pt(a)gmail.com LinkedIn -> http://www.linkedin.com/in/carlosmferreira

2 2

Supporting boost 1.64 for Visual Studio 2017
by Evgen8 23 Apr '17

23 Apr '17

The "NuGet" system indicates that BC 2017 is supported. *boost_locale-vc141. Compiler: Visual Studio 2017. Platforms: Win32, x64.* But attempts to use this package end with nothing. Regardless of how I install the "boost_locale" - do I get the same result manually or using "NuGet"? Attempts to install it on another machine ran out the same. Is this a bug? /1>libboost_locale-vc141-mt-1_64.lib(generator.obj) : error LNK2001: unresolved external symbol "class boost::system::error_category const & __cdecl boost::system::system_category(void)" (?system_category@system@boost@@YAABVerror_category@12@XZ) 1>libboost_locale-vc141-mt-1_64.lib(localization_backend.obj) : error LNK2001: unresolved external symbol "class boost::system::error_category const & __cdecl boost::system::system_category(void)" (?system_category@system@boost@@YAABVerror_category@12@XZ) 1>libboost_locale-vc141-mt-1_64.lib(lcid.obj) : error LNK2001: unresolved external symbol "class boost::system::error_category const & __cdecl boost::system::system_category(void)" (?system_category@system@boost@@YAABVerror_category@12@XZ) 1>libboost_locale-vc141-mt-1_64.lib(date_time.obj) : error LNK2001: unresolved external symbol "class boost::system::error_category const & __cdecl boost::system::system_category(void)" (?system_category@system@boost@@YAABVerror_category@12@XZ) 1>libboost_locale-vc141-mt-1_64.lib(generator.obj) : error LNK2001: unresolved external symbol "class boost::system::error_category const & __cdecl boost::system::generic_category(void)" (?generic_category@system@boost@@YAABVerror_category@12@XZ) 1>libboost_locale-vc141-mt-1_64.lib(localization_backend.obj) : error LNK2001: unresolved external symbol "class boost::system::error_category const & __cdecl boost::system::generic_category(void)" (?generic_category@system@boost@@YAABVerror_category@12@XZ) 1>libboost_locale-vc141-mt-1_64.lib(lcid.obj) : error LNK2001: unresolved external symbol "class boost::system::error_category const & __cdecl boost::system::generic_category(void)" (?generic_category@system@boost@@YAABVerror_category@12@XZ) 1>libboost_locale-vc141-mt-1_64.lib(date_time.obj) : error LNK2001: unresolved external symbol "class boost::system::error_category const & __cdecl boost::system::generic_category(void)" (?generic_category@system@boost@@YAABVerror_category@12@XZ) 1>E:\Yandex.Disk\Projects\OS\Release\Devs.exe : fatal error LNK1120: 2 unresolved externals/ -- View this message in context: http://boost.2283326.n4.nabble.com/Supporting-boost-1-64-for-Visual-Studio-… Sent from the Boost - Dev mailing list archive at Nabble.com.

3 2

Re: [boost] Supporting boost 1.64 for Visual Studio 2017
by Andrey Semashev 22 Apr '17

22 Apr '17

On 04/23/17 00:11, Nadtochiy Evgeniy wrote: > 22.04.2017, 21:07, "Andrey Semashev" <andrey.semashev(a)gmail.com>: >> >> On 04/22/17 20:29, Evgen8 via Boost wrote: >> >> The "NuGet" system indicates that BC 2017 is supported. >> *boost_locale-vc141. Compiler: Visual Studio 2017. Platforms: >> Win32, x64.* >> But attempts to use this package end with nothing. Regardless of >> how I >> install the "boost_locale" - do I get the same result manually or >> using >> "NuGet"? Attempts to install it on another machine ran out the >> same. Is this >> a bug? >> >> /1>libboost_locale-vc141-mt-1_64.lib(generator.obj) : error LNK2001: >> unresolved external symbol "class boost::system::error_category >> const & >> __cdecl boost::system::system_category(void)" >> >> >> The missing symbols are from Boost.System. Since you're linking static >> libraries, you'll have to specify Boost.Locale dependencies manually to >> link with in your project. >> > How can i do this? There was always enough installation with NuGet... I don't know what NuGet is or how it works, but the libraries to link with are typically specified in VS project settings (look for the linker parameters tab). PS: Also, please, don't top post.

1 0

[1.64][process] Windows line endings in headers
by Andrey Semashev 22 Apr '17

22 Apr '17

Hi, I can see some of the headers in Boost.Process (for example, boost/process/cmd.hpp, boost/process/env.hpp) contain Windows line endings. Regarding 1.64, Windows line endings are also present in the .tar.bz2 package, which is supposed to be targeted for POSIX systems. 1. Could Windows line endings be removed in git? 2. Could the release procedures be updated to ensure that foreign line endings don't creep into the released packages? I understand that 1.64 has sailed, but I think at least a note (preferably, with a patch) would be appropriate in the release notes.

7 11

[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

Locating Visual Studio 2017 on disk
by Andrew Pardoe 20 Apr '17

20 Apr '17

Folks, We had a number of conversations about the fact that VS 2017 could be installed in any location, or multiple locations, and no longer created a registry key pointing to an install location. There's also the problem that an installation of VS 2017 may or may not contain C++ tools (as was the case with VS 2015.) The solution proposed by the VS team-creating a tool called VSWhere-was inadequate for some scenarios such as Boost's because it would have required either caching a binary in your source enlistment or compiling code to locate the compiler. A number of people on this list asked for a more straightforward solution. I'm happy to tell you that your feedback was heard. We're going to start shipping the VSWhere tool in a known location on any machine that has VS 2017. More details can be found in this blog post: https://blogs.msdn.microsoft.com/heaths/2017/04/21/vswhere-is-now-installed… This doesn't fix the problem for all the versions of VS 2017 that are installed already. And this doesn't help our version numbers to make any more sense (although I'm pushing to fix that as well.) But at least in the future you'll be able to locate VS installs from a scripted environment. Thanks for being loud and reaching out to us. As always, I'm happy to help you with any issues you might have with MSVC-just ask. Andrew Pardoe MSVC compiler & tools

1 0