- Boost - lists.boost.org

Re: [boost] Re: [Boost.Test] New testing procedure?
by Robert Ramey 24 May '04

24 May '04

Jeff Garland wrote: > Well as soon as Robert wants to run the torture test he's going to get it > at all sites if he controls it via his Jamfile. So we need some > boost-wide option to define these variations. Hopefully my other email > clarifies the idea. My concern was raised base on the following scenario: a) I get things working to taste on the 3 or 4 compilers I have installed. b) I check in to CVS c) Test is run - takes a long time d) But shows some problems in the 5 compilers I don't have e) Now I start to fix stuff - more or less one compiler at a time f) Now much computer resource are used to no good purpose. I can't stop the test from running on the compilers that I know will fail anyway. g) Now my interest shifts to another compiler and a whole different set of wasted effort is done. .... q) Now everything is spiffy r) test runs - but only those tests that are dependant on something that has changed. The situation is tolerable - until something changes that changes the library - then caos from q onward the problem might be manageable if BJAM was could manage dependencies from are particular x.hpp -> y.cpp -> test.cpp. But as it is now, if one *.cpp file in the library has to be rebuilt, all the test that depend on any portion of the library have to be run. I realize this is an unrealistic hope but we're allowed to dream. So checking in a new Jamfile to customize at test is OK but it still leaves me with doing all the compilers even though I know it's a waste of time. Robert Ramey

3 2

RE: Re:[boost] [Boost.Test] New testing procedure?
by Roman Yakovenko 24 May '04

24 May '04

Aleksey Gurtovoy wrote: > a) incremental cylces, with a full rebuild once a week or > something similar > (here at Meta, for instance, are currently doing full > rebuild on every > cycle); > > b) distributed testing of libraries, with the following > merging of results > into a single report. I agree with Aleksey. I am using boost a lot in my work. So I would like to give something back. I can test CVS version of boost on WinXP + compiler of MS Visual Studio 7.1. And at home on "Fedora Core 2" gcc 3.4. The question is what should I send back? Roman

2 1

[Boost-bugs] [ boost-Support Requests-959156 ] boost for ARM platform?
by SourceForge.net 24 May '04

24 May '04

Support Requests item #959156, was opened at 2004-05-23 16:50 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=959156&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: boost for ARM platform? Initial Comment: mailto:peter.mason@dilithiumnetworks.com is writing ... Sorry if this has been discussed already, but I've only just joined. Something I'm building under an ARM toolchain/devkit requires Boost functionality, and thus needs a porting of boost to ARM platforms. I'm not even familiar with the build tools used to build Boost, so it's a daunting task. Can someone please tell me that such a port has been done already and it's available at XXX? If not, then I'd appreciate some options and guidance. Thanks in advance. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=959156&group_i… ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

2 1

wrap_stringstream status
by Gennadiy Rozental 23 May '04

23 May '04

Hi, I finished anothher round of modification in wrap_stringstream makeing it more generic (actually it now template basic_wrap_stringstream and specializations). Is there still interest in putting it uner boost/utility and do we need a fast review for it? If yes I will prepare doc page. Gennadiy.

3 6

Re:[boost] [Boost.Test] New testing procedure?
by Robert Ramey 23 May '04

23 May '04

Dave Abrahams wrote: > maybe we need to move to a > different model wherein the test library's own tests are run on a CVS > branch of the code (?) so that Gennadiy can see and deal with his > problems before they are merged into the main trunk and break > everything else? Clearly, test the test (meta-testing ?) is a special category. I needs to be staged to be tested itself before being used to test other stuff. I believe boost testing is going to be an issue in the near future do the fact that testing time is getting longer and longer and longer. I believe we will have to move to an "on demand" model for most testing while reserving "total coverage" testing for just prior to release. Although this wouldn't definitively address the issue raised it would help. As only those libraries currently being tested would suffer due to dependencies on other code. It would also save lots of time and permit test time to keep from becoming an issue. Robert Ramey

5 17

IMPLICIT_CAST macro
by Gennaro Prota 23 May '04

23 May '04

Hi, I was grep'ing for my name in the boost repository in order to update any old license reference and found the following definition in implicit_cast.hpp: // Macro for when you need a constant expression (Gennaro Prota) #define BOOST_IMPLICIT_CAST(dst_type, expr) \ ( sizeof( implicit_cast<dst_type>(expr) ) \ , \ static_cast<dst_type>(expr) \ ) This wasn't the form I submitted though, as the comma operator isn't allowed in a constant expression and I remember pointing out on this list that this was a case where it would be useful :) Maybe the above was simply copied from this post: http://lists.boost.org/MailArchives/boost/msg42102.php where I was saying that it *doesn't* work and that I had to use the check_helper<> template. Genny.

2 5

Re:[boost] Re: [Boost.Test] New testing procedure?
by Robert Ramey 23 May '04

23 May '04

