- Boost - lists.preview.boost.org

Segmented Tree Sequence documentation broken
by Vicente J. Botet Escriba 09 Dec '15

09 Dec '15

Hi, the link to Segmented Tree Sequence documentation in the review schedule and the Incubator is broken. https://det.github.io/segmented_tree_seq Vicente

2 2

[shared_ptr] Clang with Microsoft CodeGen in VS 2015 Update 1
by Beman Dawes 09 Dec '15

09 Dec '15

See http://blogs.msdn.com/b/vcblog/archive/2015/12/04/introducing-clang-with-mi… I tried building the Boost.Filesystem DLL with clang/c2 using the Visual Studio solution from libs/filesystem/test/msvc. As indicated the blog post, the following changes were needed in the project's properties: Configuration Properties General Platform Toolset : Clang 3.7 with Microsoft CodeGen (v140_clang_3_7) C/C++ General Warning Level : EnableAllWarnings (-Wall) Code Generation Enable C++ Exceptions: Yes (-fexceptions) Language Enable Run-Time Type Information: Yes (-frtti) Precompiled Headers Precompiled Header: Not using Precompiled Headers The operations.cpp compile failed with the following errors: 2> operations.cpp 2> In file included from ..\..\..\src\operations.cpp:44: 2> In file included from ../../../../..\boost/filesystem/operations.hpp:25: 2> In file included from ../../../../..\boost/filesystem/path.hpp:29: 2> In file included from ../../../../..\boost/shared_ptr.hpp:17: 2> In file included from ../../../../..\boost/smart_ptr/shared_ptr.hpp:28: 2> In file included from ../../../../..\boost/smart_ptr/detail/shared_count.hpp:29: 2> In file included from ../../../../..\boost/smart_ptr/detail/sp_counted_base.hpp:45: 2>../../../../..\boost/smart_ptr/detail/sp_counted_base_clang.hpp(29,1): error : cannot mangle this C11 atomic type yet 2> inline void atomic_increment( atomic_int_least32_t * pw ) 2> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 2>../../../../..\boost/smart_ptr/detail/sp_counted_base_clang.hpp(34,1): error : cannot mangle this C11 atomic type yet 2> inline boost::int_least32_t atomic_decrement( atomic_int_least32_t * pw ) 2> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 2>../../../../..\boost/smart_ptr/detail/sp_counted_base_clang.hpp(39,1): error : cannot mangle this C11 atomic type yet 2> inline boost::int_least32_t atomic_conditional_increment( atomic_int_least32_t * pw ) 2> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ So it looks like the clang/c2 toolset doesn't support atomics yet. The __c2__ and __c2_version__ macros allow detection of the clang/c2 toolset, could a workaround be added to shared_ptr? I know we don't usually worry about workarounds for preview (i.e. early beta) compiler releases, but the ability to add the clang/c2 toolset to local tests for library developers working on Windows will be a big plus IMO. --Beman PS: Has anyone figured out how to invoke clang/c2 from the command line?

3 6

boost::hash - different values for the same input?
by trafdev 09 Dec '15

09 Dec '15

