- Boost-announce - lists.preview.boost.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

[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

[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