- Boost - lists.boost.org

Regression testing goes horribly wrong! (+ patch)
by Guillaume Melquiond 14 Jul '04

14 Jul '04

Hi, If you take a look at the regression logs [1], you will see a few problems. First, a lot of test types [2] are missing. The "bind" or "date-time" libraries don't have any value in the test type column. Other libraries like the "array" library do have values in this column, however. Second, the name of some "nested" libraries are wrong. For example, the "algorithm/string" is shown as "algorithm", the "numeric/conversion" and "numeric/interval" libraries are both mixed under "numeric". But the "numeric/ublas" is correctly named. Third, expected failures are not correctly shown in the advanced regression logs [3] since some library names are wrong. Fourth, some libraries are compiled in the wrong directories. Instead of being compiled in "bin/boost/libs/whatever/test/something.test", they are directly compiled in "bin/boost/status/something.test" [4]. If you run the regression tests, you will see what I mean. It's quite possible that the problems for the first three points are related to the fourth. Indeed, it seems only libraries wrongly compiled in "bin/boost/status/something.test" get to be correctly identified. It's the case for the "array" and "numeric/ublas" libraries for example. I don't understand how regression testing takes place into Boost. From my humble point of view, it is quite a mess. I didn't understand why some libraries were compiled in the wrong place; I suppose it has to do with bjam and their Jamfiles. I did however find a way to correct the first two bugs (and probably the third). The test_log.xml are indeed wrongly generated by process_jam_log. So here is a patch to process_jam_log.cpp so that it correctly generates the test_log.xml files. Unfortunately I don't understand at all some parts of this program, so I only corrected what seemed obviously wrong to me. But maybe the bugs were somewhere else and I only designed a lame workaround? Could the author of these lines shed some light on what their purpose was supposed to be? In the meantime, maybe the regression testers could clear their "bin" directory (so that all the test_log.xml are created from scratch) and apply the patch? Since Boost 1.31 is supposed to ship in less than 20 days, it would be great if the regression logs were correctly generated. Thanks. Best regards, Guillaume [1] For example, a small regression log: http://boost.sourceforge.net/regression-logs/cs-AIX.html All recent regression logs are affected. [2] "run", "compile", "compile_fail", etc [3] Some of the yellow cells should actually be gray in this log: http://boost.sourceforge.net/regression-logs/cs-win32_metacomm/developer/su… [4] For example, look at the compile line used for: http://boost.sourceforge.net/regression-logs/cs-AIX-links.html#lambda-bll_a… Index: process_jam_log.cpp =================================================================== RCS file: /cvsroot/boost/boost/tools/regression/process_jam_log.cpp,v retrieving revision 1.25 diff -u -r1.25 process_jam_log.cpp --- process_jam_log.cpp 28 Jun 2004 03:04:21 -0000 1.25 +++ process_jam_log.cpp 9 Jul 2004 17:38:59 -0000 @@ -241,11 +241,11 @@ } test_info info; - test2info_map::iterator itr( test2info.find( library_name + "/" + test_name ) ); + test2info_map::iterator itr( test2info.find( test_name ) ); if ( itr != test2info.end() ) info = itr->second; - if ( library_name.empty() ) + if ( !info.file_path.empty() ) library_name = test_path_to_library_name( info.file_path ); if ( info.type.empty() ) @@ -511,8 +511,6 @@ line.find( "\"", pos+3 )-pos-3 ); convert_path_separators( info.file_path ); if ( info.file_path.find( "libs/libs/" ) == 0 ) info.file_path.erase( 0, 5 ); - if ( test_name.find( "/" ) == string::npos ) - test_name = "/" + test_name; test2info.insert( std::make_pair( test_name, info ) ); // std::cout << test_name << ", " << info.type << ", " << info.file_path << "\n"; }

5 17

Functors and Boost::MPL
by Dan 14 Jul '04

14 Jul '04

It occurs to me that it should be possible to manage an mpl::vector of types which are actually functors. One could add functors to this list with compile time complexity and likewise call all the functors in the list with compile time complexity. Requiring none of the function pointers, class templates, or virtual functions typically used for this purpose. I think it should be easy to create the vector, but how does one construct an object of each type and call operator() on it? -Dan "The only impossible task is the task you never start"

2 1

[assign] not in status/Jamfile
by JOAQUIN LOPEZ MU?Z 14 Jul '04

14 Jul '04

Shouldn't be there an entry for this lib in status/Jamfile? The code is checked in since 2 weeks ago. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 2

Re:[boost] Re: serialization:question regarding test
by Robert Ramey 14 Jul '04

14 Jul '04

