- Boost - lists.boost.org

RE: [boost] Re: White cells
by Rozental, Gennadiy 02 Aug '04

02 Aug '04

> > ######################################## > > > > local test-dir = > > "$(BOOST_ROOT)$(SLASH)libs$(SLASH)test$(SLASH)test$(SLASH)" > > ; > > > > run ifstream_line_iterator_test.cpp > <lib>../build/boost_unit_test_framework > > : #args > > : $(test-dir)test_files/ifstream_line_iterator.tst1 > > $(test-dir)test_files/ifstream_line_iterator.tst2 ; > > > > What is wrong here? > > 1. It's ugly. If I am not mistaken it was you or Beman who introduced this var, because local reference (../test or ./) did not work. > 2. I'm not certain that BOOST_ROOT will always be set (though it > probably will). I think it is. And it still unclear why it's failing then. Gennadiy.

2 1

How to test multiple versions of a library?
by Michael Glassford 02 Aug '04

02 Aug '04

Currently the Boost.Threads regression tests only test the dynamically linked version of the library. On Win32, at least, there are fairly significant differences between the dynamically linked and statically linked versions (due to thread-specific-storage cleanup), so it would be good to run at least some of the tests for both versions. How do I do this? Mike

4 4

RE: [boost] Re: White cells
by Rozental, Gennadiy 02 Aug '04

02 Aug '04

> The way libs/test/test/Jamfile refers to input files is broken. > > there should be no use of $(test-dir). > > tests are always run from the directory of the Jamfile. If this would be the case it should work, I think. Here related part of Jamfile: ######################################## local test-dir = "$(BOOST_ROOT)$(SLASH)libs$(SLASH)test$(SLASH)test$(SLASH)" ; run ifstream_line_iterator_test.cpp <lib>../build/boost_unit_test_framework : #args : $(test-dir)test_files/ifstream_line_iterator.tst1 $(test-dir)test_files/ifstream_line_iterator.tst2 ; What is wrong here? Gennadiy.

2 1

Re:Re: [thread] barrier.cpp don't compile with msvc60 & stlport]
by Robert Ramey 02 Aug '04

02 Aug '04

>cool - i use the same configuration! So every has to work ;-)) >Why does it compiles on meta-comm and not on my machine? I tried it on >two differend machines. (but both with the same stlport) >So what's different? >I use the ms-iostream - what kind of iostreams is the regressiontest using? I use msvc + stlport 4.5.3 compiled with streams and it builds the serialization library on my machine w/o problems. The daily tests show what seems to be a similar configuration which fails to build with a compile error in spirit. Sooo one or more of the following is true a) something is different - its not clear what b) spirit 1.6 - needs some sort of tweak - I'm not sure this will ever happen. c) Its really annoying to see a column of all failures knowing that the issue is fixable but not by me. Robert Ramey

3 2

Broken toolset config on Meta-Comm Darwin results?
by Jeff Garland 02 Aug '04

02 Aug '04

I'm wondering what toolset is being used for the Meta-Comm Darwin tests. Seems like there is a configuration issue for shared libraries since all the date_time dll tests fail. See http://www.meta-comm.com/engineering/boost-regression/developer/date_time.h… Also, 'gcc' doesn't really give much about the compiler being used. Based on the other failures I'm guessing a variant of 2.95.x? Note that in the other Darwin tests with gcc 3.3.x date_time passes all tests... http://boost.sourceforge.net/regression-logs/cs-Darwin.html Jeff

2 1

Boost-wide reports: Time to join in!
by Aleksey Gurtovoy 02 Aug '04

02 Aug '04

Now that we have Boost-wide reports up and running [1], I'd like to encourage all regression runners who's results are not represented there yet take a tiny bit of time to join in. The setup procedure is documented in http://tinyurl.com/4pnfd. It's very short and painless, too! It's crucial that we have an objective picture of the codebase when/before we release, and Boost-wide reports is the only instrument that is able to provide us with it. So please, join in! [1] http://www.boost.org/regression-logs/developer -- Aleksey Gurtovoy MetaCommunications Engineering

11 28

[numeric/conversion] CW8 duplicate resolution errors.
by Rene Rivera 02 Aug '04

02 Aug '04

