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

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

10 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

1 0

Lack of response to pull requests
by Beman Dawes 10 May '14

10 May '14

IMO it should be a Boost policy that anyone who submits a pull request deserves a response within a reasonable period of time. *What is a "response"?* GitHub pull requests have a "Comment" mechanism, so that's the best mechanism as it ensures reaching the submitter even they don't read the developer list. We also need to delineate some common responses, but that can wait until the overall policy is agreed upon. *What is a "reasonable period of time"?* This may be a bit of a bike shed discussion since whatever we start with may need adjustment based on experience. Would two weeks be a good starting point? *Who should step in if there is no response from the library maintainer?* The Community Maintenance Team IMO is the logical choice. A pull request that does not receive a timely response may be an early warning sign that the library involved does not have an active maintainer. The CMT folks are interested maintenance and already have processes to review pull requests. This would be an expansion of their mandate, and details need to be worked out such as what happens if the library maintainer is just busy at the moment. *What should the pull submitter do if there is no response within the reasonable period of time?* Send an email to the CMT pointing to the open pull request. (It would be nice if the submitter didn't have to do anything, but that implies the ability to monitor open pull requests. See "[GitHub] List open pull requests for all libraries?") Comments? --Beman

1 0

Re: [boost] [GSoC, MPL11] Community probe
by Louis Dionne 09 May '14

09 May '14

Gonzalo Brito Gadeschi <g.brito <at> aia.rwth-aachen.de> writes: > I have a question: the proposal and library are called MPL11. That is true, but I'm starting to realize that it's a very bad name. The project started about two years ago, when C++14 was still out of my sight. Be reassured that I always consider the latest version of the language, not only C++11. > In my experience, relaxed constexpr allows for beautiful metaprogramming > with respect to C++11, in particular when combined with Boost.Fusion, and I > think that it is really a game changer with respect to C++11 constexpr, > since it allows not only "functional" metaprogramming but also "imperative" > metaprogramming, significantly lowering the learning curve of > metaprogramming for C++ programmers. Could you please expand on the nature of metaprogramming you have been doing with constexpr? Are you talking about manipulating values of a literal type, or about "pure type" computations? See below for more on that. > Have you consider the influence of relaxed constexpr (C++14) in your > library? > > Could it simplify the design/implementation/usage of the MPL? I did consider the impact of C++14 on the design of the library, and I still am. At this point, my conclusion is that we must define what we mean by a "template metaprogramming library". I differentiate between two main kinds of computations that can be done at compile-time. The first is manipulating "pure types" with metafunctions (e.g. type traits): using void_pointer = std::add_pointer_t<void>; using pointers = mpl::transform< mpl::list<int, char, void, my_own_type>, mpl::quote<std::add_pointer> >::type; The above example is completely artificial but you get the point. The second kind of computation is manipulating values of a literal type at compile-time. using three = mpl::plus<mpl::int_<1>, mpl::int_<2>>::type; The MPL wraps these values into types so it can treat computations on those as computations of the first kind, but another library could perhaps handle them differently (probably using constexpr). constexpr int three = plus(1, 2); It is easy to see how constexpr (and relaxed constexpr) can make the second kind of computation easier to express, since that is exactly its purpose. However, it is much less clear how constexpr helps us with computations of the first kind. And by that I really mean that using constexpr in some way to perform those computations might be more cumbersome and less efficient than good old metafunctions. As for using constexpr to express computations on literal values, another question arises. Should there be a general library for handling those at compile-time, or should it be the responsibility of a well written domain- specific library to provide means to perform domain-specific computations at compile-time whenever possible? For example, should the MPL11 provide constexpr math functions, or should the std:: math functions be constexpr whenever possible? Another example is std::array. While the MPL11 could provide a constexpr container for homogeneous values of a literal type, simply changing the `begin` and `end` of `std::array` to be constexpr would make it possible to iterate on the array at compile-time. template <typename T, std::size_t n> constexpr T sum(std::array<T, n> array) { T s{0}; for (T i: array) // awesome s += i; return s; } constexpr std::array<int, 5> array{{1, 2, 3, 4, 5}}; static_assert(sum(array) == 15, ""); Unfortunately, I don't think this is happening in C++14, but I could be mistaken. Still, you certainly understand the implications. So a valid question that must be answered before I/we can come up with a "final" version of the library that can be proposed to Boost (or for standardization) is: "What is the purpose of a TMP library?" Once that is well defined, we won't be shooting at a moving target anymore. Right now, I have avoided these questions as much as possible by focusing on computations of the first kind. For those computations, my research so far shows that constexpr is unlikely to be of any help. If someone can come up with counter-examples or ideas that seem to refute this, _please_ let me know and I'll even buy you a beer in Aspen. This is _very_ important; it's central to my current work. > Would a rewrite of MPL11 be necessary afterwards (MPL14)? If constexpr turns out to be a game changer for computations of the first kind, then I suspect a large part of the current MPL11 would have to be rewritten. Of course, I tried to prevent this from happening by going slowly and looking at all the possibilities, but these things happen and it's part of the game. As for computations of the second kind, not _much_ work (comparatively) has been done on them because I knew it was a can of worms. So even drastic changes would not kill the library as it stands. Finally, if any of this does not make sense to someone, please let me know (on this list or privately) so I can explain further and correct any fallacious reasoning on my part. I hope this answers your questions; sorry for the long-winded answer but I think it can be informative for others too. Regards, Louis

5 13

Re: [boost] Is Boost dead? [Re: Anyone is interested in being
by Sebastian Theophil 09 May '14

09 May '14

> The dev list is down about 30% 2011 onwards as against before 2011. > > Monthly commits to Boost are about 500 per month since 2011 as > compared to about 1000 per month before 2011. > Niall, don't forget that the marginal usefulness of every new contribution might be shrinking. Many Boost libraries were essential for C++03 users but become less useful once you've migrated to C++11. They were testing grounds for new standard features. The better the standard library, and the better the programming language itself, the less need there will be for an extensive library as boost. Seen through that lens, a dying boost library might be a good sign. Though I don't actually believe the dying part yet. There are still many useful libraries in boost that haven't made it into the standard. There are even more libraries I'd like to be included in boost, thus becoming default choices, even if they can never make it into the standard. Regards Sebastian -- Dr. Sebastian Theophil | stheophil(a)think-cell.com Senior Software Engineer We are looking for C++ Developers: http://www.think-cell.com/career think-cell Software GmbH | Chausseestr. 8/E | 10115 Berlin | Germany http://www.think-cell.com | phone +49 30 666473-10 | US phone +1 800 891 8091 Amtsgericht Berlin-Charlottenburg, HRB 85229 | European Union VAT Id DE813474306 Directors: Dr. Markus Hannebauer, Dr. Arno Sch?dl

2 1

[config] Should BOOST_NO_CXX11_ALLOCATOR be undefined for libcpp without std=c++11
by Glen Fernandes 09 May '14

09 May '14

I observed the absence of BOOST_NO_CXX11_ALLOCATOR with clang and libc++ without -std=c++11. Is this intended? Right now BOOST_NO_CXX11_ALLOCATOR's absence is (in my view) an indication of whether C++11 allocators, including class template std::allocator_traits, are supported - and without -std=c++11 neither could be. Glen

2 3

[Align] and [smart_ptr] local copy of modular boost not updating correctly.
by Fletcher, John P 08 May '14

08 May '14

Boost smart_ptr has changed to use the new library boost align which has just passed its review. Unfortunately this change does not automatically carry forward into my local copy of modular boost. I have a directory libs/align but it is empty. What do I need to do to get this new library (and any other new submodules) into my local copy? Thanks John

3 2

JSON Archives for Boost.Serialization
by Matt Calabrese 08 May '14

08 May '14

I'm looking into implementing JSON archives to be used with Boost.Serialization in a manner similar to the xml archives. After a quick search I see that others have worked on this (2008 GSOC project?), though there is nothing currently in Boost that I see. Is there any existing work on this that is up somewhere before I implement my own from scratch? -- -Matt Calabrese

3 3

[thread] Request review of new synchronisation object, boost::permit<>
by Niall Douglas 07 May '14

07 May '14

Dear Boost, Review and commentary upon a proposed new Boost object, boost::permit<> is invited. A quick description of their purpose: "Permits come in two variants, consuming and non-consuming. There is always a one-to-one relationship between the granting of a permit and the receiving of that permit, the only difference with the non-consuming variant is that the permit is automatically regranted as soon as it is consumed. This leads to the only API difference to condition variables: permit<consuming=true> provides notify_one() but not notify_all(), whilst permit<consuming=false> provides neither and you will have to use grant() and revoke() instead. When deciding to substitute permits for condition variables, you will need to decide carefully which kind of permit is the correct substitute." "Permit objects are actually very similar to a void promise/future i.e. they act as a reusable promise/future pair but without transporting any value or exception state, just the permission to proceed. This is due to their original design intention, which was as a promise/future equivalent for C11 (see below for their history, and note that the original C API is available in the boost::c_permit namespace and documentation can be found at https://ci.nedprod.com/job/Boost.Thread%20Build%20Documentation/lastSu ccessfulBuild/artifact/boost-trunk/boost/thread/permit/latex/pthread_p ermit_reference.pdf). As such, they can be very useful for situations where a promise/future is too heavy (permits can spin instead of sleep, plus they need not be repeatedly constructed and destructed)." There is lots more detail at their documentation page: https://ci.nedprod.com/job/Boost.Thread%20Build%20Documentation/Boost. Thread_Documentation/libs/thread/doc/html/thread/synchronization/permi t_ref.html Source code of Permit containing fork of Boost.Thread: https://github.com/ned14/thread/tree/permit_object They come with a functional and load soak test suite. They work on Windows, Linux, FreeBSD and I believe OS X. Any other questions do ask. Niall -- Currently unemployed and looking for work in Ireland. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/

8 27

[TTI] macro to "box" types for subsequent traits extraction?
by Rein Halbersma 07 May '14

07 May '14

Hi everyone, this is my first post to this mailinglist, so I hope I follow the proper conventions around here (yes, I did read the Discussion Policy). I have a small feature request for the Type Traits Introspection library: a macro BOOST_TTI_BOX_TYPE(U) that defines a class template box_type<T> with a nested typedef named "type" that equals T::U. Rationale: because box_type<T> is a metafunction that can be supplied to mpl::eval_if, this facilitates user-defined traits that extract a nested type U, but can fall back to a (user-defined) default type. This mimics the C++11 allocator_traits that also provide defaults for allocators that lack certain nested typedefs or other properties. Small self-contained example: http://coliru.stacked-crooked.com/a/76b9abf4aaf00350 One could probably also define similar "boxing" macros to go along with the has_template and other introspection tools in TTI. Would this be considered a useful feature? Rein

3 4

[locale] Who owns/has commit access to review/merge a pull request?
by Chris Stylianou 07 May '14

07 May '14

I have a pull request on boost::locale (on the develop branch), but it appears there has no activity in this repository since the SVN -> Git migration occurred. Who actually maintains boost::locale? I would really like to have this pull request review and then hopefully merge, so that it makes the 1.56 release :) -- View this message in context: http://boost.2283326.n4.nabble.com/locale-Who-owns-has-commit-access-to-rev… Sent from the Boost - Dev mailing list archive at Nabble.com.

3 5