headers
Tom Brinkman | 30 Dec 20:14

Futures - Reviews Needed (January 5, 2009)

Futures

Join the review and discussion starting January 5, 2009.

I need commitments for reviews from threading experts on the two
Futures library candidates.

Braddock Gaskill - http://braddock.com/~braddock/future
Anthony Williams - http://www.justsoftwaresolutions.co.uk/files/n2561_future.hpp

Early comments are welcome.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Michael Marcin | 30 Dec 21:03

Re: Futures - Reviews Needed (January 5, 2009)

Tom Brinkman wrote:
> Futures
> 
> Join the review and discussion starting January 5, 2009.
> 
> I need commitments for reviews from threading experts on the two
> Futures library candidates.
> 
> Braddock Gaskill - http://braddock.com/~braddock/future
> Anthony Williams - http://www.justsoftwaresolutions.co.uk/files/n2561_future.hpp
> 
> Early comments are welcome.

Is the expected result of the review to choose a library (or none) or to 
create a third library that is a mixture of the two?

--

-- 
Michael Marcin

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Tom Brinkman | 31 Dec 02:42

Futures - Reviews Needed (January 5, 2009)

>> Is the expected result of the review to choose a library (or none) or to
>> create a third library that is a mixture of the two?

I have no expectations about the results.  I'm interested to hear your
views and those of the authors about how to proceed.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
David Abrahams | 31 Dec 19:04
Favicon
Gravatar

Re: Futures - Reviews Needed (January 5, 2009)

Are we reviewing both libraries at once?

Sent from my iPhone

On Dec 30, 2008, at 4:44 PM, "Tom Brinkman" <reportbase <at> gmail.com>  
wrote:

>>> Is the expected result of the review to choose a library (or none)  
>>> or to
>>> create a third library that is a mixture of the two?
>
> I have no expectations about the results.  I'm interested to hear your
> views and those of the authors about how to proceed.
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
vicente.botet | 15 Jan 19:01

Re: Futures - callback before and after setting

Hi,

sometime ago Peter Dimov asked if the effects of a set callback (ala Braddock ) is guaranteed to be observed
by a task waiting on a future. The answer was not because the the callbacks are called after the futures are
notified. I was wondering if we don't need to make two kind of callback on setting: one before notifying all
the futures and the other after. In this way the promise setting could be completly decorated.

Braddock, what do you think?

Best,
Vicente

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Tom Brinkman | 31 Dec 20:03

Re: Futures - Reviews Needed (January 5, 2009)

>> Are we reviewing both libraries at once?

That is my understanding.  However, at this point, until persuaded
otherwise, I'm inclined to suggest to both authors that they
should find a way to work together and issue a joint release.  I've
looked at both libraries and the differences are subtle.
Maybe we just need to persuade them that it would not diminish their
work in any way if they were to submit a joint release.
As both submissions are of high quality, I would not want to
discourage either author.

It would also seem to me that the logging library proposals have the
same problem.
It would be my hope that we could get the authors of the various
logging library proposals to work together and issue a joint release
as well.

One could dream.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
David Abrahams | 1 Jan 08:24
Favicon
Gravatar

Re: Futures - Reviews Needed (January 5, 2009)


on Wed Dec 31 2008, "Tom Brinkman" <reportbase-AT-gmail.com> wrote:

>>> Are we reviewing both libraries at once?
>
> That is my understanding.  

As a review wizard, isn't that decision in part up to you?

> However, at this point, until persuaded
> otherwise, I'm inclined to suggest to both authors that they
> should find a way to work together and issue a joint release.  

I am inclined the same way, but if they're going to do that, we should
not use a formal review to sort out any large-scale decisions that they
can make between them.

> I've looked at both libraries and the differences are subtle.  Maybe
> we just need to persuade them that it would not diminish their work in
> any way if they were to submit a joint release.  As both submissions
> are of high quality, I would not want to discourage either author.
>
> It would also seem to me that the logging library proposals have the
> same problem.  It would be my hope that we could get the authors of
> the various logging library proposals to work together and issue a
> joint release as well.

