May 2014 - Boost - lists.preview.boost.org

Re: [boost] Community Maintenance Team and neglected libraries
by Ahmed Charles 18 May '14

18 May '14

I'll be sure to take a look at the outdated pull requests when you send them to the cmt list. ________________________________ From: Beman Dawes Sent: 5/15/2014 3:35 PM To: Boost Developers List Subject: Re: [boost] Community Maintenance Team and neglected libraries On Tue, Apr 22, 2014 at 11:36 AM, Daniela Engert <dani(a)ngrt.de> wrote: > 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. > This is one of the specific examples we have been discussing at C++Now in Aspen this week. * You did the right thing when you submitted pull requests. * Your should get some form of response within a reasonable period of time. It will take the CMT awhile to put a specific time on "reasonable" but certainly a month with no response is not reasonable. * Please post a message on the CMT mailing list, with links to the pull requests that you haven't heard anything about. It is their responsibility to decide how to proceed. * If you have questions about global maintenance changes touching many libraries, the CMT list is the best place to ask for guidance. The CMT folks care about maintenance so it is not spamming the list to ask them maintenance related questions. HTH, --Beman _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Boost iterators are not SFINAE-friendly
by pfultz2 17 May '14

17 May '14

Boost iterators aren't SFINAE-friendly. This is a problem when building traits that detect certain behavior. Heres a simple example: #include <vector> #include <type_traits> #include <boost/iterator/filter_iterator.hpp> template<class> struct holder { typedef void type; }; template<class Iterator, class=void> struct is_advanceable : std::false_type {}; template<class Iterator> struct is_advanceable<Iterator, typename holder< decltype(std::declval<Iterator>() += std::declval<int>()) >::type> : std::true_type {}; static_assert(is_advanceable<std::vector<int>::iterator>::value, "This will pass"); struct predicate { template<class T> bool operator()(T&&) const; }; static_assert(not is_advanceable<boost::filter_iterator<predicate, std::vector<int>::iterator>>::value, "This won't pass"); Although, it doesn't always lead to a compile error(rather than subtitution failure), it does lead some very erroneous errors. Thanks, Paul -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-iterators-are-not-SFINAE-friendly-… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

[utility] Moving addressof out of Boost.Utility
by Glen Fernandes 17 May '14

17 May '14

I was informed the eventual plan is to get rid of Utility as a sub-module, and I observed that Assert was moved out already. If there's any interest in (and no objection to) moving boost::addressof out of it, I don't mind making that change. What would be the most appropriate home for it? A Boost.AddressOf sub-module similar to Boost.Assert? Glen

4 6

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