- Boost - lists.boost.org

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

[Serialization] Errors when compiling using GCC 3.4
by Allen Yao 23 May '04

23 May '04

I just updated my gcc from 3.3.3 to 3.4, and found that the serialization17 and serialization18 cannot compile. There are many error messages, some of them seem to caused by lack of "typename", others are very strange, for example, about using boost::noncopyable. Does someone try serialization library on GCC 3.4? Can it be compiled? I suspect I am missing something. Otherwise, I would like to try to "fix" the "bugs" myself. Best regards.

1 0

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

23 May '04

Jeff Garland wrote: >And that's today. Consider during the next couple months 3-4 new libraries >are pending to be added. Serialization tests alone dramatically increase >the >length of the time to run the regression if we always run the full test. >What >will happen in a year when we have say 10 new libraries? > >Robert and I have believe something will need to be done. We've tried to >start a discussion, but no one responded: > >http://lists.boost.org/MailArchives/boost/msg64471.php >http://lists.boost.org/MailArchives/boost/msg64491.php I don't know how feasable this would be, but you might also want to consider library dependancies so that if you modify the iterator adaptors library you can pull a list of tests that need to be re-run because the associated libraries use iterator adaptors. This would reduce the number of tests that need to be performed on each cycle, but you'd need some way of archiving the results and only updating the ones that are re-run. When testing a new platform/compiler/configuration, you can tell the test suite to run all the tests for that setup, but for the others (where it has already been run) it will operate as above, unless an explicit request for the full set of tests is provided (allowing for, say, the full set to be performed weekly while the dependant tests are performed daily/every 12 hours). I like the idea of specifying the test level (basic, torture, concept). Regards, Reece _________________________________________________________________ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/

3 6

RE: [boost] Re: [Boost.Test] New testing procedure?
by Reece Dunn 23 May '04

23 May '04

David Abrahams wrote: >"Jeff Garland" <jeff(a)crystalclearsoftware.com> writes: > > > On Sat, 22 May 2004 13:18:41 -0400, David Abrahams wrote > >> > I like the idea of specifying the test level (basic, torture, >concept). > >> > >> I am opposed to the idea of requiring humans to initiate the right > >> tests, at least without proof that mechanically-initiated tests are > >> unworkable. I don't think we've proven that yes. > > > > They shouldn't be human initiated -- just configured to one level or >another. > > Now obviously a human would need to intervene to reset the level, but >that > > would only be in the case of ramping up to release, adding a new >library, > > adding a new compiler, or a specific author request. I believe this >would be > > rather infrequent. I was not suggesting that the basic/full tests be initiated by a human. This is what shell scripts are for: full-tests.sh and basic-tests.sh! Then tell a computer to run full-tests.sh once a week and basic-tests.sh daily. > > Basically, right now we have no way of setting up a Jamfile that can >satisfy > > the need to have full up tests for new compilers, etc and a basic set of >quick > > tests...short of replacing the Jamfile all the time. > >I don't see that as a need, or neccessarily an advantage. Only >outdated tests get run. > >That said, of course we do have a way: > > # foo.jam > > if $(Not_Defined) > { > # torture tests go here > } > >In what way is commenting out the "if" line and checking in the >jamfile significantly different from other mechanisms one might use to >alter the set of tests that get run? Is it possible to add the level as a parameter like how you can configure static/dynamic linking, e.g.: test basic : basic.cpp : <level>basic ; test complete : complete.cpp : <level>torture ; # basic-tests.sh bjam ... basic-test # full-tests.sh bjam ... full-test Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

2 2

scoped_ptr - custom deleter?
by Robert Ramey 23 May '04

23 May '04

Question: Shouldn't scoped_ptr have a constructor of the form: template<class Y, class D> scoped_ptr(Y * p, D d) where D is a custom deleter. Shared_ptr has it. I have a need for this now. This has been raised during a discussion with Martin Ecker re serialization library implementation. Robert Ramey.

