- Boost-announce - lists.preview.boost.org

[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

[review] FSM Review extended until August 27th
by Martin Vuille 20 Aug '08

20 Aug '08

By request, the formal review for Andrey Semashev's Finite State Machines (FSM) library has been extended and will run until August 27th. This is your last chance to submit a review and cast your vote for or against inclusion of this library into Boost. The documentation (overview and reference) is available online: http://boost-extension.redshoelace.com/docs/boost/fsm/doc/state_machine.html http://boost-extension.redshoelace.com/docs/boost/fsm/doc/reference.html The current submission is available from the sandbox vault at http://tinyurl.com/yjozfn (or http://www.boostpro.com/vault/index.php?action=downloadfile&filename=FSM.zip &directory=&PHPSESSID=48493076c1ea60ae316f7b60f15b9ed1, if you prefer.) ----------- Description ----------- "The main goals of the library are: * Simplicity. It should be very simple to create state machine using this library. * Performance. The state machine infrastructure should not be very time and memory-consuming in order to be applicable in more use cases. * Extensibility. A developer may want to add more states to the existing state machine, and this addition should be relatively safe since it shouldn't interfere with the existing states. The developer should also be able to specify additional transitions and events for the machine with minimum modifications to the existing code." "Boost.FSM vs. Boost.Statechart There is another library in Boost that provides similar functionality: Boost.Statechart. Although it currently covers almost all major Boost.FSM features and provides ones that are not supported in this library, Boost.Statechart is more targeted to creation of big and complex state machines with possibility of distributed development. But this does not come at no price and Statechart has little tools for compile-time programming and does not provide as much run-time performance as Boost.FSM does. So there are main guidelines for users to make a decision between Boost.FSM and Boost.Statechart: [...]" "The following compilers are known to have problems or most likely will have ones: * Microsoft Visual C++ 6.0 and 7.0. Most probably will fail to compile due to lack of partial template specialization support. * Borland C++ Builder 5.5.1 (free version). Fails to compile due to lack of partial template specialization and in-class using declarations support. Some other minor problems also have been noticed. Newer versions of the compiler have not been tested. * OpenWatcom 1.5. Fails to compile due to problems with Boost.MPL code. Newer versions of the compiler have not been tested. * SunPro C++ Compiler 5.5 for Solaris (SPARC). Most likely will show problems with function overload resolution. Newer versions of the compiler have not been tested." The current submission is available from the sandbox vault at http://tinyurl.com/yjozfn (or http://www.boostpro.com/vault/index.php?action=downloadfile&filename=FSM.zip &directory=&PHPSESSID=48493076c1ea60ae316f7b60f15b9ed1, if you prefer.) ---------------------------------- What to include in Review Comments ---------------------------------- Your comments may be brief or lengthy, but basically the Review Manager needs your evaluation of the library. If you identify problems along the way, please note if they are minor, serious, or showstoppers. Here are some questions you might 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? 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. Thanks in advance for your participation in this review. MV

1 0

[review] FSM Second Call for Reviews
by Martin Vuille 19 Aug '08

19 Aug '08

The formal review for Andrey Semashev's Finite State Machines (FSM) library has been running for a week now and continues until the 20th. There have been some lively discussions about the library, but no one has yet entered an explicit yes or no vote. If there are no votes either way, the FSM library submission will be rejected by default. If you wish to review, but don't have time before the review period ends on the 20th, please let me know as it may be possible to extend the review period. And, finally, a reminder to include an explicit "for" or "against" vote in your review. ----------- The documentation (overview and reference) is available online: http://boost-extension.redshoelace.com/docs/boost/fsm/doc/state_machine.html http://boost-extension.redshoelace.com/docs/boost/fsm/doc/reference.html The current submission is available from the sandbox vault at http://tinyurl.com/yjozfn (or http://www.boostpro.com/vault/index.php?action=downloadfile&filename=FSM.zip &directory=&PHPSESSID=48493076c1ea60ae316f7b60f15b9ed1, if you prefer.) There has already been some discussion of the library since the rewiew was first announced: http://www.nabble.com/FSM-Review-Announcement-to18820219.html http://www.nabble.com/FSM-Review-Reminder-to18890305.html ----------- Description ----------- "The main goals of the library are: * Simplicity. It should be very simple to create state machine using this library. * Performance. The state machine infrastructure should not be very time and memory-consuming in order to be applicable in more use cases. * Extensibility. A developer may want to add more states to the existing state machine, and this addition should be relatively safe since it shouldn't interfere with the existing states. The developer should also be able to specify additional transitions and events for the machine with minimum modifications to the existing code." "Boost.FSM vs. Boost.Statechart There is another library in Boost that provides similar functionality: Boost.Statechart. Although it currently covers almost all major Boost.FSM features and provides ones that are not supported in this library, Boost.Statechart is more targeted to creation of big and complex state machines with possibility of distributed development. But this does not come at no price and Statechart has little tools for compile-time programming and does not provide as much run-time performance as Boost.FSM does. So there are main guidelines for users to make a decision between Boost.FSM and Boost.Statechart: [...]" "The following compilers are known to have problems or most likely will have ones: * Microsoft Visual C++ 6.0 and 7.0. Most probably will fail to compile due to lack of partial template specialization support. * Borland C++ Builder 5.5.1 (free version). Fails to compile due to lack of partial template specialization and in-class using declarations support. Some other minor problems also have been noticed. Newer versions of the compiler have not been tested. * OpenWatcom 1.5. Fails to compile due to problems with Boost.MPL code. Newer versions of the compiler have not been tested. * SunPro C++ Compiler 5.5 for Solaris (SPARC). Most likely will show problems with function overload resolution. Newer versions of the compiler have not been tested." The current submission is available from the sandbox vault at http://tinyurl.com/yjozfn (or http://www.boostpro.com/vault/index.php?action=downloadfile&filename=FSM.zip &directory=&PHPSESSID=48493076c1ea60ae316f7b60f15b9ed1, if you prefer.) ---------------------------------- What to include in Review Comments ---------------------------------- Your comments may be brief or lengthy, but basically the Review Manager needs your evaluation of the library. If you identify problems along the way, please note if they are minor, serious, or showstoppers. Here are some questions you might 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? 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. Thanks in advance for your participation in this review. MV

1 0

Boost 1.36.0 release notice
by Beman Dawes 15 Aug '08

15 Aug '08

Boost 1.36.0 has been released and is available from SourceForge. See http://sourceforge.net/projects/boost/ This release include four new libraries: * Accumulators: Framework for incremental calculation, and collection of statistical accumulators, from Eric Niebler. * Exception: A library for transporting of arbitrary data in exception objects, and transporting of exceptions between threads, from Emil Dotchevski. * Units: Zero-overhead dimensional analysis and unit/quantity manipulation and conversion, from Matthias Schabel and Steven Watanabe * Unordered: Unordered associative containers, from Daniel James. Updated libraries include Asio, Assign, Function, Hash, Interprocess, Intrusive, Math, MPI, Multi-index Containers, PtrContainer, Spirit, Thread, Wave, and Xpressive. The release managers were Beman Dawes, Rene Rivera, and Daniel James. One note of caution: the initial SourceForge release files were missing some of the documentation. If you downloaded before 16:00 UTC, August 14th, please download again to be sure to get the full distribution. Sorry for the inconvenience! --Beman Dawes PS: The 1.36.0 version of the web site should be up within a few hours. If you can't wait, see http://beta.boost.org now!

1 0

[review] FSM Review Starts Today August 11th
by Martin Vuille 11 Aug '08

11 Aug '08

The formal review for Andrey Semashev's Finite State Machines (FSM) library begins today and will run until the 20th. The documentation (overview and reference) is available online: http://boost-extension.redshoelace.com/docs/boost/fsm/doc/state_machine.html http://boost-extension.redshoelace.com/docs/boost/fsm/doc/reference.html The current submission is available from the sandbox vault at http://tinyurl.com/yjozfn (or http://www.boostpro.com/vault/index.php?action=downloadfile&filename=FSM.zip &directory=&PHPSESSID=48493076c1ea60ae316f7b60f15b9ed1, if you prefer.) There has already been some discussion of the library since the rewiew was first announced: http://www.nabble.com/FSM-Review-Announcement-to18820219.html http://www.nabble.com/FSM-Review-Reminder-to18890305.html ----------- Description ----------- "The main goals of the library are: * Simplicity. It should be very simple to create state machine using this library. * Performance. The state machine infrastructure should not be very time and memory-consuming in order to be applicable in more use cases. * Extensibility. A developer may want to add more states to the existing state machine, and this addition should be relatively safe since it shouldn't interfere with the existing states. The developer should also be able to specify additional transitions and events for the machine with minimum modifications to the existing code." "Boost.FSM vs. Boost.Statechart There is another library in Boost that provides similar functionality: Boost.Statechart. Although it currently covers almost all major Boost.FSM features and provides ones that are not supported in this library, Boost.Statechart is more targeted to creation of big and complex state machines with possibility of distributed development. But this does not come at no price and Statechart has little tools for compile-time programming and does not provide as much run-time performance as Boost.FSM does. So there are main guidelines for users to make a decision between Boost.FSM and Boost.Statechart: [...]" "The following compilers are known to have problems or most likely will have ones: * Microsoft Visual C++ 6.0 and 7.0. Most probably will fail to compile due to lack of partial template specialization support. * Borland C++ Builder 5.5.1 (free version). Fails to compile due to lack of partial template specialization and in-class using declarations support. Some other minor problems also have been noticed. Newer versions of the compiler have not been tested. * OpenWatcom 1.5. Fails to compile due to problems with Boost.MPL code. Newer versions of the compiler have not been tested. * SunPro C++ Compiler 5.5 for Solaris (SPARC). Most likely will show problems with function overload resolution. Newer versions of the compiler have not been tested." The current submission is available from the sandbox vault at http://tinyurl.com/yjozfn (or http://www.boostpro.com/vault/index.php?action=downloadfile&filename=FSM.zip &directory=&PHPSESSID=48493076c1ea60ae316f7b60f15b9ed1, if you prefer.) ---------------------------------- What to include in Review Comments ---------------------------------- Your comments may be brief or lengthy, but basically the Review Manager needs your evaluation of the library. If you identify problems along the way, please note if they are minor, serious, or showstoppers. Here are some questions you might 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? 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. Thanks in advance for your participation in this review. MV

1 0

FSM Review Reminder
by Martin Vuille 08 Aug '08

08 Aug '08

The formal review for Andrey Semashev's Finite State Machines (FSM) library is scheduled for August 11th to 20th. The documentation (overview and reference) is available online: http://boost-extension.redshoelace.com/docs/boost/fsm/doc/state_machine.html http://boost-extension.redshoelace.com/docs/boost/fsm/doc/reference.html Quoting from the documentation: "The main goals of the library are: * Simplicity. It should be very simple to create state machine using this library. * Performance. The state machine infrastructure should not be very time and memory-consuming in order to be applicable in more use cases. * Extensibility. A developer may want to add more states to the existing state machine, and this addition should be relatively safe since it shouldn't interfere with the existing states. The developer should also be able to specify additional transitions and events for the machine with minimum modifications to the existing code." "Boost.FSM vs. Boost.Statechart There is another library in Boost that provides similar functionality: Boost.Statechart. Although it currently covers almost all major Boost.FSM features and provides ones that are not supported in this library, Boost.Statechart is more targeted to creation of big and complex state machines with possibility of distributed development. But this does not come at no price and Statechart has little tools for compile-time programming and does not provide as much run-time performance as Boost.FSM does. So there are main guidelines for users to make a decision between Boost.FSM and Boost.Statechart: [...]" "The following compilers are known to have problems or most likely will have ones: * Microsoft Visual C++ 6.0 and 7.0. Most probably will fail to compile due to lack of partial template specialization support. * Borland C++ Builder 5.5.1 (free version). Fails to compile due to lack of partial template specialization and in-class using declarations support. Some other minor problems also have been noticed. Newer versions of the compiler have not been tested. * OpenWatcom 1.5. Fails to compile due to problems with Boost.MPL code. Newer versions of the compiler have not been tested. * SunPro C++ Compiler 5.5 for Solaris (SPARC). Most likely will show problems with function overload resolution. Newer versions of the compiler have not been tested." The current submission is available from the sandbox vault at http://tinyurl.com/yjozfn (or http://www.boostpro.com/vault/index.php?action=downloadfile&filename=FSM.zip &directory=&PHPSESSID=48493076c1ea60ae316f7b60f15b9ed1, if you prefer.) MV

1 0