- Boost-announce - lists.boost.org

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

Egg Review starts today March 31st
by dan marsden 31 Mar '08

31 Mar '08

The review of the Egg library by Shunsuke Sogame starts today.The library is concerned with the implementation and adaptation of function objects. As function objects are everywhere in Boost and C++, I hope to see plenty of discussion and votes during the review. 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

[Review][Proto] Review finished
by Hartmut Kaiser 30 Mar '08

30 Mar '08

Hi all, the review of Eric Nieblers Proto Library has finished. Even if I still need to prepare the review summary over the next couple of days I'm convinced we had a very productive and very active review period - we received 16 votes, which is way more than the average. Thanks to all who prepared a review or who simply took part in the vibrant discussions. Regards Hartmut Review Manager

1 0

Boost 1.35.0 released
by Beman Dawes 29 Mar '08

29 Mar '08

Boost is pleased to announce the availability of release 1.35.0. This is a major release that includes 12 new libraries, and coincides with an upgrade and reorganization of the www.boost.org web site. The new libraries are: * Asio: Portable networking, including sockets, timers, hostname resolution and socket iostreams, from Chris Kohlhoff. * Bimap: Boost.Bimap is a bidirectional maps library for C++. With Boost.Bimap you can create associative containers in which both types can be used as key, from Matias Capeletto. * Circular Buffer: STL compliant container also known as ring or cyclic buffer, from Jan Gaspar. * Function Types: Boost.FunctionTypes provides functionality to classify, decompose and synthesize function, function pointer, function reference and pointer to member types. From Tobias Schwinger. * Fusion: Library for working with tuples, including various containers, algorithms, etc. From Joel de Guzman, Dan Marsden and Tobias Schwinger. * GIL: Generic Image Library, from Lubomir Bourdev and Hailin Jin. * Interprocess: Shared memory, memory mapped files, process-shared mutexes, condition variables, containers and allocators, from Ion Gaztañaga. * Intrusive: Intrusive containers and algorithms, from Ion Gaztañaga. * Math/Special Functions: A wide selection of mathematical special functions from John Maddock, Paul Bristow, Hubert Holin and Xiaogang Zhang. * Math/Statistical Distributions: A wide selection of univariate statistical distributions and functions that operate on them from John Maddock and Paul Bristow. * MPI: Message Passing Interface library, for use in distributed-memory parallel application programming, from Douglas Gregor and Matthias Troyer. * System: Operating system support, including the diagnostics support that will be part of the C++0x standard library, from Beman Dawes. Among existing libraries, Boost.Threads has been upgraded to reflect changes made by the C++ committee in the process of including Boost.Threads in C++0x. Dozens of people contribute to each Boost release. Rene Rivera, Daniel James, and John Maddock were instrumental in readying this release. It wouldn't have happened without them. --Beman Dawes, Release Manager

1 0

Re: [Boost-announce] [boost] Logging library review results
by John Torjo 18 Mar '08

18 Mar '08