1 0

any interest in a producer consumer template?
by Arash Partow 23 May '04

23 May '04

Hi all, I was wondering if there would be any interest in a template library based around producers and consumers. I've developed something already and have a series of working examples, I propose a library that consist of 3 basic entities, a producer a consumer and a hybrid entity called an interchange. the entities themselves will be threaded and will be linked together via a linking mechanism that is itself a base template but which can be extended to provide data transfer between same system processes and threads and also extended versions which provide data transfer over pipes, sockets, serial lines etc.. the idea of the producer-consumer is very simple the producer produces a type of data ie: string, a class, a struct etc.. and a consumer that is instantiated as a consumer of the type will consume the data provided by the producer and do something with it. The interchange entity is a transformation entity, it acts both as a consumer and as a producer, it consumes from a producer or another interchange, and then invokes the user implemented transmute method to convert/munge/process the data from one type to another then sends it to its consumer. Simple class syntax: template < typename OutputType // class IdleProductionPolicy = Policy class for implementing producer's //behavior during idle production periods. > class Producer : public Thread { }; template <typename InputType> class Consumer : public Thread { }; template < typename InputType, typename OutputType // template < typename > class InternalProducer possible future policy > class Interchange : public Thread { }; The link mechanism is a basically a type that supports the common type between a producer and its consumer, it is a one way flow of data, the consumer is signaled when data is ready for it to collect if its asleep it will awake and fetch the data if its doing something else when it comes back to go and wait for the condition from the producer to be signaled it will instantly be awaken and go off and fetch the data off the link. the data on the link or more precisely in the container which resides in the link is made thread safe via mutexes around the add and get methods. A link has a basic get and add functionality but depending what entity is being implemented they will only see it via an interface and hence only be able to invoke 1 kind of method, a producer can only invoke "add" where-as a consumer can only invoke a get, an interchange can invoke both because it is instantiated with both a consumer and producer link interface, but the links are separate for an interchange, because it requires 2 links, one link for the incoming data and one link for the out going data. both link maybes of different types, ie: Producer <string> ----> Interchange <string, AClass> ----> Consumer <AClass> I need some opinions, about whether or not people will find this library useful and hence have it as part of Boost, if so could people give me their opinions about my design, its just a simple first trial run at designing it, i intended for the producers and interchange entities to be policy driven as far as production of data is concerned. I think this library can be used in distributed computing, in network packet assembly, and also for interfacing and passing data up and down threaded software layers. Any advice, opinions would be very much appreciated. Kind regards Arash Partow __________________________________________________ Be one who knows what they don't know, Instead of being one who knows not what they don't know, Thinking they know everything about all things. http://www.partow.net A more detailed class syntax and usage is here: template < typename OutputType // class IdleProductionPolicy = Policy class for implementing producer's //behavior during idle production periods. > class Producer : public Thread { private: typedef vector < OutputType > TypeVector; typedef ProducerLink < OutputType > TypeLink; public: Producer(TypeLink* _link, unsigned int _minpendbufsize = MIN_PEND_BUF_SIZE, unsigned int _maxpendbufsize = MAX_PEND_BUF_SIZE, unsigned int _id = 0) { }; ~Producer(){}; unsigned int getMinPenBufferSize() { return minpendbufsize; }; unsigned int getMaxPenBufferSize() { return maxpendbufsize; }; void setMinPenBufferSize(int _minpenbufsize = MIN_PEND_BUF_SIZE) { minpendbufsize = _minpenbufsize; }; void setMaxPenBufferSize(int _maxpenbufsize = MAX_PEND_BUF_SIZE) { maxpendbufsize = _maxpenbufsize; }; virtual void setActiveMode(bool state = true) { }; protected: void add(OutputType t) {}; void add(const TypeVector& tlist) {}; virtual bool manufacture()=0; private: void execute() {}; }; template <typename InputType> class Consumer : public Thread { private: typedef vector < InputType > TypeVector; typedef ConsumerLink < InputType > TypeLink; public: Consumer(TypeLink* _link){}; ~Consumer(){}; protected: void get(TypeVector& tlist) { }; void setLink(TypeLink& _link) { }; virtual bool consume()=0; private: void execute(){}; }; template < typename InputType, typename OutputType // template < typename > class InternalProducer possible future policy > class Interchange : public Thread { public: typedef vector < InputType > ConsDataList; typedef vector < OutputType > ProdDataList; typedef ConsumerLink < InputType > ConsLink; typedef ProducerLink < OutputType > ProdLink; public: Interchange( ConsLink* _consLink, // Link from the producer entity ProdLink* _prodLink, // Link to the consumer entity unsigned int _minpendbufsize = MIN_PEND_BUF_SIZE, unsigned int _maxpendbufsize = MAX_PEND_BUF_SIZE, unsigned int _id = 0 // for debugging purposes ) { }; ~Interchange() {}; unsigned int getMinPenBufferSize() {}; unsigned int getMaxPenBufferSize() {}; void setMinPenBufferSize(int _minpenbufsize = MIN_PEND_BUF_SIZE) { }; void setMaxPenBufferSize(int _maxpenbufsize = MAX_PEND_BUF_SIZE) { }; void setActiveMode(bool state = true){}; protected: void add(OutputType t) { prodLink->add(t); }; void add(const ProdDataList& tlist) { prodLink->add(tlist); }; void get(ConsDataList& tlist) { consLink->get(tlist); }; void setConsumerLink(ConsLink& _link) { consLink = _link; }; void setProducerLink(ProdLink& _link) { prodLink = _link; }; virtual bool transmute()=0; private: void execute(){}; }; Usage would be as follows: class AClass { public: AClass(string str):val(str){} ~AClass(){}; void displa(){cout << val << endl;}; private: string val; }; class MyProducer : public Producer<string> { public: typedef ProducerLink < string > LinkType; MyProducer(LinkType* _link, int minpenbs, int maxpenpbs):Producer<string>(_link, minpenbs, maxpenpbs){}; bool manufacture() { add("abc"); return true; }; }; class MyInterchange : public Interchange<string,AClass> { public: typedef ProducerLink < string > ProdLinkType; typedef ConsumerLink < string > ConsLinkType; MyInterchange( ConsLinkType* _conslink, ProdLinkType* _prodlink, unsigned int minpenbs, unsigned int maxpenbs ):Interchange<string,string>( _conslink, _prodlink, minpenbs, maxpenbs, ){}; bool transmute() { vector <string> slist; get(slist); for(unsigned int i = 0; i < slist.size(); i++) { add(AClass(slist[i])); } add(slist); return true; }; private: }; class MyConsumer: public Consumer<AClass> { public: typedef ConsumerLink < string > LinkType; MyConsumer(LinkType* _link, int mpID):Consumer<string>(_link){}; bool consume() { vector <AClass> alist; get(alist); for(unsigned int i = 0; i < slist.size(); i++) { alist[i].display(); } return true; }; }; int main () { Link < string > link1; Link < AClass > link2; MyProducer myproducer = MyProducer(new ProducerLink <string>(&link1),10,50); MyInterchange myinterchange = MyInterchange(new ConsumerLink <string>(&link1),new ProducerLink <AClass>(&link2),1,10); MyConsumer myconsumer = MyConsumer(new ConsumerLink <AClass>(&link2)); myproducer.start(); myinterchange.start(); myconsumer.start(); while(true) { . . . } return true; }

2 2

MSDN News of the week
by Edward Diener 22 May '04

22 May '04

The news of the week at MSDN, first item, http://msdn.microsoft.com/ mentions Boost. All Boost developers can take a bow and to them I also offer my applause.

1 1