I just put in some fixes for the following type of errors: # Error: # ambiguous access to overloaded function # 'std::log10(float)' # 'std::log10(float)' The problem was the direct use of "boost/compatibility/cpp_c_headers/cmath" instead of doing the standard "#include <cmath>"... =================================================================== RCS file: /cvsroot/boost/boost/boost/numeric/conversion/converter_policies.hpp,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- converter_policies.hpp 25 Jul 2004 16:58:06 -0000 1.2 +++ converter_policies.hpp 1 Aug 2004 16:01:18 -0000 1.3 @@ -12,7 +12,7 @@ #include <typeinfo> // for std::bad_cast -#include "boost/compatibility/cpp_c_headers/cmath" // for std::floor and std::ceil +#include <cmath> // for std::floor and std::ceil #include "boost/type_traits/is_arithmetic.hpp" =================================================================== RCS file: /cvsroot/boost/boost/libs/numeric/conversion/test/test_helpers.cpp,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- test_helpers.cpp 24 Jun 2004 11:59:25 -0000 1.1 +++ test_helpers.cpp 1 Aug 2004 16:05:07 -0000 1.2 @@ -16,7 +16,7 @@ // from the Numeric Conversions Library // // -#include "boost/compatibility/cpp_c_headers/cmath" +#include <cmath> #include "boost/limits.hpp" #include "boost/utility.hpp" =================================================================== That makes all the tests pass in CW8. This might fix other failures in other toolsets. Tests for VC7.1 and Mingw still all pass. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

2 1

RE: [boost] build_monitor.exe: a cure worse than the disease
by Victor A. Wagner Jr. 02 Aug '04

02 Aug '04

At Sunday 2004-08-01 16:37, you wrote: >Victor A. Wagner Jr. writes: > > I have NO idea what criteria build_monitor uses to killing > > processes, > >Two conditions: > >1) They have to be spawned by 'bjam.exe' executable. how do you know? >2) They have to be running for more than 5 minutes or show an > error dialog window. these other things run 100% of the time on my system. in the middle of the night they may even go for 5 minutes with NO I/O. > > but when I awoke this morning, it had managed to kill: the dnet > > "run in the background" ORG process, Pirch (my IRC client), a > > proxy that lets me get dcc's through my hardware firewall, > > Trillian (the instant message program), SpyBot resident..... > > I think you get the picture. > >How did you determine that it's build_monitor that caused all >that? While there is always a possibility of a program having bugs, >it's hard to believe that this particular one started to misbehave >all of a sudden after a year of stable work and no changes to the >source code. > > > this thing just walked through my system like a hoard of Vandals > > (or was it Visigoths). whatever > >I'm sorry to hear about the whole thing, but let's get to the roots >of it. First of all, why do you think it was build_monitor? Second, >what operating system are you running? 1) My system has run flawlessly for over a year also and two days ago was when I first installed monitoring..... the first time it ran a bunch of stuff wasn't working in the morning, but I'd been very tired when I went to bed and figured MAYBE I'd shut them down (unlikely as I _never_ _NEVER_ shut down the dnet client)...but I let it go... I made some changes to regression.py so it would work better here then manually ran the system that afternoon...no problems. I let it run automatically again overnight and "bam" all these things that are ONLY started at login time and NEVER touched by me are missing again.... the _logical_ place to look is at "what's new?"... what's new is -monitored on the test line in my script. btw, this morning I also noticed that build_monitor had it's own window open and was spewing out TONS or data to it... is that normal? I took out the teststreams test (I think) but this afternoon's run had already started... but I chose ignore when the modal dialog (may the .....) popped up. btw, tho my log clearly shows them sent to the ftp site, they're not on the website yet... the date is Sunday the time 21:30:03 in the xml file I'd be more than happy to help find this as any problems in running the regression tests will just mean less folks willing to run them. if you get back to me quickly, I can turn on the "-monitored" again... the run starts in just over 2 hours (on the 1/2 hour) (still missing teststreams at this point). 2) WinXPpro sp1 >-- >Aleksey Gurtovoy >MetaCommunications Engineering >_______________________________________________ >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"

3 3

serialization - test/compiler status
by Robert Ramey 02 Aug '04

02 Aug '04

