Hartmut Kaiser | 1 Mar 16:31 2008
Picon

[Review] Proto review starts today, March 1st

Hi all,

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
(Continue reading)

John Maddock | 8 Mar 17:06 2008
Picon

[boost] Floating Point Utilities Review Result

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  
(Continue reading)

Hartmut Kaiser | 14 Mar 01:20 2008
Picon

[Proto] review period extended to end March 28th

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
(Continue reading)

Gennadiy Rozental | 17 Mar 11:01 2008
Picon

Logging library review results

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 --

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-announce
John Torjo | 18 Mar 21:52 2008

Re: [boost] Logging library review results

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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-announce

Beman Dawes | 29 Mar 21:22 2008
Picon

Boost 1.35.0 released

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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-announce

Hartmut Kaiser | 30 Mar 21:06 2008
Picon

[Review][Proto] Review finished

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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-announce

dan marsden | 31 Mar 08:35 2008
Picon

Egg Review starts today March 31st

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/
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-announce


Gmane