Again, aren't you able to influence that a bit as review wiz? 

--

--
(Continue reading)

Permalink | Reply |
headers
John Phillips | 2 Jan 01:21

Re: Futures - Reviews Needed (January 5, 2009)

David Abrahams wrote:
> on Wed Dec 31 2008, "Tom Brinkman" <reportbase-AT-gmail.com> wrote:
> 
>>>> Are we reviewing both libraries at once?
>> That is my understanding.  
> 
> As a review wizard, isn't that decision in part up to you?
> 
>> However, at this point, until persuaded
>> otherwise, I'm inclined to suggest to both authors that they
>> should find a way to work together and issue a joint release.  
> 
> I am inclined the same way, but if they're going to do that, we should
> not use a formal review to sort out any large-scale decisions that they
> can make between them.
> 
>> I've looked at both libraries and the differences are subtle.  Maybe
>> we just need to persuade them that it would not diminish their work in
>> any way if they were to submit a joint release.  As both submissions
>> are of high quality, I would not want to discourage either author.
>>
>> It would also seem to me that the logging library proposals have the
>> same problem.  It would be my hope that we could get the authors of
>> the various logging library proposals to work together and issue a
>> joint release as well.
> 
> Again, aren't you able to influence that a bit as review wiz? 
> 

   The choice to do these together came from a discussion on the list
(Continue reading)

Permalink | Reply |
headers
David Abrahams | 6 Jan 16:14
Favicon
Gravatar

Re: Futures - Reviews Needed (January 5, 2009)


on Thu Jan 01 2009, John Phillips <phillips-AT-mps.ohio-state.edu> wrote:

> David Abrahams wrote:
>>
>> Again, aren't you able to influence that a bit as review wiz? 
>>
>
>   The choice to do these together came from a discussion on the list
> when they were submitted. Since Anthony's submission is an
> implementation of the proposal for the standard, his interface is
> fixed for him, and the thought from the discussion was we should at
> least look at what the standard is adding. Braddock's submission
> differs somewhat, and people wanted a chance to have a boost library
> that was different from the proposal, if it proved superior.
>
>   Sorry if you missed out on that, but it was several months ago. Ron
> and I just went with the desires of those who commented.
>
>   BTW: After long and honorable service, Tom stepped down as a review
> wizard a bit more than a year ago. I'm sure he would have plenty to
> offer if he wanted it back, but as far as I know, he hasn't asked to
> be re-appointed.

Sorry to have lost track of all this a bit.  Regardless, it seems like
this has potential for a great deal of confusion and I was wondering if
the actual review wizards can do anything more to make it go smoothly.

--

-- 
Dave Abrahams
(Continue reading)

Permalink | Reply |
headers
vicente.botet | 31 Dec 14:19

Re: Futures - Reviews Needed (January 5, 2009)

----- Original Message ----- 
From: "Tom Brinkman" <reportbase <at> gmail.com>
To: <boost-announce <at> lists.boost.org>; <boost <at> lists.boost.org>
Sent: Tuesday, December 30, 2008 8:15 PM
Subject: [boost] Futures - Reviews Needed (January 5, 2009)

> 
> Futures
> 
> Join the review and discussion starting January 5, 2009.
> 
> I need commitments for reviews from threading experts on the two
> Futures library candidates.
> 
> Braddock Gaskill - http://braddock.com/~braddock/future
> Anthony Williams - http://www.justsoftwaresolutions.co.uk/files/n2561_future.hpp
> 
> Early comments are welcome.

Hi,

This will be a particular review for everal reasons:
* there are two libraries for review the 'same' concept
* this is the first time we review a library that has a corresponding accepted standard for C++0x
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2800.pdf  based on http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2627.html)
* one of them is presented by one of the authors of the C++0x proposal.

I want to do a review, but IMO any Future Boost library should at least provide the current C++0x Future
accepted standard and use the Boost.Exception library as mechanism to transport the exceptions. Other
libraries that should be used are Boost.Chrono and Boost.Move, but these are not yet even in the schedule
(Continue reading)

