September 2008 - Boost-announce

[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