Hi All, > I read through the submitted reviews and here is a short summary: > > Thanks to all who contributed. Now I'll know what needs to be improved - again ;) I'd like to formally ask for another review mid-end July. So, looking for a review manager - again ;) > > In the end we came to 8 negative 7 positive votes with average 4.9 grade. > Essentially opinions split right in a middle. Oh, how familiar these days ;) > > I must say this puts me in a quite a spot. The library obviously has great > potential, but quite unacceptable by many in it's current form. While > praising it's flexibility in many aspects, the reviewers expressed wide > variety of serious concerns regarding design, implementation and > documentation. > > Yup, will redo, and redo the docs as well. > The logging library submission is NOT accepted in it's current form. > > My biggest concern, as many others expressed here before, is that we do need > the logging library. So I can't be any more encouraging to John to resubmit > an updated version for review within any reasonably short time, once issues > brought during review are addressed. I am not going to list all the issues > here - you will need to look through quite detailed reviews, but I want to > emphasize most prominent ones: > > Again, I'd like to resubmit, mid-end July. > * The library would gain from clean separation of framework and solution. > What I mean here is that there should be separate > layer which defines only generic concepts and another layer for specific > solutions provided by library. My personal suggestion is to use layered > design, where each layer is more feature-rich, but more targeted. > Got it. > * Library should support wide variety of "simple cases" out of the box and > with minimal efforts required by users. *Each* usage scenario should be well > documented and supported by example. > Yes - my problem is that each person seems to have a different opinion of what "simple case". However, what I'll do is this: - have a few simple cases, and write the code for them - minimize the number of lines I write in order to meet a certain case - question: what do you think it's a reasonable number of lines, for a simple case? I'd go for 5-10 lines of code. About those simple cases : the problem is that I have my own simple cases - which might not be what you want. So, if you have your great simple case, shout! On a side-note - I'll make a couple of web pages where I'll split the work to be done. Then, you all are most welcome to comment on them. > * Library shouldn't try to be too smart. All optimizations and advanced > features should be eliminated. At least not in a review version. This > includes any kind of optimized strings or scenario based log selection. > Later on you may start adding them based on user input. > I see - ok, basically that's easier for me. So I'm down with that ;) > * I recommend to start some kind of pool for simple/common cases on the dev > list before you jump to support them. Library should clearly state that > other more advanced usage cases are supportable as well. The same > recommendation applies to the general set of supported features by the > library out of the box. > Got it. > * Macros usage should be marginally reduced. Documentation should explain > how to write them, but not force them as the only solution. > Yup, will do. > * You may consider supporting lambda like API an one of the alternatives. > That should be possible. > * Unicode support strategy needs to be fixed > Yes, it will. > * Documentation require major revision. Obviously I can't put it as a > requirement, but my personal recommendation - drop doxigen. IMO you can't > Well, I'll think about it - however, I really love doxygen. So I guess we shouldn't blame the tool for the fact that I messed up the docs. > have professional documentation based on this format. Plus it's > unnecessarily pollute your code. Boostbook and Quickbook are much more > No offense about Boostbook: http://www.boost.org/doc/html/boostbook/getting/started.html But if getting started is so complex, I tend to not use it. > attractive solutions. Also many reviewers expressed desire for more formal > tone in user's guide and reference. (Another personal comment - where did > About the formal tone in the user's guide/reference - will do. > you find word "gather" usage as noun? I personally would prefer something > like "entry") > > Where have I used it as a noun? > Yet again I'd like to express our gratitude to the John for his efforts and > hopes that he'll be able to see this library though to the eventual success. > It has great potential. > > Thanks ;) And it'll happen ;) Best, John -- http://John.Torjo.com -- C++ expert http://blog.torjo.com ... call me only if you want things done right

1 0

Logging library review results
by Gennadiy Rozental 17 Mar '08

17 Mar '08

This is unfortunately delayed results review of Logging library submitted by John Torjo. I read through the submitted reviews and here is a short summary: - 2 Tom Brinkman | evaluate it again, if a more boost friendly, lambda style public interface is present + 7 Steven Watanabe | all the issues with destructors and exceptions absolutely must be fixed + 7 Vadim | with some improvements to documentation and ease-of-use - 0 Phil Endecott | not in its current form + 9 Jurko Gospodnetic | seems good enough - 3 Jamie Allsop | changes that are needed are too numerous to warrant a 'yes and tidy-up' vote - 2 Christian Holmquist | the documentation is written with other scenarios in mind - 4 Sean Hunt | approach is a little too generic and forces the user to jump through hoops + 9 Arnstein Ressem | compiler and valgrind warnings has to be fixed before submission + 6 Loic Joly | yes, knowing this library will probably evolve anyway + 7 Paul A Pristow | expecting some quite major revisions of documentation, and perhaps implementation - 3 Amit | Not in its current form. with some changes library would have support -1/2 Paul Bexter | spread too thin - 4 Scott Woods | logging facility should be targeted slightly differently + 10 Bruce Sharpe | need exactly this functionality - 1 Andrey Semashev | expect something different and more elaborate from the logging library (The number after the vote is my own estimation of review vote in 0-10 grade). Paul Bexter did not express clear vote, but submitted an opinion supporting Amit position. In the end we came to 8 negative 7 positive votes with average 4.9 grade. Essentially opinions split right in a middle. Oh, how familiar these days ;) I must say this puts me in a quite a spot. The library obviously has great potential, but quite unacceptable by many in it's current form. While praising it's flexibility in many aspects, the reviewers expressed wide variety of serious concerns regarding design, implementation and documentation. Well, I can't delay it any more. ;) Under the circumstances, I prefer to err on a side of caution. The logging library submission is NOT accepted in it's current form. My biggest concern, as many others expressed here before, is that we do need the logging library. So I can't be any more encouraging to John to resubmit an updated version for review within any reasonably short time, once issues brought during review are addressed. I am not going to list all the issues here - you will need to look through quite detailed reviews, but I want to emphasize most prominent ones: * The library would gain from clean separation of framework and solution. What I mean here is that there should be separate layer which defines only generic concepts and another layer for specific solutions provided by library. My personal suggestion is to use layered design, where each layer is more feature-rich, but more targeted. * Library should support wide variety of "simple cases" out of the box and with minimal efforts required by users. *Each* usage scenario should be well documented and supported by example. * Library shouldn't try to be too smart. All optimizations and advanced features should be eliminated. At least not in a review version. This includes any kind of optimized strings or scenario based log selection. Later on you may start adding them based on user input. * I recommend to start some kind of pool for simple/common cases on the dev list before you jump to support them. Library should clearly state that other more advanced usage cases are supportable as well. The same recommendation applies to the general set of supported features by the library out of the box. * Macros usage should be marginally reduced. Documentation should explain how to write them, but not force them as the only solution. * You may consider supporting lambda like API an one of the alternatives. * Unicode support strategy needs to be fixed * Documentation require major revision. Obviously I can't put it as a requirement, but my personal recommendation - drop doxigen. IMO you can't have professional documentation based on this format. Plus it's unnecessarily pollute your code. Boostbook and Quickbook are much more attractive solutions. Also many reviewers expressed desire for more formal tone in user's guide and reference. (Another personal comment - where did you find word "gather" usage as noun? I personally would prefer something like "entry") Yet again I'd like to express our gratitude to the John for his efforts and hopes that he'll be able to see this library though to the eventual success. It has great potential. Gennadiy Rozental -- Review Manager --

