- Boost - lists.boost.org

How do I test more configurations locally
by Joshua Marshall 14 Sep '18

14 Sep '18

Hello all, How do I test more configurations on my local systems rather than relying on TravisCI and AppVeyor? I've been working on fixing up BGL to pass basic TravisCI and AppVeyor tests, but it seems I have to be particularly reliant on those online tests. I'd like to have more of that done on my local system. There is probably a way to do that, but I don't know what it is.

3 3

REMINDER: Formal Review of Histogram by Hans Dembinski
by Mateusz Loskot 14 Sep '18

14 Sep '18

Dear All, (NOTE: This is not start the review announcement yet) I'd just like to *remind* you all that the review of the Histogram library developed by Hans Dembinski is going to happen according to the schedule [1], from September 17, 2018 to Septenber 26, 2018. I will be sending the official START announcement this weekend. [1] https://www.boost.org/community/review_schedule.html Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0

[outcome] Change semantics on UB from peer review agreed semantics?
by Niall Douglas 14 Sep '18

14 Sep '18

Dear Boost, At https://github.com/ned14/outcome/issues/150, Andrzej has raised his desire to change Outcome's semantics on UB from what the two peer reviews here agreed to previously. As this would be a major change to interface different to what the consensus here agreed to, I am asking boost-dev to weigh in with its opinion. Status: ------- Outcome has been finished, apart from docs, since April (http://boost.2283326.n4.nabble.com/outcome-v2-1-progress-report-td4702900.h…) for the Boost and standalone variants, and since July for the experimental P1028 edition. The documentation has not been touched since the February review, but will be tackled when my current work contract ends this November, and I regain free time. Preamble: --------- Outcome has the notion of programmable "default actions" which occur when the user does something like call `.value()` on a `result<T, E>` which has an error. Let's call this "value-on-valueless". Outcome, as was approved here, has the following selector on `result<T, E>` in the Boost edition: ``` template <class T, class EC, class E> using default_policy = std::conditional_t< std::is_void<EC>::value && std::is_void<E>::value, terminate, std::conditional_t< trait::has_error_code_v<EC>, error_code_throw_as_system_error<T, EC, E>, std::conditional_t< trait::has_exception_ptr_v<EC> || trait::has_exception_ptr_v<E>, exception_ptr_rethrow<T, EC, E>, all_narrow >>>; template <class R, class S = boost::system::error_code, class NoValuePolicy = policy::default_policy<R, S, void>> using boost_result = basic_result<R, S, NoValuePolicy>; template <class R, class S = boost::system::error_code, class NoValuePolicy = policy::default_policy<R, S, void>> using result = boost_result<R, S, NoValuePolicy>; ``` So, if result's `E` is: - `void`, value-on-valueless calls `std::terminate()`. - contains an error code, value-on-valueless throws `system_error()`. - otherwise is hard undefined behaviour i.e. we tell the compiler that value-on-valueless will never happen, and the compiler doesn't even compile code for it to happen. The documentation, as was approved here, made it very clear that hard UB is the default for custom defined `E` types. See https://ned14.github.io/outcome/tutorial/default-actions/happens1/. A nice segfault usually emerges. For the standalone edition, judging from user feedback and bug reports, this hard UB behaviour is the most common intentional configuration for Outcome users. I have not received any complaints about this choice, if anything a majority has been choosing Outcome precisely *because* of this choice. Andrzej's request ----------------- Andrzej points out in https://github.com/ned14/outcome/issues/150 that it's too easy to get surprised by a small source change which causes the error code trait to no longer match the `E` type, thus flipping the code base from throwing `system_error` into hard UB unexpectedly and without warning. He wishes to change the default to failure to compile i.e. if result's `E` is: - `void`, value-on-valueless calls `std::terminate()`. - contains an error code, value-on-valueless throws `system_error()`. - otherwise a failure to compile with useful diagnostic. Users can, of course, manually specify a `NoValuePolicy` of `all_narrow` if they wish hard UB on value-on-valueless. It would be a non-trivial change from what peer review (twice) agreed, as the default would have substantially changed. What is boost-dev's opinion on this proposed change in semantics? Thanks, Niall

10 32

list.boost.org
by David Bellot 09 Sep '18

09 Sep '18

Hi, I'm looking for the person in charge of lists.boost.org, the mailing list server. We're having an issue on one of the mailing list (ublas). Cheers, David

3 2

[ublas] How to merge a PR?
by Frédéric 09 Sep '18

