- Boost - lists.preview.boost.org

Ticket system getting spamed
by Mateusz cerkiewny 20 Aug '14

20 Aug '14

#10352 <https://svn.boost.org/trac/boost/ticket/10352> #10351 <https://svn.boost.org/trac/boost/ticket/10351> #10342 <https://svn.boost.org/trac/boost/ticket/10342> #10339 <https://svn.boost.org/trac/boost/ticket/10339> #10335 <https://svn.boost.org/trac/boost/ticket/10335> #10331 <https://svn.boost.org/trac/boost/ticket/10331> #10334 <https://svn.boost.org/trac/boost/ticket/10335> Are spamms

2 1

[log] Problem Building Boost 1.55 With GCC Using C++11 Mode Due to AVX2 Support
by Stewart, Robert 20 Aug '14

20 Aug '14

We've run into a problem building log. It doesn't appear to be a known issue and we're not sure how to work around it. We found a hack to make our builds succeed, but there may well be a better workaround and we're not certain whether there are any issues with what we've done. We tried to build Boost 1.55 with GCC 4.8.1, 4.8.3, and 4.9.1 with the following commands: ./bootstrap.sh --prefix=<prefix> --libdir=<prefix>/lib --with-toolset=gcc ./b2 --build-type=complete --layout=versioned 'cxxflags=-m64 -O2 -g -pipe' 'cflags=-m64 -O2 -g -pipe' 'linkflags=-Wl,-rpath -Wl,<prefix>/lib -L<gcc_dir>/lib64 -Wl,-rpath -Wl,<gcc_dir>/lib64 -m64' -d+2 -j3 ./b2 --build-type=complete --layout=versioned 'cxxflags=-m64 -O2 -g -pipe' 'cflags=-m64 -O2 -g -pipe' 'linkflags=-Wl,-rpath -Wl,<prefix>/lib -L<gcc_dir>/lib64 -Wl,-rpath -Wl,<gcc_dir>/lib64 -m64' -d+2 -j3 install The errors we get come from this command during the build: gcc.compile.c++ bin.v2/libs/log/build/gcc-4.9/release/link-static/log-api-unix/threading-multi/dump_avx2.o "g++11" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -pthread -fno-strict-aliasing -ftemplate-depth-1024 -m64 -O2 -g -pipe -march=core-avx2 -mavx -mavx2 -fabi-version=0 -m64 -O2 -g -pipe -DBOOST_ALL_NO_LIB=1 -DBOOST_CHRONO_STATIC_LINK=1 -DBOOST_FILESYSTEM_STATIC_LINK=1 -DBOOST_LOG_BUILDING_THE_LIB=1 -DBOOST_LOG_USE_NATIVE_SYSLOG -DBOOST_LOG_WITHOUT_EVENT_LOG -DBOOST_SPIRIT_USE_PHOENIX_V3=1 -DBOOST_SYSTEM_NO_DEPRECATED -DBOOST_SYSTEM_STATIC_LINK=1 -DBOOST_THREAD_BUILD_LIB=1 -DBOOST_THREAD_DONT_USE_CHRONO=1 -DBOOST_THREAD_POSIX -DBOOST_THREAD_USE_LIB=1 -DDATE_TIME_INLINE -DNDEBUG -I"." -c -o "bin.v2/libs/log/build/gcc-4.9/release/link-static/log-api-unix/threading-multi/dump_avx2.o" "libs/log/src/dump_avx2.cpp" There are many lines of output; I've elided similar messages to highlight the unique ones: {standard input}: Assembler messages: {standard input}:611: Error: operand type mismatch for `vpsrldq' ... {standard input}:819: Error: no such instruction: `vextracti128 $0x1,%ymm2,%xmm2' ... {standard input}:1087: Error: no such instruction: `vextracti128 $0x1,%ymm3,48(%r15)' ... {standard input}:1312: Error: operand type mismatch for `vpaddb' While there might be a way to actually get b2 to disable AVX2 support, we hacked libs/log/build/Jamfile.v2 with these commands: sed -i 's:dump_avx2::g' libs/log/build/Jamfile.v2 sed -i 's:<define>BOOST_LOG_USE_AVX2::g' libs/log/build/Jamfile.v2 Those remove dump_avx2 from BOOST_LOG_COMMON_AVX2_SRC and remove the definition of BOOST_LOG_USE_AVX2, which prevents compiling enable_avx2(). Is there a better way to solve or work around this problem? _____ Rob Stewart robert.stewart(a)sig.com Software Engineer, Middleware using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

2 2

[git] Pushing commit(s) after pulling
by Edward Diener 20 Aug '14

20 Aug '14

I share a library with others and make some commit to a branch of that library. Then I try to 'push' the commit, only to be told that there are changes that have been made which I need to 'pull'. So I 'pull' the latest changes for that branch, and luckily there is no conflict(s) with my local commit(s). What do I do now ? I can 'push' my changes successfully but then the history of my particular changes appears to be lost. Am I supposed to revert my changes to the local repository by doing a 'reset' and then reapply those changes ? That seems onerous. What is the right way to 'push' my changes and still preserve the history of each one of them on the remote repository ?

5 9

[mpl] Proceeding with modularization
by Andrey Semashev 20 Aug '14

20 Aug '14

Hi, Now that 1.56 is out I believe we can proceed with modularization. I'd like to complete Boost.MPL decomposition into Boost.MPL.Core and Boost.MPL that I started some time ago. I can see two ways of doing this: I can keep the two parts in the separate git repositories or I can move Boost.MPL.Core to a sub- library within the same git repo. I'd prefer the second approach since this allows to create a single pull request and keeps the library history in one place, but maybe there are other considerations?

3 3

Re: [boost] [Concepts] Definition. Was [GSoC] [Boost.Hana] Formal review request
by Brian Wood 19 Aug '14

19 Aug '14

Niall Douglas writes: > > Such a design would not make good use of hardware DMA such that use > of the CPU can be completely avoided for bulk data transfers. To > invoke hardware DMA, all i/o must be done from 4Kb aligned memory > buffers. Indeed AFIO can enforce that for you because it's so > important to performance. > > Generally if you're bothering to use async i/o, you have no interest > in *ever* copying memory. That rules out all serialisation usually :) How about calling it OS-level serialization? I don't think the need for message framing goes away. Somehow the length of a message has to be calculated and put in place. -- Brian Ebenezer Enterprises - In G-d we trust. http://webEbenezer.net

1 0

GSoC: Pipeline status
by Benedek Thaler 19 Aug '14

19 Aug '14

Hi, As GSoC is coming to its end, I'd like to present you the Pipeline library: code: https://github.com/erenon/pipeline documentation: http://erenon.hu/pipeline I'll continue to work on this project, the next big thing is to implement a coroutine based execution. I hope using cooperative scheduling will enable a much better throughput/latency combination over the nice and easy to use interface we currently have. Thanks, Benedek

1 0

[serialize] Noncopyable errors in the latest 'master'
by Edward Diener 19 Aug '14

19 Aug '14

In testing out libraries which use Boost PP, with clang as the compiler, I am seeing a great deal on 'master' of: > ..\..\..\boost/archive/detail/basic_serializer.hpp:35:7: error: 'operator=' is a private member of 'boost::noncopyable_::noncopyable' > class basic_serializer : Does anybody know what this is all about ? It is occuring in a number of libraries using serialization.

1 0

[GSoC] [Boost.Hana] Status update
by Louis Dionne 18 Aug '14

18 Aug '14

Dear Boost, Summer of code is coming to its end, and I think this is a good time to give an update about Hana and what's going to happen next. In early august, I asked for a review of Hana. As a result, I got many comments and questions which helped me improve the library and also take the pulse of the C++ community. Ever since the review, I've been working on improvements and modifications to the library and its documentation. Thanks to all of those who gave comments, and especially to those who experimented with the library and reported problems/thoughts. My initial (personal) objective was to push a new library in Boost by the end of the summer. I now realize that this is unlikely to happen given the amount of work that's left and the amount of time on my hands. That being said, I still think Hana solves the problem of C++ metaprogramming in a very elegant way, and I'm not giving up on its development because GSoC ends. Hence, I will continue working on the project as much as my studies allow it and I plan to ask for informal reviews during fall. Eventually, I still hope to fulfil my initial goal of making Hana available to a wide audience via Boost. I would also like to mention that I will be presenting Hana at CppCon 2014 in september; consider attending if you followed the project this summer. Finally, I would like to thank everyone that was involved with making my participation to GSoC possible; I worked hard, had a lot of fun and I think my work (or at least derivations of it) will be useful to Boost and the wider C++ community given enough time. Regards, Louis

1 0

Debugger Visualizers discussion
by Antony Polukhin 18 Aug '14

18 Aug '14

Hi all, There is project that contains a bunch of XML files. Those files can be used to improve debugging on MSVC: For example: * using this project debug view of `boost::variant<int, float> i(1);` will show `1` instead of raw memory and internals of boost::variant. * optional<boost::container::string> will show string content or `none` instead of ram memory and some unreadable internals Maybe we should embed those files into the Boost? It would be great to have some magic bjam command `b2 install-debug` after which VisualStudio becomes aware of Boost classes. Files for pretty debugging could be also written for GDB. Will it be useful? Link o the project: https://github.com/KindDragon/CPPDebuggerVisualizers Files are located at https://github.com/KindDragon/CPPDebuggerVisualizers/tree/master/VS2013/Vis… -- Best regards, Antony Polukhin

3 3

[git] [filesystem] [system] [timer...] Remove useless SVN branches?
by Beman Dawes 18 Aug '14

18 Aug '14

Boost library repos converted from Subversion are littered with branches created by the conversion process that seem to me to be quite useless. For example, Boost filesystem has 65 branches, yet only 10 or so have any usefulness I'm aware of. A lot of the useless branches have names that begin "sandbox" or "svn-". I go back to the subversion repo when I want to look at pre-git-conversion history. Is there any point in retaining these branches? Does anyone object if I remove these branches from the libraries where I am the maintainer? What are other maintainers doing about stale branches? --Beman

3 2