1 0

[Proto] review period extended to end March 28th
by Hartmut Kaiser 14 Mar '08

14 Mar '08

Hi all, There have been several requests to extend the Proto review period. For this reason the review now will end on March 28th. This should give you sufficient time to have a closer look at the library and to prepare a review. The original announcement follows: The review of Eric Nieblers Proto library starts today, March 1st 2008, and will end on March 14th. I really hope to see your vote and your participation in the discussions on the Boost mailing lists! --------------------------------------------------- About the library: Proto is a framework for building Domain Specific Embedded Languages in C++. It provides tools for constructing, type-checking, transforming and executing expression templates. More specifically, Proto provides: * An expression tree data structure. * Operator overloads for building the tree from an expression. * Utilities for defining the grammar to which an expression must conform. * An extensible mechanism for immediately executing an expression template. * An extensible set of tree transformations to apply to expression trees. * A mechanism for giving expressions additional behaviors and members. Documentation is here: http://boost-sandbox.sourceforge.net/libs/proto Download proto.zip from here: http://www.boost-consulting.com/vault/index.php?directory=Template%20Metapro gramming Proto is a very important infrastructure library, IHMO. It has been used as the backbone for several other library writing efforts already, such as Xpressive and the rewrite of Spirit (there it has been used for all three parts: the parser, the lexer and the generator modules), and it is a key enabling technology in the long-planned unification of Phoenix and the Lambda Library. --------------------------------------------------- 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

[boost] Floating Point Utilities Review Result
by John Maddock 08 Mar '08

08 Mar '08

Floating Point Utilities Review Result. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ There were 6 positive reviews and no negative ones, so Johan Rade's Floating Point Utility library has been accepted into Boost. The main issues and topics that came up for discussion were: 1) A couple of minor bugs were uncovered relating to signed NaN testing when using the SSE2 registers, and deserialising NaN's: both were fixed during the review period. 2) We had a discussion about the usefulness or otherwise of signed NaN's and the changesign function: Johan agreed to drop support for these as the signbit of NaN's is not considered part of the NaN payload and need not be preserved by the compiler, this could usefully be summarised in a rationale: especially now that negative NaN's are not formatted with a "-" sign? 3) JM made a few quite fruitless suggestions about optimising away calls to memcpy: this should be documented in a rationale to prevent JM from making the same mistake again :-) 4) John Phillips raised the issue of finding these tools - making sure that they don't get lost amongst all the other special functions and "stuff" in Boost.Math. JM and Johan have agreed to work together to ensure this doesn't happen. 5) There were a couple of suggestions for a convenience function for installing the facets in a locale/iostream: Johan agreed to add this. 6) There was +1 vote for manipulators rather than flags to the facet constructors - further investigation suggested this was problematic in a header only library - so the suggestion was dropped. 7) There was one comment about the library not using quickbook for documentation: ideally it would be nice to see this fixed so that the docs integrate seamlessly with the rest of Boost.Math - but see #4 as well. Many thanks to Johan for making these utilities available. John Maddock. Review Manager for the Floating Point Utilities. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/ listinfo.cgi/boost

1 0