June 2004 - Boost - lists.preview.boost.org

[admin] Wiki Spam -- IP's are being banned
by Jeff Garland 28 Jun '04

28 Jun '04

All - I'm cross-posting this to boost-users and the developer list since it pertains to both. Over the last couple months there has been a rise in 'spam attacks' on the Wiki. Basically people are inserting links to commercial sites on wiki pages. These sites are totally unrelated to boost, c++, etc. I thank the many boosters that have spent their precious time removing the defacements. But the time has come to crack down. The following IP ranges have been banned from the Wiki. 61.55.32.* 61.55.33.* 69.63.103.* 210.82.76.* 210.82.106.* 219.233.195.* 218.5.65.* I will be monitoring and banning additional IP addresses as needed. If I have accidentally banned someone incorrectly, please let me know offlist: jeff at crystalclearsoftware.com Thanks, Jeff

1 0

shared_ptr<> and atomic_count
by Colin Rafferty 28 Jun '04

28 Jun '04

Hi- Looking at the implementation of shared_count<>, it seems as though it always uses a mutex for incrementing and decrementing the counter. Is there a reason why we aren't using atomic_count instead? In the worst case, it will have the same performance, but in the best case, it can be significantly faster (BOOST_USE_ASM_ATOMIC_H). Thanks. -- Colin Rafferty

1 0

Re: 1.32 release preparation
by Johannes Brunen 28 Jun '04

28 Jun '04

On Mon, 28 Jun 2004 07:37:24 -0400, David Abrahams wrote > Boost.Graph changes have caused plenty of regressions in Boost.Python > in the past. Sorry, I thougth that this would be a pretty good example of a high level library. So I was wrong. On Mon, 28 Jun 2004 07:33:26 -0400, David Abrahams wrote > We should have more releases. Waiting for libraries to be checked in > is one thing that keeps us from being able to release more frequently. Yes, but if I have the choice of waiting one additional week for the check in of an accepted library against waiting 2 month for the next release I would choose to wait that additional week. However, I have read in one of the other mails that you have a deadline with your book. So live is not that simple at all. I won't persist on changing the planned schedule. Don't get me wrong. > It sounds like you want a whole new Boost procedure for reviews *and* > releases. That seems like a stretch; we don't have any idea whether > it would work at all. No, I merely think that a library should be accepted when it is ready for checkin and there is not a list of changes and request pending. On Mon, 28 Jun 2004 07:34:22 -0400, David Abrahams wrote >> On Mon, 28 Jun 2004 10:51:36 +0200, Johannes Brunen wrotes >> We should list them on the lib page but in a special section. > I don't like the sound of that. It should be very clear to people > which things are part of Boost and which aren't. Ok, I second that. If it not clear for people what is part of boost then it is the wrong way. People should be able to build on a boost release. With kind regards Johannes

1 0

iterator_traits.pdf not marked as binary
by Peter Dimov 28 Jun '04

28 Jun '04

libs/iterator/doc/iterator_traits.pdf is not marked as binary in the CVS. -- Peter Dimov http://www.pdimov.com

2 1

[Graph] What to do about broken compilers?
by Doug Gregor 28 Jun '04

28 Jun '04

The graph library has always been in a "barely usable" support on certain compilers (Borland <= 5.6.4 and MSVC 6.0, in particular). The regression tests have always been a mess---Boost 1.31.0 has very few passes for these compilers, and 1.32.0 isn't looking any better. However, the library is somewhat usable, if you stick to a very small subset and don't mind working around INTERNAL COMPILER ERRORs all of the time. What to do? I'm marking the library "unusable" on both compilers, so that we can concentrate our efforts on those compilers that might actually work. Complain loudly, quickly, and preferably with patches if you think this is the wrong approach. Doug

4 5

Boost.Threads: RW mutexes and locks.
by Batov, Vladimir 28 Jun '04

28 Jun '04