I've been working to make changes in the serialization system to support more platforms and pass more tests. I'm approaching the end of what I can do. The following comments reflect the state of the library as I recently uploaded and so may not be reflected by the current test tables. Windows platforms from http://www.meta-comm.com/engineering/boost-regression/developer/serializatio n.html Metroworks CodeWarrior 9.2. - all test failures are related to one of the following three pending issues: a) slist test doesn't compile. The error is related to the internals of the slist implementation which I've been unable to decipher. b) link errors/warnings of replicated symbols. A number of tests - all those that use export and perhaps others generate duplicate symbol warnings for i/o streams. The generated executables also fail with unexpected messages. I suspect an issue with the compiler configuration files cwpro9.hpp for this platform. c) tests using non-intrusive serialization fail to find overload for serialization functions. (Commeau also has this problem). I suspect a compiler bug. So far I've been unable to resolve these issues and would be very appreciative if someone who has and interest and experience with this compiler would like to investigate this issues. MSVC-STLPORT a) In some environments - has a problem compiling spirit 1.6.1. I believe this has to be resolved by tweaking spirit. Borland Passes most tests - certain test failure indicate features which are not ever going to be usable on this platform - basically automatic serialization of arrays. MSVC 6.0/7.0 Pass mosts tests - certain test failure indicate features which are not ever going to be usable on this platform - basically automatic serialization of arrays. These are documented in the manual. VC 7.1 Passing 100 % VC 8.0 Small problem with compile error in library build - I'm hoping that this will build and pass 100 % Gcc 3.x Passing 100 %. Tests on platforms which don't support wide char i/o (e.g. cygwin and mingw). show failure for the related tests This is a feature of the build/bjam system and are not to be considered failures. Intel 7.1 This fails when export is used with invalid dynamic cast. This is unresolvable by me as I don't have this compiler on my system. Anyone with and interest in this compiler is invited to jump in. Intel 8.0 Passing 100 % MACOS - Darwin from http://www.meta-comm.com/engineering/boost-regression/developer/serializatio n.html Previous test results show failure with wide-char i/o. I believe I have addressed this and hoped that next results will show 100 %. Current test results suggest an issue outside my influence. The program links with messages which suggest some sort of issue related to the test_exec_monitor. I would be very appreciative if anyone else want's to take a look at this. Linux - from http://boost.sourceforge.net/regression-logs/cs-Linux/developer/serializatio n.html Gcc 3.2.3, 3.3.2, 3.3.3 Pass 100% Gcc 2.95 This system doesn't support new style streams. This might be made to work but I can't justify the effort. Gcc 2.95 - stlport This probably could be made to work without tooo much problem - but as before its hard to justify the effort given the availability of a free upgrade to gcc 3.3+. As in the case of all the stlport tests, its not clear whether or not the version of stlport is built with streams and in some case which version is being used. GCC 3.4.1 This always passed 100 % - I made and corrected an obscure error while working on other platforms. I'm hoping for 100% next time Intel 7.1 Same as above for gcc 3.4.1 Intel 8.0 Hmmmm this passes 100% in windows and I believe has passed before. This situation is much confused by the policy of frequent releases of compiler updates. We label all of these intel 8.0 even though they are not the same. This os/compiler combination exhibits problems with the array test and export. I see it as unresolvable by me. Interested parties are invited to jump in. Other platforms - from http://boost.sourceforge.net/regression-logs/ AIX This is hung up in the compilation of large mpl expression. Working around this would require access to such a compiler platform which I don't have. This will only get resolved if someone has sufficient interest/necessity to invest the required effort. HP-UX/PARISC - aCC These compiles fail to build the library. The error messages suggest that these compilers don't support enough C++ template syntax to be useable without undertaking heroic efforts and having direct access to the compiler/platrom. IRIX64 This libraries aren't being tested frequently enough to be useful for resolving problems of library implementation. I am marking these platforms unusable for the serialization library. Robert Ramey

2 1

Re:[boost] [serialization] use of iterator_facade, CW8 build
by Robert Ramey 01 Aug '04

01 Aug '04

Rene Rivera wrote: >In another painfully hunt to fix the problems with the seriazation lib >issues in CW8... I tracked the problem down to another instance of: >static_cast<const&>(x) where x is a template with template ctors. The >problem was in iterator_facade, and not directly in the serialization >lib which made it even harder to find :-( >Anyway, I applied this change (figured since this is a known problem by >now with an easy portable solution it would not be a problem)... Hats off - I know this was hard to find. BTW it didn't show up on my test machine which was running CW Pro 9 . Also it looks like someone (B. Dawes? Or perhaps the tester) modified the build so that we don't get a lot of link errors. I believe I'm making progress in understanding an issue with broken function template overloads which breaks non-intrusive serialization. We'll see. Robert Ramey

1 0