Permalink | Reply |
headers
Johan Torp | 5 Jan 01:49

Re: Futures - Reviews Needed (January 5, 2009)


Vicente Botet Escriba wrote:
> 
> Tom, It is not clear from your mail which library from Anthony will be
> reviewed. Is it
> http://www.justsoftwaresolutions.co.uk/files/n2561_future.hpp,
> http://www.justsoftwaresolutions.co.uk/threading/free-implementation-of-c++-futures.html
> or 
> http://www.stdthread.co.uk/forum/index.php?topic=64.0?
> 

http://www.justsoftwaresolutions.co.uk/files/n2561_future.hpp does not
contain any wait_for_any or wait_for_all functionality and it includes
packaged_task. Is this really the version that is being reviewed?

Best Regards, Johan Torp
www.johantorp.com

--

-- 
View this message in context: http://www.nabble.com/Futures---Reviews-Needed-%28January-5%2C-2009%29-tp21221849p21283712.html
Sent from the Boost - Dev mailing list archive at Nabble.com.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Steve Karmesin | 31 Dec 20:27

Re: Futures - Reviews Needed (January 5, 2009)

I have some comments on the design of Braddock Gaskill's Boost.Future library. 
I haven't really looked at the other one because I don't want to reverse
engineer the code.  I would not accept that library without documentation
comparable to Gaskill's.

I have a fair amount of experience with using threads from C++.  While I've seen
the idea of futures before I haven't used them.

I really like the documentation.  It is a major help for evaluating the design
decisions.  I have not yet used the library, at this point I'm just evaluating
the design and interface in the docs.  Since I haven't acutally used it yet I'm
not yet prepared to say accept or reject on this library.

It appears to be well thought through.  I like the split between promise and
future to separate the put and get interfaces.

There is one point where I question the design decision: reference semantics. 
There are certainly times when that is useful, but I can also see times when it
is not.  My preference would be for a exposed concrete class.  That could then
be used as a building block for a reference semantic class.  Allowing users to
minimize interaction with memory management seems like a potential win.  This
doesn't seem like a huge issue, but I thought I would raise it for discussion.

A second issue has to do with capturing and rethrowing exceptions. This is a
very cool capability but the implementation is limited because it can't detect
and use user derived subtypes of the system exception types. This can be done
with external polymorphism and would be a significant improvement.

Instead of storing a runtime_error store a pointer to an internal abstract base
class such as untyped_exception_wrapper.  Derive from that a templated class
(Continue reading)

Permalink | Reply |
headers
Steven Watanabe | 31 Dec 20:53

Re: Futures - Reviews Needed (January 5, 2009)

AMDG

Steve Karmesin wrote:
> A second issue has to do with capturing and rethrowing exceptions. This is a
> very cool capability but the implementation is limited because it can't detect
> and use user derived subtypes of the system exception types. This can be done
> with external polymorphism and would be a significant improvement.
>
> Instead of storing a runtime_error store a pointer to an internal abstract base
> class such as untyped_exception_wrapper.  Derive from that a templated class
> exception_wrapper that stores the user's type and can rethrow that type.
>
> Then the set_exception member can be template and the exception type, wraps it
> with exception_wrapper and stores the pointer to the abstract base.
>
> Then when the user goes to get the value from the future and it finds that there
> was an exception, it calls the rethrow method on the abstract base, the
> templated derived class does the concrete rethrow of the user's type and the
> user can then catch that type.  This way the future library can catch and
> rethrow exceptions of types that it knows nothing about.
>
> Below is some demonstration code for this pattern.
>   

This functionality is already in Boost.
http://www.boost.org/libs/exception/doc/tutorial_exception_ptr.html

In Christ,
Steven Watanabe
(Continue reading)

Permalink | Reply |
headers
Steve Karmesin | 31 Dec 22:09

Re: Futures - Reviews Needed (January 5, 2009)

On Wed, Dec 31, 2008 at 12:53 PM, Steven Watanabe <watanabesj <at> gmail.com>wrote:

