- Pharo-dev - lists.pharo.org

[Pharo-project] Status of Alien FFI in windows Re: plan for 1.1

by Mariano Martinez Peck

So...which is the status of Alien FFI ? I remember Marco Schmidt did the first work of running FFI in windows...then I think David was integrating such changes in VMMaker.. so, it is ready ? can be generate the plugin using VMMaker for winwows and it just works? Thanks for any update Mariano 2010/5/26 Guillermo Polito <guillermopolito(a)gmail.com> > Where can I read something about Alien? I can give a little hand for the > windows part :). > > > On Wed, May 26, 2010 at 11:12 AM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>wrote: > >> Stef, >> >> I am more concerned about Alien on Linux, which is not working. Beyond >> that, I want to learn more about how to make calls using Alien; the more I >> read, the more I have my doubts about its ease of use. I will gladly eat >> those words if it's easy to use. >> >> Bill >> >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [ >> pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane >> Ducasse [stephane.ducasse(a)inria.fr] >> Sent: Wednesday, May 26, 2010 10:04 AM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] plan for 1.1 >> >> yes this is good point. >> I would like to have alien or ffi in 1.1. Now I do not know the status of >> Alien on windows. >> >> On May 26, 2010, at 2:52 PM, Schwab,Wilhelm K wrote: >> >> > Stef, >> > >> > My initial reaction to 1.1's approaching release was "where are the >> callbacks/aliens?" Sig appears to be offering some competition to Alien. >> If he/we can provide a comprehensive and convenient way to make calls, do >> callbacks, additionally put calls onto other OS threads, and do all of this >> on the three major platforms, then it could easily turn out the best option >> for external interfacing. >> > >> > I am happy to see us take time to get it right. My only concern would >> be that we not fall into a pattern of leaving out the difficult things that >> we set out to accomplish with a given release. Since 1.1 is approaching >> releasable form and FFI/Alien/NB is unclear at present, a release makes >> sense. >> > >> > Short answer: sure, whatever you say :) >> > >> > Bill >> > >> > >> > ________________________________________ >> > From: pharo-project-bounces(a)lists.gforge.inria.fr [ >> pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane >> Ducasse [stephane.ducasse(a)inria.fr] >> > Sent: Wednesday, May 26, 2010 4:20 AM >> > To: Pharo Development >> > Subject: [Pharo-project] plan for 1.1 >> > >> > Hi guys >> > >> > we were discussing how we can handle 1.1 and the flux of good changes. >> > Here is the proposal: >> > we take two or three weeks to let people try their code in 1.1 >> beta >> > we integrate fixes that are important or easy >> > then we wait one week >> > then we launch 1.1 rc and 1.2 unstable >> > >> > does this plan look ok for you? >> > The key point is that we want to avoid to have a pile of changes pending >> because they can rot easily. >> > >> > Stef >> > _______________________________________________ >> > Pharo-project mailing list >> > Pharo-project(a)lists.gforge.inria.fr >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >> > _______________________________________________ >> > Pharo-project mailing list >> > Pharo-project(a)lists.gforge.inria.fr >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 31, 2010

Re: [Pharo-project] Drag&drop a method, remove the method

by Mariano Martinez Peck

On Fri, May 28, 2010 at 7:40 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > >> > <OT> > >> > Now that we are talking about OB and drag and drop, can I tell you my > >> > dream? > >> > I would LOVE to be able to drag a method to the "instance" and "class" > >> > buttons to change methods from one side to the other one without > having > >> > to > >> > use RB. > >> > I have no idea if it is possible nor the cost of it, I just express > my > >> > wishes ;) > >> > </OT> > >> > >> That's difficult to do, not impossible though. > >> > > > > Ok :( > > Thanks anyway. > > Name: OB-Morphic-lr.125 > Author: lr > Time: 28 May 2010, 7:39:56 pm > UUID: 6be02689-5ff7-42e6-b1ec-f93ba26bb437 > Ancestors: OB-Morphic-lr.124 > > - added the possiblity to drag items onto option buttons, for example > to move items from the class to the instance side > > Lukas, what kind of beer do you like? I promise, next time I see you I will invite you with something hahahha I have just tested and works wonderful. OB is getting better and better :) Thanks a lot Mariano > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 31, 2010

Re: [Pharo-project] O2 and Pharo 1.0

