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

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

29 Jun '04

David Abrahams <dave(a)boost-consulting.com> writes: >> Robert, I'm very happy to have your contributions in this discussion, >> but it's hard to take your diagnosis of where the problem lies all >> that seriously when you haven't even been through a single Boost >> release with a library of your own! >I hope I didn't squash the discussion with this remark; I'm really >interested in exploring the possibilities here. I guess I should've >asked how you formed your impressions of the problem's cause. As I recall, the previous release was scheduled for beginning November. I was working on the serialization library at the time and using the development tree at the time. When the release was announced, lots of new stuff was added. There were a couple of tweaks in the new iterators which required changes for me to keep up. Trying to develop new stuff based on he development tree became inconvenient but I needed features not it 1.30 . Then about the middle of January "is_abstract" was dropped in. This was an evolved version of one I had adapted from ?R Sharoni's code. It was slightly different from the original in the way compilers not supported. So we didn't have real good knowledge about which platforms supported it and what value it should return on platforms that didn't support it. I was considered a very small change but consumed maybe a week of back and forth. It became clear that I could not submit a proposed serialization library based on the development tree that could be reviewed by large number of members downloading the library over an extended period without users encountering a lot of frustration and my trying to keep up with a morphing main trunk. As soon as it was released, I switched to maintain compatibility with the released 1.31 and it has worked out well. Based on this experience, it is my perception that the main development trunk was at least somewhat fluid over a period of 2 to 3 months and this made development more difficult. These are just the things I happen to run into first hand. The traffic on the list left me with the impression that my experience wasn't unique. That is how I formed my impression of the problem's cause. It is my reluctance to contribute to this problem which has discouraged me from checking in the serialization library until it is at a point where I believe there are no undocumented bugs/deficiencies. That is why the serialization library is not yet checked in. At this point nothing in boost depends on the serialization library. Should that change in the future, this discussion convinces me that before checking in any non-trivial changes, I should re-run the whole test suite on my local setup. In the case of MPL, I would think that it would be prudent to run that part of the test suite that depends upon MPL on one's local environment before checking it in - given that we don't use a branch for untested code. Robert Ramey

2 1

1.32 release preparation
by Aleksey Gurtovoy 29 Jun '04

29 Jun '04