>
>>  This functionality is already in Boost.
> http://www.boost.org/libs/exception/doc/tutorial_exception_ptr.html
>

Cool. Then the Future library should use it.

-Steve
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Steve Karmesin | 3 Jan 18:43

Re: [Boost-announce] Futures - Reviews Needed (January 5, 2009)

A couple of points that I would want to see clarified on the Boost.Futures
proposal to make sure the major design decisions are vetted:

The first is on callbacks.  The description does not make clear what thread
the callback is required to be done in.  I would guess that the easiest
implementation is to put it be in the thread in which the promise is
fulfilled, but I would want that to be specified in the interface since it
would affect how I would use it.

A second question on callbacks: Would it not make sense to use the boost
signals package for this?  I think that provides a very rich interface for
binding values to the callbacks, and that is very useful.

Next, I'm wondering about the reference semantics.  Is that there because it
is not sensible to copy them?  If that is the case then the alternative
would be to prohibit copy and not require memory management under the hood.
The downside there is that the user would usually have to use pointer to
futures/promises in order to build containers of them.  On the whole I think
I come down on the side of liking the reference semantics, but I don't think
it is a no brainer and would want to see some commentary on it.

In general I like this package a lot and wish I could use it on my current
project :-).

-Steve Karmesin
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Anthony Williams | 5 Jan 12:43

Re: Futures - Reviews Needed (January 5, 2009)

"Tom Brinkman" <reportbase <at> gmail.com> writes:

> Futures
>
> Join the review and discussion starting January 5, 2009.
>
> I need commitments for reviews from threading experts on the two
> Futures library candidates.
>
> Braddock Gaskill - http://braddock.com/~braddock/future
> Anthony Williams - http://www.justsoftwaresolutions.co.uk/files/n2561_future.hpp

The latest version of that library is at:

Docs: http://www.justsoftwaresolutions.co.uk/files/futures_documentation.html
Code+Docs: http://www.justsoftwaresolutions.co.uk/files/n2561_futures_revised_20080530.zip

Anthony
--

-- 
Anthony Williams
Author of C++ Concurrency in Action | http://www.manning.com/williams
Custom Software Development | http://www.justsoftwaresolutions.co.uk
Just Software Solutions Ltd, Registered in England, Company Number 5478976.
Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Johan Torp | 5 Jan 22:29

Re: Futures - Reviews Needed (January 5, 2009)


Here is my review. Quite long so please bear with me :)

* What is your evaluation of the design?

The split promise/future design, exception propagation mechanism and broken
promise detection are well thought through. I have full confidence that both
authors are quite capable to nail down any details remaining regarding
these.

I think we should have support for movable types which motivates the
distinction between shared_future and unique_future (as in William's
version). 

I am however, very concerned about the waiting mechanisms and callback hooks
of both libraries. See motivation below.

* What is your evaluation of the implementation?

Both implementations seem to be of good quality.

* What is your evaluation of the documentation?

I haven't spent much time reviewing them, at a first glance they both seem
fine but William's might add some flesh. I personally wouldn't mind allowing
a lot of documentation to be added after a formal review acceptance.

* What is your evaluation of the potential usefulness of the library?

It depends. It has the potential to become an extremely useful library if we
(Continue reading)

Permalink | Reply |
headers
vicente.botet | 18 Jan 23:15

Re: Futures - Reviews Needed (January 5, 2009)

Hi,

----- Original Message ----- 
From: "Johan Torp" <johan.torp <at> gmail.com>
To: <boost <at> lists.boost.org>
Sent: Monday, January 05, 2009 10:29 PM
Subject: Re: [boost] Futures - Reviews Needed (January 5, 2009)

> 
> Here is my review. Quite long so please bear with me :)
> 
> --- MOTIVATION---
> 
> My hope is that we can find a minimal acceptable library which support
> whatever use cases we deem important. I am worried that the C++ committee is
> too focused on using futures as a part of a thread pool interface. Gaskill
> has identified a number of use cases (guards, scheduling, lazy futures etc)
> which OTOH might be too elaborate. But if the interface isn't powerful
> enough we risk getting a wide variety of non-compatible future
> implementations out there. 

