- Boost - lists.boost.org

constrained_value: 1 more question
by Neal Becker 20 May '08

20 May '08

Is it really intentional that the error handling of constrained & operator = (const value_type & v) uses BOOST_ASSERT(_check_value()); But in void _initialize() it uses throw_exception<>()(_value, _value, _constraint());

2 1

constrained_value redundant check?
by Neal Becker 20 May '08

20 May '08

constrained & operator = (const value_type & v) { if(constraint()(v)) _value = v; else error_handler()(_value, v, _constraint()); BOOST_ASSERT(_check_value()); << Isn't this redundant? return *this; } Maybe this should be: constrained & operator = (const value_type & v) { if(constraint()(v)) _value = v; else { error_handler()(_value, v, _constraint()); BOOST_ASSERT(_check_value()); } return *this; }

2 1

setting rpath in boost libraries
by brook＠biology.nmsu.edu 20 May '08

20 May '08

I am trying to compile (using bjam) boost 1.35.0 on a Unix box with gcc and have discovered that the wave library depends on some others but the build process doesn't set the rpath in the wave shared library. Is there some magic that can be used to cause bjam to have the linker set the rpath within the library? Thanks for your hlep. Cheers, Brook

1 0

Re: [boost] regression results for the release?
by Boris Gubenko 20 May '08

20 May '08

Rene Rivera wrote: > We can still get the 1.35.0 results. We just need volunteers to run the > regression results against 'tags/release/1_35_0'. And if we have those > results, I could turn around and generate the expected_results.xml. I can do it for HP platforms. Thanks, Boris ----- Original Message ----- From: <boost(a)lists.boost.org> To: <boost(a)lists.boost.org> Sent: Tuesday, May 20, 2008 11:07 AM Subject: Re: [boost] regression results for the release? > Beman Dawes wrote: >> David Abrahams wrote: >>> http://www.boost.org/development/testing.html quoth: >>> >>> Will all Boost libraries work with your compiler? Unfortunately, the >>> answer is "it depends". See the regression testing results to see >>> exactly what works and what doesn't. >>> >>> But when I "see the regression testing results," all I see are results >>> for the trunk and the release branch. If I'm an ordinary user, I'm >>> using the 1.35.0 _release_. Do those libraries work with my compiler? >> >> Noted. One of the pushes for 1.36.0 will be to rewrite the release >> procedures, and then actually follow them. > > We can still get the 1.35.0 results. We just need volunteers to run the > regression results against 'tags/release/1_35_0'. And if we have those > results, I could turn around and generate the expected_results.xml. > > > -- > -- Grafik - Don't Assume Anything > -- Redshift Software, Inc. - http://redshift-software.com > -- rrivera/acm.org (msn) - grafik/redshift-software.com > -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost >

1 0

[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