October 2008 - Boost-announce - lists.stage.boost.cppalliance.org

[1.37.0 beta] Beta release available on SourceForge
by Beman Dawes 23 Oct '08

23 Oct '08

1.37.0 beta 1 is available on SourceForge. See http://tinyurl.com/674rcl There is one known bug in the beta; the Getting Started Guide release number is still shown as 1.36.0. That will be fixed in the final release. There is one new library (Proto) in the release and numerous bug fixes and updates to existing libraries. The beta period will be approximately ten days. Please post bug reports to either the boost developer or user lists, but also let us hear about success stories too! Many thanks to Eric Niebler, Daniel James, Rene Rivera, Marshall Clow, the testers, and all the others who helped to get this beta release together. --Beman Dawes

1 0

[thread_safe_signals][signals2] call for reviewers (review tentatively scheduled Nov 1st - Nov 10th)
by Stjepan Rajko 13 Oct '08

13 Oct '08

Hello all, The review for the Signals2 library (formerly known as thread_safe_signals - description below) submitted by Frank Mori Hess has been tentatively scheduled for Nov 1st - Nov 10th. As per a recent discussion on the review process (http://tinyurl.com/48tdjs) and after consulting with the review wizards, we would like to try something new for this review: have a number of reviewers commit beforehand to submitting a review. The goal of signing up is to ensure that there is both sufficient interest in the library, and that there will be enough reviews submitted for an informed decision on acceptance. If you are interested in this library, I encourage you to sign up now to be a reviewer (by this you commit to submitting a review preferably by the end of the review period). Of course, additional reviews from non-signed-up reviewers will also be welcome, but without enough reviewers signing up beforehand it is not clear that we should proceed with a review at this time. To sign up, please send me a reply (here or privately), and let me know whether the review period is suitable for you (we can make some adjustments if necessary). I strongly encourage participation from reviewers that would examine the library from a purely user standpoint (commenting on the interface and / or the documentation), as well as reviewers that would be willing to look into the details of the implementation (i.e., you don't have to focus on both). I you would like to sign up, please let me know by this Saturday (October 18th). About the library: -------- * The library can be downloaded from: http://www.boostpro.com/vault/index.php?&directory=thread_safe_signals (latest version is signals2-2008-10-08.zip) * Documentation is also available online: http://www.comedi.org/projects/signals2/libs/signals2/doc/html/index.html * A synopsis: The Boost.Signals2 library (formerly known as thread_safe_signals) is an implementation of a managed signals and slots system. Signals represent callbacks with multiple targets, and are also called publishers or events in similar systems. Signals are connected to some set of slots, which are callback receivers (also called event targets or subscribers), which are called when the signal is "emitted." Signals and slots are managed, in that signals and slots (or, more properly, objects that occur as part of the slots) can track connections and are capable of automatically disconnecting signal/slot connections when either is destroyed. This enables the user to make signal/slot connections without expending a great effort to manage the lifetimes of those connections with regard to the lifetimes of all objects involved. When signals are connected to multiple slots, there is a question regarding the relationship between the return values of the slots and the return value of the signals. Boost.Signals2 allows the user to specify the manner in which multiple return values are combined. * Relationship to Boost.Signals: This is a thread-safe variant of the original Boost.Signals library. There have been some changes to the interface to support thread-safety, mostly with respect to automatic connection management. The following thread offers some more details on the differences between the two implementations, as well as a plan of a phased replacement of Boost.Signals should Signals2 be accepted: http://tinyurl.com/4sqau3 [nabble] Again, if you are interested in this library, please consider signing up as a reviewer. Kind regards, Stjepan (review manager)

1 0

[Review] Phoenix review results
by Hartmut Kaiser 04 Oct '08

04 Oct '08

Hi all, the Phoenix review is over and I counted 15 votes, 11 of which vote for acceptance and 4 vote for conditional acceptance. Let me explain. All reviewers stated that the outstanding quality of the library and its documentation fully merit immediate acceptance. There is no direct concern with regard to the library itself. Phoenix V2 is already in the Boost distribution as a Spirit sub-library and has matured for a long time, proving its stability and usability. On the other hand, Phoenix provides functionality already covered by Boost.Bind and Boost.Lambda. It is the general intention to use Phoenix as the development ground for a new unified Boost library in this area. The review discussions revealed quite some details and certain problems which have to be resolved for this merger to happen. Joel has a full list of these details and promised to address all of them before adding Phoenix to the Boost SVN. The library authors made clear from the beginning that the review of the current Version 2 of the library is just a stepping stone towards this goal. At the same time Eric Niebler presented a first version of a Proto based Phoenix rewrite (referenced as Phoenix V3). It is the general consensus to use Phoenix V3 as the basis for further development. At the same time Phoenix V3 exposes the same interface as Phoenix V2 and passes all related tests. This review formally was about Phoenix V2, but largely turned out to be a discussion of the future of Bind/Lambda and how Boost should go forward in this direction. Again, the general consensus here is that a) we need a unified approach to bind, lambda, et.al., and b) Boost users need interface stability and minimal disruption. So here is the review result: The quality of Phoenix warrants immediate acceptance into Boost. OTOH, adding Phoenix to Boost as is introduces yet another library dealing with functional idioms. This possibly increases the confusion around the fact which of the libraries to use, etc. The goal should be to have a clear integration of, and migration path from the existing Boost.Bind and Boost.Lambda libraries before final addition of Phoenix to Boost. We will have a mini review before Phoenix gets merged to SVN to make sure whether the feedback from the v2 review was accommodated. Additionally this review will have to discuss: - the breaking interface changes from v2 - the migration path from boost::bind and lambda to Phoenix - how the interoperability with std::bind is solved (result_of semantics) - C++0x features such as rvalue references and variadic templates - the new extensibility mechanism - unified placeholders and interoperability issues with other Proto-based DSELs (such as Spirit.Qi, Spirit.Karma, and Xpressive) - compile times In general, the review was valuable for what it accomplished. It moved us closer towards a unified Boost library in the domain of functional programming idioms. Thanks to Joel and Dan for the high quality submission and to all participating the discussion for their valuable insights! Regards Hartmut Review Manager

1 0