David Abrahams wrote: > We currently already have a way of expressing that "known to not work on X > compiler" idea in the regression system. We could make the build > system smart about it. I haven't seen that. That would be helpful. How can I specify that its pointless to run tests on a particular compiler. Probably simpler, though, you could just put something in one of your library headers that said: > #if BOOST_WORKAROUND(compiler1) || BOOST_WORKAROUND(compiler2) || ... > # error doesn't work yet > #endif Actually I've done something similar for systems whose support for wide character i/o is insufficient. Its sort of OK but the the test show up as all failures which is slightly miss leading. At it doesn't take all that long but I'd prefer just to skip it. >> from q onward the problem might be manageable if BJAM was could manage >> dependencies from are particular x.hpp -> y.cpp -> test.cpp. > Of course it can and does. >> But as it is now, if one *.cpp file in the library has to be >> rebuilt, all the test that depend on any portion of the library have >> to be run. >Of course they should. >> I realize this is an unrealistic hope but we're allowed to dream. >I clearly don't know what you're talking about here. What I mean is: Test.cpp only depends on module1.cpp which Is in the library. The functions in module1.cpp can only be accessed by including header1.hpp in the test either directly or indirectly. Suppose module2.cpp gets recompilied. This provokes a rebuild of the library which provokes a rebuild of test.cpp and rerunning of the test. This occurs even though this isn't necessary as module1.cpp - the only module the test depends upon - hasn't changed. In other words. The dependency granularity is the library - not the modules within the library. My understanding comes from study of BJAM and observation of my system when I make a change. I would be very pleased to find out that I'm wrong about this. So let me see if I have this right. a) I can check in a different version of runtest that will set my "testing level" appropriate for the state of the library and change it as necessary. b) I can specify which compilers should be included/excluded from the test. (somehow - I don't know how yet) c) If something changes that effects any code/header module used by the library - everything is going to be rebuilt and tested regardless of the dependency of the particular test. OK - given a and b I think this can be made to work with relatively little difficulty. >From another post: >> The same set of tests should be runnable by the regression tester >> and hence associated with the column in the results table. So >> something like: >> >> VC7.1 VC7.1 VC7.1 etc >> release release debug >> dll static dll >> >> test1 Pass fail Pass >> test2 Pass Pass Pass >> ... >> >> Then basic/complete option controls the number of tests run. >That's outta hand, IMO. If it's worth having options, let's keep > them simple. The compiler_status program is a good start but I have a real need for something that can produce the table above driven by a command line configuration string. So much so that that I'm almost up for writing it myself using the current compiler_status program as a staring point. It may happen. My experience is that when I have the debug version all running spiffy, I always have some weird issue with release mode which is compiler dependent. Usually its related to the compiler/linker dropping stuff it doesn't think needs to be instantiated. In practice, once its fixed, it doesn't break until some really major change occurs. So my policy will be to run the relase mode test just once in a very long while. Robert Ramey

2 1

RE: [boost] class properties: request for promotion and/or fast review.
by Reece Dunn 23 May '04

23 May '04

Gennadiy Rozental wrote: >Hi, > >I am using simple class properties facility for some time and found it >quite >useful. Actually it's nothing fancy - simple helper classes to eliminate >repetitive setter/accessor methods (and no need for language extensions). Have you had a look at SC22/WG21/N1615 (C++ Properties -- A Library Solution) by Lois Goldthwaite (http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2004/n1615.pdf)? Regards, Reece _________________________________________________________________ Stay in touch with absent friends - get MSN Messenger http://www.msn.co.uk/messenger

2 1

Re: PING: Lambda Documentation Problem
by Stephan T. Lavavej 23 May '04

23 May '04

[Jaakko Jarvi] > for_each is the only one that takes a 'free-form' function > object. Yes, as I said, it is "special". > If side effects are allowed, I don't understand why for_each > is classified as a non-modifying sequence. It sure can modify > the elements of the sequence. What is (philosophically) > different in the way that, say, std::replace, modifies the > elements of the sequence? Because for_each() does not do the modifying, the /functor/ does the modifying. Contrast replace(), which does the modifying itself. > Do you know what Bjarne is referring to with the 'recent > standards resolution'? I have E-mailed him asking for a clarification. > The sgi STL documentation (predecessor of what is currently > in the standard) ... is wrong wrt the final Standard. > This must be the initial reason why for_each is in the > category of non-modifying sequences. It may have been that this was the intent pre-Standardization. > A DR would be in place: either explicitly mention that > side-effects (of the sort that modify the values in the > sequence) are not allowed, or move for_each to mutating algs. > Volunteer to raise that and provide wording? I don't believe that a DR is necessary given the phrasing in TC++PL, which is reasonably authoritative (though lacking Standard force). Stephan T. Lavavej

2 1

[boost.test] feature request - random order of testing
by Pavel Vozenilek 23 May '04

23 May '04

Would it be possible to add ability to execute tests in random order, instead of as they are added into suite? Example: test_suite* init_unit_test_suite(int argc, char * argv[]) { test_suite* tests = BOOST_TEST_SUITE("..."); tests->add(BOOST_TEST_CASE(&test1)); tests->add(BOOST_TEST_CASE(&test2)); return tests; } Here test1() will be always executed before test2(). This behaviour may hide errors. It would be nice to have: - possibility to say: now execute test in random order, - if error happens framework would print out seed for random, - ability set seed manualy is needed to be able to repeat problem. (If such feature is already present in library my weak reading skills didn't spot it.) /Pavel

3 4