RW mutexes/locks are important to a threading library and appear simple to implement. However, Boost.Threads lacks it. I wrote something simple that appear to do the job using the functionality already available in Boost.Threads. If the idea is considered good/robust/efficient enough and worth having in the library, I can re-write it to conform with the rest of Boost.Threads. class rw_mutex : private boost::noncopyable { typedef boost::condition Condition; public: friend class writer_lock; friend class reader_lock; rw_mutex() : num_readers_(0), num_writers_(0) {} private: boost::mutex mutex_; Condition reader_condition_; Condition writer_condition_; int num_readers_; int num_writers_; }; class writer_lock : public boost::mutex::scoped_lock { typedef boost::mutex::scoped_lock super; public: writer_lock(rw_mutex& mutex) : super(mutex.mutex_), mutex_(mutex) { ++mutex_.num_writers_; // Make new readers wait. // If there are readers in-progress, wait for them to finish. while (mutex_.num_readers_) mutex_.writer_condition_.wait(*this); } ~writer_lock() { --mutex_.num_writers_; // Last writer notifies waiting readers. // If not last, wake up the next writer. if (!mutex_.num_writers_) mutex_.reader_condition_.notify_all(); else mutex_.writer_condition_.notify_one(); } private: rw_mutex& mutex_; }; class reader_lock : public boost::mutex::scoped_lock { typedef boost::mutex::scoped_lock super; public: reader_lock(rw_mutex& mutex) : super(mutex.mutex_), mutex_(mutex) { // If there are writers waiting, let them in first. while (mutex_.num_writers_) mutex_.reader_condition_.wait(*this); ++mutex_.num_readers_; // Make new writes wait. unlock(); } ~reader_lock() { lock(); --mutex_.num_readers_; // Last reader notifies if (!mutex_.num_readers_) mutex_.writer_condition_.notify_one(); } private: rw_mutex& mutex_; };

3 2

Re:[boost] Re: 1.32 release preparation
by Johannes Brunen 28 Jun '04

28 Jun '04

On Sun, 27 Jun 2004 19:05:45 -0700, Robert Ramey wrote > Here is the current scenario. > > a) The announcement gets posted - release 1.32 scheduled for date x. > b) Each developer decides - uh oh I better get in my changes before date x. > c) Of course these changes take longer > d) and break some other things > e) which takes longer still IMHO, point d) touches a weak point: There are two kind of libraries in a system like boost. At first, there are core libraries which are used by many other libraries. Changes at these libraries are potentially dangerous and must be well-considered since they can broke a lot of stuff. They should early checked into CVS to get time for stabelizing the base. Secondly, there are libraries which 'only' provide a special feature like the boost graph library the circular_buffer library. They shouldn't be expected to lead to regressions of other boost libraries. I think that they could be handled differently than the core libraries. > a) the release manager or the core influential developers keep an eye on the > current state of the CVS tree and tests. > b) When things look "pretty good", branch for release without warning. None > of this loading my latest feature in to make the schedule. > c) the Main tree goes on as usual > d) pending issues in the release branch are addressed by nagging the person > responsible. > e) the new version is releases with a number like 1.31.1 or maybe even 28 > July 2004. > f) any changes between branch and release should be just bug fixes which can > then be merged back into the development tree. > > Under this system, releases would occur more frequently - on the order of 6 > weeks. If you're ready to check in your latest feature and the new release > branch catches you with your pants down - well too bad. But it's no big deal > because the next release will be in 6? weeks anyhow which is close to what > its going to take to shake out the repercussions of your check in anyway. We should seriouly consider such a release process. Howerver, then the CVS main tree must always be in a nearly 'Release-Ready' state. But IMO that is anyway a good idea. > But I > think it's really hard to get such a large number of people working > independently on exactly the same schedule. Yes ... > Almost all libraries are accepted subject to some changes being made. Many > such changes seem simple but end up rippling through the whole library. This > takes time. This is IMHO an indication of a flaw in the current boost review process. A library should be only accepted after the list of requested changes has been made. Additionally, I think a library should be accepted only if it is compatible to the current CVS main tree. > Once a library is accepted, then one can get serious about making it pass > with a larger number of compilers. This also takes time - a lot of time Passing compilers which weren't supported during the review process under no circumstances shouldn't delay the integration of the library into the boost main pool. Supporting a special compiler is only a nice to have feature. This means not that it not worth spending the effort supporting important platforms. However, in the first iteration I just expect a library to be written in ANSI C++ and to be usable on platforms which support it. > These changes end up having a ripple effect and can result it changes like > moving things in namespaces and subdirectories. While this is going on, the > system is broken and really not suitable to be subject to the daily testing > routine. This is IMHO an indication of a flaw ... (s.a) > So it seems attractive to deal with all this stuff before one does > the initial check in to CVS. This way one can start with a relatively clean > start. I second this. With best regards Johannes