09 Sep '18

Hi, I submitted a PR 1 month ago. Something rather trivial. How can it be merge? https://github.com/boostorg/ublas/pull/56 Thanks, F

2 1

Re: [boost] list.boost.org
by Bjorn Reese 09 Sep '18

09 Sep '18

On 09/09/18 00:13, David Bellot via Boost wrote: > I'm looking for the person in charge of lists.boost.org, the mailing list > server. We're having an issue on one of the mailing list (ublas). https://lists.boost.org/Archives/boost/2017/02/232710.php

1 0

[all] Request for out of the box visibility support
by Antony Polukhin 09 Sep '18

09 Sep '18

I'd like to draw attention to a problem with Boost binaries for Linux. There's an awesome -fvisibility=hidden flag for Linux compilers that improves load times, performance, size of binaries and reduces the chance of symbol collisions. More info at https://gcc.gnu.org/wiki/Visibility . Unfortunately, most of the Boost libraries do not set it by default: - atomic - chrono - container - context - contract - coroutine - date_time - exception - fiber - filesystem - graph - graph_parallel - iostreams - locale - mpi - program_options - python - random - regex - signals - system - test - thread - timer - type_erasure - wave Moreover minority of the above libraries just do not work with the flag. Users just can not run ./b2 cxxflags="-fvisibility=hidden" because there's a chance that some library could stop linking. Actually things are even more ugly. Linux distributions usually do not tune the build flags for each package so at least Debian based distributions build Boost with default flags. Users get suboptimal builds. If you're a maintainer of one of the above libraries *please do* the following steps: * Make sure that all the public symbols are accordingly marked with appropriate BOOST_SYMBOL_* macro. Instruction is available here: https://www.boost.org/doc/libs/1_68_0/libs/config/doc/html/boost_config/boo… * Turn on the visibility=hidden by default: * by adding <target-os>linux:<cxxflags>"-fvisibility=hidden" to the Jamfile if you do not care much for antique compilers (Example https://github.com/boostorg/stacktrace/blob/819f2b1c861dec7530372a990ecabab… ) * by using a more advanced technique for detecting the flag availability (For example see https://github.com/boostorg/math/blob/develop/build/Jamfile.v2#L20 or https://github.com/boostorg/log/blob/develop/build/Jamfile.v2#L24 ) P.S.: I would appreciate any comments or updates on the feature request. P.P.S.: Log, Math, Serialization (and Stacktrace) libraries already use that flag by default. Many thanks! -- Best regards, Antony Polukhin

10 33

[range] #11202: boost.sort header conflicts with boost.range header
by Steven Ross 07 Sep '18

07 Sep '18

https://svn.boost.org/trac10/ticket/11202 has been sitting for years. The "using range::sort" causing the namespace pollution needs to be deleted, and then everything depending on that inside boost needs to be fixed. This will break people dependent on the namespace pollution, but that's the only way to clean it up. Is anyone willing to take on this cleanup? Is there a good way to identify cross-library dependency breakages in situations like this so they can be fixed?

10 20

Trac
by Robert Ramey 07 Sep '18

07 Sep '18

Could we agree to stop using the Trac system? The github issues/pr system is much more functional. I propose we close the trac system to new issues - be of course leave it available for reference. Robert Ramey

21 57

Guidelines on copyright notice maintenance
by Mateusz Loskot 06 Sep '18

06 Sep '18

Hi, The license guidelines [1] include instructions on "How should Boost programmers apply the license to source and header files?" Unless I've missed it, there seem to be lack of guidelines about how to maintain (existing) copyright notices. I don't aim to resurrect the old lengthy thread from Sept 2015 on validity of copyright notices. In that thread, however, some guidelines or conventions were expressed: [2] "because copyright is only claimed for changes meeting a certain threshold of originality" [3] "It's up to those people to add a line if they so decide. Copyright only covers expressions of creativity." Those suggests, there seem to be common understanding on if/how/when it is recommended or even necessary to update copyright notice in a source file of a Boost library. Wouldn't it be helpful to captured those as guidelines in the BSL FAQ. Would there be someone knowledgeable about it and willing to make the update or at least explain it here? (I will make it into HTML and PR to boostorg/website) I understand David and Beman, primary authors of the page [1], may no longer be available. [1] https://www.boost.org/users/license.html [2] https://lists.boost.org/Archives/boost/2015/09/225565.php [3] https://lists.boost.org/Archives/boost/2015/09/225570.php Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

2 2