1.31.0 has been tagged (Version_1_31_0) for release. Release candidate 3 (.zip format only) is available at www.esva.net/~beman/boost_1_31_0_rc3.zip. Please report any problems right away. This will be the final release candidate unless a really major problem is discovered. The actual release won't be until tomorrow, to give more regression tests a chance to cycle, and to give people a chance to look at RC3 Thanks, --Beman
Beman Dawes wrote:
1.31.0 has been tagged (Version_1_31_0) for release.
Release candidate 3 (.zip format only) is available at www.esva.net/~beman/boost_1_31_0_rc3.zip.
Please report any problems right away. This will be the final release candidate unless a really major problem is discovered.
On [boost-users] we have a reported problem with boost::function and MSVC 7.1: Cheenu Srinivasan wrote:
The following program throws a bad_function_call exception when compiled with VisualStudio 7.1. It happens with both boost-1.30.2 and boost_1_31_0_rc2. No problems when compiled with g++ 2.95.1 on solaris.
---- #include <boost/bind.hpp> #include <boost/function.hpp> using namespace boost; #include <iostream> using namespace std;
double f(int i, double d) { cout << "int = " << i << endl; return d; }
main() { boost::function<double (int)> bound_func = boost::bind(f, _1, 1.234); int i = 99; cout << bound_func(i) << endl; }
I don't know whether this should be considered a showstopper, but it's troubling.
Peter Dimov wrote:
On [boost-users] we have a reported problem with boost::function and MSVC 7.1:
Cheenu Srinivasan wrote:
The following program throws a bad_function_call exception when compiled with VisualStudio 7.1. It happens with both boost-1.30.2 and boost_1_31_0_rc2. No problems when compiled with g++ 2.95.1 on solaris.
[...] I was unable to reproduce the problem, though. Both 1.30.2 and 1.31.0 seem to work fine for me.
On Tue, 3 Feb 2004, Peter Dimov wrote:
Peter Dimov wrote:
On [boost-users] we have a reported problem with boost::function and MSVC 7.1:
Cheenu Srinivasan wrote:
The following program throws a bad_function_call exception when compiled with VisualStudio 7.1. It happens with both boost-1.30.2 and boost_1_31_0_rc2. No problems when compiled with g++ 2.95.1 on solaris.
[...]
I was unable to reproduce the problem, though. Both 1.30.2 and 1.31.0 seem to work fine for me.
Could someone else try this out, to see if they can reproduce the problem? Doug
Could someone else try this out, to see if they can reproduce the problem?
This isn't reproducable for me with either 1.30.2 or 1.31.0. S. ---------------------------------------------- Stefan Slapeta Vienna / Austria http://www.slapeta.com
On Tue, 3 Feb 2004, Bronek Kozicki wrote:
On Tue, 3 Feb 2004 13:33:07 -0500 (EST), Douglas Paul Gregor wrote:
Could someone else try this out, to see if they can reproduce the problem?
I cannot reproduce it, too (using boost1.31rc3 and VC71 with and without /Za switch)
Thanks to everyone who has tried this. So it looks like it might be an optimizer bug (did anyone else try with optimization on?). This probably isn't a showstopper bug if it is an optimizer problem (especially if one needs particularly high optimization settings to trigger it). I'll try to work around this problem tonight, but it won't make 1.31.0. Doug
At 10:09 AM 2/3/2004, Beman Dawes wrote:
1.31.0 has been tagged (Version_1_31_0) for release.
Release candidate 3 (.zip format only) is available at www.esva.net/~beman/boost_1_31_0_rc3.zip.
Please report any problems right away. This will be the final release candidate unless a really major problem is discovered.
The actual release won't be until tomorrow, to give more regression tests a chance to cycle, and to give people a chance to look at RC3
Ralf Grosse-Kunstleve" has kindly made RC3 available on a faster site: http://cci.lbl.gov/~rwgk/tmp/boost_1_31_0_rc3.zip He as also made a re-packed version available: http://cci.lbl.gov/~rwgk/tmp/boost_1_31_0_rc3.tar.gz Thanks Ralf! --Beman
Beman Dawes <bdawes@acm.org> writes:
At 10:09 AM 2/3/2004, Beman Dawes wrote:
1.31.0 has been tagged (Version_1_31_0) for release.
Release candidate 3 (.zip format only) is available at www.esva.net/~beman/boost_1_31_0_rc3.zip.
Please report any problems right away. This will be the final release candidate unless a really major problem is discovered.
We are running the regression on rc3, but our machine is very slow (700Mhz) and I think the results are going to be avaliable only by 10-12am today (February 04). -- Misha Bergal MetaCommunications Engineering
At 03:28 AM 2/4/2004, Misha Bergal wrote:
Beman Dawes <bdawes@acm.org> writes:
At 10:09 AM 2/3/2004, Beman Dawes wrote:
1.31.0 has been tagged (Version_1_31_0) for release.
Release candidate 3 (.zip format only) is available at www.esva.net/~beman/boost_1_31_0_rc3.zip.
Please report any problems right away. This will be the final release candidate unless a really major problem is discovered.
We are running the regression on rc3, but our machine is very slow (700Mhz) and I think the results are going to be avaliable only by 10-12am today (February 04).
I'll wait for them; they are too important to rush. --Beman
Beman Dawes <bdawes@acm.org> writes:
At 03:28 AM 2/4/2004, Misha Bergal wrote:
Beman Dawes <bdawes@acm.org> writes:
At 10:09 AM 2/3/2004, Beman Dawes wrote:
1.31.0 has been tagged (Version_1_31_0) for release.
Release candidate 3 (.zip format only) is available at www.esva.net/~beman/boost_1_31_0_rc3.zip.
Please report any problems right away. This will be the final release candidate unless a really major problem is discovered.
We are running the regression on rc3, but our machine is very slow (700Mhz) and I think the results are going to be avaliable only by 10-12am today (February 04).
I'll wait for them; they are too important to rush.
Done. See http://tinyurl.com/ytbpz. Comparison (visualy) with last rc_1_31_0 results (http://tinyurl.com/3d7aj) shows the regression on utility - operators_test / msvc-stlport graph - bfs / vc7.1 I cannot say the exact reason for their failure, but for me they are not showstoppers. -- Misha Bergal MetaCommunications Engineering
Misha Bergal wrote:
utility - operators_test / msvc-stlport
The regressions for 1.31.0-rc3 posted at <http://tinyurl.com/3fde7> looked good, as did the other regression tests for RC_1_31_0 and HEAD. Any idea what happened? -- Daniel Frey aixigo AG - financial solutions & technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: daniel.frey@aixigo.de, web: http://www.aixigo.de
Daniel Frey <daniel.frey@aixigo.de> writes:
Misha Bergal wrote:
utility - operators_test / msvc-stlport
The regressions for 1.31.0-rc3 posted at <http://tinyurl.com/3fde7> looked good, as did the other regression tests for RC_1_31_0 and HEAD. Any idea what happened?
I don't have a definite answer. One probable cause is that the regressions for 1.31.0-rc3 and RC_1_31_0 were run on different machines. The crucial difference might be in that the machine which ran 1.31.0-rc3 is significanly slower. Our build monitor is programmed to terminate any test which runs for more than 100 seconds. And that's what might have happened with this test. -- Misha Bergal MetaCommunications Engineering
Misha Bergal wrote:
Daniel Frey <daniel.frey@aixigo.de> writes:
Misha Bergal wrote:
utility - operators_test / msvc-stlport
The regressions for 1.31.0-rc3 posted at <http://tinyurl.com/3fde7> looked good, as did the other regression tests for RC_1_31_0 and HEAD. Any idea what happened?
I don't have a definite answer. One probable cause is that the regressions for 1.31.0-rc3 and RC_1_31_0 were run on different machines.
The crucial difference might be in that the machine which ran 1.31.0-rc3 is significanly slower. Our build monitor is programmed to terminate any test which runs for more than 100 seconds. And that's what might have happened with this test.
OK, so I think we should keep an eye on it whether or not it happens again. If the test needs to be split up into smaller chunks to run faster, let me know. Regards, Daniel -- Daniel Frey aixigo AG - financial solutions & technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: daniel.frey@aixigo.de, web: http://www.aixigo.de
At 10:58 PM 2/5/2004, Misha Bergal wrote:
Our build monitor is programmed to terminate any test which runs for more than 100 seconds.
We need Boost.Build options to report build time and test time. That would help debug test issues like this, would aid regression testers, and could be interesting information it its own right. --Beman
Beman Dawes wrote:
1.31.0 has been tagged (Version_1_31_0) for release.
Release candidate 3 (.zip format only) is available at www.esva.net/~beman/boost_1_31_0_rc3.zip.
Please report any problems right away. This will be the final release candidate unless a really major problem is discovered.
The actual release won't be until tomorrow, to give more regression tests a chance to cycle, and to give people a chance to look at RC3
Not exacly showstopping but here are some suggestions for potential inclusion in future boost distributions, based on running on IRIX with MIPSPro compilers. IRIX 'sh' doesn't like scripts with non UNIX line endings! (extracted from the tar.gz, although RC2 the zip file also has the same issue) Shipping a 'tar' will generally mean that the UNIX scripts should be executable add the following to make MIPSPro the default for IRIX rather than gcc when building bjam --- boost_1_31_0_rc3/tools/build/jam_src/build.sh Wed Feb 4 14:29:47 2004 +++ boost_1_31_0_rc3/tools/build/jam_src/build_patched.sh Wed Feb 4 14:23:57 2004 @@ -63,6 +63,8 @@ Guess_Toolset () { if test_uname Darwin ; then BOOST_JAM_TOOLSET=darwin + elif test_uname IRIX ; then BOOST_JAM_TOOLSET=mipspro + elif test_uname IRIX64 ; then BOOST_JAM_TOOLSET=mipspro elif test_path gcc ; then BOOST_JAM_TOOLSET=gcc elif test_path icc ; then BOOST_JAM_TOOLSET=intel-linux elif test -r /opt/intel/compiler70/ia32/bin/iccvars.sh ; then Thanks Kevin -- | Kevin Wheatley | These are the opinions of | | Senior Do-er of Technical Things | nobody and are not shared | | Cinesite (Europe) Ltd | by my employers |
--- Kevin Wheatley <hxpro@cinesite.co.uk> wrote:
IRIX 'sh' doesn't like scripts with non UNIX line endings! (extracted from the tar.gz, although RC2 the zip file also has the same issue)
I assume you are using the tar file that I made yesterday. To be minimally intrusive I didn't change the line endings from DOS to UNIX format. I just wanted to help UNIX users who don't have unzip to get started. IIUC Beman will convert the line endings to UNIX format when making the tar file for the final release. This should resolve your problem with sh. Ralf __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/
At 12:34 PM 2/4/2004, Ralf W. Grosse-Kunstleve wrote:
--- Kevin Wheatley <hxpro@cinesite.co.uk> wrote:
IRIX 'sh' doesn't like scripts with non UNIX line endings! (extracted from the tar.gz, although RC2 the zip file also has the same issue)
I assume you are using the tar file that I made yesterday. To be minimally intrusive I didn't change the line endings from DOS to UNIX format. I just wanted to help UNIX users who don't have unzip to get started. IIUC Beman
will convert the line endings to UNIX format when making the tar file for the final release...
Yes. In the future perhaps we should put up release candidates with both line endings. The reason I'm hesitant to do that is simply that I only have an ISDN Internet connection, so those big downloads and uploads are a trial. It is getting more and more frustrating. The phone company has actually installed DSL in the central office and run fiber to near my home/office, but for unfathomable reasons isn't providing DSL service to my neighborhood. A phone company employee stopped by the other day to tell me how wonderful his DSL service was - he lives on the other side of town and got it at his house last fall. I'm surprised I didn't strangle him. Anyhow, the release candidate experiment seems to have been a success, so we will expand it to UNIX-style line endings next time around. --Beman
Beman wrote:
It is getting more and more frustrating. The phone company has actually installed DSL in the central office and run fiber to near my home/office, but for unfathomable reasons isn't providing DSL service to my neighborhood. A phone company employee stopped by the other day to tell me how wonderful his DSL service was - he lives on the other side of town and got it at his house last fall. I'm surprised I didn't strangle him.
Maybe you realized the negative effect that would have had on the credibility of Boost, as a community and library, and on the chances of getting those nifty functional constructs incorporated in the next C++ Standard Library? Killer constructs would carry an all-too-verbatim semantics... You cannot run dual ISDN? That have helped my frustration at times (I know have cable access.) /David
Kevin Wheatley wrote:
add the following to make MIPSPro the default for IRIX rather than gcc when building bjam
--- boost_1_31_0_rc3/tools/build/jam_src/build.sh Wed Feb 4 14:29:47 2004 +++ boost_1_31_0_rc3/tools/build/jam_src/build_patched.sh Wed Feb 4 14:23:57 2004 @@ -63,6 +63,8 @@ Guess_Toolset () { if test_uname Darwin ; then BOOST_JAM_TOOLSET=darwin + elif test_uname IRIX ; then BOOST_JAM_TOOLSET=mipspro + elif test_uname IRIX64 ; then BOOST_JAM_TOOLSET=mipspro elif test_path gcc ; then BOOST_JAM_TOOLSET=gcc elif test_path icc ; then BOOST_JAM_TOOLSET=intel-linux elif test -r /opt/intel/compiler70/ia32/bin/iccvars.sh ; then
Thanks
Thank you for that... I will add those ASAP. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
participants (11)
-
Beman Dawes -
Bronek Kozicki -
Daniel Frey -
David Bergman -
Douglas Paul Gregor -
Kevin Wheatley -
Misha Bergal -
Peter Dimov -
Ralf W. Grosse-Kunstleve -
Rene Rivera -
Stefan Slapeta