I don't see that this should be a problem. Just follow the instructions in the release notes: a) Download spirit 1.61 from SourceForge.net to a local directory. On my machine its c:/spirit161 b) Define (export) environmental variable SPIRIT_ROOT=c:/spirit161. The build/test jamfile set up is sensitive to the SPIRIT_ROOT variable and will put it in the include path for those systems that are known to require it. Right not that is msvc 6.0 and all tested borland compilers. Other compilers just work with the latest version of spirit from the CVS Tree. This works on my system without any other special adjustments other than the above. So I'm asking that the testers set up their environment as above before running the tests. I don't think that's an unreasonable request. In fact, I believe this should be seen as a vindication and demonstration of the power and flexibility of the bjam/jamfile system rather than an extra burden. Robert Ramey Dave Abrahams wrote: >"Robert Ramey" <ramey(a)rrsd.com> writes: >> It seems I've succeeded in getting my serialization project checked in. >> >> (I've held back the Jamfile in the test directory pending a tiny >> tweak) >> >> And I have a couple of questions regarding testing. > >> a) in order for libraries to be built for Borland and VC 6.0 which >> don't support Spirit 1.8 but do support spirit 1.6, the Jamfile checks >> for the environmental variable SPIRIT_ROOT and if found presumes it >> contains the root of the directory where Spirit 1.6 is located. This >> has worked well in my local environment. An environment which tests >> this library for these compilers will also need to have Spirit 1.6 >> installed and have the SPIRIT_ROOT variable set accordingly. I don't >> know who I should inform about this. >That's not going to work well in the Boost regression suite. >Tests get run against a current copy of the Boost tree, and we don't have >any provision to check out (say) an old branch of Spirit.

3 2

[1.32 release] Linux regressions
by Aleksey Gurtovoy 14 Jul '04

14 Jul '04

Everything seems to be broken due to an error in a system header -- http://tinyurl.com/5r2dh. -- Aleksey Gurtovoy MetaCommunications Engineering

2 2

Win32 regressions
by Stefan Slapeta 14 Jul '04

14 Jul '04

Is the current state of win32 regressions written down anywhere? The results on the boost site are of april! Thanks, Stefan

1 1

serialization:question regarding test
by Robert Ramey 14 Jul '04

14 Jul '04

It seems I've succeeded in getting my serialization project checked in. (I've held back the Jamfile in the test directory pending a tiny tweak) And I have a couple of questions regarding testing. a) in order for libraries to be built for Borland and VC 6.0 which don't support Spirit 1.8 but do support spirit 1.6, the Jamfile checks for the environmental variable SPIRIT_ROOT and if found presumes it contains the root of the directory where Spirit 1.6 is located. This has worked well in my local environment. An environment which tests this library for these compilers will also need to have Spirit 1.6 installed and have the SPIRIT_ROOT variable set accordingly. I don't know who I should inform about this. b) its unclear to me how to exclude certain platforms. I've been unable go get non-intrusive serialization with Commeau - much to my disappointement. This is pretty much a show-stopper for this compiler. (Other than this it seems to compile cleanly - though perhaps a tad picky with warnings). So I would like to know how to exclude Comeau from the tests. c) As currently loaded, the test programs create temporary files in the systems temporary directory. And leaves them there - I occasionally delete them in masse. It only just dawned on me that this would be very inconvenient for the test setup so I'm going to tweak the tests to remove their trash at the end. So in some case some trash may be left over but shouldn't accumulate at a large rate as before. I hope this is acceptable. Robert Ramey

4 5

Another spirit compile problem using HP aC++
by DY, JERRY U (SBCSI) 14 Jul '04

14 Jul '04

Here's another problem while compiling with aC++. This has been reported to the HP aC++ team, but in the meantime, I'm posting this fix to the list for review and for future users of Spirit for aC++. BTW, I'm a little afraid to commit changes to the repository, so quick question: If I end up committing changes that need to be backed out, can I delete that version that I committed easily? Thanks! boost/spirit/core/primitives/impl/match.ipp:101 ===old=== inline void match<nil_t>::swap(match& other) { std::swap(len, other.len); } ===new=== inline void match<nil_t>::swap(match<nil_t>& other) { std::swap(len, other.len); } -Jerry

3 2

uBLAS developers meeting ?
by Toon Knapen 14 Jul '04

14 Jul '04

I was discussing with Michael Stevens about organising a uBLAS developers meeting. And thus we decided to ask the community if 1) there would be any interest, 2) which topics people would like to discuss 3) what format would best fit, 4) and finally where and when. As for the topics (item 2), I think following list are certainly candidates: Evaluation of the design of uBLAS and discussion of future design Evaluation of the efficieny of uBLAS Syntax and ET engine Evaluation of the documentation and how to go from there. Restating the main goals of uBLAS Organisation of ublas project. overview of applications using uBLAS. As for the format I think most important are having intense discussions on the topics above. Presentations (by volunteers) could serve to initiate the dicussion on specific topics. Where and when to organise it probably depends on the interest from the developers. It seems like many active ublas-dev members are at most a few 100km from Cologne (Germany) so getting this group together could be easy in a small timeframe. But it is probably easier to discuss the 'where and when' once we have more information about 'who' would like to attend. toon

1 0

[Signals][Patch] test/ordering_test.cpp
by Juergen Hunold 14 Jul '04

14 Jul '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi ! the test in ordering_test.cpp does not use the BOOST_SIGNALS_NAMESPACE #define and therefore breaks if BOOST_SIGNALS_NAMESPACE is #defined to something else (for Qt-compatibilty, for example). The attached patch corrects this. Yours, Jürgen - -- * Dipl.-Math. Jürgen Hunold ! Institut für Verkehrswesen, Eisenbahnbau * voice: ++49 511 762-2529 ! und -betrieb, Universität Hannover * fax : ++49 511 762-3001 ! Appelstrasse 9a, D-30167 Hannover * hunold(a)ive.uni-hannover.de ! www.ive.uni-hannover.de -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA9C9gljbJ/LLrxrYRAm35AJ9nHAPPumz4xPnPa0ZjQLlfiCkaTACgx1ys o/5GVsumKIOkGkYYoeHjVco= =aTJg -----END PGP SIGNATURE-----

2 1