[1.33.0] Regression test status
The following summarizes the regression test status of each of the Boost libraries. We're doing well, but there are still quite a few libraries with outstanding failures. I've listed those libraries here along with the compilers/platforms on which they are failing. May is half-way finished: I hope to stabilize by the end of the month for release. Lots of failures: iostreams (vc-7_1, vc-8_0, mingw-3_4_2, borland-5_6_4, gcc-3_3-darwin, gcc-2.95.3-linux, gcc-2.95.3-stlport-4.5.3-linux, gcc-3.3.5-linux, gcc-3.4.3-linux, intel-8.1-linux). numeric/ublas (all compilers fail test4, test5) parameter (vc-7_1, borland-5_6_4, cw-8_3, msvc-stlport, vc7, msvc, gcc-2.95.3-linux, gcc-2.95.3-stlport-4.5.3-linux) program_options (borland-5_6_4, vc7, gcc-3_3-darwin, intel-8.1-linux) ptr_container (borland-5_6_4, cw-8_3, msvc-stlport, vc7, msvc, gcc-2.95.3-linux, gcc-2.95.3-stlport-4.5.3-linux, vcc-3.4.3-linux) range (vc-7_1, vc-8_0, borland-5_6_4, gcc-2.95.3-linux, gcc-2.95.3-stlport-4.5.3-linux, gcc-3.3.5-linux, gcc-3.4.3-linux) serialization (most compilers fail something) test (every compiler fails something) A few failures: algorithm/string (vc7, cw-8.3) date_time graph (vc-8_0) integer (msvc) iterator (borland-5_6_4) math (cw-9_4) multi_index (msvc) pool (borland-5_6_4) python (vc-8_0, msvc-stlport, vc7, gcc-3_3-darwin) random (gcc-3_3-darwin, gcc-2.95.3-linux, gcc-2.95.3-stlport-4.5.3-linux) regex (borland-5_6_4, msvc-stlport, vc7, msvc, gcc-2.95.3, gcc-2.95.3-stlport-4.5.3-linux) spirit (cw-8_3, gcc-3_3-darwin on multiprocessor machines) thread (cw-9_4, msvc-stlport, msvc) utility (call_traits_test on msvc-stlport, vc7, msvc) wave (cw-8_3) Libraries that with no failures: algorithm/minmax any array assign bind concept_check config conversion crc disjoint_sets filesystem format function functional functional/hash io lambda logic math mpl multiarray numeric/conversion numeric/interval optional preprocessor rational signals smart_ptr static_assert timer tokenizer tuple type_traits variant Doug
I've been taking a whack at the problems that show up on gcc-3_3-darwin. On May 14, 2005, at 12:22 PM, Douglas Gregor wrote:
program_options (borland-5_6_4, vc7, gcc-3_3-darwin, intel-8.1-linux)
The unicode_test_dll failure on Darwin is really, really strange. Everything is fine with static linking, but conversion inexplicably fail when we link dynamically. Attempts to debug this failed miserably :(
mpl (gcc-3_3-darwin)
Fixed.
random (gcc-3_3-darwin, gcc-2.95.3-linux, gcc-2.95.3-stlport-4.5.3-linux)
Fixed.
spirit (cw-8_3, gcc-3_3-darwin on multiprocessor machines)
This fails on Darwin for multiprocessor systems but is fine on uniprocessor systems, which seems to indicate some kind of race condition, although I can't tell if it's in the Thread library or the test itself. However, I'm looking at boost/spirit/core/non_terminal/impl/object_with_id.ipp and I'm a bit concerned about the static mutex in object_with_base_id::acquire_object_id, for two reasons: 1) It's inline, so we're relying on the compilers to be good about generating only one mutex. 2) Static initialization is not necessarily thread-safe, so two threads could conceivably initialize it at precisely the same moment, and might explain the error we're seeing. When I get back to my multiprocessor Darwin machine, I'll see if there's a workaround. Doug
Douglas Gregor wrote:
I've been taking a whack at the problems that show up on gcc-3_3-darwin.
On May 14, 2005, at 12:22 PM, Douglas Gregor wrote:
program_options (borland-5_6_4, vc7, gcc-3_3-darwin, intel-8.1-linux)
The unicode_test_dll failure on Darwin is really, really strange. Everything is fine with static linking, but conversion inexplicably fail when we link dynamically. Attempts to debug this failed miserably :(
Bad. Unless some Darwin expert knows what's going on all I can do is mark failures as expected. Maybe there debug version of the standard library, but even if there is, debugging this might be hard. - Volodya
Douglas Gregor wrote:
parameter (cw-8_3)
OK.. I really need to get that one working.. Really want to use the parameter library.
ptr_container (cw-8_3)
I though I had fixed that.. And yes I had.. The code involved changed again.. Looking at it again.
test (cw-8_3)
I looked at this earlier in the week. CW-8.3 has real problems with the environment var code. The compiler crashes, as in segfault, during the parsing of some parts of the code. Which code is context dependent.
algorithm/string (cw-8_3) date_time (cw-8_3)
Investigating.
spirit (cw-8_3)
This is not directly a problem in spirit. But the problem I've mentioned elsewhere with BOOST_STATIC_ASSERT. It can be worked around if we are willing to have a BOOST_STATIC_ASSERT_IN_FUNCTION.
thread (cw-9_4)
I think that needs markup to say the same as for cw-8_3, that it's not implemented for the compiler.
wave (cw-8_3)
Hmm.. strange one. -- -- 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 Sat, 14 May 2005 16:26:04 -0500, Rene Rivera wrote
algorithm/string (cw-8_3) date_time (cw-8_3)
Investigating.
String or date-time? I've marked the rest of the failures for 8_3 as expected -- don't think it's really worth spending much time on this old compiler. All the features from date-time 1.32 should work equivalently with 1.33 and most of the new features are working. Most of the marked failures are the locale/dll problem. OTOH, i've checked in a change to hopefully resolve a batch of the cw-9_5 regressions -- I may ask you for a hand if i can't resolve them by guessing over the next few days... Jeff
Jeff Garland wrote:
On Sat, 14 May 2005 16:26:04 -0500, Rene Rivera wrote
algorithm/string (cw-8_3)
date_time (cw-8_3)
Investigating.
String or date-time?
Both.
I've marked the rest of the failures for 8_3 as expected -- don't think it's really worth spending much time on this old compiler.
It's one of the ones I use.. Hence why I spend time one it ;-) But Marking them as expected would be what I would have most likely ended up doing. -- -- 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
Rene Rivera wrote:
Douglas Gregor wrote:
ptr_container (cw-8_3)
I though I had fixed that.. And yes I had.. The code involved changed again.. Looking at it again.
Fixed again. -- -- 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
Rene Rivera wrote:
Douglas Gregor wrote:
algorithm/string (cw-8_3)
Investigating.
Fixed. -- -- 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
Rene Rivera wrote:
Douglas Gregor wrote:
parameter (cw-8_3)
OK.. I really need to get that one working.. Really want to use the parameter library.
Fixed. But... The basic problem is that CW-8.3 is one of those compilers that doesn't support boost::result_of. There appears to be an existing work around for this situation in boost/parameter/aux_/result_of0.hpp, but it was disabled. What I don't know is if it was intentional or not, as all I did was change the namespace "aux_" to "aux" to enable the use of the work around. Was this intentional? AFAICT this affects these testers: sunpro-5_3-sunos, borland-5_6_4, cw-8_3, msvc-stlport, vc7, msvc. -- -- 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
Rene Rivera <grafik.list@redshift-software.com> writes:
Rene Rivera wrote:
Douglas Gregor wrote:
parameter (cw-8_3) OK.. I really need to get that one working.. Really want to use the parameter library.
Fixed. But...
The basic problem is that CW-8.3 is one of those compilers that doesn't support boost::result_of. There appears to be an existing work around for this situation in boost/parameter/aux_/result_of0.hpp, but it was disabled. What I don't know is if it was intentional or not, as all I did was change the namespace "aux_" to "aux" to enable the use of the work around. Was this intentional?
No, that was a last-minute typo. It should have always said "aux." Thanks for the fix! -- Dave Abrahams Boost Consulting www.boost-consulting.com
Douglas Gregor <doug.gregor@gmail.com> writes:
parameter (vc-7_1, borland-5_6_4, cw-8_3, msvc-stlport, vc7, msvc,
Hopefully most of these are fixed now.
A few failures:
python (vc-8_0 gcc-3_3-darwin dmc-stlport
These are all configuration errors. The testers should check their configuration variables. Unfortunately I don't know how to see the commands they used to invoke bjam or their environment variables
msvc-stlport, vc7
Not sure what's up with these; I'll look into it. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On May 15, 2005, at 5:23 AM, David Abrahams wrote:
Douglas Gregor <doug.gregor@gmail.com> writes:
parameter (vc-7_1, borland-5_6_4, cw-8_3, msvc-stlport, vc7, msvc,
Hopefully most of these are fixed now.
A few failures:
python (vc-8_0 gcc-3_3-darwin dmc-stlport
These are all configuration errors. The testers should check their configuration variables. Unfortunately I don't know how to see the commands they used to invoke bjam or their environment variables
I believe I've fixed the configuration on OSL's gcc-3_3-darwin. Updated regression results in a few hours... Doug
At 03:23 2005-05-15, David Abrahams wrote:
Douglas Gregor <doug.gregor@gmail.com> writes:
parameter (vc-7_1, borland-5_6_4, cw-8_3, msvc-stlport, vc7, msvc,
Hopefully most of these are fixed now.
A few failures:
python (vc-8_0 gcc-3_3-darwin dmc-stlport
These are all configuration errors. The testers should check their configuration variables. Unfortunately I don't know how to see the commands they used to invoke bjam or their environment variables
PYTHON_ROOT=C:\Python24 PYTHON_VERSION=2.4 and as I commented previously, I cannot run args.py C:\Projects\boost\libs\python\test>python args.py running... ********************************************************************** File "args.py", line 5, in __main__ Failed example: from args_ext import * Exception raised: Traceback (most recent call last): File "C:\Python24\lib\doctest.py", line 1243, in __run compileflags, 1) in test.globs File "<doctest __main__[0]>", line 1, in ? from args_ext import * ImportError: No module named args_ext and on and on and on for many of the lines bounded by the """ ..... """ If I remove what appear to be comments, it runs fine C:\Projects\boost\libs\python\test>python argsnocomments.py running... Done. the entire contents, then, is: C:\Projects\boost\libs\python\test>type argsnocomments.py # Copyright David Abrahams 2004. Distributed under the Boost # Software License, Version 1.0. (See accompanying # file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) def run(args = None): import sys import doctest if args is not None: sys.argv = args return doctest.testmod(sys.modules.get(__name__)) if __name__ == '__main__': print "running..." import sys status = run()[0] if (status == 0): print "Done." sys.exit(status)
msvc-stlport, vc7
Not sure what's up with these; I'll look into it.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
_______________________________________________ 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"
"Victor A. Wagner Jr." <vawjr@rudbek.com> writes:
At 03:23 2005-05-15, David Abrahams wrote:
Douglas Gregor <doug.gregor@gmail.com> writes:
parameter (vc-7_1, borland-5_6_4, cw-8_3, msvc-stlport, vc7, msvc,
Hopefully most of these are fixed now.
A few failures:
python (vc-8_0 gcc-3_3-darwin dmc-stlport
These are all configuration errors. The testers should check their configuration variables. Unfortunately I don't know how to see the commands they used to invoke bjam or their environment variables
PYTHON_ROOT=C:\Python24 PYTHON_VERSION=2.4
and as I commented previously, I cannot run args.py C:\Projects\boost\libs\python\test>python args.py running... ********************************************************************** File "args.py", line 5, in __main__ Failed example: from args_ext import * Exception raised: Traceback (most recent call last): File "C:\Python24\lib\doctest.py", line 1243, in __run compileflags, 1) in test.globs File "<doctest __main__[0]>", line 1, in ? from args_ext import * ImportError: No module named args_ext
and on and on and on for many of the lines bounded by the """ ..... """ If I remove what appear to be comments, it runs fine
Not a big surprise. Those aren't comments; those are the test cases ;-) """ ... """ is just one way of writing strings in Python. Strings on the first line of a function body become documentation, but this string is not that. The problem is that one of the DLL dependencies of the .pyd file (really a dynamically loaded DLL) that gets built is not in the PATH. For VC8 there's a horrible problem finding MSVC80P.DLL. See http://forums.microsoft.com/msdn/ShowPost.aspx?PostID=9805 for more information. I managed to get things to build by tracking down the file and doing the build explicitly and doing set PATH=c:/windows/WinSxS/x86_Microsoft.VC80.DebugCRT_1fc8b3b9a1e18e3b_8.0.50215.4652_x-ww_a12cf373/;%PATH% before firing up bjam. Of course, it will probably be in some other subdirectory of C:\Windows\WinSxS on your machine. HTH, -- Dave Abrahams Boost Consulting www.boost-consulting.com
At 15:32 2005-05-15, you wrote:
"Victor A. Wagner Jr." <vawjr@rudbek.com> writes:
At 03:23 2005-05-15, David Abrahams wrote:
Douglas Gregor <doug.gregor@gmail.com> writes:
parameter (vc-7_1, borland-5_6_4, cw-8_3, msvc-stlport, vc7, msvc,
Hopefully most of these are fixed now.
A few failures:
python (vc-8_0 gcc-3_3-darwin dmc-stlport
These are all configuration errors. The testers should check their configuration variables. Unfortunately I don't know how to see the commands they used to invoke bjam or their environment variables
PYTHON_ROOT=C:\Python24 PYTHON_VERSION=2.4
and as I commented previously, I cannot run args.py C:\Projects\boost\libs\python\test>python args.py running... ********************************************************************** File "args.py", line 5, in __main__ Failed example: from args_ext import * Exception raised: Traceback (most recent call last): File "C:\Python24\lib\doctest.py", line 1243, in __run compileflags, 1) in test.globs File "<doctest __main__[0]>", line 1, in ? from args_ext import * ImportError: No module named args_ext
and on and on and on for many of the lines bounded by the """ ..... """ If I remove what appear to be comments, it runs fine
Not a big surprise. Those aren't comments; those are the test cases ;-)
""" ... """
is just one way of writing strings in Python. Strings on the first line of a function body become documentation, but this string is not that.
The problem is that one of the DLL dependencies of the .pyd file (really a dynamically loaded DLL) that gets built is not in the PATH. For VC8 there's a horrible problem finding MSVC80P.DLL. See http://forums.microsoft.com/msdn/ShowPost.aspx?PostID=9805 for more information. I managed to get things to build by tracking down the file and doing the build explicitly and doing
set PATH=c:/windows/WinSxS/x86_Microsoft.VC80.DebugCRT_1fc8b3b9a1e18e3b_8.0.50215.4652_x-ww_a12cf373/;%PATH%
before firing up bjam. Of course, it will probably be in some other subdirectory of C:\Windows\WinSxS on your machine.
I added C:\WINDOWS\WinSxS\x86_Microsoft.VC80.DebugCRT_1fc8b3b9a1e18e3b_8.0.50215.4652_x-ww_a12cf373 to my system path (so all users would access it) and it apparently made no difference in my tests yes, I looked fro the file and pasted the directory name in rather than using the one that worked on your machine, apparently it's in the same place on mine.
HTH, -- Dave Abrahams Boost Consulting www.boost-consulting.com
_______________________________________________ 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"
"Victor A. Wagner Jr." <vawjr@rudbek.com> writes:
The problem is that one of the DLL dependencies of the .pyd file (really a dynamically loaded DLL) that gets built is not in the PATH. For VC8 there's a horrible problem finding MSVC80P.DLL. See http://forums.microsoft.com/msdn/ShowPost.aspx?PostID=9805 for more information. I managed to get things to build by tracking down the file and doing the build explicitly and doing
set PATH=c:/windows/WinSxS/x86_Microsoft.VC80.DebugCRT_1fc8b3b9a1e18e3b_8.0.50215.4652_x-ww_a12cf373/;%PATH%
before firing up bjam. Of course, it will probably be in some other subdirectory of C:\Windows\WinSxS on your machine.
I added C:\WINDOWS\WinSxS\x86_Microsoft.VC80.DebugCRT_1fc8b3b9a1e18e3b_8.0.50215.4652_x-ww_a12cf373 to my system path (so all users would access it) and it apparently made no difference in my tests yes, I looked fro the file and pasted the directory name in rather than using the one that worked on your machine, apparently it's in the same place on mine.
In that case I suggest you use "depends" on the .pyd file to track down what other DLL dependencies it may have acquired, and put them in the path. The way I actually verified this for myself was to download a utility called NTFileMon that logs all filesystem activity. You can filter out apps other than Python and actually watch the system looking for all the DLL dependencies as it fails. If you don't want to use bjam to launch it, all you need to do is do the environment setup that bjam is doing and then invoke: python -c "import args_ext" HTH, -- Dave Abrahams Boost Consulting www.boost-consulting.com
"Victor A. Wagner Jr." <vawjr@rudbek.com> writes:
before firing up bjam. Of course, it will probably be in some other subdirectory of C:\Windows\WinSxS on your machine.
I added C:\WINDOWS\WinSxS\x86_Microsoft.VC80.DebugCRT_1fc8b3b9a1e18e3b_8.0.50215.4652_x-ww_a12cf373 to my system path (so all users would access it) and it apparently made no difference in my tests yes, I looked fro the file and pasted the directory name in rather than using the one that worked on your machine, apparently it's in the same place on mine.
The problem should be solved now, after going around and around with Martyn Lovell, Microsoft's libraries lead, for a couple of days (thanks, Martyn!) A new build step is required when creating DLLs from the command-line, having something to do with "manifests." You can read all about it here: http://msdn2.microsoft.com/library/bxf4ee9f(en-us,vs.80).aspx I have integrated the neccessary steps into BBv1, and will try to do the same with BBv2 ASAP. -- Dave Abrahams Boost Consulting www.boost-consulting.com
At 13:14 2005-05-21, David Abrahams wrote:
"Victor A. Wagner Jr." <vawjr@rudbek.com> writes:
before firing up bjam. Of course, it will probably be in some other subdirectory of C:\Windows\WinSxS on your machine.
I added
C:\WINDOWS\WinSxS\x86_Microsoft.VC80.DebugCRT_1fc8b3b9a1e18e3b_8.0.50215.4652_x-ww_a12cf373
to my system path (so all users would access it) and it apparently made no difference in my tests yes, I looked fro the file and pasted the directory name in rather than using the one that worked on your machine, apparently it's in the same place on mine.
The problem should be solved now, after going around and around with Martyn Lovell, Microsoft's libraries lead, for a couple of days (thanks, Martyn!)
very cool, my next scheduled run starts in 45 minutes
A new build step is required when creating DLLs from the command-line, having something to do with "manifests." You can read all about it here: http://msdn2.microsoft.com/library/bxf4ee9f(en-us,vs.80).aspx
I have integrated the neccessary steps into BBv1, and will try to do the same with BBv2 ASAP.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
_______________________________________________ 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"
participants (6)
-
David Abrahams -
Douglas Gregor -
Jeff Garland -
Rene Rivera -
Victor A. Wagner Jr. -
Vladimir Prus