Hi. As per hash_range docs (http://www.boost.org/doc/libs/1_59_0/doc/html/hash/reference.html#boost.has…) "This hash function is not intended for general use, and isn't guaranteed to be equal during separate runs of a program - so please don't use it for any persistent storage or communication." As per code (http://www.boost.org/doc/libs/1_59_0/boost/functional/hash/hash.hpp) it uses hash_combine_impl which doesn't use any random, process_id etc values which might change during new process launches. At the same time, in an example describing container usage in the shared memory (http://www.boost.org/doc/libs/1_59_0/doc/html/interprocess/allocators_conta…) boost::hash is being used: typedef boost::unordered_map < KeyType , MappedType , boost::hash<KeyType> ,std::equal_to<KeyType> , ShmemAllocator> MyHashMap; My question is: is it safe to use boost::hash in a shared (persistent) storage or it's safe only for a particular (non-pointer) types? In this case, boost::hash docs should be changed to mention this exceptions, because otherwise no one could use boost::hash in a shared memory containers.

1 0

Updated 1.60 release schedule
by Marshall Clow 09 Dec '15

09 Dec '15

Since we were late on the 1.60 release, we've updated the release schedule. The master branch is currently open for bugfixes and documentation changes ONLY. The master branch will close on Sunday night (Dec 12th). We will build an RC for the 1.60 release Monday, and if all goes well, release it on Thursday, December 17th. So get those bug fixes in before Sunday! -- Marshall

1 0

[qvm] Review announcement
by Phil Endecott 09 Dec '15

09 Dec '15

Adam Wulkiewicz wrote: > The formal review of Emil Dotchevski's QVM library begins > today on 7th Dec and ends on 16th Dec. Adam sent this announcement email to the boost@, boost-users@ and boost-announce(a)lists.boost.org lists. Which seems OK, except that as I have previously noted the gmane.org website seems to get confused by such messages; this announcement will have appeared on only the announce page at gmane.org and any followups that are sent to e.g. the boost@ list will not be displayed by gmane at all. You might argue that this is a gmane.org bug, and that is true, but on the other hand we do want everyone who might be interested to know about the review, and a quick look at email headers will show that many do use the gmane.org web interface to read these lists. I've previously suggested that whatever "how to be a review manager" documentation that exists should advise that announcements should be posted separately to each list. Perhaps no such documentation exists! (I'll post some comments about the actual proposal soon.) Regards, Phil.

2 1

[LOG] formatting_ostream API change
by Andrew Hundt 09 Dec '15

09 Dec '15

I had the following code, which worked in 1.58: #include <boost/log/trivial.hpp> #include <boost/exception/all.hpp> #include <boost/algorithm/string.hpp> /// @todo move elsewhere, because it will conflict with others' implementations of outputting vectors template<typename T> inline boost::log::formatting_ostream& operator<<(boost::log:: formatting_ostream& out, std::vector<T>& v) { out << "["; size_t last = v.size() - 1; for(size_t i = 0; i < v.size(); ++i) { out << v[i]; if (i != last) out << ", "; } out << "]"; return out; } I used it to output a std::vector<float> as follows: BOOST_LOG_TRIVIAL(trace) << “Real joint angles from FRI: " << realJointPosition << "\n"; However this now seems to fail in 1.59. I’ve created a github gist with the compiler output <https://gist.github.com/ahundt/5869dbd09e889b7153c3> in case that’s helpful as well. I see that the update recently had some breaking changes, what is the new way to provide the desired functionality? Thanks for your help. Cheers! Andrew Hundt

2 3

Boost release 1.60.0 beta 1 is now available from SourceForge
by Marshall Clow 08 Dec '15

08 Dec '15

Boost release 1.60.0 beta 1 is now available from SourceForge. See http://sourceforge.net/projects/boost/files/boost/1.60.0.beta.1/ For details of what's in the release, see http://www.boost.org/users/history/version_1_60_0.html. Note that the links to files on this web page are for the final release - use the SourceForge link above to get the beta files. Please download the beta, give it a try, and report any problems you encounter. Known issues: * Errors when building Boost.TypeErasure for older versions of Visual Studio. * Boost.Test fails when building on Darwin with gcc 4.9.2 The files (and associated md5s) are: MD5 (boost_1_60_0_b1.7z) = 63530c9594b24f56e5df79d910c9daeb MD5 (boost_1_60_0_b1.tar.bz2) = 29af12a1028536219a21517e953df4eb MD5 (boost_1_60_0_b1.tar.gz) = 74df7f5eb5e32f3a92b6141af3c6f541 MD5 (boost_1_60_0_b1.zip) = 90c25c34b64eb6cc88845ec5372938d7 Thanks, -- The Boost Release Team

2 1

Checking for #pragma GCC diagnostic push|pop availability
by Marshall Clow 08 Dec '15

08 Dec '15

Shane Turner wrote: > I found another issue with a bad compiler version check in > boost/interprocess/detail/config_begin.hpp before using "#pragma GCC > diagnostic push", which, for GCC, is only available at version 4.6.0 and > later. Since I'm using GCC 4.4.7, my compile fails. It looks to me like interprocess is the one that really needs fixing. [ There could be a lot of cleanup here, but that's for another time ] I will make a PR. -- Marshall I have found (in non-test code) #if defined(__GNUC__) && (__GNUC__*10000 + __GNUC_MINOR__*100 + __GNUC_PATCHLEVEL__ > 40800) type_traits/has_logical_not.hpp #if BOOST_GCC >= 40700 tuple/detail/tuple_basic.hpp #Effectively >= 40600 smart_ptr/shared_ptr.hpp smart_ptr/scoped_ptr.hpp smart_ptr/detail/shared_count.hpp #if defined(BOOST_GCC) && BOOST_GCC >= 40600 random/detail/disable_warnings.hpp random/detail/enable_warnings.hpp #if defined(__clang__) move/detail/std_ns_begin.hpp move/detail/std_ns_end.hpp #elif defined(__GNUC__) && !(defined(__INTEL_COMPILER) || defined(__ICL) || defined(__ICC) || defined(__ECC)) \ && (__GNUC__ * 100 + __GNUC_MINOR__) >= 406 log/detail/header.hpp log/detail/footer.hpp #if defined(__clang__) || (defined(__GNUC__) && !(defined(__INTEL_COMPILER) || defined(__ICL) || defined(__ICC) || defined(__ECC)) && (__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 6))) lexical_cast/try_lexical_convert.hpp #if defined(BOOST_GCC) && (BOOST_GCC >= 40000) interprocess/detail/config_begin.hpp interprocess/detail/config_end.hpp #Effectively >= 40600 get_pointer.hpp

2 1

[boost-users][boost-announce][QVM] Formal review begins today
by Adam Wulkiewicz 07 Dec '15

07 Dec '15

Dear Boost community, The formal review of Emil Dotchevski's QVM library begins today on 7th Dec and ends on 16th Dec. Boost QVM defines a set of generic functions and operator overloads for working with quaternions, vectors and matrices of static size with the emphasis on 2, 3 and 4-dimensional operations needed in graphics, video games and simulation applications. While it provides its own quaternion, matrix and vector types, it is designed to work primarily with user-defined types through user specializations of the q_traits, v_traits and m_traits templates. QVM's source code is available on Github: https://github.com/zajo/boost-qvm Full documentation is also viewable on Github: http://zajo.github.io/boost-qvm/ We encourage your participation in this review. At a minimum, kindly state: - Whether you believe the library should be accepted into Boost * Conditions for acceptance - Your name - Your knowledge of the problem domain. You are strongly encouraged to also provide additional information: - What is your evaluation of the library's: * Design * Implementation * Documentation * Tests * Usefulness - Did you attempt to use the library? If so: * Which compiler(s) * What was the experience? Any problems? - How much effort did you put into your evaluation of the review? More information about the review process can be found here: http://www.boost.org/community/reviews.html We await your feedback! Best regards, Adam Wulkiewicz

1 0

interest in an asynchronous linear algebra library?
by Oswin Krause 07 Dec '15

07 Dec '15

Hi list, Disclaimer: What I am proposing here does not exist (yet). But it will in the near future and if there is interest i would like to give something back to the boost community. I would like to propose a new library to boost: asynchronous blas. What is it and what can I do with it? It is a linear algebra library where all computations are carried out in an asynchronous manner on GPU and CPU. Computing a matrix-matrix product does not block the current thread but instead launches a task which at some point returns with a result, allowing the main thread to continue until the result is needed. GPU and CPU tasks can be started at the same time depending on each other (e.g. a CPU computation waits until the GPU returned some needed result and vice-versa) Why is this important? Which problems does it solve? Many linear algebra libraries are target towards either a) solving a few large linear algebra problems b) solving many small similar problems This library is targeted towards the middle ground: a medium amount of decently sized problems. Here the problem is that it is often hard to use all the computing resources available as a single problem will not exhaust the device resources and there is no easy way to launch several similar tasks in parallel. This problem occurs often in GPU computing where out-of-order execution of kernels is used to fill up the device. Similarly, it is often hard to make CPU and GPU work together as GPU tasks are asynchronous while CPU tasks are often synchronous and it is not straight forward to couple both without blocking either CPU or GPU. How does it work? Expression templates similar to boost::ublas are used to create a dependency graph: which object is used in which computations and which tasks have to wait to ensure a correct outcome? a simple case would be two independent computations like matrix A=prod(B,trans(B)); matrix C=prod(trans(B),B); a normal library like ublas would wait until A is computed before C is evaluated. Instead, it can be more efficient to just add the two tasks to a list and let worker threads execute them as soon as resources are available. First the computation of A is put into the graph and A is marked as "being written to" while B is marked as "being read". When C is added to the list, it does not depend on the first computation as several tasks can read from B at the same time. So another worker thread can grab the task and execute it. If we now add the task B += prod(D,prod(C,trans(D)); the library computes it as matrix temp = prod(C,trans(D); B += prod(D,temp). temp can be computed as soon as C is computed. But B can only be computed after A and temp are computed as we can only write to B after all previous tasks using B are finished. Are you qualified? I am main contributor to https://github.com/Shark-ML/Shark/ and as part of it I forked ublas https://github.com/Shark-ML/Shark/tree/master/include/shark/LinAlg/BLAS which now uses several linear algebra libraries as possible backends (ATLAS, openBLAS...). What is the timeline? I would start developing a minimal example ASAP based on the rewrite of ublas above. I would use a minimum set of features (only dense square matrices) and basic GPU support. Opinions? Best, Oswin

8 17