- Boost-announce - lists.boost.org

[release] Boost 1.64.0 Beta 2
by Rene Rivera 30 Mar '17

30 Mar '17

Boost release 1.64.0 beta 2 is now available at: <https://dl.bintray.com/boostorg/beta/1.64.0.beta.2/source/> The SHA256 checksums are as follows: 49c9339b9d8e7b2610ef84c80cd10b2252c119ebcc3222450beb0e94c1da1522 boost_1_64_0_b2.7z 92ec7cbf1e77c5979e381dd8104f9e96c0471c276e566272751a981d806db94b boost_1_64_0_b2.tar.bz2 da5670892b7b572808491b13a7b9421c3c18e6f395d6a5ec822466db466eda01 boost_1_64_0_b2.tar.gz 61d6e29e8a1d7503fe13a9d916842f0ec2e625f733b98b29ce563f8cbdb482bf boost_1_64_0_b2.zip The notable difference from Beta 1 is the inclusion of the missing Boost Process library. For details of what's in the release, see < http://www.boost.org/users/history/version_1_64_0.html>. Note that the links to files on this web page are for the final release - use the link above to get the beta files. There are also pre-built libraries provided by Tom Kent here: <https://dl.bintray.com/boostorg/beta/1.64.0.beta.2/binaries/> Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

1 0

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

30 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/

1 0

[release] Boost 1.64.0 Beta 1
by Rene Rivera 23 Mar '17

23 Mar '17

Boost release 1.64.0 beta 1 is now available at: <https://dl.bintray.com/boostorg/beta/1.64.0.beta.1/source/> The SHA256 checksums are as follows: 8f0ba6b73fad15115049f9b3e7e27eae43be10a94b51a57142f3a27e55ef4beb boost_1_64_0_b1.7z b5c5abf127a3f723dafcc7cf55876c1bda9f014fb1b117f6a7f769e3cc407c4f boost_1_64_0_b1.tar.bz2 a7fe98a9a9f615f6fa68d8ea09ce725d19e3a4fe4719c21c9db29dff88b3b6e3 boost_1_64_0_b1.tar.gz 593005661af8dfe132b2b16bc2cd41339e6acd58456913f353d765090d7868f7 boost_1_64_0_b1.zip For details of what's in the release, see < http://www.boost.org/users/history/version_1_64_0.html>. Note that the links to files on this web page are for the final release - use the link above to get the beta files. There are also pre-built libraries provided by Tom Kent here: <https://dl.bintray.com/boostorg/beta/1.64.0.beta.1/binaries/> Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

1 0

[boost][safe_numerics] review results
by Andrzej Krzemienski 18 Mar '17

18 Mar '17