Hi All, I'm finally ready to start working towards the next release, which as some of you might remember I volunteered to manage. Below is a preliminary schedule what I would like to propose, subject to adjustments as I receive your input: June 24-27: Announce a preliminary release schedule, collect information about everyone's plans for the release, adjust/confirm the schedule, make regression reports to reflect the actual status of the main trunk, setup nighly runs of the inspection report (http://tinyurl.com/2vo5p) construct a "Release Progress" page publishing the milestones, the collective TODO list, and links to all the reports. June 27-July 16: Use regression reports to identify and resolve the outstanding issues with the main trunk. Walk through and deal with all the patches and bug reports submitted to the list/SourceForge tracker since the last release. In accordance with the TODO list, track the progress of individual developers. By July 15, 24:00 US Central Time every line of code that is intended to be put into this release should be in the CVS, and the next round of regression reports should show no regressions against the then-current expected failures markup. July 16: Branch for release. Switch regression tests to run on the branch. July 17-July 18: No code checkins are allowed expect to fix the failures resulted from branching (hopefully none). Documentation checkins are still OK. Perform the rest of the pre-release tasks listed in http://tinyurl.com/2meuh. July 18, 24:00 US Central Time marks a complete freeze of the branch. July 19-July 20: Prepare and test the release candidate archives. Fix any found issues and repeat. July 21: Release according to the http://tinyurl.com/2meuh procedure. As you can see from the first milestone's description, at this point I'd like to collect everybody's plans for the release (for those developers who do plan to do something, of cource), with approximate dates, so that we have a better understanding of how everything is going to fall together. Please post these plans to the list with "[1.32 Plan]" prefix in the subject. As usual, any other comments/suggestions are more than welcome. Thank you! -- Aleksey Gurtovoy MetaCommunications Engineering

14 29

typo in boost::thread
by Janusz Piwowarski 29 Jun '04

29 Jun '04

Hello, Numerous files of boost::thread has CR+CR+LF as line ending. I noticed it happens regularly, maybe there's a way to prevent this? Also, there's a typo in try_lock member of scoped_timed_lock<TimedMutex> class: is: return (m_locked = lock_ops<TryMutex>::trylock(m_mutex)); should be:? return (m_locked = lock_ops<TimedMutex>::trylock(m_mutex)); Regards, Janusz

2 2

RE: [boost] The Test Tools Docs, Concept Checking
by Rozental, Gennadiy 29 Jun '04

29 Jun '04

I could add proposed text, once somebody prepared it. Gennadiy. > Hi, > > I have been reading the Test Tools docs. Would it be a > good idea to add ConceptChecking to the list of alternative > methods of reporting errors, in > /test/doc/index.html#introduction ? A recent post on boost > alluded to the fact that Concepts (ie What is a concept? ) > can be difficult to understand. Well ... ConceptChecks are > the medium for pinning down Concepts in C++ code and are > probably the most effective means of error reporting at > compile time, but are not used as much as they could be. The > Boost Test Library would seem to be as good a place as any to > promote them, which could help to remove some of the mystery. > > regards > Andy Little

3 2

[Test] Failures on GCC 2.95.3
by Doug Gregor 29 Jun '04

29 Jun '04

The file boost/test/detail/basic_cstring/io.hpp contains this workaround function for GCC 2.95.3: template<typename CharT> inline std::ostream& operator<<( std::ostream& os, basic_cstring<CharT> const& str ) { typedef typename basic_cstring<CharT>::mutable_char char_type; char_type const* const beg = reinterpret_cast<char_type const* const>( str.b egin() ); char_type const* const end = reinterpret_cast<char_type const* const>( str.e nd() ); os << std::basic_string<char_type>( beg, end - beg ); return os; } What is mutable_char? It doesn't show up anywhere else in Boost. Doug

2 1

Missing http://www.boost.org/regression-logs/cs-win32_metacomm/developer/index.html
by Doug Gregor 29 Jun '04

29 Jun '04

I have a sinking feeling that I might have broken something when modifying the explicit failures file :( Doug

2 1

Re: Boost.Threads proposed change: lock constructors
by Batov, Vladimir 28 Jun '04

28 Jun '04

> Part of the point, though, is that try_lock doesn't actually work that > way: one of the try_lock constructors does a non-blocking try_lock(), > and the other does a blocking lock(). Without looking, do you always > remember which one does which? I don't. Well, first, the behavior that I was talking about in my prev. email (ones I was happy about) were the 'basic' constructors (that I called 'default' constructors -- what an embarassment). The following is IMHO good and I would not like see them complicated: 1. scoped_lock l(m); // Blocks until it locks. 2. scoped_lock l(m, true); // As above. 3. scoped_lock l(m, false); // Only declaration. Does nothing. Needed if I need to declare but use it later. 4. try_lock l(m); // Tries to lock. Always falls through. I need to check the result. 5. try_lock l(m, false); // Only declaration. Does nothing. 6. timed_lock l(m, time); // Blocks until locks or 'time' expires. 7. timed_lock l(m, false); // Only declaration. Does nothing. I have to agree that the following behavior 8. try_lock l(m, true); 9. timed_lock l(m, true); that according to the documentation call lock() instead of respective try_lock() and timed_lock() look wrong. I'd be temted to say that merely making (8) work as (4) would be sufficient fo fix try_lock. (9) does not appear "fixable" in a similar way. I am tempted to suggest something similar to overloaded 'operator new': struct nolock_t {}; nolock_t nolock; 1. scoped_lock l(m); 2. scoped_lock l(m, nolock); 3. try_lock l(m); 4. try_lock l(m, nolock); 5. timed_lock l(m, time); 6. timed_lock l(m, nolock); It removes redundancy (as with the original scoped_lock(m) and scoped_lock(m, true)) and makes everything simple and consistent. Just a thought. V

2 1

How to handle name mangling in "versioned" toolsets?
by John Maddock 28 Jun '04

28 Jun '04

At present we have two types of toolsets: 1) Unversioned toolsets such as "intel-win32", which produce unversioned toolset suffixes to library names, "iw" in this case. 2) Versioned toolsets such as "intel-win32-7.1-vc6-stlport-4.5.3" which produce versioned toolset suffixes to library names, "iw71" in this case. This produces a problem with the autolinking code which can take either approach, but not both (or at least not both auto-magically, and this is causing some regression test failures at present). In other words I'm asking for some kind of consistent policy here; note that if the choice is to consistently use "versioned" toolsets then we're committing ourselves to constantly updating the build system and autolinking code to keep up with new compiler releases. So, I guess I'm leaning towards "unversioned" mangled toolset names, but would like more some feedback, so: what does everyone else think? Thanks, John.

