- Boost - lists.preview.boost.org

[atomic] Major rewrite landed in develop
by Andrey Semashev 14 May '14

14 May '14

Hi, I've merged a major rewrite of Boost.Atomic into develop. The changes are quite massive to describe in a few words, but the most significant ones are: - The interface of atomic<> template and atomic_flag are now completely decoupled from the atomic operations implementation (the backends). It is now more consistent across all platforms and not duplicated everywhere. - atomic_flag and fences are now available through separate headers atomic_flag.hpp and fences.hpp. These headers are still included by atomic.hpp for backward compatibility. - The definition of configuration macros BOOST_ATOMIC_XXX_LOCK_FREE is now available through a separate header capabilities.hpp. Users are able to include it and test these macros before including the rest of Boost.Atomic. Most macros are now defined more correctly based on the sizes of the types (i.e. BOOST_ATOMIC_LONG_LOCK_FREE now actually depends on the size of long and is equivalent to BOOST_ATOMIC_INT32_LOCK_FREE or BOOST_ATOMIC_INT64_LOCK_FREE). - Added support for 128-bit atomic ops with MSVC. The support is always enabled for x86_64. There are some ancient AMD chips that don't support cmpxchg16b, users can define BOOST_ATOMIC_NO_CMPXCHG16B if they want to target those. - Added support for BOOST_ATOMIC_FLAG_INIT, although it is optional and atomic_flag is still zero initialized by default. I did not find a way to implement it and keep compatibility with C++03. - Improved ARM backend with gcc (tested for compilation). Now it supports 64- bit atomics. All operations are written in ll/sc manner instead of a CAS loop. - Added a separate ARM backend for MSVC (tested for compilation). Some support for ARM was added to develop earlier but the new implementation is better optimized (it uses appropriate intinsics wrt memory ordering). - Added support for 64-bit atomic ops for SPARCv9 with gcc (completely untested). - Added support for DEC Alpha backend with gcc (completely untested). It is based on the dead and incomplete code that was present in Boost.Atomic before. - Removed support for IA64 on Windows. Not sure if it is needed, but it can be added relatively easily. There are many more changes. Lots of code duplication removed, bugs with arithmetic overflow fixed and things I don't remember. This new version is the foundation for further improvements that are needed for Boost.Sync. In particular, I plan to add new operations (btr/bts, inplace logical operations) and maybe free atomic functions. You can see in the above list that much of the code is not properly tested, and I have little-to-none experience with some of the platforms. To my knowledge, there are no non-x86 regular testers. Therefore I'd appreciate if people reviewed and tried the code. Please, report any feedback, good or bad. Thank you.

1 0

[graph] Fix for directed_graph::swap
by Ben Pope 14 May '14

14 May '14

https://github.com/boostorg/graph/pull/5 Ben

1 1

compressed_pair breaks with multiple instances of empty types
by Hite, Christopher 14 May '14

14 May '14

I've been abusing compressed_pair to build a compressed_tuple. I'm pretty sure this bug can be fixed using intermediate types on the hierarchy. struct Empty1{}; struct Empty2{}; int i=sizeof( boost::compressed_pair<Empty1, boost::compressed_pair<Empty1, Empty2> >); //boom int j=sizeof( boost::compressed_pair<Empty1, Empty2>); //ok int k=sizeof( boost::compressed_pair<Empty1, Empty1>); //ok int h=sizeof( boost::compressed_pair<std::string, boost::compressed_pair<std::string, Empty2> >); //ok cc1plus: warnings being treated as errors In file included from ..../boost/boost_1_50_0/include/boost/compressed_pair.hpp:21, from /home/w461845/src/edgamm/src/lib/libLogger/include/libLogger/LogChain.hpp:4, from OLogTest.cpp:1: ..../boost/boost_1_50_0/include/boost/detail/compressed_pair.hpp: In instantiation of "boost::details::compressed_pair_imp<Empty1, boost::compressed_pair<Empty1, Empty2>, 3>": ..../boost/boost_1_50_0/include/boost/detail/compressed_pair.hpp:348: instantiated from "boost::compressed_pair<Empty1, boost::compressed_pair<Empty1, Empty2> >" OLogTest.cpp:112: instantiated from here ..../boost/boost_1_50_0/include/boost/detail/compressed_pair.hpp:73: error: direct base "Empty1" inaccessible in "boost::details::compressed_pair_imp<Empty1, boost::compressed_pair<Empty1, Empty2>, 3>" due to ambiguity g++ (GCC) 4.4.7 20120313 (Red Hat 4.4.7-4) Chris Hite This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email.

