March 2016 - Boost - lists.preview.boost.org

Boost 1.61.0 open for fixes
by Vladimir Prus 02 Apr '16

02 Apr '16

The master branch is now open for bugfixes for 1.61.0. Please make sure that develop tests are healthy prior to merging. We're two weeks late relative to the plan, so further dates were also moved by two weeks in the calendar. -- The release managers

2 1

[Trac][convert] Associate Vladimir as author of Boost.Convert
by Vicente J. Botet Escriba 01 Apr '16

01 Apr '16

Hi, I requested sometime ago to add convert to the Trac system. It was done, but it was associated to me as maintainer. Please, could someone assign it to Vladimir Batov Vladimir, I guess you need to give your use in name. Best, Vicente Convert <http://www.boost.org/doc/libs/1_60_0/libs/convert/> An extendible and configurable type-conversion framework. Author(s) Vladimir Batov First Release 1.59.0

4 5

Coroutine2 examples - Cannot link properly.
by Carlos Ferreira 01 Apr '16

01 Apr '16

Hello to all. I'm having trouble in compiling the coroutine2 examples. For the fibonacci example, the following linking error occurs: /usr/include/boost/coroutine2/detail/pull_control_block.ipp:62: undefined reference to `boost::context::execution_context::current()' Now, I know that I have to link against boost context, something that I'm already doing, but for some reason, it is not enough. Can anyone help me with this? Thank you. -- Carlos Miguel Ferreira Researcher at Telecommunications Institute Aveiro - Portugal Work E-mail - cmf(a)av.it.pt Skype & GTalk -> carlosmf.pt(a)gmail.com LinkedIn -> http://www.linkedin.com/in/carlosmferreira

3 14

[boost 1.61] authorization to merge to master
by Raffi Enficiaud 31 Mar '16

31 Mar '16

Dear Boost, I would like to merge a boost.test bugfix to master. Those changes are running on develop for a week. I haven't done my PR for the website change log update because of that (would change the content of the PR). According to the schedule, boost 1.61 is open for bugfixes since 10 days now, but as I understood, we are still waiting for post RC2 go. - do I still have time for the website PR? - would the opening 1.61 for bugfixes be announced on the ML? - Am I allowed to merge those changes, so that I can reopen develop for post 1.61 developments? Thanks, Raffi Enficiaud

2 2