2 1

Re: 1.32 release preparation
by Johannes Brunen 28 Jun '04

28 Jun '04

On Sun, 27 Jun 2004 16:35:15 -0400, David Abrahams wrote > Should we have accepted libraries checked in immediately (on a branch, > maybe?), Maybe we should reconsider the meaning of 'acceptance' in the review process. Apart of that, I think that this is a very good idea. > and then only added to the libs page when the authors > deem them ready? We should list them on the lib page but in a special section. > If they're checked in on the trunk they can even get the benefit of > regression testing while the authors whip them into shape. Yes, that would be fine. With best regards Johannes

2 1

Re: [boost] Re: 1.32 release preparation
by Johannes Brunen 28 Jun '04

28 Jun '04

On Sun, 27 Jun 2004 08:30:20 -0700, Jeff Garland wrote: > As much as I'd like to see circular_buffer, serialization, etc in this release I'd rather > see us pull off a release that doesn't take 2-3 months to accomplish. I > believe we should hold the line on the schedule now and anything that isn't > ready should simply go in the next release. I disagree on that. We don't have that many Boost releases. Waiting for the next one could be a long time. Therefore, I propose to wait until all (or as many as possibly considering a reasonable time schedule) accepeted libraries will be checked into CVS and be part of the release. > And if there are a large > number of new things left out by that approach then we should plan another > release sooner rather than waiting 4 months. However, then you need new volunteers which have to spend the time for the whole procedure again. > One is that we have been reviewing and > accepting a large number of libraries recently. So, many of these have been > accepted in the last couple months. The other thing that seems to be a > pattern is that libraries get accepted, then authors get a list of changes to > make. I could think of a review process which accepts a library only after the list of requested changes has beem made. > If they get busy it often takes months to get these done and then > finally they check into CVS. So a release tends to trigger the evaluation of > anything that is in that multi-month pipeline. That isn't good. I would prefere a review process which leads to final acceptance only after a library is 'CVS' compatible i.e. does not yield to any (known) regressions of the existing pool libraries and is equipted with a working testing facility. With best regards Johannes

2 1

Re:[boost] Re: 1.32 release preparation
by Robert Ramey 28 Jun '04

28 Jun '04

Dave Abrahams wrote: >I'd like to know the reasons for "all the sudden rush". We did >announce a schedule long ago, and it has already been delayed by three >weeks. I'm not asking in order to point fingers; I just want to know >how to avoid the "sudden rush" next time. Here is the current scenario. a) The announcement gets posted - release 1.32 scheduled for date x. b) Each developer decides - uh oh I better get in my changes before date x. c) Of course these changes take longer d) and break some other things e) which takes longer still Personally I think the concept of scheduling a release fundamentally flawed. I would suggest another idea. a) the release manager or the core influential developers keep an eye on the current state of the CVS tree and tests. b) When things look "pretty good", branch for release without warning. None of this loading my latest feature in to make the schedule. c) the Main tree goes on as usual d) pending issues in the release branch are addressed by nagging the person responsible. e) the new version is releases with a number like 1.31.1 or maybe even 28 July 2004. f) any changes between branch and release should be just bug fixes which can then be merged back into the development tree. Under this system, releases would occur more frequently - on the order of 6 weeks. If you're ready to check in your latest feature and the new release branch catches you with your pants down - well too bad. But it's no big deal because the next release will be in 6? weeks anyhow which is close to what its going to take to shake out the repercussions of your check in anyway. I realize that this is not the most orthodox way of doing things. But I think it's really hard to get such a large number of people working independently on exactly the same schedule. >How come we have so many >accepted libraries that have not even been put in the CVS? Almost all libraries are accepted subject to some changes being made. Many such changes seem simple but end up rippling through the whole library. This takes time. Once a library is accepted, then one can get serious about making it pass with a larger number of compilers. This also takes time - a lot of time These changes end up having a ripple effect and can result it changes like moving things in namespaces and subdirectories. While this is going on, the system is broken and really not suitable to be subject to the daily testing routine. So it seems attractive to deal with all this stuff before one does the initial check in to CVS. This way one can start with a relatively clean start. Robert Ramey

6 6