1 0

Re: [boost] Is there any interest in a library for actor programming? [preliminary submission]
by Charousset, Dominik 14 May '14

14 May '14

Lets hope the mail arrives this time ... boost(a)lists.boost.org [129.79.39.203] #<[129.79.39.203] #5.0.0 smtp; 5.4.7 - Delivery expired (message too old) [Default] 451-'4.3.5 Server configuration problem' (delivery attempts: 76)> #SMTP# ________________________________________ From: Dominik Charousset [dominik.charousset(a)haw-hamburg.de] Sent: Friday, May 09, 2014 14:18 To: boost(a)lists.boost.org Subject: Re: [boost] Is there any interest in a library for actor programming? [preliminary submission] On 09.05.2014, at 10:52, Jan Herrmann <jherrmann79(a)gmx.de> wrote: On 08.05.2014 19:30, Dominik Charousset wrote: >> Hi all, >> >> >> attached you'll find the first preliminary submission for Boost.Actor as ZIP file along with the Manual in PDF version. You currently still need CMake, a Boost.Jam build file will follow. The project is hosted at GitHub:https://github.com/Neverlord/boost.actor > > As far as I understand a library with LGPL can not be part of boost (see www.boost.org/development/requirements.html ). So the it should be changed. Yes, we would switch the license to the Boost License should it become accepted. >> To state the obvious: we [1] took our time, but not because we are not taking the boost submission serious. In fact, the opposite is true. We did refine libcppa (which is the base for Boost.Actor) over the last months based on community feedback - feedback from this mailing list, last year's C++Now, GitHub, and libcppa's mailing list. However, we are not just trying to lift our library into Boost. We want Boost.Actor to fit into Boost as good as possible - and we did significant changes to the API (see below), which also took time. Furthermore, we think performance is key when providing a native actor system. Boost.Actor/libcppa has now reached a level of performance with the latest version that lives up to our expectations - and hopefully to the expectations of (future) users as well. A brief performance evaluation [2] is attached. The graphs still mention 'libcppa' instead of Boost.Actor. >> >> I hope the lack of Boost.Jam support is not too much of an issue - I thought it would be a good idea to post the preliminary submission before the C++Now (you can meet me there!), to get people time to play with Boost.Actor beforehand. >> >> >> *Differences between Boost.Actor and libcppa* >> >> If you don't have any experience with libcppa, you can simply skip this. The most visible change is the removal of any_tuple and cow_tuple. The COW tuple implementation of libcppa is in our opinion not general enough and is too intermeshed with the type system. Instead, Boost.Actor provides the class `message` that is an opaque container from a user's point of view. Also, the pattern matching has been reduced to a minimal DSL for defining message handlers. The separate DSL for guard expressions is gone completely (a similar functionality still exists though). Since our pattern matching only worked with messages/any_tuples, we don't see too much use of it outside of Boost.Actor. We are still hoping for native pattern matching in C++ (N3449 proposed this a while ago) in which case our DSL would become unnecessary anyways. As a side-effect of removing all these parts, Boost.Actor has become a streamlined version of libcppa that is easier to grasp and that will be easier to mai > ntain i > n the long run as well. >> >> >> *Boost.Actor depends on...* >> >> variant, optional, none, string_algorithms, intrusive_ptr, thread (currently as header-only dependency), context/coroutine (for cooperatively scheduled blocking actors). Some examples also require program_options. >> >> >> *Boost.Actor does NOT use...* >> >> (1) MPL. Boost.Actor uses a ludicrous amount of metaprogramming based on boost::actor::detail::type_list. I've tried to port it to MPL and wasted almost two days doing so. MPL is a great C++ library. Unfortunately, C++98, not C++11. Even after adding variadic helpers to reduce the amount of template instantiations, it would still explode and fail to compile. I've stopped after writing half the size of the current type_list utility functions and still wasn't able to reduce the amount of template instantiations significantly enough. That being said, I am looking forward to the GSoC project for MPL11. >> >> (2) Serialization. The first and most obvious problem I have with this library is the lack of a portable binary archive. String serialization is sufficient for a lot of applications, but the performance hit for both networking overhead and the string serialization itself is not acceptable in an actor system. Furthermore, simply adding such a binary archive would not be enough. The library does not give you a platform-independent representation of the type names, which is crucial. Also, one cannot create an instance of a type given only its type name and then deserialize its values from a network stream (I was thinking of ETI::key_register using the uniform names and ETI::find, but it only solves a part of the problem). Adding all of these capabilities on top of boost.serialization plus writing a portable binary archive (or maybe use something like EOS - http://epa.codeplex.com/) would probably result in more code and most likely in a more complicated design, i.e., would be > harder to maintain. Maybe I miss the forest for the trees here and some experienced boost.serialization user knows a straightforward way I don't see. However, maybe there is interest in extending boost.serialization. I'd be happy to work on patches for adding uniform names, etc. >> >> (3) Boost.Asio. There is definitely potential to port the low-level parts of the middleman to Asio, I think. These changes would be transparent to the user, though, since users really only use the broker and can forget about the rest. >> >> >> *Separating parts of Boost.Actor?* >> >> Vicente J. Botet Escriba suggested to separate some parts of library. Namely the constexpr atom() [the other parts he suggested were removed, btw]. Aside from that, there are some C++11 utility functions that I think would be useful for other developers as well. Namely int_list [3] which can be used to create indices for variadic types such as tuples to allow users to apply the values of a tuple to a functor with apply_args [4]. type_list [5] is a powerful tool too, but I think this functionality goes to MPL11 anyways. Something that might be worth lifting to the boost namespace is unit [6], which makes metaprogramming (for me) a lot easier by providing an easy way of lifting void to something useful and don't need to worry whether or not it might end up in a tuple or variant. MPL already has void_t, but it doesn't seem to be indented to be used the way I use unit. For binary serialization of floats, there is IEEE 754 packing/unpacking [6] that is based on http://beej.us/gu > ide/bgn > et/examples/pack2.c > > What is the difference from your int_list and std::integer_sequence (http://en.cppreference.com/w/cpp/utility/integer_sequence) ? The difference is: integer_sequence didn't exist when I wrote int_list. But it's good to know that there's a standard way to do it in C++14. Thanks for the hint. By the way, is there any policy regarding C++11 in Boost? Should we just skip it and directly aim for C++14? The code base is currently C++11 compliant. Switching to C++14 would make a thing or two easier (i.e. I could remove some code). >> Sorry for the wall of text, the Mail got longer and longer somehow ... >> >> >> >> [1] "We" are a working group at the University of Applied Sciences Hamburg: http://inet.cpt.haw-hamburg.de/ >> >> [2] The sources for all benchmark programs can be found here: https://github.com/Neverlord/cppa-benchmarks, please keep in mind that the evaluation uses libcppa, so the API used in the benchmarks is different. >> >> [3] https://github.com/Neverlord/boost.actor/blob/a0cab41e2946df7d751c59dfead0c… >> >> [4] https://github.com/Neverlord/boost.actor/blob/ea53a515e09a98baa173ad379127c… >> >> [5] https://github.com/Neverlord/boost.actor/blob/58d6177837788b2e54b8547531bda… >> >> [6] https://github.com/Neverlord/boost.actor/blob/644a47760d6b55eef438a81d7bcdc… >> >> [7] https://github.com/Neverlord/boost.actor/blob/ea53a515e09a98baa173ad379127c…

