- Boost-announce - lists.boost.org

[signals2][review] The review of the signals2 library (formerly thread_safe_signals) begins today, Nov 1st
by Stjepan Rajko 01 Nov '08

01 Nov '08

Hello all, The review for the Signals2 library (formerly known as thread_safe_signals) submitted by Frank Mori Hess begins today (Nov 1st) and is scheduled to end on Nov 10th. I would like to thank Franz Alt, Terry Golubiewski, Doug Gregor, Ravikiran Rajagopal and Andrew Webber for making this review possible by committing to reviewing the library. How to submit a review: -------- As usual, EVERYONE is welcome to participate in the review discussions and to submit a review. 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). Here are some questions you might want to answer in your review (feel free to skip those that don't apply to your analysis): * 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, every review should answer this question: * Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Please submit your review either to the list or privately to me by the end of the review period. If you send me a review privately I will forward it to the list so the review can be discussed. If you would prefer me to forward your review anonymously (with your name removed) please indicate that in your e-mail. If you are a first time reviewer, here is some more information to get you started: * http://www.boost.org/community/reviews.html has more information on the review process * the review officially takes place on both the boost dev and boost-user lists, but typically more of the discussion happens on the boost dev list * if you want to get a feel for past reviews, you can find them in the archives (see http://www.boost.org/community/groups.html) - the past review dates are on the review schedule (http://www.boost.org/community/review_schedule.html) Typically, there is a period of discussion between the reviewers and the author, with official reviews coming in towards the tail end of the review period. 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] The Signals2 FAQ also covers some differences: http://tinyurl.com/576gl6 Kind regards, Stjepan (review manager)

1 0

[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

[Review] Phoenix review starts today, September 21st
by Hartmut Kaiser 21 Sep '08

21 Sep '08

Hi all, The review of Joel de Guzmans and Dan Marsdens Phoenix V2 library starts today, September 21st 2008, and will end on September 30th. I really hope to see your vote and your participation in the discussions on the Boost mailing lists! --------------------------------------------------- About the library: The Phoenix library enables FP techniques such as higher order functions, lambda (unnamed functions), currying (partial function application) and lazy evaluation in C++. The focus is more on usefulness and practicality than purity, elegance and strict adherence to FP principles. History: Phoenix is a mature library from years of use as a sub-project under Spirit where it serves its purpose for semantic action handling. Phoenix predates Lambda's acceptance into Boost, but not Lambda itself. When Lambda was reviewed, it was concluded that both libraries were to be merged, and work on it began, culminating in Phoenix V2, what you are seeing now (an interesting offshoot of this effort is Boost.Fusion. We needed a powerful tuple facility with algorithms to get the design right). Recently, Eric Niebler did a (fully compatible) port to proto making use of boost.typeof for result type deduction. Eric's port, while significant, will not be the subject of the review, but can be regarded as the future of Phoenix (Phoenix V3). Phoenix V2 is currently a utility library included with Spirit V2 and therefore is already available from the latest Boost distributions (headers: $BOOST_ROOT/boost/spirit/home/phoenix, docs: $BOOST_ROOT/libs/spirit/phoenix, or http://www.boost.org/doc/libs/1_36_0/libs/spirit/phoenix/index.html) Phoenix V2 is a very important infrastructure library, IHMO. It has been used for several other library writing efforts already, most notably, Spirit V2. --------------------------------------------------- Please always state in your review, whether you think the library should be accepted as a Boost library! Additionally please consider giving feedback on the following general topics: - 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? Regards Hartmut Review Manager

1 0

[review] FSM Library review result
by Martin Vuille 15 Sep '08

15 Sep '08

This is a summary of the comments received during the review of Andrey Semashev's Finite State Machines (FSM) library. Apologies for the delay in getting these out. DOCUMENTATION * Relocate ToC to make it stand out. * Several people used the Wikipedia article http://en.wikipedia.org/wiki/Finite_state_machine as a reference for FSM terminology and operation, and found discrepancies between Boost.FSM and that description. Perhaps Boost.FSM should explicitly describe its FSM metamodel, or refer to an existing metamodel (Wikipedia FSM or Harel or UML Statechart, for example). The latter was mentioned several times as being preferred since it is a standard. * If possible, use standard terminology. For example, "transition map" vs. "state transition table". Or define the non-standard terms. * Include a comprehensive rationale mapping the design choices to the design objectives. * Compare/contrast Boost.FSM with the FSM implementation as described in "C++ Template Metaprogramming". * Add an example of event deferral using boost::function. * Clarify support for multithreading vs. asynchronous FSM, as some were confused by existing text. * Clarify lifetime of objects. * Add implementation of example using transition map/STT. * Add more complex example(s). SCOPE/FEATURES These were features that were suggested or asked about. Some or all may not be suited for addition to the library. In that event, it may be useful to explicitly mention in the documentation that they are not supported, and why. * Support nested states. Return-to-history was cited as an example of a benefit of nested states over nested FSM. * In STT, support matching "any" from state. * Add syntactic sugar to support "synthetic" states (cf. http://lists.boost.org/Archives/boost/2008/08/140714.php) * Support event deferral. * Support data-dependent transitions (perhaps this is the same as the synthetic state suggestion above). * Improve modeling of the "transition" concept. Specifically, there was an issue with the fact that the action was associated with a state rather than a transition. INTERFACE * There was a lot of discussion comparing the amount of code required to implement an "ad hoc" FSM, vs. the amount of code required to implement the same FSM using Boost.FSM. * The "transition map" representation was deemed to contain too much syntactic noise and not sufficiently similar to a traditional STT, and it was suggested that it should include the transition action. * Some felt that the interface was too procedural rather than being declarative. IMPLEMENTATION * There was quite a bit of discussion of the Boost.FSM implementation vs. the C++TM implementation, but I don't believe there were any specific conclusions reached. * Handling of event is different depending on whether or not transition map is used (handled by "to" state vs. current state, respectively). This is also the case when an event is not found in the transition map. This could lead to errors. Thanks again to Andrey for his submission and to all the reviewers and other who made comments for their input. MV

1 0

[review] FSM Library review result
by Martin Vuille 05 Sep '08

05 Sep '08

This is a brief report of the results of the review of Andrey Semashev's Finite State Machines (FSM) library. I want to do justice to the discussions that took place, and will follow-up with a complete summary next week. In spite of a good amount of discussion and an extension of the review period, the number of reviews was smaller than I had hoped for. Nonetheless, I believe that the library received an adequate review and, based on the review comments and other discussions, the FSM library cannot be accepted into Boost at this time. A total of four reviews were submitted, as follows: Andrea Carbone: YES Phil Endecott: NO Jeff Flinn: NO Chris Knight: NO Darryl Green also submitted a mini-review, which did not include an explicit yes or no vote, but expressed doubt about whether the library should be accepted. On the positive side, several people noted that the goals of the library (simplicity and greater performance than Boost.StateCharts) were valid and that such a library was needed in some applications. I personally support this view. I would like to thank Andrey for his efforts in developing the library. I would like to encourage him to pursue the discussions that were begun during this review and perhaps try again with an updated submission. MV

1 0

[review] Dataflow Review starts today, September 1st
by jarvi＠cs.tamu.edu 01 Sep '08

01 Sep '08

The review of Stjepan Rajko's Dataflow library starts today, September 1st, and will run until September 10th. --------------------------------------------------------- Description of the library: Dataflow is a generic library for dataflow programming. Dataflow programs can typically be expressed as a graph in which vertices represent components that process data, and edges represent the flow of data between the components. As such, dataflow programs can be easily reconfigured by changing the components and/or the connections. This review focuses on the Dataflow.Signals layer of the library. For its data transport mechanism, Dataflow.Signals uses Boost.Signals which can be used to make lasting dataflow connections based on function calls. Dataflow.Signals provides the following to facilitate signals-based dataflow networks: * A number of useful general-purpose components, and building blocks for implementing new components. * Various free functions and operators for connecting and using components. The library documentation provides some concrete examples of how Dataflow.Signals layer can be used. Some examples are: * Implementing distributed dataflow applications using Dataflow.Signals and Boost.Asio * An image processing network using Dataflow.Signals and Boost.GIL * A GUI dataflow editor (located in the Dataflow.Blueprint documentation) While the Dataflow library contains other layers, only the Dataflow.Signals layer is ready for review. Reviewers are welcome to provide feedback for any part of the library, but please be aware that the documentation and implementation for the other layers may be lacking (for example, there is the generic support layer, which provides concepts applicable to different dataflow frameworks, and can be used to develop generic dataflow code, as well as the Dataflow.Blueprint layer which provides run-time reflection and modeling of dataflow networks in a Boost Graph Library graph for any dataflow framework with implemented Dataflow library support). For the time being, please consider these other layers as implementation details or proof-of-concept examples, as appropriate. The library is accessible as a tarball at: http://www.boostpro.com/vault/index.php?&directory=Dataflow The documentation can be accessed here: http://www.dancinghacker.com/code/dataflow/ The documentation particular to the Dataflow.Signals layer under review: http://www.dancinghacker.com/code/dataflow/dataflow/signals.html Dataflow depends on many existing Boost libraries, such as Fusion and MPL. The Dataflow.Signals layer builds functionality over Boost.Signals. The Dataflow library has been tested using a recent version of the Boost trunk, as well as the 1.35 release. Tests and examples have been built successfuly on OS X (GCC 4.0, 4.2), Linux (GCC 4.2), and Windows (MSVC 8.0 and to some degree MinGW GCC 4.2). --------------------------------------------------------- --------------------------------------------------------- Questions you may want to answer in your review: - 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? In particular, please remember to answer the following question explicitly: - Do you think the library should be accepted as a Boost library? Jaakko Järvi Review Manager

1 0

[filesystem][xpressive] Hotfix patches available for 1.36.0
by Beman Dawes 29 Aug '08

29 Aug '08

Hotfix patches are available to fix Boost.Filesystem and Boost.Xpressive [1.36.0] problems. See http://svn.boost.org/trac/boost/wiki/ReleasePractices/HotFixes Providing hotfix patches is something new and experimental for Boost. Please let us know on the users or developers mailing list if you find the patches useful or have other comments. Thanks, --Beman

1 0

[review] FSM Review ends today
by Martin Vuille 27 Aug '08

27 Aug '08

The formal review for Andrey Semashev's Finite State Machines (FSM) ends today. If anyone is working on a review, please post it no later than Friday. I will post the results of the review early next week. Thanks to everyone who participated in the review. MV

1 0