by Mariano Martinez Peck

On Fri, May 28, 2010 at 6:00 PM, Alexandre Bergel <alexandre(a)bergel.eu>wrote: > Mariano, is there a way to update this? > > Yes, of course. This problem already appeared. In one mail I suggested O2 maintainers to change that. There are two possibilities: - Change the current version and put 'Dev' as default instead of core - Create a new version and release it (not in development) with a new baseline and in that baseline you put 'Dev' as default group. Anyway, it would be cool to update ConfigurationOf02 since there are new versions of its dependencies. Cheers Mariano > Alexandre > > > On 28 May 2010, at 08:18, Mariano Martinez Peck wrote: > > > Hi Juanjo. I think the problem is that ConfigurationOfO2 doesn't include > oCompletion in the default group. Try the group 'Dev' and you will get it. > > > > Look the conf: > > > > spec > > group: 'default' with: #('Core' ); > > group: 'Core' with: #( 'OmniBrowser2' 'O2-Standard' > 'O2-Morphic' 'O2-Enhancements'); > > group: 'Dev' with: #( 'Core' 'O2-Refactory' 'OCForO2'); > > group: 'Tests' with: #(); > > group: 'Core Tests' with: #('Core' 'Tests' ); > > > > > > Cheers > > > > Mariano > > > > > > 2010/5/28 JuanjoE <juanjoe(a)gmail.com> > > Hi, I tried to install O2 in Pharo 1.0 update #10517. > > > > All I do was Loader new load: 'O2'. It works fine, but the problem I'm > having is that oCompletion doesn't work with O2 browser. Any clue where I > can start looking? > > > > > > Thanks > > > > El problema no es mentirse, el problema es creerse > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 31, 2010

[Pharo-project] How do I install seaside in Pharo 1.0?

by Torsten Bergmann