3 2

Re: Boost.Threads: Do we need all those mutexes?
by Batov, Vladimir 28 Jun '04

28 Jun '04

My question was more about the design rather than how I could work it around. I may be wrong but specializing mutex does not look like a good idea as it appears to be lock-specific functionality. So, I thought we might consider having only mutex and typedefing others to it (not to break old code) -- the simpler the better. Isn't it? V. > Do we need all three separate concepts -- mutex, try_mutex and > timed_mutex? I think the idea was that it would be possible to implement the mutex types that supported fewer operations more efficiently. Whether this actually turned out to be true is another question. > I'd expect the mutex concept to remain unchanged and "try" > and "timed" refinements to be related solely to the ways I try locking > that only mutex. That is, I always have one mutex and under different > circumstances lock it unconditionally (scoped_lock) or try locking it > and check if that attempt succeeds (scoped_try_lock) or try locking > within a certain time period (scoped_timed_lock). If you want this, just use a timed_mutex and scoped_timed_lock. In the current release it supports lock() and timed_lock() operations; in the next release it will support try_lock() as well. Mike ------------------------------ _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost End of Boost Digest, Vol 772, Issue 2 *************************************

1 0

GCC 3.4 lpthread warnings
by Jeff Garland 28 Jun '04

28 Jun '04

On the regression tests I'm seeing lots of warnings from gcc 3.4. For example: date_time - test_greg_wstream - gcc-3.4.0-linux Compiler output: In file included from /boost/head-regression/boost/boost/config.hpp:44, from /boost/head-regression/boost/boost/date_time/locale_config.hpp:19, from /boost/head-regression/boost/boost/date_time/compiler_config.hpp:14, from /boost/head-regression/boost/boost/date_time/gregorian/gregorian.hpp:19, from ../libs/date_time/test/gregorian/testgreg_wstream.cpp:10: /boost/head-regression/boost/boost/config/stdlib/libstdcpp3.hpp:33:7: warning: #warning "Boost threading support turned on, you may need to link against -lpthread unless you define BOOST_DISABLE_THREADS when building." Lots of other libraries are seeing similar warnings with gcc 3.4. Date-time does nothing with threads so I believe based that I should just set define BOOST_DISABLE_THREADS for the test cases to resolve this. But since I'm not certain of all the implications of this I thought I'd as for advice before proceeding. One specific question that comes to mind is do I need to limit the scope to gcc so I don't break MT, dll mode on Windows? Thanks, Jeff

6 15