[boost 1.61 - [thread] Request for permission to merge
by Vicente J. Botet Escriba 31 Mar '16

31 Mar '16

Hi, I would like to merge once it is announced that the release branch is open for fixes a minor fix https://svn.boost.org/trac/boost/ticket/11562 - (condition_variable_any::wait_until + recursive_mutex + steady_clock) timer expires after computer time is set forward on Ubuntu 64-bit add missing template parameter in wait_until. https://github.com/boostorg/thread/commit/9db70b803d8f45632cd92cd61ab019c1f… and the rollback of something that resulted in a regression https://svn.boost.org/trac/boost/ticket/12049 - Assertion failure from detached threads during shutdown rollback BOOST_THREAD_PATCH. https://github.com/boostorg/thread/commit/47357de276fe4fc01469f34c1dbf8b26f… Best, Vicente

1 1

Re: [boost] [filesystem] Horrible documentation
by Tatsuyuki Ishi 31 Mar '16

31 Mar '16

> From: Edward Diener <eldiener(a)tropicsoft.com> > Date: Wed, 30 Mar 2016 00:06:00 -0400 > Subject: Re: [boost] [filesystem] Horrible documentation > > What sort of documentation unification with other libraries do you mean ? By saying unification, I'm talking about the green-background header. It's in most documentation and also on the homepage. > Can you not increase the font size, if it is too small for you to read, in your preferred browser since the doc is HTML ? The layout is quite problematic. Not only the font, text breaks border, and the page is too tall(long). I noticed it's created with FrontPage 2002. Come on, this is 2016.

3 2

[release] Download data
by Daniel James 31 Mar '16

31 Mar '16

Hi, Currently the download details for a release are included in the quickbook source file for the release notes, which is a bit wonky, and makes it tricky to add extra data, so I'm thinking about storing it separately. This should make it easier to add things like hash signatures and links to third party downloads, such as the windows binaries. So I'm thinking about how to make it easy for people to add the details of their downloads. Could possibly create an extra file for each release, and then people can add data using pull requests, much as we've been using pull requests on the quickbook files, which seems to work fairly well. Another possibility is that we could pull in the details from the server's API, although I don't really fancy having to support multiple data sources with different APIs. Any other ideas? Also, is there any way in which you'd like me to make this kinds of information available for your scripts, packaging etc. Here's a rough version of how the internal data might be stored in a JSON file (other file formats are possible): { 'version': '1.61.0', 'status': 'beta', 'release-notes': '/feed/history/boost_1_61_0.qbk', 'documentation': '/doc/libs/1_61_0/', 'downloads': [ { 'url': 'http://..../boost_1_61_0_beta1.tar.bz2', 'hash': '484c635.....' }, { 'url': 'http://..../boost_1_61_0_beta1.7z', 'hash': 'f93de8.....' }, // ... ], 'third-party': [ { 'url': 'http://...', 'title': 'Windows binaries', 'whatever_else': '' } ] }

1 0

[filesystem] Horrible documentation
by Tatsuyuki Ishi 30 Mar '16

30 Mar '16

Sorry for complaining. Is there any plan to use any documentation tool to regenerate this? It's not unified with other libraries, and too horrible due to the small font size. I really can't read that.

2 1

[Root Pointer] Benchmark w/ Threading = 124% faster
by Phil Bouchard 30 Mar '16

30 Mar '16

I just noticed that if I do not define the BOOST_DISABLE_THREADS macro, root_ptr is faster than allocate_shared_noinit by 124%: unique_ptr (new): 42.1397 unique_ptr (make_unique): 43.4631 shared_ptr (new): 76.4543 shared_ptr (make_shared): 76.6611 shared_ptr (allocate_shared_noinit): 81.9926 root_ptr (new): 66.3417 Thanks, -Phil

1 2

Fwd: [sort parallel] New Parallel Sort Algorithm
by Francisco José Tapia 29 Mar '16

29 Mar '16

This message is for to announce the new version of the Boost Sort Parallel algorithms. You can find in http://github.com/fjtapia/sort_parallel. In the documentation, you can see the description of the algorithms, examples of invocations, and the graphs of the benchmark of the algorithms. The benchmark was not include in the library. I created other repository https://github.com/fjtapia/sort_parallel_benchmark, where you can find the code of the benchmark, the library, and the external code of the TBB parallel stable sort. It was not logic, include external code inside the library. The most significant of this version is the new parallel sort algorithm (internally named Block Indirect Sort) In the Parallel Sort Algorithms, we can find two groups. - Algorithms very fast with many threads (GCC Parallel Sort, Microsoft Parallel Buffered Sort), but use an additional memory as the data. - Algorithms without additional memory, but slower with many threads (TBB Parallel Sort, Microsoft Parallel Sort) The new algorithm *invented, designed and implemented by the author, provide the speed of GCC Parallel Sort and a memory usage similar to TBB. With the additional advantage that don't need any library ( Open MP , TBB, Microsoft PPL …). Only need a C++11 compiler. An example shows you this : Sorting 100 000 000 random numbers of 64 bits. In a server with 32 threads. The results obtained was *Time spent* *Memory used (MB)* *GCC Parallel Sort* 1.05 secs 1560 MB *TBB Parallel Sort* 1.76 secs 783 MB *Block Indirect Sort* 0.97 secs 790 MB In the repository with the benchmark code you can find the benchmark results with several machines https://github.com/fjtapia/sort_parallel_benchmark/tree/master/Linux64_GCC/… <https://github.com/fjtapia/sort_parallel_benchmark/tree/master/Linux64_GCC/…>In these files, you can see the rival is GCC. TBB is clearly surpassed, due to their internal algorithm. GCC divide the data, sorted independently by all the threads. And after for to merge do an easy process, and copy in an auxiliary memory, of the same size than the used by the data. All the threads are fed, but need the double of memory. The new algorithm, do the division, and sort independently, but for the merge, have a small buffer of 1024 elements, and when a part is moved to the buffer, must calculate which part must be copied in that place. Do the same but without the additional memory. Due this, need more CPU for to do the process. The hyper threading (HT) provide around a 30% more power to the processor, and usually in the machines with HT activate, the new algorithm is a bit faster than GCC, and with the HT deactivate is slower, and TBB is slower except when very big objects. But then the bottleneck is not the algorithm, is the data bus The new algorithm is a collection of bad algorithms when you have only 1 thread. But they are easily subdivided. This permit parallelize all the process and have fed all the threads. The new algorithm is documented in two articles - block_indirect_sort_brief_en.*:* (Introduction and graph benchmarks) - block_indirect_sort_en.pdf: (Introduction, detailed description of the algorithm and benchmarks.) If you want to test the benchmark in your machine it's easy. In the benchmark repository, you have the code used, and shell scripts for to compile and run, saving the results in a Results.txt file, for Linux GCC and CLANG and Windows Visual Studio 15 If you see any problem, mistake, something to improve or need any other information, please, say me. Yours Francisco * Invented: The algorithm had been ideate, designed and implemented beginning from zero from an old idea. After read hundreds of articles and books, I didn't find any similar. If you know something, please say me. But the important is not the author, is provide a fast, robust, and easy to use algorithm to the community of programmers.

1 0