Hi Everyone, This is to inform you that safe_numerics library by Robert Ramey is *CONDITIONALLY ACCEPTED* to Boost. The list of conditions can be found down below. I would like to congratulate Robert for getting the library into Boost, and thank him for the effort to develop a useful library for the community. I also would like to thank everyone who participated in the review and shared their useful feedback. I recorded five reviews with a yes/no vote: - Paul A. Bristow (yes with conditions) - Steven Watanabe (yes with conditions) - John Maddock (yes with conditions) - Antony Polukhin (yes) - Barrett Adair (yes) And three without a vote: - Vicente J. Botet Escriba - John McFarlane - Peter Dimov We also got some feedback from an individual nicknamed "scatters" at Reddit (https://www.reddit.com/r/cpp/comments/5x1z67/boostsafe_ numerics_formal_review_starts_today/deew1kq/), and from Tomasz Kaminski in private conversation. There was a general consensus that the problem of surprises with C++ ints deserves a solution. Some people observed that there are other ways to approach the same problem, but it was agreed that the approach taken by safe_numerics is sound. The acceptance conditions mostly revolve around documenting micro-decisions made by the library, and fixing bugs. They apply to the reviewed GIT commit 3bcfabe1cafb8ef6edf08d3bd8730a1555b1c45d, but I know Robert is already working on fixing them, and has most of them fixed locally. *Acceptance conditions:* - Comply with Boost formal requirements: 1. index.html in root directory that redirects to doc/. 2. all headers in folder include/boost/numeric/. 3. Macro safe_literal: either remove it or let it follow Boost macro naming conventions: BOOST_NUMERIC_SAFE_LITERAL(). - Automatic promotion policy: either just remove it, or fix it so that: - it can see the range of safe_base in order to allow for slower increase in sizeof(), - it is clear from documentation how the promotion mechanism works. - in particular, what type gets selected for bit-wise operators &, | - The division bug (see below) is fixed. - Decide and document up front how the library addresses each of the following different situations: - overflow upon arithmetical operation, - unexpected promotion to unsigned when comparing signed with unsigned number, - arithmetic operation on unsigned int with negative value versus a signed value (-1 + 1u). - bit-wise operation on negative signed integers (unless they are removed), or that would produce one as the result. - division by zero, - operations upon default-constructed int type with indeterminate value, - conversion from float to int, when float contains non-integral value. - conversion from float to int, when float contains an integral value that would overflow upon native conversion - operator% where one operand is negative (for native ints it is implementaiton-defined) - leftshift by 32 bits (on 32-bit int) - Decide and document what safe's default constructor does. - Document upon which operations safe<> throws exceptions (or, signals arithmetic error at run-time). IOW, document in which cases safe<> never throws exceptions (signals run-time failure) because it is able to say that the operation will always succeed. - Document what happens when you invoke an operation on two instances of safe<> with different policies. - Resolve name conflict with interval, which already exists in namespace boost::numeric::interval. Either use a different namespace or a different name. - Remove anonymous namespaces from the header files. Use namespace detail and inline functions instead. - Improve test cases, so that they also check if numeric values of computations are correct (not only whether an operation throws or not). - Use enable_if (or similar) tricks to constrain the overload resolution for your arithmetical operations, so that they only work for numeric types rather than "any type T". - Fix the division bug: safe<signed, automatic> a {-1}; safe<unsigned, automatic> b {2}; auto c = a / b; // this returns 2147483647 <%28214%29%20748-3647> - Either document that safe<T> only works for scalar types (rather than any T that models concept Integer<T>), or provide alternate implementation of safe_base, as described in https://github.com/robertramey /safe_numerics/issues/44 - Fix linker errors when building a program from two cpp files that include safe_numerics headers. The error is caused by non-inline full specializations of operator<<. - Either entirely remove the support for bit-wise ops on signed types (make it a compiler error), or provide a consistent implementation that detects any UB or surprising results. - `++i` should return by reference; `i--` should return by value. *Other important issues* The following are *not *conditions for library acceptance, but I still recommend addressing them before the initial release. - Concepts: what do you need them for? Any other type except built-in scalars does not work anyway. Do you want to show how close safe<T> resembles T? In this case, they need to be changed. If you want to extend safe<T> to other T's, they need to be fixed: https://github.com/robertramey/safe_numerics/issues/46 <https://github.com/robertramey/safe_numerics/issues/46> - IOStreams interoperability needs fixes: - Move to a separate header, so that it does not affect compilation times when not needed (but provide forward declarations, so that implicit conversions to int do not make IOStreams work with unintended semantics) - Fix other problems as per https://github.com/robertramey /safe_numerics/pull/35 - safe<>'s interface is not documented - Make the library compile with -fno-exceptions: https://github.com/robertramey/safe_numerics/pull/31 <https://github.com/robertramey/safe_numerics/pull/31> - Some people fail to see how this library is better than just using rar ints but compiling with a UB-sanitizer. Address this in the documentation. - Prevent inadvertent ADL by putting safe into a nested namespace boost::numeric::save_types, and then in boost::numeric import: `using boost::numeric::save_types::safe`. This way boost::numeric::safe still works, but inadvertent ADL of everything inside namespace boost::numeric is prevented. - Does it make sense to apply bitwise operations on two different types? If so, document the semantics. - Fix header names and paths in documentation. - Consider adding support for saturation policy upon overflow. - Expression `safe<int>{4} ^ 1` does not compile due to overload resolution ambiguity. - Fix constexpr usages. - If possible, make workarounds in order to make the library work with MSVC. - Document that operations on safe<> do not thorw exceptions other than these thrown by exception policy. *Suggestions* The following summarizes other useful suggestions for improving the library in the future. - operation `safe<signed>{INT_MIN} + safe<unsigned>{UINT_MAX}` throws even though the mathematical result would fit in either signed or unsigned int. This is correct according to what policies describe, but is at the same time surprising, given that comparison `safe<signed>{INT_MIN} < safe<unsigned>{UINT_MAX}` just gives a mathematically correct answer rather than throwing an exception. Document this behavior explicitly. - Remove underflow_error from the policies: it sends the wrong message, that som form of an underflow is checked in this library. - Expose functions like add(), divide() in public interface, they might be useful on their own. - Expose the constructor with check disabled in the public interface, like `safe<int>{1, checks_sisabled{}}` this helps to locally disable the checks where the user knows that certain chain of operaitons will not overflow, and checks are redundant, but the library cannot see it. - Issues reported with bit-shift operators - unary operator- on unsigned type with pormotion policy `automatic` could return a signed type. - Use BOOST_NORETURN wherever possible, e.g. in throwing policies. - Use BOOST_LIKELY, BOOST_UNLIKELY for the policy tests. - Add support for statful policies. - Maybe drop the support for automatic type widening, to simplify the interface and the scope of the library, and let some other library handle the widening, maybe BigInt. Regards, Andrzej Krzemienski

1 0

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

17 Mar '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/

1 0

[boost][safe_numerics] The review is finished
by Andrzej Krzemienski 13 Mar '17

13 Mar '17

Hi Everyone, The review of safe_numerics library by Robert Ramey is now finished. Thanks to all participants for submitting their reviews, and sharing their insights. I will announce the result in the next couple of days. -- Andrzej Krzemienski, review manager

1 0

[boost][safe_numerics] Formal review starts today
by Andrzej Krzemienski 01 Mar '17

01 Mar '17

Hi Everyone, Today, on March 2nd (or tomorrow, depending on your timezone), is the start of the formal review of safe_numerics library by Robert Ramey. The review will run till March 11th. I will be serving as review manager. safe_numerics is a set of drop-in replacements for the built-in integer types, which make the guarantee that the results of operations are either correct according to the rules of integer arithmetic or report a diagnosable error (rather than offering modulo arithmetic results, or resulting in undefined behavior, or returning incorrect results as in the case of signed vs. unsigned comparisons). The library can be found on GitHub: https://github.com/robertramey/safe_numerics/ Online docs: http://htmlpreview.github.io/?https://github.com/robertramey/safe_numerics/ master/doc/html/index.html Formal Review comments can be posted publicly on the mailing list or Boost Library Incubator <http://blincubator.com>, or sent privately to the review manager, that is myself. Here are some questions you might want to answer in your review: - 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 most importantly: Do you think the library should be accepted as a Boost library? For more information about Boost Formal Review Process, see: http://www.boost.org/community/reviews.html Your review is needed! Regards, Andrzej Krzemieński, review manager.

1 0

[gsoc17] Boost will be participating in Google Summer of Code in 2017
by Niall Douglas 27 Feb '17

27 Feb '17

I am very pleased to inform the Boost community that Google accepted us into their Summer of Code programme this year. This was especially welcome after we were given "a year off" last year which could have caused substantial disruption to the multi year student projects had it not been due to the timely action of the steering committee and generous sponsorship of a stop gap Boost Summer of Code in 2016 by IMC Financial Markets. Last year Google completely rebuilt the Summer of Code website so it no longer is anything like it was before. Now we must individually invite those who vote on student projects, so *anyone willing to rank student project proposals* can you please email us with your details: 1. Your email address matching your Google Account so we can invite you onto the GSoC programme. 2. (Optional) your email address matching your Github Account so we can invite you onto the Boost GSoC github org for 2017 as a potential mentor. Our thanks to those who have already added project ideas to https://svn.boost.org/trac/boost/wiki/SoC2017, but we need MORE ideas and MORE potential project mentors. Follow the project idea template at https://svn.boost.org/trac/boost/wiki/GSoCIdeaTemplate and either add it straight to the wiki page or email it to us so we can add it for you. Our thanks to all in advance.

1 0

[safe_numerics] Review coming in March
by Andrzej Krzemienski 15 Feb '17

15 Feb '17

Hi Everyone, This is to inform you ahead of time that the formal review of Robert Ramey's Safe Numerics library will be held in about two weeks: March 2 - March 11. Boost Numerics is a set of drop-in replacements for the built-in integer types, which make the guarantee that the results of operations are either correct according to the rules of integer arithmetic or report a diagnosable error (rather than offering modulo arithmetic results, or resulting in undefined behavior, or returning incorrect results as in the case of signed vs. unsigned comparisons). The library can be found on GitHub: https://github.com/robertramey/safe_numerics/ Online docs: http://htmlpreview.github.io/?https://github.com/robertramey/safe_numerics/… Even before the formal review starts, you can provide your review on Boost Library Incubator: http://blincubator.com/reviews/?library_id=426 It will also be included in the final verdict. I will be making the official announcement on March 2. Andrzej Krzemienski, review manager.

1 0

[gsoc17] Attn: We need 2017 mentors and project ideas for Boost!
by Niall Douglas 07 Feb '17

07 Feb '17

Dear Boost community, We are now a few weeks from the beginning of Google Summer of Code 2017! Last year we had the big surprise of being rejected by Google as an org, the second time ever, on the basis that Google felt we needed a year off. Thanks to the quick actions of the Boost Steering Committee and IMC Financial Markets we managed to put together a "Boost Summer of Code" so the students with projects in progress would not be left stranded. Despite a fair few teething problems, I think that worked out okay. As part of filling in our application for 2017, we must supply to Google a list of potential GSoC mentors and potential GSoC projects for summer 2017 in order to be approved as an organisation this year. Therefore a lengthy page of awesome project ideas at https://svn.boost.org/trac/boost/wiki/SoC2017 before *February 9th* would be an enormous help to getting us approved again this year and bringing to Boost another US$35,000 of Google funding. If you think yourself able to mentor a student doing some work on Boost this summer, *please* consider adding a description of the proposed work item and your name to the list. The year before last we had more slots awarded to us by Google than we had good combinations of student and mentor, so we had to return slots which I believe has not happened here at Boost GSoC in at least a decade. That means that your project ideas have a better chance than ever of receiving funding if you can find a good student, and that is best done by getting project ideas floated *early*. If you want to know more about mentoring a Google Summer of Code funded student work before you nominate yourself, please feel free to ask on the main Boost developers mailing list boost(a)lists.boost.org or via gsoc-admin(a)boost.org. Thank you in advance for your time.

1 1