[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

Problems compiling regex with gcc3 on aix and hpux
by Goetz Isenmann 28 Jun '04

28 Jun '04

Hi! I get ugly warnings (they look dangerous to me) when I compile boost/regex on AIX and HP-UX with gcc. On Linux and FreeBSD everything is fine. For example /usr/local/gcc-3.3.3/bin/g++ -c -I. libs/regex/src/cregex.cpp compiles without any complains. On aix43 and hpux11 this gives me the attached warning messages. The order of the messages is slightly different on both platforms, but after sorting the output is identical. I use boost-1.31.0 and see no differences with and without boost-1.31.0-regex-patch-20040503. -- Goetz Isenmann

2 3

Provisional schedule for Boost-1.33
by John Maddock 28 Jun '04

28 Jun '04

Booster's: It's apparent that several of us will just miss the 1.32 deadlines, and I'm sure some people will be concerned when their code will get released as a result, so provisionally I'd like to propose a schedule for 1.33 so we all know where we are. Unless someone else would like to volunteer (and please don't be shy in doing so!), then I guess that means I've just volunteered to manage the release.... Regards, John Maddock. Provisional 1.33 release schedule: ~~~~~~~~~~~~~~~~~~~~~~ Mon 30th August 2004 [1]: ~~~~~~~~~~~~~~~~ Deadline for additions and changes (other than patches to known issues, and docs) to core Boost libraries [2]. Deadline for the addition of new libraries to cvs unless they pass all tests with the core compiler set [3]. Mon 13th September 2004: ~~~~~~~~~~~~~~~~~~ Deadline for additions and changes (other than patches to regressions, and docs) to all Boost libraries. Deadline for all new library additions. Mon 27th September 2004: ~~~~~~~~~~~~~~~~~~ Branch for release, no changes to the release branch without the release managers permission (except for docs). Mon 4th October 2004: ~~~~~~~~~~~~~~~~ First release candidate published, actual release will be as soon as possible thereafter. Notes: ~~~~ 1) There should be a few reminders of this deadline in the weeks beforehand. 2) The core Boost libraries are those that other Boost libraries heavily depend upon: bind config (unless change is restricted to a single compiler, and can be tested with all effected versions of that compiler before commit). enable_if. integer. iterators (the construction framework subset only). mpl operators preprocessor smart_ptr's static_assert test type_traits. 3) The core compiler set includes those compilers that are known to be highly conforming, and for which no failures will normally be expected: gcc 3.3 or later on Linux. Visual C++ 7.1 on Win32. Intel C++ 8 on Win32 or Linux.

1 0

Re: 1.32 release prepar
by Robert Ramey 28 Jun '04

28 Jun '04

Last time we ended up making a release candidate which isolated a couple of final issues. Maybe this is a symptom and maybe it points in the direction of an interesting idea. New code is checked in and tested in the development tree just as it is now. Regression testing and everything remains exactly as it is. Code that documents all test failures and is considered ready for release is moved to the Release Candidate tree. The exact same regression testing setup used on the development tree is used here. Presumably, it would be run much less as things would only be checked in when thought to be perfect which is an infrequent occurrence. Developers develop against the Release Candidate tree. When they have something they like, the check into the Main Development tree as they do now. Traffic on the main development tree is the same as it is now. The Release Candidate Tree should be ready for "shipment" at any convenient time. This basically should consist of assignation of a version number to the tree state. It would not be or scheduled event dramatic event. It could happen as frequently as is convenient. Of course a test failure on the RC tree would be dramatic event. The check in causing such an event could be cast from the RC Tree (Heaven) back into the Main Development Tree (Purgatory) and the author would suffer the attendant embarrassment. Hopefully this would be an infrequent event. I realize that I haven't personally had a library go through the release process so feel free to ignore this idea. Robert Ramey

2 1

[config] about BOOST_NO_POINTER_TO_MEMBER_TEMPLATE_PARAMETERS
by Joaquín Mª López Muñoz 28 Jun '04

28 Jun '04

In config/intel.hpp, this defect macro is defined as follows #if defined(__ICL) && (__ICL <= 710) # define BOOST_NO_POINTER_TO_MEMBER_TEMPLATE_PARAMETERS #endif The macro should be defined *only* for Intel C++ 7.1 or older for Windows 32-bit. So my questions are: 1. Is the definition correct in light of what I said above? 2. What's the meaning of all those different macros __ICC, __ICL and __ECC? I've googled for them but found nothing conclusive. Thanks Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 4

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

28 Jun '04

John Torjo wrote: > Batov, Vladimir wrote: >> >> 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. > ^^^^ > > just curios, shouldn't this be thread-safe? I believe it is thread-safe as writer_lock currently inherits from scoped_lock and, consequently, we get inside the writer_lock constructor after its base-class scoped_lock constructor. The base-class constructor does the synchronization.

1 0