- Boost - lists.preview.boost.org

wiki/Git/GitHome should list the repo address
by Josh Juran 17 May '14

17 May '14

Hi, I websearched 'boost git', and the top result was the GitHome wiki page. It would be helpful if this page included the address of Boost's Git repository near the top. <https://svn.boost.org/trac/boost/wiki/Git/GitHome> Josh

2 1

Application need a Review Manager. Anyone is interested?
by Renato Forti 17 May '14

17 May '14

Hi All, The proposed Boost.Application, needs a Review Manager. Anyone is interested? The project: https://github.com/retf/Boost.Application Thanks

4 3

[optional] new version in master
by Andrzej Krzemienski 16 May '14

16 May '14

Hi Everyone, This might have been too hasty, but I have put a new version of Boost.Optional on branch master. Tests in 'develop' and 'master' branches pass fine, but I am not sure what it says about overall stability of the library. The changes include: - Move semantics, interoperable with std::move_if_noexcept() -- i.e., move operations are conditionally noexcept; - Using explicit operator bool() rather than custom 'safe-bool idiom' --on applicable platforms; this will break code that exploited the security hole in safe-bool idiom. - Now, you cannot bind optional<T const&> to a temporary (the constructor and assignment taking T&& is deleted);this also break some usages that are likely buggy, but there is a macro to put it back. - Comparison with boost::none does not require that T be EqualityComparable: we just forward the call to operator bool() od operator!(). - optional<T&&> is explicitly prohibited. - some operations are marked noexcept (on platforms that support the keyword). - Rewritten some portions of documentation. I encourage everyone with spare time and available resources to test the version and give us feedback. Please remember that this is supposed to be an incremental improvement over the previous version (for Boost 1.56.0), and next upgrades are planned in the future. Regards, &rzej

2 1

[context] Using Boost.Context on the BlueGene/Q
by Thomas Heller 16 May '14

16 May '14

Hi list, I was very happy to see that Boost.Context has been fixed for PPC64. Thanks a lot for that. I was able to verify that the fix worked on the BlueGene/Q. Both on the Head node, which is a POWER7 and the compute nodes which are a PowerPC A2. However, in order to build the library, I needed to manually call the assembler as the predefined commands did not work. For example, the BG/Q provided assembler doesn't know the "--64" switch and the assembler i want to use is called bgclang-as instead of plain as. For the compute nodes, I additionally want to use the -ma2 flag to have the proper assembly generated. Is there a way to have that configurable by the user? Right now, the only way i could find to fix that is to manually edit the Jamfile.v2 in the context build directory. Any advice or hints to fix it properly are highly appreciated. Thanks, Thomas -- Thomas Heller Friedrich-Alexander-Universität Erlangen-Nürnberg Department Informatik - Lehrstuhl Rechnerarchitektur Martensstr. 3 91058 Erlangen Tel.: 09131/85-27018 Fax: 09131/85-27912 Email: thomas.heller(a)cs.fau.de

2 2

Re: [boost] Community Maintenance Team and neglected libraries
by Edward Diener 16 May '14

16 May '14

On 4/22/2014 12:29 PM, Ben Pope wrote: > In case you haven't heard of the CMT: > https://svn.boost.org/trac/boost/wiki/CommunityMaintenance > > I'm also interested in getting the test results less yellow and more > green, I don't have a lot of time, I'm sure I'm not alone. > > There are quite a few places where the library code is probably fine, > but the failure is in the test itself, the fix is often simple and > uncontroversial. > > Without picking on any particular library or author, here are some > examples: > > * Link the tests with boost::system > http://thread.gmane.org/gmane.comp.lib.boost.maint/92 > * Merge existing fixes in develop to master > http://thread.gmane.org/gmane.comp.lib.boost.devel/250129 > * Fight with casts > http://thread.gmane.org/gmane.comp.lib.boost.devel/250143 > * Disambiguate a type > https://svn.boost.org/trac/boost/ticket/9540 These refer to system, MPI, utility, and assign. None of these are in the list of libraries which the community maintenance team has write acces to apply fixes. Hopefully the developers who do have write access to these libraries will look at the issues involved.