Yes, IMO the documentation should show at least that the accepted library can manage with these use cases.
Why not as examples.

> I'll give a brief introduction for those who haven't followed my earlier
> future-related posts. I think that "choice" or waiting hasn't been thought
> through properly. In non-trivial use cases you probably have multiple
> futures and would like to schedule executions once they are completed.
(Continue reading)

Permalink | Reply |
headers
Johan Torp | 19 Jan 06:59

Re: Futures - Reviews Needed (January 5, 2009)


Vicente Botet Escriba wrote:
> 
>> A third option is that the user starts an extra fire-and-forget thread
>> (or
>> run it in a thread pool or has an idle thread waiting around) which waits
>> for the future. However, threads are rather heavy weight in contemporary
>> desktop operating systems (default stack space 1mb in windows and 8mb in
>> linux) so this would, IMHO, severely limit the usefulness of futures.
> 
> This is exactly what I have implemented with the fork_after function using
> wait_for_all. If the asynchronous executor is a thread_pool you will need
> a task and not a thread, so no heavy at all.
> 

However, thread pools do not aim to provide good latency which might make a
such future implementation useless for scheduling related usage (which might
still be ok since it could be the best design option we have). I'd love to
hear the authors views on this. 

Also we do not have any thread pools in boost today. 

Vicente Botet Escriba wrote:
> 
>> William's version provides the free functions wait_for_any and
>> wait_for_all.
>> Using these, a scheduler could schedule an arbitrary amount of futures
>> using
>> just one additional future waiting thread. However, the current
>> implementation of wait_for_any suffers some serious problems:
(Continue reading)

Permalink | Reply |
headers
vicente.botet | 19 Jan 08:10

Re: Futures - Reviews Needed (January 5, 2009)


----- Original Message ----- 
From: "Johan Torp" <johan.torp <at> gmail.com>
To: <boost <at> lists.boost.org>
Sent: Monday, January 19, 2009 6:59 AM
Subject: Re: [boost] Futures - Reviews Needed (January 5, 2009)

> Also we do not have any thread pools in boost today. 

There is at least the ThreadPool proposal from Olivier on the queue Schedule.

Vicente

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
vicente.botet | 19 Jan 08:48

Re: Futures - Reviews Needed (January 5, 2009)


----- Original Message ----- 
From: "Johan Torp" <johan.torp <at> gmail.com>
To: <boost <at> lists.boost.org>
Sent: Monday, January 19, 2009 6:59 AM
Subject: Re: [boost] Futures - Reviews Needed (January 5, 2009)

> However, thread pools do not aim to provide good latency which might make a
> such future implementation useless for scheduling related usage (which might
> still be ok since it could be the best design option we have). I'd love to
> hear the authors views on this. 

Could you develop the use case you have in mind.

 
> Actually, I started writing a reply but I couldn't really understand your
> implementation. I was hoping one of the authors would reply first and I
> could join in later. To solve the complexity problem, I agree we need to
> expose some stateful abstraction and can't do with just free functions.

Replay to the post. Let me know what you don't understad. 

> If we choose require a third thread (or thread pool) for future composition,
> I'm sure there are lots of nice interfaces like your proposal above. I don't
> want to spend too much time designing these fancier features now though.

Which other features would you want?

> Vicente Botet Escriba wrote:
>>
(Continue reading)

Permalink | Reply |
headers
Johan Torp | 19 Jan 19:19

Re: Futures - Reviews Needed (January 5, 2009)


Vicente Botet Escriba wrote:
> 
>> However, thread pools do not aim to provide good latency which might make
>> a
>> such future implementation useless for scheduling related usage (which
>> might
>> still be ok since it could be the best design option we have). I'd love
>> to
>> hear the authors views on this. 
> 
> Could you develop the use case you have in mind.
> 

I'm thinking about libpoet, asio and the scheduling related use cases from
Gaskill's documentation.