1 0

Re: [boost] Is there any interest in a library for actor programming? [preliminary submission]
by Dominik Charousset 14 May '14

14 May '14

> On 11 May 2014, at 09:36 pm, Larry Evans wrote > > Hi Dominik, > > On 05/08/14 12:30, Dominik Charousset wrote post > http://article.gmane.org/gmane.comp.lib.boost.devel/250747 > including: > [snip] >> >> [3] https://github.com/Neverlord/boost.actor/blob/a0cab41e2946df7d751c59dfead0c… > > However, I have a question about the implementation. > > https://github.com/Neverlord/boost.actor/blob/a0cab41e2946df7d751c59dfead0c… > > uses a recursive call using a List<typename ...Ts> which is 1 shorter > than the argument list, List<T0, Ts...>. > Why not just pass sizeof...(T0, Ts...): > > http://en.cppreference.com/w/cpp/language/sizeof... > > and keep adding indices while decreasing this sizeof value, > as done here: > > http://svn.boost.org/svn/boost/sandbox/variadic_templates/boost/mpl/package… > > in the package_range_c template class where: > > Start value would be 0 > and Finish value would be sizeof...(T0, Ts...) > > It achieves the same result, but without producing unneeded > instantiations. For example: > > package_range_c<std::size_t,0,sizeof...(mpl::vector<T0,T2,T3>>::type > package_range_c<std::size_t,0,sizeof...(mpl::vector<S0,S2,S3>>::type > > would produce 1 instantiation of: > > package_range_c<std::size_t,0,3> > > whereas the int_list.hpp code would, IIUC, produce the same > number of instantiations for the T's and S's. > > Wouldn't using the sizeof... method be easier to understand > as well as produce few instantions? Reviewing the code again, I think there's really no good reason to recurse over Ts. Doing the unrolling in il_indices recursively with only two specializations is a simple design, but the instantiations of type_list are indeed unnecessary. Also, the dependency to type_list could be dropped when unrolling based on sizeof.... > -regards, > Larry > > NOTE: I tried to post to the newsgroup; however, apparently my > post got lost :( Let's hope the list is working again...

