[1.37.0 beta] Beta release available on SourceForge

1.37.0 beta 1 is available on SourceForge. See http://tinyurl.com/674rcl There is one known bug in the beta; the Getting Started Guide release number is still shown as 1.36.0. That will be fixed in the final release. There is one new library (Proto) in the release and numerous bug fixes and updates to existing libraries. The beta period will be approximately ten days. Please post bug reports to either the boost developer or user lists, but also let us hear about success stories too! Many thanks to Eric Niebler, Daniel James, Rene Rivera, Marshall Clow, the testers, and all the others who helped to get this beta release together. --Beman Dawes

Hi there, first of all thanks for a great beta release. I have tested it with a fairly complex application of mine, making heavy use of serialization (the core dumps reported in a recent thread on the user's list seem to be gone - great, thanks Robert :-), boost.threads, boost.asio, boost.bind, and smart pointers. I have so far run into *no major* difficulties, but will of course report issues as they arise. *** A small, but from my point of view still significant, nuisance is that bug report 2091 doesn't appear to have been fixed, although it is easy to cure with a change of typedef dst_adjustment_offsets<time_duration_type> dst_adjustment_offsets; to typedef boost::date_time::dst_adjustment_offsets<time_duration_type> dst_adjustment_offsets; in line 161 of <BOOSTROOT>/boost/date_time/tz_db_base.hpp . Alternatively it is possible to rename the typedef in line 161 and in the 2 or so subsequent occurances. *** In the absence of this fix, I need to patch Boost on many recent Linux patforms (at least a current Debian Lenny and OpenSUSE 11, but likely others as well, if they have a g++ 4.3.x Compiler). Best Regards, Ruediger

On Thu, Oct 23, 2008 at 03:45:38PM +0200, Ruediger Berlich wrote:
*** A small, but from my point of view still significant, nuisance is that bug report 2091 doesn't appear to have been fixed, although it is easy to cure
Ditto. And also Ticket #1726, which Jeff (the date_time maintainer) emailed privately to say could be fixed using the patch provided in the ticket. -Steve

Ruediger Berlich wrote:
A small, but from my point of view still significant, nuisance is that bug report 2091 doesn't appear to have been fixed, although it is easy to cure with a change of
typedef dst_adjustment_offsets<time_duration_type> dst_adjustment_offsets;
to
typedef boost::date_time::dst_adjustment_offsets<time_duration_type> dst_adjustment_offsets;
in line 161 of <BOOSTROOT>/boost/date_time/tz_db_base.hpp .
Alternatively it is possible to rename the typedef in line 161 and in the 2 or so subsequent occurances.
I have sent patches for this and some other issues to Jeff for approval. I hope we will manage to merge those fixes before the final release.

On Thu, Oct 23, 2008 at 3:55 PM, Andrey Semashev <andrey.semashev@gmail.com>wrote:
Ruediger Berlich wrote:
A small, but from my point of view still significant, nuisance is that bug report 2091 doesn't appear to have been fixed, although it is easy to cure with a change of
typedef dst_adjustment_offsets<time_duration_type> dst_adjustment_offsets;
to
typedef boost::date_time::dst_adjustment_offsets<time_duration_type> dst_adjustment_offsets;
in line 161 of <BOOSTROOT>/boost/date_time/tz_db_base.hpp .
Alternatively it is possible to rename the typedef in line 161 and in the 2 or so subsequent occurances.
I have sent patches for this and some other issues to Jeff for approval. I hope we will manage to merge those fixes before the final release.
We will get as many as possible into the final release. Thanks, --Beman

Hello
"RB" == Ruediger Berlich writes: RB> In the absence of this fix, I need to patch Boost on many recent Linux RB> patforms (at least a current Debian Lenny and OpenSUSE 11, but likely RB> others as well, if they have a g++ 4.3.x Compiler).
I also have patches for boost with gcc 4.3 - they attached to trac with numbers 2301, 2303, 2304 may they will included into final release - they contain only variables renaming to eliminate warnings -- With best wishes, Alex Ott, MBA http://alexott.blogspot.com/ http://xtalk.msk.su/~ott/ http://alexott-ru.blogspot.com/

On Fri, Oct 24, 2008 at 7:35 AM, Alex Ott <alexott@gmail.com> wrote:
Hello
"RB" == Ruediger Berlich writes: RB> In the absence of this fix, I need to patch Boost on many recent Linux RB> patforms (at least a current Debian Lenny and OpenSUSE 11, but likely RB> others as well, if they have a g++ 4.3.x Compiler).
I also have patches for boost with gcc 4.3 - they attached to trac with numbers 2301, 2303, 2304
Have these been OK'ed by Jeff yet? If not please ask him. If they are OK'ed, and you need someone to apply them, please email me privately.
may they will included into final release - they contain only variables renaming to eliminate warnings
Thanks, --Beman

On Thu, Oct 23, 2008 at 9:45 AM, Ruediger Berlich < ruediger.berlich@iwr.fzk.de> wrote:
Hi there,
first of all thanks for a great beta release. I have tested it with a fairly complex application of mine, making heavy use of serialization (the core dumps reported in a recent thread on the user's list seem to be gone - great, thanks Robert :-), boost.threads, boost.asio, boost.bind, and smart pointers. I have so far run into *no major* difficulties, but will of course report issues as they arise.
*** A small, but from my point of view still significant, nuisance is that bug report 2091 doesn't appear to have been fixed, although it is easy to cure with a change of
typedef dst_adjustment_offsets<time_duration_type> dst_adjustment_offsets;
to
typedef boost::date_time::dst_adjustment_offsets<time_duration_type> dst_adjustment_offsets;
in line 161 of <BOOSTROOT>/boost/date_time/tz_db_base.hpp .
Alternatively it is possible to rename the typedef in line 161 and in the 2 or so subsequent occurances. ***
In the absence of this fix, I need to patch Boost on many recent Linux patforms (at least a current Debian Lenny and OpenSUSE 11, but likely others as well, if they have a g++ 4.3.x Compiler).\
I'll try to make sure we apply as many of these date-time patches as possible before the release, but it will be Monday or Tuesday before I get a chance to work on it. In the meantime, if anyone with write permission has date-time patches Jeff has OK'ed stable on trunk, please go ahead and merge them to branches/release. The release test reporting has started to cycle again. Thanks for the report! --Beman

Beman Dawes wrote:
1.37.0 beta 1 is available on SourceForge. See http://tinyurl.com/674rcl
Little request: could you publish the originating SVN revision (and/or tag it in SVN)? -- Genny

On Thu, Oct 23, 2008 at 1:07 PM, Gennaro Prota <gennaro.prota@yahoo.com>wrote:
Beman Dawes wrote:
1.37.0 beta 1 is available on SourceForge. See http://tinyurl.com/674rcl
Little request: could you publish the originating SVN revision (and/or tag it in SVN)?
See svn.boost.org/svn/boost/tags/release/Boost_1_37_0_beta1 I almost forgot to do the tag. I really should change the release procedure to run from the tags/release, but that only occurred to me recently and I haven't had a chance to do it. Thanks, --Beman

Beman Dawes wrote:
On Thu, Oct 23, 2008 at 1:07 PM, Gennaro Prota <gennaro.prota@yahoo.com>wrote:
Beman Dawes wrote:
1.37.0 beta 1 is available on SourceForge. See http://tinyurl.com/674rcl
Little request: could you publish the originating SVN revision (and/or tag it in SVN)?
See svn.boost.org/svn/boost/tags/release/Boost_1_37_0_beta1
Gulp! How is it possible that if I look e.g. at .../libs/dynamic_bitset/example/example3.cpp it originates from revision 40341 (=24055) under branches/release, which is from 4 years ago?? -- Genny

On Fri, Oct 24, 2008 at 11:43 AM, Gennaro Prota <gennaro.prota@yahoo.com>wrote:
Beman Dawes wrote:
On Thu, Oct 23, 2008 at 1:07 PM, Gennaro Prota <gennaro.prota@yahoo.com
wrote:
Beman Dawes wrote:
1.37.0 beta 1 is available on SourceForge. See
Little request: could you publish the originating SVN revision (and/or tag it in SVN)?
See svn.boost.org/svn/boost/tags/release/Boost_1_37_0_beta1
Gulp! How is it possible that if I look e.g. at
.../libs/dynamic_bitset/example/example3.cpp
it originates from revision 40341 (=24055) under branches/release, which is from 4 years ago??
That's how SVN works. The revision number for a file is the last revision that changed the file, IIRC. --Beman

Beman Dawes wrote: [...]
See svn.boost.org/svn/boost/tags/release/Boost_1_37_0_beta1
Gulp! How is it possible that if I look e.g. at
.../libs/dynamic_bitset/example/example3.cpp
it originates from revision 40341 (=24055) under branches/release, which is from 4 years ago??
That's how SVN works. The revision number for a file is the last revision that changed the file, IIRC.
Eh, thanks for the confidence. Except that the last revision affecting that file is 49423, from October 21 (of this year). -- Genny

On Mon, Oct 27, 2008 at 2:14 PM, Gennaro Prota <gennaro.prota@yahoo.com>wrote:
Beman Dawes wrote: [...]
See svn.boost.org/svn/boost/tags/release/Boost_1_37_0_beta1
Gulp! How is it possible that if I look e.g. at
.../libs/dynamic_bitset/example/example3.cpp
it originates from revision 40341 (=24055) under branches/release, which is from 4 years ago??
That's how SVN works. The revision number for a file is the last revision that changed the file, IIRC.
Eh, thanks for the confidence. Except that the last revision affecting that file is 49423, from October 21 (of this year).
Revision 49423 was applied on Tuesday, but the cutoff was already past and the files for the beta had already been extracted. 49408 was the last revision to make it into the beta. Just to be sure, I checked the actual content of the file at the pre-beta and post-beta revisions, and that is exactly what happened. A current checkout does pick up the 49423 changes, so they will appear in the final release. Thanks, --Beman

Hi, On Thu, Oct 23, 2008 at 08:55:15AM -0400, Beman Dawes wrote:
1.37.0 beta 1 is available on SourceForge. See http://tinyurl.com/674rcl
So you started announcing beta versions? Great, I really like this considering the errors which bothered me in the past in released versions.
The beta period will be approximately ten days. Please post bug reports to either the boost developer or user lists, but also let us hear about success stories too!
I wonder why the same problems as in previous releases occur again: Many files in the tarball have wrong permission, e.g. libs/test/doc/html/execution-monitor/compilation.html: -rwxr-xr-x Why is an HTML file marked executable? Please check either the output of "find -type f -perm +111" or the svn:executable property in the repository. ############################################################### configure cannot be called from a separate build directory: boost_1_37_0_beta1/build$ ../configure --prefix=/home/jens/local ../configure: 210: ./tools/jam/src/build.sh: not found Building Boost.Jam with toolset ... cd: 223: can't cd to ./tools/jam/src ############################################################### There are again a lot of warnings (gcc-4.3.2) which can easily be avoided. The first one: libs/program_options/src/options_description.cpp|74| warning: suggest explicit braces to avoid ambiguous ‘else’ Since I learned in the past that such patches are often ignored I do not send a patch. It's also trivially reproducable for everyone (as gcc is free). ############################################################## A minor cosmetic issue: ./configure --show-libraries shows: The following libraries require building: - date_time - filesystem - function_types [snipped] Are the dashs useful? I would prefer a more compact output. ############################################################## All my internal test cases work well with this version of Boost. But one has of course to ignore warnings in Boost's code using -isystem <path_to_boost_headers>, at least for gcc. Jens

On Mon, Oct 27, 2008 at 10:43 AM, Jens Seidel <jensseidel@users.sf.net> wrote:
###############################################################
There are again a lot of warnings (gcc-4.3.2) which can easily be avoided. The first one: libs/program_options/src/options_description.cpp|74| warning: suggest explicit braces to avoid ambiguous 'else'
Since I learned in the past that such patches are often ignored I do not send a patch. It's also trivially reproducable for everyone (as gcc is free).
##############################################################
Not sure if anyone cares but: I'm seeing this as well on FreeBSD-7.0-amd64 machine I have. There are a lot of warnings (mostly string casting which newer more stricter gcc's don't like). The good news is other than a small patch to libs/regex/build/Jamfile.v2 (adding /usr/local/lib to search path) and the setting of LD_LIBRARY_PATH within gcc.jam, beta1 built successfully on my FreeBSD machine! (and the asio networking examples seem to work just fine). This release with some minor edits will be MUCH more friendlier to the FreeBSD community for sure. I ran regression tests on it as well and it had some failures - I think. I'm still new to running them so I can't really be more specific right now. -aps

on Mon Oct 27 2008, "Alexander Sack" <pisymbol-AT-gmail.com> wrote:
On Mon, Oct 27, 2008 at 10:43 AM, Jens Seidel <jensseidel@users.sf.net> wrote:
###############################################################
There are again a lot of warnings (gcc-4.3.2) which can easily be avoided. The first one: libs/program_options/src/options_description.cpp|74| warning: suggest explicit braces to avoid ambiguous 'else'
Since I learned in the past that such patches are often ignored I do not send a patch. It's also trivially reproducable for everyone (as gcc is free).
##############################################################
Not sure if anyone cares but:
I'm seeing this as well on FreeBSD-7.0-amd64 machine I have. There are a lot of warnings (mostly string casting which newer more stricter gcc's don't like).
The good news is other than a small patch to libs/regex/build/Jamfile.v2 (adding /usr/local/lib to search path) and the setting of LD_LIBRARY_PATH within gcc.jam, beta1 built successfully on my FreeBSD machine!
Those two changes, I believe, are related and should be fixed in the Boost.Build system. Please open a Trac ticket for them at http://svn.boost.org -- Dave Abrahams BoostPro Computing http://www.boostpro.com

On Mon, Oct 27, 2008 at 6:37 PM, David Abrahams <dave@boostpro.com> wrote:
on Mon Oct 27 2008, "Alexander Sack" <pisymbol-AT-gmail.com> wrote:
On Mon, Oct 27, 2008 at 10:43 AM, Jens Seidel <jensseidel@users.sf.net> wrote:
###############################################################
There are again a lot of warnings (gcc-4.3.2) which can easily be avoided. The first one: libs/program_options/src/options_description.cpp|74| warning: suggest explicit braces to avoid ambiguous 'else'
Since I learned in the past that such patches are often ignored I do not send a patch. It's also trivially reproducable for everyone (as gcc is free).
##############################################################
Not sure if anyone cares but:
I'm seeing this as well on FreeBSD-7.0-amd64 machine I have. There are a lot of warnings (mostly string casting which newer more stricter gcc's don't like).
The good news is other than a small patch to libs/regex/build/Jamfile.v2 (adding /usr/local/lib to search path) and the setting of LD_LIBRARY_PATH within gcc.jam, beta1 built successfully on my FreeBSD machine!
Those two changes, I believe, are related and should be fixed in the Boost.Build system. Please open a Trac ticket for them at http://svn.boost.org
Dave, way AHEAD of you, opened up both with patches attached: Its 2438 and 2437 I believe. They aren't exactly related though. IF I can get these patches and the patch/bug I filed regarding the execution_monitor.ipp, boost should compile out of the box on FreeBSD 6.x-CURRENT with ease! :D -aps
participants (9)
-
Alex Ott
-
Alexander Sack
-
Andrey Semashev
-
Beman Dawes
-
David Abrahams
-
Gennaro Prota
-
Jens Seidel
-
Ruediger Berlich
-
Steve M. Robbins