When you use the script you will always load the "latestVersion" which is now (since time went on) a higher number for Seaside then at the times of Pharo 1.0 and is now surely intended for the newer Pharo 1.1. You can try one of the older versions by loading a specific version instead of the latest: ((Smalltalk at: #ConfigurationOfSeaside ) project version: '...') load You can also use one of the prebuilt images from: http://seaside.st/download/pharo Bye T. -- GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

May 31, 2010

Re: [Pharo-project] SUnit Time out

by StÃ©phane Ducasse

On May 31, 2010, at 12:29 PM, Nicolas Cellier wrote: > Oh, and I see one more advantage: Only quick tests are run > interactively by default from your TestRunner. > We could automate the separation between long tests and quick tests > based on timeout if the information is discoverable (either in method > annotations or class side query, I don't care). but do we have to tag that with a timeout. jorge already sorted tests as unit = fast and integration = slow. In interactive mode we could only run the fast one. I think that we have already a lot and we do not use it enough. So we will learn and see. Stef

May 31, 2010

Re: [Pharo-project] SUnit Time out

by StÃ©phane Ducasse

>> >> > > In other words, the timeout has the advantage to turn a rather > implicit requirement into an explicit requirement. > And it's then up to test producers to fine tune their tests wrt this > requirement or use the available hooks in case of long tests, rather > than letting the integrator guess. yes now for that we can probably use "We already have #should:notTakeMoreThan: and friends in TestCase. The complete TestCase can be protected by overriding #runCase, the individual test by wrapping the code of the test method. "

May 31, 2010

Re: [Pharo-project] SUnit Time out

by StÃ©phane Ducasse

ok tx Now may be the test runner should be adapted. We will see. Now I just remove the items from the urgent list and if the need emerges we know that this is there. Stef On May 31, 2010, at 12:10 PM, Nicolas Cellier wrote: > 2010/5/30 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> >> On May 30, 2010, at 8:52 PM, Chris Muller wrote: >> >>> (Copying squeak-dev too). >>> >>> I'm not sold on the whole test timeout thing. When I run tests, I >>> want to know the answer to the question, "is the software working?" >>> >>> Putting a timeout on tests trades a slower, but definitive, "yes" or >>> "no" for a supposedly-faster "maybe". But is getting a "maybe" back >>> really faster? I've just incurred the cost of running a test suite, >>> but left without my answer. I get a "maybe", what am I supposed to do >>> next? Find a faster machine? Hack into the code to fiddle with a >>> timeout pragma? That's not faster.. >> >> Thanks this is a really good point. >> >>> But, the reason given for the change was not for running tests >>> interactively (the 99% case), rather, all tests form the beginning of >>> time are now saddled with a timeout for the 1% case: >>> >>> "The purpose of the timeout is to catch issues like infinite loops, >>> unexpected user input etc. in automated test environments." >>> >>> If tests are supposed to be quick (and deterministic) anyway, wouldn't >>> an infinite loop or user-input be caught the first time the test was >>> run (interactively)? Seriously, when you make software changes, we >>> run the tests interactively first, and then the purpose of night-time >>> automated test environment is to catch regressions on the merged >>> code.. >> >> Yes this is what I was also implying in my previous mail. >> If we have a test server this does not really help to have a time out >> and I wonder the case of infinite loop because this may be really rare. >> > > My opinion differs here. Every test should run in a short time frame > but a few exceptions. So it seems reasonnable to just have to specify > a default timeout on your architecture and some specific timeouts for > a few specific tests (or test classes). > > Your main argument is that manual tuning will always be better than > automated default behaviour, and we can only agree on that one. > > But there are two pragmatic cases you don't take into account: > - the case when community supplied test cases do not comply with these > rather implicit requirements, and image integrator does not have time > to dig into each case and do the fine tuning for the rest of > community. > - the case when automated tests are used for exploratory package testing. > > In the first case, integrator just put a threshold that will reject > some tests, up to rest of community to inject more time in solving the > problem. > > Maybe Andreas was also addressing case of network-in-the-loop tests. > Thus it can be seen as a quick hack for by-passing the low level > timeout and number of retries (which are not always accessible that > easily in some APIs...). > > Concerning infinite loops occurence, some are produced by uncompatible > packages. So when you automate compatible package exploration, it > might help because I doubt you will have explored each case > interactively. Of course, you can always put a timeout at upper level > in your bash or something, but it would not be particularly fine > grained, would it ? > > One typical case I often bump into is those classes defining printOn: > by sending storeOn: et vice et versa, same for printString and > printOn:. If core happens to change between two releases, and you have > a subclass defined in your package, probability to run into one of > these infinite loops increases. > > Nicolas > >>> In that case, the high-level test-controller which spits out the >>> results could and should be responsible for handling "unexpected user >>> input" and/or putting in a timeout, not each and every last test >>> method.. >>> >>> IMO, we want short tests, so let's just write them to be short. If >>> they're too long, then the encouragement to shorten them comes from >>> our own impatience of running them interactively. Running them in >>> batch at night requires no patience, because we're sleeping, and >>> besides, the batch processor should take responsibility for handling >>> those rare scenarios at a higher-level.. >> >> I agree. >> Thanks for sharing your thoughts. >> So the issue is done. :) >> >> >>> >>> Regards, >>> Chris >>> >>> >>> On Sat, May 29, 2010 at 2:53 AM, stephane ducasse >>> <stephane.ducasse(a)free.fr> wrote: >>>> Hi guys >>>> >>>> in Squeak andreas introduced the idea of test time out >>>> Do you think that this is interesting? >>>> >>>> Stef >>>> >>>> SUnit >>>> ----- >>>> All test cases now have an associated timeout after which the test is considered failed. The purpose of the timeout is to catch issues like infinite loops, unexpected user input etc. in automated test environments. Timeouts can be set on an individual test basis using the <timeout: seconds> tag or for an entire test case by implementing the #defaultTimeout method. >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 31, 2010

Re: [Pharo-project] SUnit Time out

by Nicolas Cellier

Oh, and I see one more advantage: Only quick tests are run interactively by default from your TestRunner. We could automate the separation between long tests and quick tests based on timeout if the information is discoverable (either in method annotations or class side query, I don't care). Of course, as a user I would be interested to distinguish failures errors and timeouts, so I would want the user interface to change. Nicolas 2010/5/31 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > 2010/5/31 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >> 2010/5/30 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> >>> On May 30, 2010, at 8:52 PM, Chris Muller wrote: >>> >>>> (Copying squeak-dev too). >>>> >>>> I'm not sold on the whole test timeout thing. Â When I run tests, I >>>> want to know the answer to the question, "is the software working?" >>>> >>>> Putting a timeout on tests trades a slower, but definitive, "yes" or >>>> "no" for a supposedly-faster "maybe". Â But is getting a "maybe" back >>>> really faster? Â I've just incurred the cost of running a test suite, >>>> but left without my answer. Â I get a "maybe", what am I supposed to do >>>> next? Â Find a faster machine? Â Hack into the code to fiddle with a >>>> timeout pragma? Â That's not faster.. >>> >>> Thanks this is a really good point. >>> >>>> But, the reason given for the change was not for running tests >>>> interactively (the 99% case), rather, all tests form the beginning of >>>> time are now saddled with a timeout for the 1% case: >>>> >>>> Â "The purpose of the timeout is to catch issues like infinite loops, >>>> unexpected user input etc. in automated test environments." >>>> >>>> If tests are supposed to be quick (and deterministic) anyway, wouldn't >>>> an infinite loop or user-input be caught the first time the test was >>>> run (interactively)? Â Seriously, when you make software changes, we >>>> run the tests interactively first, and then the purpose of night-time >>>> automated test environment is to catch regressions on the merged >>>> code.. >>> >>> Yes this is what I was also implying in my previous mail. >>> If we have a test server this does not really help to have a time out >>> and I wonder the case of infinite loop because this may be really rare. >>> >> >> My opinion differs here. Every test should run in a short time frame >> but a few exceptions. So it seems reasonnable to just have to specify >> a default timeout on your architecture and some specific timeouts for >> a few specific tests (or test classes). >> >> Your main argument is that manual tuning will always be better than >> automated default behaviour, and we can only agree on that one. >> >> But there are two pragmatic cases you don't take into account: >> - the case when community supplied test cases do not comply with these >> rather implicit requirements, and image integrator does not have time >> to dig into each case and do the fine tuning for the rest of >> community. >> - the case when automated tests are used for exploratory package testing. >> >> In the first case, integrator just put a threshold that will reject >> some tests, up to rest of community to inject more time in solving the >> problem. >> > > In other words, the timeout has the advantage to turn a rather > implicit requirement into an explicit requirement. > And it's then up to test producers to fine tune their tests wrt this > requirement or use the available hooks in case of long tests, rather > than letting the integrator guess. > > Nicolas > >> Maybe Andreas was also addressing case of network-in-the-loop tests. >> Thus it can be seen as a quick hack for by-passing the low level >> timeout and number of retries (which are not always accessible that >> easily in some APIs...). >> >> Concerning infinite loops occurence, some are produced by uncompatible >> packages. So when you automate compatible package exploration, it >> might help because I doubt you will have explored each case >> interactively. Of course, you can always put a timeout at upper level >> in your bash or something, but it would not be particularly fine >> grained, would it ? >> >> One typical case I often bump into is those classes defining printOn: >> by sending storeOn: et vice et versa, same for printString and >> printOn:. If core happens to change between two releases, and you have >> a subclass defined in your package, probability to run into one of >> these infinite loops increases. >> >> Nicolas >> >>>> In that case, the high-level test-controller which spits out the >>>> results could and should be responsible for handling "unexpected user >>>> input" and/or putting in a timeout, not each and every last test >>>> method.. >>>> >>>> IMO, we want short tests, so let's just write them to be short. Â If >>>> they're too long, then the encouragement to shorten them comes from >>>> our own impatience of running them interactively. Â Running them in >>>> batch at night requires no patience, because we're sleeping, and >>>> besides, the batch processor should take responsibility for handling >>>> those rare scenarios at a higher-level.. >>> >>> I agree. >>> Thanks for sharing your thoughts. >>> So the issue is done. :) >>> >>> >>>> >>>> Regards, >>>> Â Chris >>>> >>>> >>>> On Sat, May 29, 2010 at 2:53 AM, stephane ducasse >>>> <stephane.ducasse(a)free.fr> wrote: >>>>> Hi guys >>>>> >>>>> in Squeak andreas introduced the idea of test time out >>>>> Do you think that this is interesting? >>>>> >>>>> Stef >>>>> >>>>> SUnit >>>>> ----- >>>>> All test cases now have an associated timeout after which the test is considered failed. The purpose of the timeout is to catch issues like infinite loops, unexpected user input etc. in automated test environments. Timeouts can be set on an individual test basis using the <timeout: seconds> tag or for an entire test case by implementing the #defaultTimeout method. >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >

May 31, 2010

Re: [Pharo-project] SUnit Time out

by Nicolas Cellier

2010/5/31 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > 2010/5/30 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> >> On May 30, 2010, at 8:52 PM, Chris Muller wrote: >> >>> (Copying squeak-dev too). >>> >>> I'm not sold on the whole test timeout thing. Â When I run tests, I >>> want to know the answer to the question, "is the software working?" >>> >>> Putting a timeout on tests trades a slower, but definitive, "yes" or >>> "no" for a supposedly-faster "maybe". Â But is getting a "maybe" back >>> really faster? Â I've just incurred the cost of running a test suite, >>> but left without my answer. Â I get a "maybe", what am I supposed to do >>> next? Â Find a faster machine? Â Hack into the code to fiddle with a >>> timeout pragma? Â That's not faster.. >> >> Thanks this is a really good point. >> >>> But, the reason given for the change was not for running tests >>> interactively (the 99% case), rather, all tests form the beginning of >>> time are now saddled with a timeout for the 1% case: >>> >>> Â "The purpose of the timeout is to catch issues like infinite loops, >>> unexpected user input etc. in automated test environments." >>> >>> If tests are supposed to be quick (and deterministic) anyway, wouldn't >>> an infinite loop or user-input be caught the first time the test was >>> run (interactively)? Â Seriously, when you make software changes, we >>> run the tests interactively first, and then the purpose of night-time >>> automated test environment is to catch regressions on the merged >>> code.. >> >> Yes this is what I was also implying in my previous mail. >> If we have a test server this does not really help to have a time out >> and I wonder the case of infinite loop because this may be really rare. >> > > My opinion differs here. Every test should run in a short time frame > but a few exceptions. So it seems reasonnable to just have to specify > a default timeout on your architecture and some specific timeouts for > a few specific tests (or test classes). > > Your main argument is that manual tuning will always be better than > automated default behaviour, and we can only agree on that one. > > But there are two pragmatic cases you don't take into account: > - the case when community supplied test cases do not comply with these > rather implicit requirements, and image integrator does not have time > to dig into each case and do the fine tuning for the rest of > community. > - the case when automated tests are used for exploratory package testing. > > In the first case, integrator just put a threshold that will reject > some tests, up to rest of community to inject more time in solving the > problem. > In other words, the timeout has the advantage to turn a rather implicit requirement into an explicit requirement. And it's then up to test producers to fine tune their tests wrt this requirement or use the available hooks in case of long tests, rather than letting the integrator guess. Nicolas > Maybe Andreas was also addressing case of network-in-the-loop tests. > Thus it can be seen as a quick hack for by-passing the low level > timeout and number of retries (which are not always accessible that > easily in some APIs...). > > Concerning infinite loops occurence, some are produced by uncompatible > packages. So when you automate compatible package exploration, it > might help because I doubt you will have explored each case > interactively. Of course, you can always put a timeout at upper level > in your bash or something, but it would not be particularly fine > grained, would it ? > > One typical case I often bump into is those classes defining printOn: > by sending storeOn: et vice et versa, same for printString and > printOn:. If core happens to change between two releases, and you have > a subclass defined in your package, probability to run into one of > these infinite loops increases. > > Nicolas > >>> In that case, the high-level test-controller which spits out the >>> results could and should be responsible for handling "unexpected user >>> input" and/or putting in a timeout, not each and every last test >>> method.. >>> >>> IMO, we want short tests, so let's just write them to be short. Â If >>> they're too long, then the encouragement to shorten them comes from >>> our own impatience of running them interactively. Â Running them in >>> batch at night requires no patience, because we're sleeping, and >>> besides, the batch processor should take responsibility for handling >>> those rare scenarios at a higher-level.. >> >> I agree. >> Thanks for sharing your thoughts. >> So the issue is done. :) >> >> >>> >>> Regards, >>> Â Chris >>> >>> >>> On Sat, May 29, 2010 at 2:53 AM, stephane ducasse >>> <stephane.ducasse(a)free.fr> wrote: >>>> Hi guys >>>> >>>> in Squeak andreas introduced the idea of test time out >>>> Do you think that this is interesting? >>>> >>>> Stef >>>> >>>> SUnit >>>> ----- >>>> All test cases now have an associated timeout after which the test is considered failed. The purpose of the timeout is to catch issues like infinite loops, unexpected user input etc. in automated test environments. Timeouts can be set on an individual test basis using the <timeout: seconds> tag or for an entire test case by implementing the #defaultTimeout method. >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >

May 31, 2010

Re: [Pharo-project] SUnit Time out

by Nicolas Cellier

2010/5/30 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > > On May 30, 2010, at 8:52 PM, Chris Muller wrote: > >> (Copying squeak-dev too). >> >> I'm not sold on the whole test timeout thing. Â When I run tests, I >> want to know the answer to the question, "is the software working?" >> >> Putting a timeout on tests trades a slower, but definitive, "yes" or >> "no" for a supposedly-faster "maybe". Â But is getting a "maybe" back >> really faster? Â I've just incurred the cost of running a test suite, >> but left without my answer. Â I get a "maybe", what am I supposed to do >> next? Â Find a faster machine? Â Hack into the code to fiddle with a >> timeout pragma? Â That's not faster.. > > Thanks this is a really good point. > >> But, the reason given for the change was not for running tests >> interactively (the 99% case), rather, all tests form the beginning of >> time are now saddled with a timeout for the 1% case: >> >> Â "The purpose of the timeout is to catch issues like infinite loops, >> unexpected user input etc. in automated test environments." >> >> If tests are supposed to be quick (and deterministic) anyway, wouldn't >> an infinite loop or user-input be caught the first time the test was >> run (interactively)? Â Seriously, when you make software changes, we >> run the tests interactively first, and then the purpose of night-time >> automated test environment is to catch regressions on the merged >> code.. > > Yes this is what I was also implying in my previous mail. > If we have a test server this does not really help to have a time out > and I wonder the case of infinite loop because this may be really rare. > My opinion differs here. Every test should run in a short time frame but a few exceptions. So it seems reasonnable to just have to specify a default timeout on your architecture and some specific timeouts for a few specific tests (or test classes). Your main argument is that manual tuning will always be better than automated default behaviour, and we can only agree on that one. But there are two pragmatic cases you don't take into account: - the case when community supplied test cases do not comply with these rather implicit requirements, and image integrator does not have time to dig into each case and do the fine tuning for the rest of community. - the case when automated tests are used for exploratory package testing. In the first case, integrator just put a threshold that will reject some tests, up to rest of community to inject more time in solving the problem. Maybe Andreas was also addressing case of network-in-the-loop tests. Thus it can be seen as a quick hack for by-passing the low level timeout and number of retries (which are not always accessible that easily in some APIs...). Concerning infinite loops occurence, some are produced by uncompatible packages. So when you automate compatible package exploration, it might help because I doubt you will have explored each case interactively. Of course, you can always put a timeout at upper level in your bash or something, but it would not be particularly fine grained, would it ? One typical case I often bump into is those classes defining printOn: by sending storeOn: et vice et versa, same for printString and printOn:. If core happens to change between two releases, and you have a subclass defined in your package, probability to run into one of these infinite loops increases. Nicolas >> In that case, the high-level test-controller which spits out the >> results could and should be responsible for handling "unexpected user >> input" and/or putting in a timeout, not each and every last test >> method.. >> >> IMO, we want short tests, so let's just write them to be short. Â If >> they're too long, then the encouragement to shorten them comes from >> our own impatience of running them interactively. Â Running them in >> batch at night requires no patience, because we're sleeping, and >> besides, the batch processor should take responsibility for handling >> those rare scenarios at a higher-level.. > > I agree. > Thanks for sharing your thoughts. > So the issue is done. :) > > >> >> Regards, >> Â Chris >> >> >> On Sat, May 29, 2010 at 2:53 AM, stephane ducasse >> <stephane.ducasse(a)free.fr> wrote: >>> Hi guys >>> >>> in Squeak andreas introduced the idea of test time out >>> Do you think that this is interesting? >>> >>> Stef >>> >>> SUnit >>> ----- >>> All test cases now have an associated timeout after which the test is considered failed. The purpose of the timeout is to catch issues like infinite loops, unexpected user input etc. in automated test environments. Timeouts can be set on an individual test basis using the <timeout: seconds> tag or for an entire test case by implementing the #defaultTimeout method. >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 31, 2010