- Boost - lists.boost.org

[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

[ublas] Supporting DNNs with Tensors/Multidimensional Arrays
by Cem Bassoy 06 Sep '18

06 Sep '18

Gsoc <https://summerofcode.withgoogle.com/organizations/4507228564881408/> 2018 just ended one week ago and we had many successefully completed student projects <https://github.com/BoostGSoC18>. I was responsible for adding tensor support to Boost.uBLAS for primarily supporting multilinear algebra operations in the field of numerics. The wiki description along with the implementation can be found here <https://github.com/BoostGSoC18/tensor>. Similar to Boost.multi_array <https://www.boost.org/doc/libs/1_68_0/libs/multi_array/doc/index.html> the runtime-reshapable tensor data structure is parametrized in terms of number of dimensions (rank/order), dimension extents, data type, layout (first- and last-order) and storage type. The first two are runtime-variable. I am also about to add subtensor (view/handle of a tensor) along with multidimensional iterators for convenient algorithm implementation. It is yet not as flexible as GSL's multi_span <https://github.com/Microsoft/GSL/blob/master/include/gsl/multi_span>: does not yet support static rank and dimensions. However, basic generic tensor operations (contraction/transposition/reshaping/...), including a nice syntax for Einstein's summation convention with placeholders, using C++17 features are provided. The operations are evaluated using expression templates (not smart yet). Similar to the tensor <https://eigen.tuxfamily.org/dox/unsupported/group__CXX11__Tensor__Module.ht…> framework of Eigen, that is used by tensor flow <https://github.com/tensorflow/tensorflow>, the tensor data structure in Boost.uBlas could be taken for implementing deep neural networks or higher-order statistics I think. I am not sure if the C++ community would appreciate if Boost has some form of basic operations for building *deep neural networks* (DNNs). I would like to ask 1. if it make sense for boost to support basic operations for DNNs? 2. what are the obligatory, necessary basic operations for creating DNN building blocks? 3. if there are any additional data structure parameters that needs to be added for (efficiently) supporting DNNs? Best, Cem

3 5

Schedule update request
by Antony Polukhin 06 Sep '18

06 Sep '18

Schedule at https://www.boost.org/development/index.html does not show next release dates and close of merge window. Please update it. Thanks in advance!

1 0

Assistance debugging compile time isomorphism failure to get PR #114 working
by Joshua Marshall 05 Sep '18

05 Sep '18

Hello all, Since Saturday I've been banging my head against this one. Over at https://github.com/anadon/graph/tree/isomorph-fix I've been trying to fix some of the newly enables travisCI failures. I'm getting a persistent type mismatch that may not be resolvable sanely, but I want to get another set of eyes before I just the gun and start suggesting ripping out tests.

1 0

Deprecation of detail endian macros.
by Rene Rivera 03 Sep '18

03 Sep '18

This is a general announcement that I'm deprecating the following that is part of Predef: Header: boost/detail/endian.hpp Macros: BOOST_BIG_ENDIAN, BOOST_LITTLE_ENDIAN, BOOST_PDP_ENDIAN, and BOOST_BYTE_ORDER You can use the equivalents from Predef < https://www.boost.org/doc/libs/1_68_0/doc/html/predef/reference.html#predef…> as follow: BOOST_BIG_ENDIAN == BOOST_ENDIAN_BIG_BYTE BOOST_LITTLE_ENDIAN == BOOST_ENDIAN_LITTLE_BYTE BOOST_PDP_ENDIAN == BOOST_ENDIAN_LITTLE_WORD There is no equivalent for BOOST_BYTE_ORDER. But there are no uses in Boost as far as I could tell. In the develop branch of Predef I've added a deprecation message indicating as such. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net

2 1