- Boost-announce - lists.boost.org

[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

FSM Review Announcement
by Martin Vuille 04 Aug '08

04 Aug '08

The formal review for Andrey Semashev's Finite State Machines (FSM) library is scheduled for August 11th to 20th. 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." "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

Egg review result
by dan marsden 17 May '08

17 May '08

This is a summary of the review of the Egg library by Shunsuke Sogame. The main issue with this review was the low number of reviews submitted, despite a reasonable amount of discussion on the list. In total only 1 review was received, from Giovanni Piero Deretta. This review was a yes vote, contingent on a mini review of improved documentation. Given this extremely low review count, unfortunately Egg cannot be accepted into Boost at this time. The remainder of this summary will cover some of the themes relating to lack of reviews, and also other highlights of the review. I'll start with some positive notes. Several comments on the list suggested that functionality in Egg was wanted by users, and that they would like to see Egg in Boost in some form in the future. Several writers also pointed out the high quality of the implementation of Egg, and technical issues were not really a focus of the discussions. During discussions on the developer several reviewers comments on the quality / style of the documentation for Egg. Motivation seemed to be a big issue in these comments, questions of the form "why should I use Egg versus Boost.XXX" were common. There typically were good reasons to use Egg, but these were not apparent to readers of the documentation. A related issue that cropped up was the sheer scale of Egg, one potential review was withdrawn as the scale of Egg was so large that the reviewer felt he could not do it justice. A couple of reviews pointed out that the documentation could be hard to follow, sometimes as the assumed expertise of the readers was possibly too high, and also for other reasons, such as the __ prefixed notation used in a lot of the documentation. Both Giovanni and Daniel Walker generously offered to provide assistance with the documentation for Egg. Joel de Guzman pointed out that that the timing of the review was poor, as it was in the immediate run up to Boostcon, and many potential reviewers would be busy with preparation for that event. This comment was supported by several people I discussed this with at Boostcon. There was much incredibly detailed technical discussion, which I cannot do justice to here. Those interested will be able to find the discussion on the mailing list archives. In summary I believe key points of the review were: * The number of reviews was insufficient to accept the library in its current form. This seemed to be due to documentation issues making reviews difficult, and the poor timing of the review before Boostcon. * The library was of high technical quality, and the functionality was needed by Boost users in some form. * Documentation issues would definitely need to be addressed before the library could be satisfactorily reviewed and accepted into Boost. I'd like to thank Shunsuke Sogame for submitting the library, and the hard work that he has put in so far. I'd like to encourage him to continue his efforts, and to take up the offers of assistance with documentation if he feels it appropriate. I personally would like to see many parts of Egg in Boost in some form in the future, and other reviewers seemed to agree. I would also like to thank the reviewer, and the many people that contributed discussion on the list, hopefully this will lead to an improved Egg returning in future. Thanks Dan Marsden Review Manager __________________________________________________________ Sent from Yahoo! Mail. A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html

1 0

Review Wizard Status Report for May 2008
by Ronald Garcia 16 May '08

16 May '08

========================================== Review Wizard Status Report for May 2008 ========================================== News ==== December 7, 2007 - Forward Library Accepted - Awaiting SVN December 16 - Unordered Containers Library Accepted - In SVN December 21 - Factory Library Accepted - Awaiting SVN January 13, 2008 - Switch Library Accepted Provisionally - Awaiting submission for mini review January 18 - Singleton Library Rejected - Awaiting resubmission, John Torjo has already volunteered to manage the next review January 30 - Flyweight Library Accepted - Awaiting SVN February 13 - Logging Library Rejected - Awaiting resubmission for new review, John Torjo has already resubmitted and Gennadiy Rozental has again volunteered to manage the review February 27 - Floating Point Utilities Library Accepted - Awaiting SVN March 14 - Proto Library Accepted - Exists as a component in Xpressive, but not yet as a separate library April 20 - Egg review completed - Results pending May 7 - Scope Exit Library Accepted - Awaiting SVN Older Issues ============ The binary_int library, accepted in October 2005 has not yet been submitted to SVN. The authors are strongly encouraged to contact the review wizards The Quantitative Units library, accepted in April 2007 has not yet been submitted to SVN The Globally Unique Identifier library, accepted provisionally in May 2007 has not yet been submitted for mini-review and full acceptance The Time Series Library, accepted in August 2007 has not yet been submitted to SVN The Accumulators library, accepted in February 2007 is in SVN The Exception library, accepted in October 2007 is in SVN The Scope Exit review report had not been submitted by the review manager. John Phillips stepped in as substitute review manager and produced a report For libraries that are still waiting to get into SVN, please get them ready and into the repository. The developers did some great work making the libraries, so don't miss the chance to share that work with others. Also notice that the review process page has been updated with a section on rights and responsibilities of library submitters. For the Scope Exit review, we would like to publicly apologize to Alexander Nasonov for how long this has languished without a report. The review wizards will work to make sure this doesn't happen any more. General Announcements ===================== As always, we need experienced review managers. In the past few months there have been a large number of reviews, but the flow of high quality submissions is just as big, so manage reviews if possible and if not please make sure to watch the review schedule and participate. Please take a look at the list of libraries in need of managers and check out their descriptions. In general review managers are active boost participants or library contributors. If you can serve as review manager for any of them, email Ron Garcia or John Phillips, "garcia at cs dot indiana dot edu" and "phillips at mps dot ohio-state dot edu" respectively. A link to this report will be posted to www.boost.org. If you would like us to make any modifications or additions to this report before we do that, please email Ron or John. If you're a library author and plan on submitting a library for review in the next 3-6 months, send Ron or John a short description of your library and we'll add it to the Libraries Under Construction below. We know that there are many libraries that are near completion, but we have hard time keeping track all of them. Please keep us informed about your progress. Review Queue ============ * Finite State Machines * Property Map (fast-track) * Graph (fast-track) * Lexer * Thread-Safe Signals * Boost.Range (Update) * Shifted Pointer * DataFlow Signals * Logging * Futures (Braddock Gaskill) * Futures (Anthony Williams) * Join (Yigong Liu) * Pimpl (Vladimir Batov) -------------------- Finite State Machines --------------------- :Author: Andrey Semashev :Review Manager: Martin Vuille :Download: `Boost Sandbox Vault <http://tinyurl.com/yjozfn>`__ :Description: The Boost.FSM library is an implementation of FSM (stands for Finite State Machine) programming concept. The main goals of the library are: * Simplicity. It should be very simple to create state machines 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 an existing state machine. A developer should also be able to specify additional transitions and events for the machine with minimum modifications to the existing code. Property Map (fast-track) ------------------------- :Author: Andrew Sutton :Review Manager: Jeremy Siek :Download: http://svn.boost.org/svn/boost/sandbox/graph-v2 :Description: A number of additions and modifications to the Property Map Library, including: * A constant-valued property map, useful for naturally unweighted graphs. * A noop-writing property map, useful when you have to provide an argument, but just don't care about the output. * See `ChangeLog <http://svn.boost.org/trac/boost/browser/sandbox/ graph-v2/libs/property_map/ChangeLog>`__ for details. Graph (fast-track) ------------------ :Author: Andrew Sutton :Review Manager: Jeremy Siek :Download: http://svn.boost.org/svn/boost/sandbox/graph-v2 :Description: A number of additions and modifications to the Graph Library, including: * Two new graph classes (undirected and directed) which are intended to make the library more approachable for new developers * A suite of graph measures including degree and closeness centrality, mean geodesic distance, eccentricity, and clustering coefficients. * An algorithm for visiting all cycles in a directed graph (Tiernan's from 1970ish). It works for undirected graphs too, but reports cycles twice (one for each direction). * An algorithm for visiting all the cliques a graph (Bron&Kerbosch). Works for both directed and undirected. * Derived graph measures radius and diameter (from eccentricity) and girth and circumference (from Tiernan), and clique number (from Bron&Kerbosch). * An exterior_property class that helps hides some of the weirdness with exterior properties. * run-time and compile-time tests for the new algorithms. * a substantial amount of documentation * Graph cores, implemented by David Gleich (@Stanford University) * Deterministic graph generators - capable of creating or inducing specific types of graphs over a vertex set (e.g., star graph, wheel graph, prism graph, etc). There are several other specific types that could be added to this, but I haven't had the time just yet. Lexer ----- :Author: Ben Hanson :Review Manager: Eric Neibler :Download: `Boost Sandbox Vault <http://boost-consulting.com/vault/ index.php? action=downloadfile&filename=boost.lexer.zip&directory=Strings%20-% 20Text%20Processing&>`__ :Description: A programmable lexical analyser generator inspired by 'flex'. Like flex, it is programmed by the use of regular expressions and outputs a state machine as a number of DFAs utilising equivalence classes for compression. Thread-Safe Signals ------------------- :Author: Frank Hess :Review Manager: Need Volunteer :Download: `Boost Sandbox Vault <http://www.boost-consulting.com/ vault/index.php?&direction=0&order=&directory=thread_safe_signals>`__ :Description: A thread-safe implementation of Boost.Signals that has some interface changes to accommodate thread safety, mostly with respect to automatic connection management. Boost.Range (Update) -------------------- :Author: Neil Groves :Review Manager: Needed :Download: `Boost Sandbox Vault <http://www.boost-consulting.com/ vault/index.php?action=downloadfile&filename=range_ex.zip&directory=>`__ :Description: A significant update of the range library, including range adapters. Shifted Pointer --------------- :Author: Phil Bouchard :Review Manager: Needed :Download: `Boost Sandbox Vault <http://www.boost-consulting.com/ vault/index.php?&direction=0&order=&directory=Memory>`__ :Description: Smart pointers are in general optimized for a specific resource (memory usage, CPU cycles, user friendliness, ...) depending on what the user need to make the most of. The purpose of this smart pointer is mainly to allocate the reference counter (or owner) and the object itself at the same time so that dynamic memory management is simplified thus accelerated and cheaper on the memory map. DataFlow Signals ---------------- :Author: Stjepan Rajko :Review Manager: Needed :Download: http://dancinghacker.com/code/dataflow/ :Description: 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. Logging ------- :Author: John Torjo :Review Manager: Gennadiy Rozental :Download: http://torjo.com/log2/ :Description: Used properly, logging is a very powerful tool. Besides aiding debugging/testing, it can also show you how your application is used. The Boost Logging Library allows just for that, supporting a lot of scenarios, ranging from very simple (dumping all to one destination), to very complex (multiple logs, some enabled/some not, levels, etc). It features a very simple and flexible interface, efficient filtering of messages, thread-safety, formatters and destinations, easy manipulation of logs, finding the best logger/filter classes based on your application's needs, you can define your own macros and much more! Futures ------- :Author: Braddock Gaskill :Review Manager: Needed :Download: http://braddock.com/~braddock/future/ :Description: The goal of the boost.future library is to provide a definitive future implementation with the best features of the numerous implementations, proposals, and academic papers floating around, in the hopes to avoid multiple incompatible future implementations in libraries of related concepts (coroutines, active objects, asio, etc). This library hopes to explore the combined implementation of the best future concepts. Futures ------- :Author: Anthony Williams :Review Manager: Needed :Download: http://www.justsoftwaresolutions.co.uk/files/ n2561_future.hpp (code) http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/ n2561.html (description) :Description: This paper proposes a kind of return buffer that takes a value (or an exception) in one (sub-)thread and provides the value in another (controlling) thread. This buffer provides essentially two interfaces: * an interface to assign a value as class promise and * an interface to wait for, query and retrieve the value (or exception) from the buffer as classes unique_future and shared_future. While a unique_future provides move semantics where the value (or exception) can be retrieved only once, the shared_future provides copy semantics where the value can be retrieved arbitrarily often. A typical procedure for working with promises and futures looks like: * control thread creates a promise, * control thread gets associated future from promise, * control thread starts sub-thread, * sub-thread calls actual function and assigns the return value to the promise, * control thread waits for future to become ready, * control thread retrieves value from future. Also proposed is a packaged_task that wraps one callable object and provides another one that can be started in its own thread and assigns the return value (or exception) to a return buffer that can be accessed through one of the future classes. With a packaged_task a typical procedure looks like: * control thread creates a packaged_task with a callable object, * control thread gets associated future from packaged_task, * control thread starts sub-thread, which invokes the packaged_task, * packaged_task calls the callable function and assigns the return value, * control thread waits for future to become ready, * control thread retrieves value from future. Notice that we are in the unusual position of having two very different libraries with the same goal in the queue at the same time. The Review Wizards would appreciate a discussion of the best way to hold these two reviews to produce the best possible addition to Boost. Join ---- :Author: Yigong Liu :Review Manager: Needed :Download: http://channel.sourceforge.net/ :Description: Join is an asynchronous, message based C++ concurrency library based on join calculus. It is applicable both to multi-threaded applications and to the orchestration of asynchronous, event-based applications. It follows Comega's design and implementation and builds with Boost facilities. It provides a high level concurrency API with asynchronous methods, synchronous methods, and chords which are "join-patterns" defining the synchronization, asynchrony, and concurrency. Pimpl ----- :Author: Vladimir Batov :Review Manager: Needed :Download: `Boost Sandbox Vault <http://www.boost-consulting.com/ vault/index.php?action=downloadfile&filename=Pimpl.zip&directory=&>`__ http://www.ddj.com/cpp/205918714 (documentation) :Description: The Pimpl idiom is a simple yet robust technique to minimize coupling via the separation of interface and implementation and then implementation hiding. This library provides a convenient yet flexible and generic deployment technique for the Pimpl idiom. It's seemingly complete and broadly applicable, yet minimal, simple and pleasant to use. Libraries under development =========================== Please let us know of any libraries you are currently developing that you intend to submit for review.

1 0

[review] BOOST_SCOPE_EXIT review results
by John Phillips 07 May '08

07 May '08

Here are the review results for the Scope Exit library, submitted by Alexander Nasonov. I would be remiss if I didn't begin these results with an apology and a thank you. The review wizards are sincerely sorry that the result of this review took so long to be presented, and very grateful that Alexander has been so patient and according to a post on the forum has even been working to improve the library in the interim when time allowed. The following people contributed to the review. Kim Barrett, Steven Wantanabe, Oleg Abrosimov, Andrey Semashev, Peder Holt, Johan Nilsson, Maxim Yanchenko, Pavel Vozenilek, Aaron LaFramboise, Ben Kuppers, Goran Mitrovic, Tom Brinkman, Martin Wille, Joseph Gauterin, Matt Gruenke, Dave Abrahams, Christian Holmquist, Mathais Gaunard, Michael Marcin, Daniel Wallin, Zach Laine, Sid Sacek, Wang Yun, and Ilya Sokolov After carefully considering the review comments, I'm pleased to announce that the Scope Exit library is accepted into Boost. As is almost always the case, there are some notes for improvement for this library, and in this case there is even a suggestion for a substantial future restructuring. Let's start with the big one first. As it is currently implemented, SCOPE_EXIT suggests a method for creating a general closure mechanism as a library. This is a useful enough idea that many of the reviewers strongly encouraged Alexander to do it, and provided ideas for implementation details. Alexander should continue to work on this, and when it is ready for review, submit it to Boost. When he gets it accepted into boost, he should consider reworking SCOPE_EXIT to build it on top of the closures and a more traditional scope guard. If this is practical, he should create the new implementation and possibly submit it for a mini-review, since it will be such a big change from the current form. On to the other issues. There were a number of comments on the documentation. Some of the most detailed were in the review by Pavel. Much of the requested information is currently present in the documentation, but not in a format that new readers find intuitive. Along with reorganization, some more examples, some more comparison information, and some actual performance information would be a good idea. Kim would like to see variadic macros supported in the implementation. This is a good idea if a large fraction of currently available compilers support them, but otherwise a low priority. Currently the library requires the user to include type_of headers, even though there is no place in the user code where a type_of appears. This will be confusing for many new users. If possible, look for a way to make the library more self-contained in this regard. Other reviewers requested ways to use the library without any type_of dependence. This would expand the audience for the library, but may not be practical. Consider it and act appropriately. Aaron requested some syntactic sugar for things like if(condition) tests. This may not be a good choice, since it greatly expands the interface while providing only minor simplifications to calls. Consider it and choose. The code needs to check for msvc compilers, since the __LINE__ statement has to be replaced for them. BOOST_SCOPE_EXIT_FASTER_IMPL should be removed. It isn't always faster, and putting experimental features in a release makes no one confident. If it becomes stable, cross-platform and consistently faster, then it can come back. BOOST_SCOPE_EXIT_TRY and BOOST_SCOPE_EXIT_CATCH_ALL are not very useful There is a compile warning because boost_scope_exit_params_struct_nn does not have an assignment operator. Define one and it will go away. Look for ways to make the syntax clearer. Goran pointed out that he doubts code reviews at his job or many others would allow the current syntax. So far, the best suggestion seems to be BOOST_SCOPE_EXIT((cref c) (ref r) (val v)). This also addresses desires to be able to pass by other than references. There was a request for the ability to nest scope_exits and build more complicated structures. I don't see how this could be done in an exception safe manner, so it is probably not a good idea. There was an extended discussion on the use of macros in the public interfaces of Boost libraries. It is certainly true that indiscriminate use of macros is a bad idea, but there is no indication that that is the case for this library. As is always the case for any Boost library, the real question should be "What is the best way to provide the best functionallity?" In this case, no suggestions other than macros have come forth, so macros are the best available choice. My thanks again to everyone who participated, to Alexander for creating and submitting the library and for his patience, and to Jody for organizing the review period. John Phillips Review Wizard -- Those only are happy, who have their minds fixed on some object other than their own happiness; on the happiness of others, on the improvement of mankind, even on some art or pursuit, followed not as a means, but as itself an ideal end. Aiming thus at something else, they find happiness by the way. John Stuart Mill

1 0

Egg Review ends today
by dan marsden 20 Apr '08

20 Apr '08

The review of the Egg library by Shunsuke Sogame ends today. If anybody is still considering doing a review, please do still submit it, even if it is a few days late. It will take a short while for me to summarise the discussion during the review period. The review result will be posted shortly. Thanks Dan Marsden Review Manager __________________________________________________________ Sent from Yahoo! Mail. A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html

1 0

Egg review period extended until April 20th
by dan marsden 13 Apr '08

13 Apr '08

Hi All The Egg review has run for 2 weeks now with zero reviews, which is obviously disappointing. There has been some good and pretty thorough discussion, and a couple of promises of reviews. As such, I'm extending the review period by 1 week until 20th April 2008. Please do post a review if you have any interest in this library. In case anybody is unsure, in the case of zero votes being posted, the default result will be a rejection. Please lets make sure we don't have to fall through to this default case. Introduction: It is not so easy to define Function Objects especially if you want to support Boost.ResultOf and Boost.Lambda. Therefore, as Boost provides iterator_facade and iterator adaptors, Egg provides function_facade and function adaptors. Egg provides the following features: * Workaround for the Forwarding Problem http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1385.htm * Helpers to build Function Objects: * egg::function and egg::function_facade provides the way to build Function Objects which supports Boost.ResultOf and Lambda. * Function Objects Adaptors(in other words, higher-order functions): * egg::curryN supports the currying. * egg::pipable emulates extension methods(C#). * egg::fuse/unfuse emulates variadic functions. * egg::nestN represents nested lambda expressions. * etc... The documentation is on line: http://p-stade.sourceforge.net/boost/libs/egg/ The zipped source code is in Vault/FunctionObjects: http://tinyurl.com/34lgda Tested under: Boost Development Trunk and Boost Version1.34.1. --------------------------------------------------- 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? Thanks Dan Marsden Review Manager ___________________________________________________________ Yahoo! For Good helps you make a difference http://uk.promotions.yahoo.com/forgood/

1 0

[Proto] Review result
by Hartmut Kaiser 07 Apr '08

07 Apr '08

Hi all, initially I was hoping to find some time over the last weekend to go through the reviews in great detail to put together a proper review report. Well, as things happen, I was not able to find the time :-( To avoid further delays, here is the short version of the review result: Proto got 16 reviews (That's well above average! Thanks to all for participating), out of which 15 have been positive. The one 'No' essentially stated that the library, even if doubtless very useful, shouldn't be accepted yet, mainly because there has to be done more work in the area of formalizing the problem domain. In my opinion this is an overwhelming result and I'm whole heartily agreeing with the majority of the voters. Proto is accepted as a Boost library. The discussions have been very detailed and there have been raised a lot of (mostly minor) issues, but Eric is aware of the problems and is working on solving them. I'll try to put together a summary as soon as possible. Regards Hartmut Review Manager

1 0

Egg 2nd request for reviews
by dan marsden 06 Apr '08

06 Apr '08

Hi All The review of the Egg library by Shunsuke Sogame has been running for 1 week now. There has been some discussion of the library on a couple of related threads, but no reviews submitted so far. Please try and find time to submit a review of this library if possible. If you wish to review, but don't have time before the review ends on April 13th, please post to that effect, we may be able to extend / move the review period to help reviewers. Introduction: It is not so easy to define Function Objects especially if you want to support Boost.ResultOf and Boost.Lambda. Therefore, as Boost provides iterator_facade and iterator adaptors, Egg provides function_facade and function adaptors. Egg provides the following features: * Workaround for the Forwarding Problem http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1385.htm * Helpers to build Function Objects: * egg::function and egg::function_facade provides the way to build Function Objects which supports Boost.ResultOf and Lambda. * Function Objects Adaptors(in other words, higher-order functions): * egg::curryN supports the currying. * egg::pipable emulates extension methods(C#). * egg::fuse/unfuse emulates variadic functions. * egg::nestN represents nested lambda expressions. * etc... The documentation is on line: http://p-stade.sourceforge.net/boost/libs/egg/ The zipped source code is in Vault/FunctionObjects: http://tinyurl.com/34lgda Tested under: Boost Development Trunk and Boost Version1.34.1. --------------------------------------------------- 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? Thanks Dan Marsden Review Manager ___________________________________________________________ Yahoo! For Good helps you make a difference http://uk.promotions.yahoo.com/forgood/

1 0