- Boost - lists.preview.boost.org

[release] 1.64.0 closed for major changes
by Rene Rivera 02 Mar '17

02 Mar '17

The master branch is now closed for new libraries and breaking changes, and will be closing for major changes in a week and closed for the beta in two weeks. Also, if you're ready, you can also add your libraries' changes to the release notes at: < https://github.com/boostorg/website/blob/master/feed/history/boost_1_64_0.q… > Thanks, -- The Boost Release Team

1 0

Re: [boost] [Boost-testing] Much longer linux regression run times
by Tom Kent 01 Mar '17

01 Mar '17

On Tue, Feb 28, 2017 at 9:08 PM, Rene Rivera <grafikrobot(a)gmail.com> wrote: > On Tue, Feb 28, 2017 at 8:55 PM, Tom Kent via Boost-Testing < > boost-testing(a)lists.boost.org> wrote: > >> >> I'm not really sure how to trace this down. Is there any way to log the >> time it takes the various libraries to complete their test suites? >> > > Not currently. The individual tests can run in parallel. To give you that > number we would have to save the information as part of the regression data > and sum it up as part of the regression reports. > > >> I'm guessing that will show one library that is using 3+ hours. Although, >> it is possible that a change went in to a higher level library that just >> adds a few seconds to each call and is used across many of the libraries. >> >> Thoughts? >> > > Binary search manually? You can limit what tests you run on the command > line by using the "--include-tests" b2 option < > https://github.com/boostorg/boost/blob/develop/status/Jamfile.v2#L18>. So > start off by only running tests for [a-m] or [n-z], then [a-g], and so on. > Until you find the time hog. > That sounds tough. As a shortcut, I've looked at the libraries that had commits to develop on the 18th: https://github.com/boostorg/boost/commits/develop?after=Y3Vyc29yOudbdLMAs4G… It looks like hana, chrono, ratio, and thread (with wave and core/winapi the previous day). If I get a chance tonight I'll start checking through those. Meanwhile, if those authors could look at those and see if there is anything that might be causing this, it would be appreciated. > > Other than that, maybe it's one of the libraries tested on Travis < > https://travis-ci.org/boostorg/boost>. And maybe check the length of > those first if they are long on Travis perhaps they are also long on > regular tests. > I could find the travis scripts for the superset repo (no change in build time), but I'm not clear on what that is doing. Is it testing individual libraries? Tom

3 2

[smart_ptr][thread] Build failures
by Raffi Enficiaud 01 Mar '17

01 Mar '17

Hi all, I have the following compilation issues on master and develop, failing the VS2008, VS2012, VS2013 builds for boost.test (VS2015 ok): 01-Mar-2017 09:57:43 common.mkdir ..\..\..\bin.v2\libs\thread 01-Mar-2017 09:57:43 common.mkdir ..\..\..\bin.v2\libs\thread\build 01-Mar-2017 09:57:43 common.mkdir ..\..\..\bin.v2\libs\thread\build\msvc-11 01-Mar-2017 09:57:43 common.mkdir ..\..\..\bin.v2\libs\thread\build\msvc-11\debug 01-Mar-2017 09:57:43 common.mkdir ..\..\..\bin.v2\libs\thread\build\msvc-11\debug\link-static 01-Mar-2017 09:57:43 common.mkdir ..\..\..\bin.v2\libs\thread\build\msvc-11\debug\link-static\threading-multi 01-Mar-2017 09:57:43 common.mkdir ..\..\..\bin.v2\libs\thread\build\msvc-11\debug\link-static\threading-multi\win32 01-Mar-2017 09:57:45 compile-c-c++ ..\..\..\bin.v2\libs\thread\build\msvc-11\debug\link-static\threading-multi\win32\thread.obj 01-Mar-2017 09:57:45 thread.cpp 01-Mar-2017 09:57:45 D:\bamboo_build_dir\SW-BCB108-VC2012W64\library\boost/thread/detail/thread.hpp(486) : warning C4067: unexpected tokens following preprocessor directive - expected a newline 01-Mar-2017 09:57:45 D:\bamboo_build_dir\SW-BCB108-VC2012W64\library\boost/smart_ptr/allocate_shared_array.hpp(355) : error C2059: syntax error : ')' 01-Mar-2017 09:57:45 D:\bamboo_build_dir\SW-BCB108-VC2012W64\library\boost/smart_ptr/allocate_shared_array.hpp(358) : see reference to class template instantiation 'boost::detail::sp_less_align<T,U>' being compiled 01-Mar-2017 09:57:45 D:\bamboo_build_dir\SW-BCB108-VC2012W64\library\boost/smart_ptr/allocate_shared_array.hpp(357) : error C2143: syntax error : missing ')' before ';' 01-Mar-2017 09:57:45 D:\bamboo_build_dir\SW-BCB108-VC2012W64\library\boost/smart_ptr/allocate_shared_array.hpp(357) : error C2143: syntax error : missing '}' before ')' 01-Mar-2017 09:57:45 D:\bamboo_build_dir\SW-BCB108-VC2012W64\library\boost/smart_ptr/allocate_shared_array.hpp(357) : error C2059: syntax error : ')' 01-Mar-2017 09:57:45 D:\bamboo_build_dir\SW-BCB108-VC2012W64\library\boost/smart_ptr/allocate_shared_array.hpp(357) : error C2238: unexpected token(s) preceding ';' Can those be quickly fixed? Thanks, Raffi