5 7

Re: [boost] Community Maintenance Team and neglected libraries
by Daniela Engert 15 May '14

15 May '14

Am 22.04.2014 18:29 schrieb Ben Pope: > There are quite a few places where the library code is probably fine, > but the failure is in the test itself, the fix is often simple and > uncontroversial. > ... > The responses have been frustrating to say the least, we really need a > way to move forward on this. > You're so true with your observation. I'm a bit disappointed too. I'm sitting on a pile of simple patches to cleanup the existing tests such that I don't have to wade through a morass of level-4 msvc compiler warnings when running the test suite. This requires both fixes to some of the libraries themselves (thereby finding real bugs on the way) and fixes to the test code to get the tests compiled in the first place. It's those sanitized libraries that I supply to my colleagues for production code because it's our policy to be absolutely clean on level-4 warnings. Some months ago, I've prepared some of those patches (more yet to come) for inclusion into boost mainline, and some of them were picked up. The rest of my pull requests seems to be neglected. I prefer to refrain from spamming the mailing lists with reminders, but is there a better way to get the message through? Dealing with quality-of-implementation issues and acting like a janitor might not be the most sexy job in the universe, but I'm happy to do it (rather than just sitting on the fence) as long as it has an effect, eventually. Ciao Dani

3 2

[GitHub] List open pull requests for all libraries? [resend]
by Beman Dawes 15 May '14

15 May '14

We need to be able to monitor the open pull requests for all Boost libraries, not just a individual library. I'm not seeing any canned way of doing that via the GitHub web site. Am I missing something? It does seem possible to access the required information via the GitHub API. Is that the best approach to take? Does anyone know how to do this? Thanks, --Beman

8 14

[test] Regression tests and boost.test merge questions
by Antony Polukhin 15 May '14

15 May '14

Hi, I'm just curious about the situation with Boost.Test. When will be the latest changes merged to master? Regression tests for master branch use develop or master version of Boost.Test? This is vital for me because TypeIndex library must be tested with RTTI off, but master version of Test fail to compile in that way. Compilation of Boost.Test in RTTI-off mode was fixed in develop branch. -- Best regards, Antony Polukhin

1 0

required toolsets
by Steven Watanabe 15 May '14

15 May '14

AMDG The list of required toolsets in explicit-failures-markup.xml is out-dated. Therefore, if no one objects, I propose setting it to the following: msvc-10.0, msvc-11.0, gcc-4.6, gcc-4.7, clang-darwin-11, clang-darwin-4.2.1, clang-linux-3.1, clang-linux-3.2, gcc-mingw-4.7, gcc-mingw-4.6 (two releases of each major compiler that appears in both the trunk and release regression tests) The sole effect of this is to determine which toolsets appear in the issues list: http://www.boost.org/development/tests/trunk/developer/issues.html In Christ, Steven Watanabe

10 32

[atomic] Support for specialized instructions
by Andrey Semashev 14 May '14

14 May '14

Hi, I've been contemplating the idea of adding support for some specialized atomic instructions to Boost.Atomic. Since I'm only familiar with x86 architecture, my current candidates are: * Increment/decrement with a check for zero result (lock inc/dec). The decrement is the most essential of the two because it would be useful for reference counters of various kinds. The increment is mostly beneficial in terms of code size, and it probably doesn't need the check for zero in most cases. * In-place logical operations (lock and/or/xor). These are useful in cases when the code needs to operate on flags or bit sets but doesn't need the result of the operation. Optional variants can be provided with a test for zero result. * Bit set/reset operations (lock bts/btr). The use cases are similar to the logical operations but the advantage is that the previous value of the altered bit can be returned. BTW, these operations are needed in Boost.Sync to implement mutexes on Windows. All these operations can be implemented through the standard atomic<> interface, and that's what would be done on platforms without support for the specialized instructions. For now the idea is to add special member functions to atomic<>, when used with arithmetic types. I was thinking about providing free functions as well, although I think that the complete set of the standard atomic functions would be required for that. Comments? Opinions?

4 6