1 0

Boosr review of the 'convert' library starts tomorrow May 21.
by Edward Diener 13 May '14

13 May '14

The review of the Convert library starts tomorrow Monday, May 12 and goes through Wednesday May 21. The Convert library builds on the boost::lexical_cast original design and experience and takes those conversion/transformation-related ideas further. * to be applicable to a wider range of conversion-related use-cases, * to provide a more flexible, extendible and configurable type-conversion framework. The Convert library can be cloned from GitHub at https://github.com/yet-another-user/boost.convert. The library follows the modular-boost format. Just clone it to modular-boost/libs in the 'convert' subdirectory and run 'b2 headers' in order to create a link to its header file directory in the modular-boost/boost subdirectory. The library comes with documentation in its top-level index.html or doc/html/index.html file. The library is by Vladimir Batov and is a second reiteration with a greater focus of his library that was reviewed in the past. I am Edward Diener and I am again serving as the review manager of the library. Comments, questions, and reviews will all be welcome for the library. Please try to sum up your review by answering these questions: What is your evaluation of the design? What is your evaluation of the implementation? What is your evaluation of the documentation? What is your evaluation of the potential usefulness of the library? Did you try to use the library? With what compiler? Did you have any problems? How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? Are you knowledgeable about the problem domain? And finally: Do you think the library should be accepted as a Boost library? As always whether you do or do not feel that the library should be accepted into Boost please specify any changes you would like to see for the library to be better in your estimation.

4 3

[RFC] Modern CORBA C++ IDL Mapping and implementation
by Felipe Magno de Almeida 13 May '14

13 May '14

Hello Boosters, Where I work we are implementing an open source, modern, CORBA implementation and IDL mapping. We want it to support C++ and C++11 IDL mapping, but we also want to create another IDL mapping. This new IDL mapping is being experimentated in the following url https://github.com/expertisesolutions/mORBid/tree/concepts It still has some very problematic issues (like compilation-time of generated code) and of course it is still far from completion. But, we would like to hear suggestions about this approach. What we did was that an IDL interface is mapped to a typedef for boost::type_erasure (I found the idea quite cool for the reasons that I'll mention below) with the requirements defined in the IDL, e.g. its operations. The IDL also emits a model for this type_erasure which is the actual stub class and is called remote_reference. It also emits a proxy_reference model for the same type_erasure typedef which receives a std::reference_wrapper and proxies the calls, this is needed because type_erasure can't switch between by-reference and by-value in runtime. Why I believe this approach is better than current IDL to C++11 mapping: Because the IDL to C++11 mapping is too intrusive. You can't really use normal classes you have written for use as servants in CORBA because you have to inherit from Skeletons classes *and* you have to use the *exact* same signature as defined in the mapping. This is *way too restricted*. This is also inerent to the OO paradigm that CORBA uses. But, we can mimic the same features using type-erasure instead of directly using dynamic polymorphism. This gives a much greater freedom to users. It might be that Boost.type_erasure is not the best tool here because of compile-time and compiler memory usage, but the idea surely is. We still haven't seriously profiled boost.type_erasure yet, but we will do so as soon as possible. I think it might be very interesting to experiment with lite concepts and Boost.concept_check as well. Also, we created a EDSL for GIOP and IIOP mapping based on the boost.spirit infrastructure. We use that to treat alignment and endianness automatically and to use the same grammar for generation and parsing of IIOP messages. The message header grammar is defined like this: start = "GIOP" & octet('\1') /* GIOP major version */ & octet('\0') /* GIOP minor version */ & endianness [ octet(MessageType) /* message_type */ & raw_size(ulong_)[body] ] ; Which is compiled to IIOP parser or generator through boost.spirit infrastructure of make_terminal, make_directive and etc. This works splendid well and is really easy to use, extend, is statically checked and has great performance. Whoever feel interested, please take a look and comments are highly appreciated. Regards, -- Felipe Magno de Almeida

