May 2008 - Boost - lists.boost.org

[boostcon] website failures
by Jonathan Franklin 20 May '08

20 May '08

I attended boostcon this year, and would like to download the slides from the wiki. However, the wiki tells me that I "do not have permission to view this page". I try logging in from the Photos section (because that is the only page I can find w/ a login link), but after supplying my username and password, I get "Page Not Found". I tried to email the webmaster address provided by the wiki, but got a response that delivery to webmaster(a)boostcon.com failed permanently: Help! Thanks, Jon

2 2

Egg review result
by dan marsden 20 May '08

20 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

5 6

v1.36 or v1.35.1?
by Richard Newman 20 May '08

20 May '08

Hello, v1.35 was released 7 weeks ago (Mar. 29). Are there plans and a release team for the next version or did I miss seeing a message about that? Will it be a v1.36.0 or a v1.35.1? Is there a target ETA? Will its content be scope- or time-defined? Kind regards, Richard --------------- Richard Newman Crowley Davis Research, Inc. richard at cdres dot com

1 0

Proposed Geometry Library
by Tom Brinkman 20 May '08

20 May '08

I've been looking at the proposed boost geometry library at: http://geometrylibrary.geodan.nl/geometry.html Two issues so far: 1) geometry::linestring seems unecessary, it just wraps vector, deque, list. Why? If every library wrapped the standard containers in this way, we'd have an explosion of these wrappers. The library should just use vector, deque, etc. directly. 2) The library should support std::back_inserter. Functions, such as geometry::simplify should work like this: std::vector<geometry::point_xy<int> > points; boost::geometry::simplify(oldpoints, std::back_inserter(points));

2 1

[futures] Future Containers?
by Dean Michael Berris 20 May '08

20 May '08

Hi Everyone, I've been following the future implementation proposals that are set to be available for review soon for inclusion in Boost. I for one would like to look at the implementations in their "review-ready" forms before doing an actual review of the different (competing?) implementations. However, before it goes out there, I would like to throw something into the mix. Right now, we've been discussing futures that contain individual values -- I know, these values can be containers, or practically anything that can be referred to with a pointer. That being said, I'd like to look at a broader application of future containers in the form of asynchronous random access containers. First, let me set up why I'm interested particularly in this matter. I'm looking at being able to map a function to a range and being able to asynchronously access certain parts of the container from multiple threads and perform operations on them. This marries the functional programming notion of function application, with asynchronous/parallel programming with "lazy values" -- only here, the values are actually computed in parallel or in separate threads (accessed through futures). So given for example: transform( input.begin(), input.end(), back_inserter(output), function_returns_future ); It would make 'output' be a back insertion sequence (or a container that supports .push_back) that contains futures. Now this would be fine, but now the problem becomes this: In the case of an associative container for example, we'd have a pair<key, future<value> > -- since futures cannot be default constructable in either implementation, I don't think code that does something like: map<int, future<int> > container; container[0].wait(); // dunno what happens here Will compile. Right now, having futures non-default constructable makes it hard(er) to put them in standard containers. This now begs the question: Will there be, or should there be, special classes of future containers that would specially be defined to work with futures? For example, in associative containers we should be able to access the elements using the index operator without having to explicitly call 'wait()', or perhaps have special future container iterators that allow for waiting on a future when dereferencing "pointed to elements". Is there a thrust towards developing a future-aware class of containers parallel to the STL containers? I personally think this will be a game changer in helping people transition towards and actually maximizing futures. I'd love to hear your thoughts on this. Have a good day everyone. -- Dean Michael C. Berris Software Engineer, Friendster, Inc.

4 8

Fwd: [Boost-testing] [Problem in tr1/test Jamfile] Nightly testing broken
by K. Noel Belcourt 20 May '08

20 May '08

