teststreams.cpp and VC8.0

I got tired of getting the exceptions so I fixed time_formatters.hpp which had a logic error in it. It's possible that the test should now be run on all platforms again. Since I don't know how to alter which tests actually run on which platforms I cannot fix that. Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

At Thursday 2004-10-28 23:42, Victor A. Wagner Jr. wrote:
I got tired of getting the exceptions so I fixed time_formatters.hpp which had a logic error in it. It's possible that the test should now be run on all platforms again. Since I don't know how to alter which tests actually run on which platforms I cannot fix that.
so I run the regression script I have.... it doesn't rebuild the vc8.0 teststreams.exe what's up? _surely_ I don't have to figure out what tests are affected by an include file change Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

On Fri, 29 Oct 2004 00:20:29 -0700, Victor A. Wagner Jr. wrote
At Thursday 2004-10-28 23:42, Victor A. Wagner Jr. wrote:
I got tired of getting the exceptions so I fixed time_formatters.hpp which had a logic error in it.
I don't see a change in CVS -- please send it to me and I will verify, test, and check in. I'm suprised you found something, b/c we've gone looking for the cause of this before and come up empty...
It's possible that the test should now be run on all platforms again. Since I don't know how to alter which tests actually run on which platforms I cannot fix that.
so I run the regression script I have.... it doesn't rebuild the vc8.0 teststreams.exe what's up?
_surely_ I don't have to figure out what tests are affected by an include file change
I don't think that the bjam dependency finding is 100% perfect. Just delete the executable -- that will force the rebuild. Jeff

At Friday 2004-10-29 08:20, you wrote:
On Fri, 29 Oct 2004 00:20:29 -0700, Victor A. Wagner Jr. wrote
At Thursday 2004-10-28 23:42, Victor A. Wagner Jr. wrote:
I got tired of getting the exceptions so I fixed time_formatters.hpp which had a logic error in it.
I don't see a change in CVS -- please send it to me and I will verify, test, and check in. I'm suprised you found something, b/c we've gone looking for the cause of this before and come up empty...
it's already checked in, and tested. Unfortunately there seems to be a serious problem in the way the regression tests are automatically being run. here's what _I_ get when I do: cvs log time_formatters.hpp ============================================================================= RCS file: /cvsroot/boost/boost/boost/date_time/posix_time/time_formatters.hpp, Working file: time_formatters.hpp head: 1.11 branch: locks: strict access list: symbolic names: RC_1_32_0: 1.11.0.4 merged_to_RC_1_32_0: 1.11 merged_to_RC_: 1.11 SPIRIT_1_6: 1.11.0.2 function_signature_patches_1_31: 1.9.0.2 minmax: 1.9 Version_1_31_0: 1.8 RC_1_31_0: 1.8.0.2 merged_to_RC_1_31_0: 1.8 Version_1_30_2: 1.3 RC_1_30_2: 1.3 Version_1_30_1: 1.3 Version_1_30_0: 1.3 merged_to_RC_1_30_0: 1.3 RC_1_30_0: 1.3.0.2 Version_1_29_0: 1.2 boost_python_llnl_: 1.2 RC_1_29_0: 1.2.0.2 keyword substitution: kv total revisions: 12; selected revisions: 12 description: ---------------------------- revision 1.11 date: 2004/07/11 18:12:25; author: az_sw_dude; state: Exp; lines: +36 -30 branches: 1.11.4; mac_fix_plus patch set for regressions from bart - 7.09 ---------------------------- revision 1.10 date: 2004/07/04 21:59:17; author: az_sw_dude; state: Exp; lines: +79 -2 added code for time input streaming ---------------------------- revision 1.9 date: 2004/02/15 16:28:07; author: az_sw_dude; state: Exp; lines: +124 -48 changes to support wide string output ---------------------------- revision 1.8 date: 2003/12/03 02:53:58; author: az_sw_dude; state: Exp; lines: +87 -79 fix tabs / formatting in source ---------------------------- revision 1.7 date: 2003/11/23 02:37:57; author: az_sw_dude; state: Exp; lines: +6 -13 license update ---------------------------- revision 1.6 date: 2003/11/05 02:38:37; author: az_sw_dude; state: Exp; lines: +2 -2 fix for failure of time_formatter regression test ---------------------------- revision 1.5 date: 2003/11/04 13:58:36; author: az_sw_dude; state: Exp; lines: +113 -51 time special values update, plus some operator additions ---------------------------- revision 1.4 date: 2003/09/08 05:32:30; author: az_sw_dude; state: Exp; lines: +32 -14 various fixes for time_duration negative handling ---------------------------- revision 1.3 date: 2002/11/02 18:17:57; author: az_sw_dude; state: Exp; lines: +41 -1 add initial version of stream output for times ---------------------------- revision 1.2 date: 2002/09/06 22:09:56; author: az_sw_dude; state: Exp; lines: +2 -2 fix tabs, add some new i/o functions ---------------------------- revision 1.1 date: 2002/08/15 18:59:16; author: az_sw_dude; state: Exp; first version -- renamed ---------------------------- revision 1.11.4.1 date: 2004/10/29 06:27:24; author: vawjr; state: Exp; lines: +7 -3 fix to the VC8.0 regrssion test. Comments in the source, this was a bug just waiting to happen as soon as some new string implementation came along. ============================================================================= Notice that it's on the RC_1_32_0 branch as that's where the regression tests get run. I believe I managed to write the change in the style of the original authors so absent someone running annotate, it will look like it's written by a "single author".
It's possible that the test should now be run on all platforms again. Since I don't know how to alter which tests actually run on which platforms I cannot fix that.
so I run the regression script I have.... it doesn't rebuild the vc8.0 teststreams.exe what's up?
_surely_ I don't have to figure out what tests are affected by an include file change
I don't think that the bjam dependency finding is 100% perfect. Just delete the executable -- that will force the rebuild.
Jeff
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

