[1.33.0] Release candidate #2 is available
Boost 1.33.0 release candidate #2 is now available at the usual place: http://www.osl.iu.edu/~dgregor/boost-1.33.0/ Please build it, test it, and report back to the mailing list. If no major problems are found before August 9th, this release candidate will become Boost 1.33.0. Doug Gregor 1.33.0 Release Manager
Douglas Gregor writes:
Boost 1.33.0 release candidate #2 is now available at the usual place:
http://www.osl.iu.edu/~dgregor/boost-1.33.0/
Please build it, test it, and report back to the mailing list. If no major problems are found before August 9th, this release candidate will become Boost 1.33.0.
Something I should have put in the release procedure: it would be nice to have these announcements to appear on the main boost.org page, too, and perhaps even posted to boost-announce list. -- Aleksey Gurtovoy MetaCommunications Engineering
Douglas Gregor writes:
Boost 1.33.0 release candidate #2 is now available at the usual place:
... and is browsable online at http://engineering.meta-comm.com/boost/1_33_0_rc2/. -- Aleksey Gurtovoy MetaCommunications Engineering
On Monday 08 August 2005 08:41, Aleksey Gurtovoy wrote:
Douglas Gregor writes:
Boost 1.33.0 release candidate #2 is now available at the usual place:
... and is browsable online at http://engineering.meta-comm.com/boost/1_33_0_rc2/.
And what are those funky characters in the left-top corner? HTML starts with О╩© and not with "<" - Volodya
Sorry I didn't get to this sooner, but lexical cast has broken my source code. I have not tracked down the source of the crash because I currently have a release build, but looking at the diffs, I believe is it due to whitespace at the end of a string that I am attempting to convert to a number, this being caused by 151c157,166 < (stream >> std::ws).eof(); ---
stream.get() == #if defined(__GNUC__) && (__GNUC__<3) && defined(BOOST_NO_STD_WSTRING) // GCC 2.9x lacks std::char_traits<>::eof(). // We use BOOST_NO_STD_WSTRING to filter out STLport and libstdc++-v3 // configurations, which do provide std::char_traits<>::eof().
EOF; #else std::char_traits<char_type>::eof(); #endif
You'll note that stream >> std::ws is no longer called. One note that I must make is that I do not have the vanilla source for lexical_cast. From the last time lexical_cast broke my source, I've commented out stream.unsetf(std::ios::skipws); in the lexical_stream constructor (see http://lists.boost.org/MailArchives/boost-users/msg03656.php for the reason). I just recalled a unit test we have that would expose the problem (and it did). By adding a [stream >> std::ws &&] before the check for eof, my problem was resolved. Is there a reason we want to fail with trailing whitespace? Thanks, Tom
Thomas Matelich wrote:
You'll note that stream >> std::ws is no longer called.
One note that I must make is that I do not have the vanilla source for lexical_cast. From the last time lexical_cast broke my source, I've commented out stream.unsetf(std::ios::skipws); in the lexical_stream constructor (see http://lists.boost.org/MailArchives/boost-users/msg03656.php for the reason).
I just recalled a unit test we have that would expose the problem (and it did). By adding a [stream >> std::ws &&] before the check for eof, my problem was resolved. Is there a reason we want to fail with trailing whitespace?
I'm not the lexical_cast author, but I do know there were discussions about this in the Boost mailing lists (search the archives, one of these threads was started by me). The reason for changing it was symmetry. In Boost 1.32, trailing whitespaces were ignored, while leading whitespaces were not. This is clearly wrong because there's no reason for asymmetry here. So the decision (which I'm fully agree with, BTW) is to *not* ignore whitespaces at all. If you want to ignore whitespaces, then the (simple) suggestion I can give you is to trim (the string_algo Boost library) the string before sending it to lexical_cast. HTH, Yuval
On 8/9/05, Yuval Ronen <ronen_yuval@yahoo.com> wrote:
Thomas Matelich wrote:
You'll note that stream >> std::ws is no longer called.
One note that I must make is that I do not have the vanilla source for lexical_cast. From the last time lexical_cast broke my source, I've commented out stream.unsetf(std::ios::skipws); in the lexical_stream constructor (see http://lists.boost.org/MailArchives/boost-users/msg03656.php for the reason).
I just recalled a unit test we have that would expose the problem (and it did). By adding a [stream >> std::ws &&] before the check for eof, my problem was resolved. Is there a reason we want to fail with trailing whitespace?
I'm not the lexical_cast author, but I do know there were discussions about this in the Boost mailing lists (search the archives, one of these threads was started by me). The reason for changing it was symmetry. In Boost 1.32, trailing whitespaces were ignored, while leading whitespaces were not. This is clearly wrong because there's no reason for asymmetry here. So the decision (which I'm fully agree with, BTW) is to *not* ignore whitespaces at all.
If you want to ignore whitespaces, then the (simple) suggestion I can give you is to trim (the string_algo Boost library) the string before sending it to lexical_cast.
Why do these changes always get made when I'm taking a break from the list? Oh well, I didn't see the value in the first change, and I don't see the value in this change. I'll add another item to my "Things to do to new Boost versions before committing" list. Thanks for the answer. Tom
Douglas Gregor <doug.gregor@gmail.com> writes: | Boost 1.33.0 release candidate #2 is now available at the usual place:
| http://www.osl.iu.edu/~dgregor/boost-1.33.0/
| Please build it, test it, and report back to the mailing list. If no | major problems are found before August 9th, this release candidate will | become Boost 1.33.0. If possible I'd like this patch to go in. The name is "LyX" not "Lyx" -- Lgb
On Aug 9, 2005, at 5:44 AM, Lars Gullik Bjønnes wrote:
Douglas Gregor <doug.gregor@gmail.com> writes:
| Boost 1.33.0 release candidate #2 is now available at the usual place:
| http://www.osl.iu.edu/~dgregor/boost-1.33.0/
| Please build it, test it, and report back to the mailing list. If no | major problems are found before August 9th, this release candidate will | become Boost 1.33.0.
If possible I'd like this patch to go in. The name is "LyX" not "Lyx"
Okay, got it. Doug
| Please build it, test it, and report back to the mailing list. If no | major problems are found before August 9th, this release candidate will | become Boost 1.33.0.
If possible I'd like this patch to go in. The name is "LyX" not "Lyx"
Doug, are we still open for trivial documentation patches like this? Thanks, John.
On Aug 9, 2005, at 11:00 AM, John Maddock wrote:
| Please build it, test it, and report back to the mailing list. If no | major problems are found before August 9th, this release candidate will | become Boost 1.33.0.
If possible I'd like this patch to go in. The name is "LyX" not "Lyx"
Doug, are we still open for trivial documentation patches like this?
Yes. I'll sent a note to the list when I'm about to roll the final release tarballs, which I expect to do tomorrow morning. Doug
Doug Gregor wrote:
On Aug 9, 2005, at 11:00 AM, John Maddock wrote:
| Please build it, test it, and report back to the mailing list. If no | major problems are found before August 9th, this release candidate will | become Boost 1.33.0.
If possible I'd like this patch to go in. The name is "LyX" not "Lyx"
Doug, are we still open for trivial documentation patches like this?
Yes. I'll sent a note to the list when I'm about to roll the final release tarballs, which I expect to do tomorrow morning.
Are you sure you'll be able to, re: ( 2005-08-09 08:52:08 - Project CVS Service ) In support of the CVS server upgrade (occurring for 36 hours starting at 2005-08-09 at 09:00 Pacific) ( 2005-08-04 10:34:06 - Project CVS Service ) Starting on 2005-08-09 at 09:00 Pacific, developer CVS service will be offline for a expected period of up to 36 hours to facilitate significant hardware upgrades. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
On Aug 9, 2005, at 11:27 AM, Rene Rivera wrote:
Are you sure you'll be able to, re:
( 2005-08-09 08:52:08 - Project CVS Service ) In support of the CVS server upgrade (occurring for 36 hours starting at 2005-08-09 at 09:00 Pacific)
( 2005-08-04 10:34:06 - Project CVS Service ) Starting on 2005-08-09 at 09:00 Pacific, developer CVS service will be offline for a expected period of up to 36 hours to facilitate significant hardware upgrades.
Aaaaarrrrrrrrrgggggghhhhhhhhhh. Doug
At 13:20 2005-08-09, you wrote:
On Aug 9, 2005, at 11:27 AM, Rene Rivera wrote:
Are you sure you'll be able to, re:
( 2005-08-09 08:52:08 - Project CVS Service ) In support of the CVS server upgrade (occurring for 36 hours starting at 2005-08-09 at 09:00 Pacific)
( 2005-08-04 10:34:06 - Project CVS Service ) Starting on 2005-08-09 at 09:00 Pacific, developer CVS service will be offline for a expected period of up to 36 hours to facilitate significant hardware upgrades.
Aaaaarrrrrrrrrgggggghhhhhhhhhh.
Doug
Hmmm, I'd forced my system to run before I left for work and stopped the auto (every 3 hours) thing because CVS was supposed to shut down. I just did a sucessful update from CVS and the build seems to be proceeding Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
Victor A. Wagner Jr. wrote:
At 13:20 2005-08-09, you wrote:
On Aug 9, 2005, at 11:27 AM, Rene Rivera wrote:
Are you sure you'll be able to, re:
( 2005-08-09 08:52:08 - Project CVS Service ) In support of the CVS server upgrade (occurring for 36 hours starting at 2005-08-09 at 09:00 Pacific)
( 2005-08-04 10:34:06 - Project CVS Service ) Starting on 2005-08-09 at 09:00 Pacific, developer CVS service will be offline for a expected period of up to 36 hours to facilitate significant hardware upgrades.
Aaaaarrrrrrrrrgggggghhhhhhhhhh.
Doug
Hmmm, I'd forced my system to run before I left for work and stopped the auto (every 3 hours) thing because CVS was supposed to shut down. I just did a sucessful update from CVS and the build seems to be proceeding
You got lucky, and so did the Sf staff. They seem to be running ahead of schedule as they just, literally a few minutes ago, put CVS back online many hours ahead of schedule :-) ( 2005-08-09 22:37:23 - Project CVS Service ) The CVS upgrade and sync has been completed. The CVS server is now online and completely operational. ( 2005-08-09 18:16:09 - Project CVS Service ) Sync of data to new CVS hardware is presently ahead of schedule, with roughly two-thirds completion; migration wrap-up and testing (anticipated to be 1-2 hours of work) to be initiated post-sync. Further status update to be posted prior to 9:00 Pacific on 2005-08-10. Outage scheduled to complete by 21:00 Pacific on 2005-08-10, based on prior outage notice. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
We have a serious problem with the 1.33.0 release candidate, which breaks all of our codes with gcc-3.3. The problem is the double definition of is_abstract: /misc/alps1/boost_1_33_0/boost/serialization/is_abstract.hpp:30: error: redefinition of `struct boost::is_abstract<T>' /misc/alps1/boost_1_33_0/boost/type_traits/is_abstract.hpp:130: error: previous definition of `struct boost::is_abstract<T>' would it be possible to put serialization/is_abstract.hpp into a different namespace or to rename it? For gcc-3.4 or higher everything works, but many users of our codes still have gcc-3.3 installed and we would thus like to support gcc-3.3. Best regards Matthias
On Aug 9, 2005, at 11:19 AM, Matthias Troyer wrote:
We have a serious problem with the 1.33.0 release candidate, which breaks all of our codes with gcc-3.3. The problem is the double definition of is_abstract:
/misc/alps1/boost_1_33_0/boost/serialization/is_abstract.hpp:30: error: redefinition of `struct boost::is_abstract<T>' /misc/alps1/boost_1_33_0/boost/type_traits/is_abstract.hpp:130: error: previous definition of `struct boost::is_abstract<T>'
would it be possible to put serialization/is_abstract.hpp into a different namespace or to rename it?
Robert, do you have a patch or workaround for this already? Doug
On Aug 9, 2005, at 11:19 AM, Matthias Troyer wrote:
We have a serious problem with the 1.33.0 release candidate, which breaks all of our codes with gcc-3.3. The problem is the double definition of is_abstract:
/misc/alps1/boost_1_33_0/boost/serialization/is_abstract.hpp:30: error: redefinition of `struct boost::is_abstract<T>' /misc/alps1/boost_1_33_0/boost/type_traits/is_abstract.hpp:130: error: previous definition of `struct boost::is_abstract<T>'
would it be possible to put serialization/is_abstract.hpp into a different namespace or to rename it?
Robert has put a fix for this in CVS. Would you grab a CVS version (from branch RC_1_33_0) to determine if it has also fixed the problem for you? (This is an important fix, but I'm trying not to seed another full release candidate). Doug
On Aug 10, 2005, at 3:12 PM, Douglas Gregor wrote:
On Aug 9, 2005, at 11:19 AM, Matthias Troyer wrote:
would it be possible to put serialization/is_abstract.hpp into a different namespace or to rename it?
Robert has put a fix for this in CVS. Would you grab a CVS version (from branch RC_1_33_0) to determine if it has also fixed the problem for you?
(This is an important fix, but I'm trying not to seed another full release candidate).
Indeed, now out codes all compile. Thanks. Matthias
participants (1)
-
Aleksey Gurtovoy -
Doug Gregor -
Douglas Gregor -
John Maddock -
larsbj＠gullik.net -
Markus Schöpflin -
Matthias Troyer -
Rene Rivera -
Thomas Matelich -
Victor A. Wagner Jr. -
Vladimir Prus -
Yuval Ronen