3 4

[thread]Forever sleeping
by Niklas Angare 01 Mar '17

01 Mar '17

Recent runs of my regression test runner NA-QNX660-x86 leave a lot of Boost.Thread test executables stuck in nanosleep, waiting for a condition variable, or both. Commit 544eda [1] which switched from CLOCK_REALTIME to CLOCK_MONOTONIC seems suspicious to me. If the returned timespec is ever compared to values based on the CLOCK_REALTIME epoch, such as system_clock, the results will be quite undesirable. Are you sure the return values of timespec_now() are only ever compared to each other and values based on the CLOCK_MONOTONIC epoch? [1] https://github.com/boostorg/thread/commit/544eda51bdf0c62b2f29dea6fe1cf935a… Regards, Niklas Angare

3 9

boost exception to_string()
by Olaf van der Spek 28 Feb '17

28 Feb '17

Hi, Is to_string() here supposed to match to_string() in boost\exception\to_string.hpp? class shared_array2 : public boost::iterator_range<T*> {}; typedef shared_array2<unsigned char> shared_data; to_string(shared_data()); I really didn't expect this to_string() to be found here.. is it a feature or is it a bug? -- Olaf

1 0

[config] [atomic] Problem with placement of BOOST_ALIGNMENT - requesting opinions/suggestions
by Groke, Paul 28 Feb '17

28 Feb '17