At Friday 2004-10-29 08:20, you wrote:
On Fri, 29 Oct 2004 00:20:29 -0700, Victor A. Wagner Jr. wrote
At Thursday 2004-10-28 23:42, Victor A. Wagner Jr. wrote:
I got tired of getting the exceptions so I fixed time_formatters.hpp which had a logic error in it.
I don't see a change in CVS -- please send it to me and I will verify, test, and check in. I'm suprised you found something, b/c we've gone looking for the cause of this before and come up empty...
It's possible that the test should now be run on all platforms again. Since I don't know how to alter which tests actually run on which platforms I cannot fix that.
so I run the regression script I have.... it doesn't rebuild the vc8.0 teststreams.exe what's up?
_surely_ I don't have to figure out what tests are affected by an include file change
I don't think that the bjam dependency finding is 100% perfect. Just delete the executable -- that will force the rebuild.
That would seem to be a very serious problem since the regression script doesn't automatically delete all the .exe also it doesn't compile to the same .exe I get when I go directly to the test directory and compile with VS.net2005 beta (Whidbey)
Jeff
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

At Friday 2004-10-29 11:05, you wrote:
At Friday 2004-10-29 08:20, you wrote:
On Fri, 29 Oct 2004 00:20:29 -0700, Victor A. Wagner Jr. wrote
At Thursday 2004-10-28 23:42, Victor A. Wagner Jr. wrote:
I got tired of getting the exceptions so I fixed time_formatters.hpp which had a logic error in it.
I don't see a change in CVS -- please send it to me and I will verify, test, and check in. I'm suprised you found something, b/c we've gone looking for the cause of this before and come up empty...
It's possible that the test should now be run on all platforms again. Since I don't know how to alter which tests actually run on which platforms I cannot fix that.
so I run the regression script I have.... it doesn't rebuild the vc8.0 teststreams.exe what's up?
_surely_ I don't have to figure out what tests are affected by an include file change
I don't think that the bjam dependency finding is 100% perfect. Just delete the executable -- that will force the rebuild.
That would seem to be a very serious problem since the regression script doesn't automatically delete all the .exe also it doesn't compile to the same .exe I get when I go directly to the test directory and compile with VS.net2005 beta (Whidbey)
deleting the .exe didn't help apparently one has to delete the .obj files Right now it is my belief that all the regression test results we see are extremely questionable. We have NO idea what is actually being tested. Absent some change in the testing, I certainly wouldn't sign off on a release.
Jeff
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:
That would seem to be a very serious problem since the regression script doesn't automatically delete all the .exe
It does if you don't run it in "incremental" mode, which is the default. (Talking about regression.py, not Boost.Build here). And Boost.Build deletes the exe for passed tests, unless specifically asked not to.
deleting the .exe didn't help apparently one has to delete the .obj files
Possibly because of the changes Dave did to make EXEs get deleted :-( I'm looking into it.
Right now it is my belief that all the regression test results we see are extremely questionable. We have NO idea what is actually being tested.
Absent some change in the testing, I certainly wouldn't sign off on a release.
AFAIK the major testers do clean builds, and others do clean builds once in a while. So I'd say the test results are valid, although not always up to date. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

Rene Rivera wrote:
AFAIK the major testers do clean builds, and others do clean builds once in a while. So I'd say the test results are valid, although not always up to date.
FWIW, I run the tests incrementally. (Clean builds every day are simply not affordable.) Regards, m

Rene Rivera wrote:
Victor A. Wagner Jr. wrote:
deleting the .exe didn't help apparently one has to delete the .obj files
Possibly because of the changes Dave did to make EXEs get deleted :-( I'm looking into it.
Nope, had nothing to do with that :-) It's now fixed in both HEAD and RC_1_32_0. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

AFAIK the major testers do clean builds, and others do clean builds once in a while. So I'd say the test results are valid, although not always up to date.
Although that might be the ideal, I don't believe it's the case: the True64 tests in particular take so long to run that they can pretty much only be run incrementally. John.

John Maddock wrote:
AFAIK the major testers do clean builds, and others do clean builds once in a while. So I'd say the test results are valid, although not always up to date.
Although that might be the ideal, I don't believe it's the case: the True64 tests in particular take so long to run that they can pretty much only be run incrementally.
The Tru64 tests are run once a day with a clean rebuild, both for cxx and gcc. Markus
participants (6)
-
Jeff Garland
-
John Maddock
-
Markus Schöpflin
-
Martin Wille
-
Rene Rivera
-
Victor A. Wagner Jr.