5 5

Re: [boost] Is there any interest in a library for actor programming? serialization + uniform names
by Andrzej Horoszczak 13 May '14

13 May '14

2 1

Lack of response to pull requests [resend]
by Beman Dawes 13 May '14

13 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

3 2

Lack of response to pull requests [resend]
by Beman Dawes 13 May '14

13 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

2 1

Boost lists back up but messages since May 9 probably lost
by Beman Dawes 13 May '14

13 May '14

Here are the details: ---------- Forwarded message ---------- From: DongInn Kim Date: Tue, May 13, 2014 at 6:48 AM Subject: Re: Boost lists are down To: Beman Dawes <bdawes(a)acm.org> Hi Beman, I am so sorry that there was a problem that I could not notice. The boost mail server and mailing list server were working OK but the spam filter server that the boost mail server use disabled our access, which I did not do and I can not do. I talked to the guy who manages the spam filter and make sure that they take care of the boost mails as well. It seems that it starts to flow but I am afraid that the mails that wowbagger had not delivered since May 9 are missing. :-( I will talk to the guy to see if there is a way to push the valid mails (i.e., non-spam mails) in the spam filter. I suspect that they are all already gone. Regards, -- - DongInn

1 0

A problem in the boost mailing list
by Kim, DongInn 13 May '14

13 May '14

Dear Boost mailing list users, My name is DongInn Kim, sysadmin of the boost mailing list. I am so sorry that there was a problem that I could not notice until this morning. The boost mail server and mailing list server have been working OK but the spam filter server that the boost mail server uses disabled our access, which I did not do and I can not do. I talked to the guy who manages the spam filter and make sure that they take care of the boost mails as well. It seems that it starts to flow but I am afraid that the mails that wowbagger had not delivered since May 9 are missing. :-( I will talk to the guy to see if there is a way to push the valid boost mails (i.e., non-spam mails) in the spam filter but I am afraid that they are all already gone. Again, I am sorry for the missing emails. Regards, -- - DongInn

1 0

Re: [boost] boost] [asio] intergrate with message loop how to
by microcai 13 May '14

13 May '14

2014-05-09 20:08 GMT+08:00 Nat Goodspeed <nat(a)lindenlab.com>: > On May 9, 2014, at 6:18 AM, microcai <microcai(a)fedoraproject.org> wrote: > >> 2014-05-05 21:57 GMT+08:00 Nat Goodspeed <nat(a)lindenlab.com>: >>> >> >>> Perhaps you might propose a cross-platform asio API extension that could give you control at the times you want, using the completion-handler mechanism? >> >> then there will be endless ways of loops that you need to integrated >> into asio. glib, qt, WIN32 message loop ... etc. > > Understood. I am not proposing that specific message-loop code be absorbed into Asio. I am asking whether you (or any interested reader) might be able to define an extension API that permits / facilitates a consuming Asio application to integrate with any required message loop. some thing like io_service::wait_events(); but , does not dispatch the event. I can run seperated thread to call this, then post message to gui thread, let gui thread run io_service::poll() to dispatch the handlers; if the hander is executed in gui thread, we can avoid lots of synchronization code between gui thread and asio thread( if io_service::run() has to be run in seperated thread. ).

1 0

test msg, please ignore
by Joaquín Mª López Muñoz 13 May '14

13 May '14

________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx

1 0

Boost Python Xcode Example
by Jared McIntyre 12 May '14

12 May '14

I have been trying to get the Boost Python example working when compiling in Xcode. Everything compiles at the moment, but the module fails to load in python. It fails to find the module if it has an extension of either .pyd or .dylib, and .so has the error "ImportError: dynamic module does not define init function” even though the function should be there. I’m sure that I have something setup incorrectly and was wondering is anyone has a working Xcode project example that I could take a look at to see where I’ve gone wrong. Thank you, Jared McIntyre

1 1

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

12 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

[asio] Windows 2000 no longer supported?
by Andrey Semashev 11 May '14

11 May '14

Hi, I've been reported this ticket: https://svn.boost.org/trac/boost/ticket/10016 that says that Boost.ASIO requires SO_UPDATE_CONNECT_CONTEXT now, which is only implemented since Windows XP. Is Windows 2000 support officially dropped in Boost.ASIO?

1 1

[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