I meant to send this to the developers the first time around. There's a problem in the libs/tr1/test/Jamfile.v2 that I've fixed with the attached patch. Okay to commit? -- Noel Begin forwarded message: > From: "K. Noel Belcourt" <kbelco(a)sandia.gov> > Date: May 17, 2008 11:05:04 AM MDT > To: Running Boost regression tests <boost-testing(a)lists.boost.org> > Subject: Re: [Boost-testing] Nightly testing broken > Reply-To: Running Boost regression tests <boost- > testing(a)lists.boost.org> > > > On May 17, 2008, at 10:49 AM, K. Noel Belcourt wrote: > >> The nightly tests are failing for this error message in results/ >> bjam.log. I'm not exactly sure how to fix it or I'd propose a patch. > > Here's a patch that seems to fix the problem. Okay to commit? > > -- Noel > >

2 1

[filesystem] "implementation defined"
by David Abrahams 20 May '08

20 May '08

The documentation for Boost.Filesystem uses the phrase "implementation defined" in at least one place without subsequently defining whatever it is (see the pathname grammar). Since these docs have to describe a particular implementation and not just be a prototype for standardization, don't we need to fill in the details? I also wonder if adhering to the standard documentation form for reference materials really makes this library accessible enough for general use. Even understanding the first example program ("simple ls") requires me to read through a great deal of reference material to understand what's going on. Maybe that just means a more complete tutorial is needed? -- Dave Abrahams BoostPro Computing http://www.boostpro.com

2 1

[operators] Question on documentation
by Daniel Frey 20 May '08

20 May '08

Hello, I have a question about the Boost.Optional documentation, explicitly about the paragraph on "Requirement Portability" <http://www.boost.org/doc/libs/1_35_0/libs/utility/operators.htm#portability>: Is this really true? Can someone please provide any reference to the standard? And if it is true, would that mean that for *any* map<T,U> requires that U is DefaultConstructible as this is required by map<T,U>::operator[], regardless of whether operator[] is used or not? (It's actually a little bit different because the Boost.Operators library uses friend functions). I have read 14.7 and discussed it with two colleagues, and we agree that the documentation is wrong and that this paragraph should simply be removed, but I would just like to check that I haven't overlooked something. Regards, Daniel

2 1

[proto v4 docs]Suggest warning about transform composition failure
by Larry Evans 20 May '08

20 May '08

The attached fails to compile because when the output of one when transform is immediately fed to another transform, the compiler complains because it expects Expr& instead of Expr as 1st arg to the composition. Although the docs on: libs/proto/doc/html/boost_proto/appendices/rationale/result_of.html *hint* that this could happen, it's not obvious. It would have helped me to see this on that page. IOW, that page could specifically say that transform compositions are not possible because a transform expects Expr& and when transforms are composed without storing intermediate values in a variable, then the 1st transform produces an Expr and not an Expr&; so, the second transform rejects it.

2 7

[phoenix] Building Lazy Containers
by Dean Michael C. Berris 20 May '08

20 May '08

Hi everyone, I've recently been contemplating on using a lot more of Phoenix (now that Phoenix 2 seems to be coming out soon) in the work I do, and I find myself looking at being able to make some things "lazy". Primarily, I'm interested at building lazy containers or lazy result sets where you have data bound with a lazy function that only gets evaluated when needed -- or a container that gets populated as necessary. For example, I want to build a mapping between an int and derived data from a database -- instead of having to query the database for all the elements of the map and building the map eagerly/greedily, I'd like to be able to lazily just fetch the required data for every element I access in the map. The function that "generates" the elements of the map will have to take care of whatever caching it needs to do, but I guess that should give enough insight into the kind of thing I'd like to accomplish. Another example would be a container which seemingly contains the fibonacci sequence up to some limit, but doesn't actually compute the Nth fibonacci number unless it's requested. Right now, I see that Phoenix 2 allows for traversing and applying STL algorithms "lazily" but I don't see a facility for creating "lazy containers" or "lazy ranges". I think I'm looking for something similar to the transform_iterator in Boost.Iterators only extended to be containers or better terms would be "result sets". Does anybody know of a way to achieve this using the current Phoenix 2 implementation in Boost.Trunk? If not, is there interest in such functionality? Thanks in advance! -- Dean Michael Berris Software Engineer, Friendster, Inc.

2 1