Vicente Botet Escriba wrote:
> 
>> Actually, I started writing a reply but I couldn't really understand your
>> implementation. I was hoping one of the authors would reply first and I
>> could join in later. To solve the complexity problem, I agree we need to
>> expose some stateful abstraction and can't do with just free functions.
>  
> Replay to the post. Let me know what you don't understad. 
>  

I'd like acknowledgement from Anthony - that he too thinks the complexity is
a real problem - before trying to solve it.
(Continue reading)

Permalink | Reply |
headers
Frank Mori Hess | 19 Jan 21:03
Favicon

Re: Futures - Reviews Needed (January 5, 2009)

On Monday 19 January 2009 13:19, Johan Torp wrote:
> Vicente Botet Escriba wrote:
> >> I would not be surprised if requiring a third thread for future
> >> composition
> >> would render it useless for many of Gaskill's use cases, libpoet and
> >> asio -
> >> which means most of the identified use cases. But I'm far from sure.
> >
> > Could you or someone develop these needs.
>
> The authors of asio, libpoet and Gaskill are best suited to answer if
> Anthony's proposal would be useful to them.

Unfortunately, I haven't had time to follow the future review threads in 
detail, or any changes that may have been made to the submitted library 
since I last looked at them many months ago.  I can only summarize some 
things about the future implementation in libpoet in the hope it will be 
helpful in some way.  

As far as composing futures, the poet::future_combining_barrier supports 
obtaining a new future whose value is obtained by applying an 
arbitrary "combiner" functor to the values from a group of input futures.  
The combiner is always executed in a future-waiting thread, not the 
promise-fulfilling thread, or a third thread.  The implementation relies 
on internal signals being emitted immediately when a promise is fulfilled, 
as well as internal event queues associated with futures.  I described it 
a little in this post:

http://lists.boost.org/Archives/boost/2008/06/138422.php
(Continue reading)

Permalink | Reply |
headers
Vicente Botet | 19 Jan 22:07

Re: Futures - Reviews Needed (January 5, 2009)

----- Original Message ----- 
From: "Frank Mori Hess" <fmhess <at> speakeasy.net>
To: <boost <at> lists.boost.org>
Sent: Monday, January 19, 2009 9:03 PM
Subject: Re: [boost] Futures - Reviews Needed (January 5, 2009)
On Monday 19 January 2009 13:19, Johan Torp wrote:
> > Vicente Botet Escriba wrote:
> > >> I would not be surprised if requiring a third thread for future
> > >> composition
> > >> would render it useless for many of Gaskill's use cases, libpoet and
> > >> asio -
> > >> which means most of the identified use cases. But I'm far from sure.
> > >
> > > Could you or someone develop these needs.
> >
> > The authors of asio, libpoet and Gaskill are best suited to answer if
> > Anthony's proposal would be useful to them.
> 
> Unfortunately, I haven't had time to follow the future review threads in 
> detail, or any changes that may have been made to the submitted library 
> since I last looked at them many months ago.  I can only summarize some 
> things about the future implementation in libpoet in the hope it will be 
> helpful in some way.  
> 
> As far as composing futures, the poet::future_combining_barrier supports 
> obtaining a new future whose value is obtained by applying an 
> arbitrary "combiner" functor to the values from a group of input futures.  
> The combiner is always executed in a future-waiting thread, not the 
> promise-fulfilling thread, or a third thread.  The implementation relies 
> on internal signals being emitted immediately when a promise is fulfilled,
(Continue reading)

Permalink | Reply |
headers
Tom Brinkman | 5 Jan 22:52

Re: Futures - Reviews Needed (January 5, 2009)

>>  BTW: After long and honorable service, Tom stepped down as a review
>> wizard a bit more than a year ago. I'm sure he would have plenty to
>> offer if he wanted it back, but as far as I know, he hasn't asked to be
>> re-appointed.

Thanks John.  Its great that you volunteered to be the Wizard.  I
still regularly
follow the boost newsgroup, so let me know if there is anything that you need.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |

Gmane