While preparing a pull request for my Boost.Atomic extensions for the z/OS compiler, I noticed that I have a slight problem there. To get the code to work on z/OS, I changed the placement of the BOOST_ALIGNMENT macro in atomic/detail/storage_type.hpp from... BOOST_ALIGNMENT(16) unsigned char data[Size]; to unsigned char data[Size] BOOST_ALIGNMENT(16); ...because unfortunately the z compiler doesn't understand the __attribute__ ((__aligned__(x))) when it's at the beginning of a variable/data member definition. (For the GNU __attribute__ ((__aligned__(x))) the new location is also the only documented location, although GCC doesn't seem to mind.) While reviewing my changes I now realized that this won't do, because BOOST_ALIGNMENT can also be defined as __declspec(align(x)) or alignas(x), both of which are legal at the beginning but not at the end of a variable/data member definition. (I'm not 100% sure about valid positions of alignas (x) - the examples I can find use alignas (x) at the beginning, but the compilers we currently use - which include MSVC, GCC and Clang, also seem to accept it at the end. __declspec(align(x)) definitely is a problem though.) And now I'm wondering what to do about this. One way to fix this would obviously be to introduce two additional macros, e.g. BOOST_ALIGNMENT_DECLSPEC and BOOST_ALIGNMENT_ATTRIBUTE. Only one of those would then expand to something non-empty, and both would have to be used in variable definitions. The BOOST_ALIGNMENT macro would remain as is for type declarations and for compatibility. The code in storage_type.hpp would then have to be re-written as BOOST_ALIGNMENT_DECLSPEC(16) unsigned char data[Size] BOOST_ALIGNMENT_ATTRIBUTE(16); Which of course is very very ugly. Another option would be a BOOST_ALIGNED_VARIABLE(alignment, variable_definition) macro. This would be nice in definitions like BOOST_ALIGNED_VARIABLE(16, unsigned char data[Size]); but much less nice in definitions like BOOST_ALIGNED_VARIABLE(16, some_template<foo BOOST_PP_COMMA bar BOOST_PP_COMMA baz>); And since not all compilers support variadic macros, this is probably the best one could do. The third option I can think of would be to leave things as they are, which of course would mean that I can't submit my Boost.Atomic implementation for z/OS... hm. I realize that making things uglier for a single compiler that almost nobody uses isn't something many people will cheer for. But then again I'd really like to have my Boost.Atomic implementation for z/OS in the official Boost releases :) So I'm calling out to you for suggestions/opinions/comments. Is there another way to combine the above mentioned square peg + round hole? And which option would you deem favorable/acceptable? Thank you for taking the time to read this wall of text, Cheers, Paul Groke The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. Dynatrace Austria GmbH (registration number FN 91482h) is a company registered in Linz whose registered office is at 4040 Linz, Austria, Freistaedterstrasse 313

3 8

[gsoc17] Boost will be participating in Google Summer of Code in 2017
by Niall Douglas 27 Feb '17

27 Feb '17

I am very pleased to inform the Boost community that Google accepted us into their Summer of Code programme this year. This was especially welcome after we were given "a year off" last year which could have caused substantial disruption to the multi year student projects had it not been due to the timely action of the steering committee and generous sponsorship of a stop gap Boost Summer of Code in 2016 by IMC Financial Markets. Last year Google completely rebuilt the Summer of Code website so it no longer is anything like it was before. Now we must individually invite those who vote on student projects, so *anyone willing to rank student project proposals* can you please email us with your details: 1. Your email address matching your Google Account so we can invite you onto the GSoC programme. 2. (Optional) your email address matching your Github Account so we can invite you onto the Boost GSoC github org for 2017 as a potential mentor. Our thanks to those who have already added project ideas to https://svn.boost.org/trac/boost/wiki/SoC2017, but we need MORE ideas and MORE potential project mentors. Follow the project idea template at https://svn.boost.org/trac/boost/wiki/GSoCIdeaTemplate and either add it straight to the wiki page or email it to us so we can add it for you. Our thanks to all in advance.

1 0

ABI navigator for Boost libraries
by Andrey Ponomarenko 26 Feb '17

26 Feb '17

Hello, I'd like to present a new project called "ABI Navigator" to search for binary symbols (functions, methods, global data, etc.) in the Boost and other open-source libraries: https://abi-laboratory.pro/index.php?view=navigator The project allows to find out in which versions of the library and in which particular objects of the library some symbol is defined, added or removed. The project is based on the ABI report for Boost: https://abi-laboratory.pro/tracker/timeline/boost/ Examples: 1. symbol "boost::system::system_category()" from libboost_system.so: https://abi-laboratory.pro/index.php?view=navigator&selected=_ZN5boost6syst… 2. symbol _ZnwmPv21boost_container_new_t from libboost_container.so: https://abi-laboratory.pro/index.php?view=navigator&selected=_ZnwmPv21boost… The project aims to help library users and maintainers to resolve issues with missed symbols and navigate through the ABI reports. Have you ever encountered the "undefined reference" error or want to know whether the symbol is _stable_ enough to use in your code? Try to find it in the ABI Navigator! Enjoy!

1 0

[release] 1.64.0 closed for major changes
by Rene Rivera 23 Feb '17

23 Feb '17

The master branch is now closed for new libraries and breaking changes, and will be closing for major changes in a week and closed for the beta in two weeks. Also, if you're ready, you can also add your libraries' changes to the release notes at: < https://github.com/boostorg/website/blob/master/feed/history/boost_1_64_0.q… > Thanks, -- The Boost Release Team -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

1 0

[mpi] Merging a PR fixing auto_ptr usage
by Andrey Semashev 22 Feb '17

22 Feb '17

Hi, Could someone take a look at this PR and hopefully merge it? https://github.com/boostorg/mpi/pull/38 It should be safe to merge, and I would really like to see it in 1.64. I'm surprised noone fixed it earlier, actually. Thanks.

2 1