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