June 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] SUnit Time out

by Nicolas Cellier

2010/6/5 Hernan Wilkinson <hernan.wilkinson(a)gmail.com>: > > > On Fri, Jun 4, 2010 at 2:32 PM, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> >> 2010/6/4 Hernan Wilkinson <hernan.wilkinson(a)gmail.com>: >> > I dont think it is a necessary... I mean, if you are doing TDD, you >> > write >> > the test and you run it inmediatly, if it takes too much time to run >> > (that >> > is, more than 2 seconds :-)) then you press ctrl+ . and problem >> > solved... >> >> Pretend you are Stephane or Andreas and trying to integrate a bunch of >> tests that you did not write. >> How do you know whether the test programmer cared about shortness ? >> How do you know whether the test is expected to be long or there is a >> regression somewhere causing an infinite loop ? >> >> From integrator point of view, best strategy is to reject any long test. > > So, the problem is not development, it is integration... so, it is not > related to TDD but how to run tests when integrating > In that case, if you are integrating the first thing you have to do is to > verify that the change, package, etc you are about to integrate "runs", that > is, the integrator should run all the tests before integrating if not after > integrating when a test fails he will not know if that is due to an > integration error or an error in the original change set. Therefore if you > have to run the test in the change "original" environment you will know how > long they will take after running them and also how long they should take > after integrating them. Yes but I doubt Andreas and Steph would make that effort. They are not even aware of "original" environment. Either the test runs in a reasonable time slot, or has an explicit long timeout statement. > Maybe changing the integration procedure avoids the need for this "feature", > that could impact when developing because of a need when integrating... > I worked in a system that had around 23.000 tests and when integrating never > feel the necessity for something like this... but when we started to have so > many tests running all of them before integration was taking more time than > expected (even thoug the 23.000 tests run in about 10 minutes or so), so we > decided to change our procedure in such a way that when a programmer > versioned a change, with that change we added the test running information > so the integrator did not need to run the test but only see how they ran > before closing the version... the time to run the test could be added to > that information and make the automatic running of test when integrating > take those times into account. > You did not hit the problem probably because you have a well managed environment/application. Andreas added this feature on pragmatic basis after hitting the problem. Automatically generated meta information could be a solution, but far more complex than Andreas simple hack. > >> If you are a producer and want to produce a long test, then you MUST >> declare it as such. >> >> Of course, that breaks a few legacy tests... >> >> > I'm saying this because the should:notTakeMoreThan: has some interesting >> > implementation details, like running the test in another process and >> > synchronizing them, etc... so running all the test would create a >> > process >> > for each test, etc. tacking more timeÂ unnecessarilyÂ in most of the >> > cases... >> > unless the implementation takes care of only doing this special >> > "feature" >> > when needed (for example, when you have that pragma) but the, if you >> > have to >> > write the pragma why not just send the message #should:notTakeMoreThan: >> > and >> > problem solved? >> > >> >> Your problem, probably, Andreas and Steph problem, I don't think so. > > hmm well again, I thought we were talking about development, but I think > that there are more developers that integrators and you spend more time > developing than integrating so, I still think that the solution should not > affect development but concentrate on the integration part of the > development process > > Bye, > Hernan. Maybe... I have the feeling that if we go toward a modular image with kind of automated testing we will hit the integration problem more and more. Nicolas >> >> Implementation details should be discussed. >> also the threshold is arbitrary and hardware dependent. >> Maybe we could use the Dorado as unit of time ;) >> but IMO, this feature is worth. >> >> Nicolas >> >> > On Sat, May 29, 2010 at 3:42 PM, StÃ©phane Ducasse >> > <stephane.ducasse(a)inria.fr> wrote: >> >> >> >> For me the point is that I have the impression that this is an >> >> interesting >> >> feature to have >> >> when we have a test server. Like that you make sure that you do not >> >> have >> >> tests with infinite recursion >> >> now this is also true that on a test server you do not really care if >> >> your >> >> tests take 30s or 2 min. >> >> >> >> Stef >> >> >> >> > 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. >> >> > >> >> > Lukas >> >> > >> >> > On 29 May 2010 16:43, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >> >> >> Stef, >> >> >> >> >> >> Time to expose some of my ignorance (don't worry, I have plenty more >> >> >> waiting where I found this): what is the tag concept? Â That sounds >> >> >> very >> >> >> Tweak-ish, and I am a real believer in doing things "with the >> >> >> language, not >> >> >> TO the language" whenever possible. Â That is not to say that >> >> >> frameworks are >> >> >> bad; in fact, it means that frameworks are good, language extensions >> >> >> are >> >> >> anywhere from suspect to evil. >> >> >> >> >> >> I have some code that I am still porting, but the basic idea is to >> >> >> be >> >> >> able to write >> >> >> >> >> >> [ >> >> >> Â "code that might not complete" >> >> >> >> >> >> ] tryForSeconds:10 onTimeOut:[ >> >> >> >> >> >> ]. >> >> >> >> >> >> With a robust capability to do such things, it is probably not >> >> >> necessary (or even appropriate) for TestCase to enforce timeouts. >> >> >> Â The >> >> >> timeout block can simply raise an exception or assert false, and >> >> >> there is no >> >> >> need to disable timeouts where they do not belong. >> >> >> >> >> >> Bill >> >> >> >> >> >> ________________________________________ >> >> >> From: pharo-project-bounces(a)lists.gforge.inria.fr >> >> >> [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Michael >> >> >> Roberts >> >> >> [mike(a)mjr104.co.uk] >> >> >> Sent: Saturday, May 29, 2010 6:17 AM >> >> >> To: Pharo-project(a)lists.gforge.inria.fr >> >> >> Subject: Re: [Pharo-project] SUnit Time out >> >> >> >> >> >> yes think it's a good idea. I'm not sure the granularity that's >> >> >> required though. >> >> >> >> >> >> mike >> >> >> >> >> >> On Saturday, May 29, 2010, 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 >> >> >> >> >> > >> >> > >> >> > >> >> > -- >> >> > 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 >> >> >> >> >> >> _______________________________________________ >> >> 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 >

June 5, 2010

Re: [Pharo-project] About TDD and Pharo

by StÃ©phane Ducasse

hernan can you chop that into simple but entry as request for improvement? Stef On Jun 3, 2010, at 11:04 PM, Hernan Wilkinson wrote: > Hi all, > this is a cool thread! :-) > > What I did are changes to the tools to make more easy to run tests and implement what is needed. For example: > > 1) When you are in the browser writing a test method, you can press ctrl + t to save the method and run the test. If the test runs, it will show the green dot in the browser, if it does not, it popups the debugger directly on the error. So, this is a way to avoid pressing ctrl + s (save) then going to the method list, rigth click an select run test and if it fails select that you want to debug it. > I think this is really useful > 2) Same as ctrl + t but ctrl + r to directly debug the test. It saves the method, puts a breakpoint in it and debugs it. Unfortunaly, in Pharo breakpoints dont show very well in the debuger (it highlights incorrect collaborations) > 3) I removed the Notifier window, it directly opens the debugger > 4) The debugger opens as a big window (so you dont have to resize it every time a test fails that is most of the time when doing tdd) > 5) The debugger has an "Implement" button that does what German Lieva suggested > 6) Removed all the questions the browser ask when saving a method that sends a message not implemented, etc. I left defined not declared class and variables. > > I think there are more things that could be improved/implemented: > 1) Provide a default implementation for methods that look like getter or setters (like German also suggested. VisualAge does that very nice) > 2) Allow the "Implement" option to work also when the method has a "subclassResponsibility" Right now it only works with "DoesNotUnderstand" > 3) Allow to define coding patterns easily and execute those coding patterns automatically when needed. For example, I have coding pattern form instance creation messages like this: > Attendee named: aName attending: aCollectionOfDates > > ^ self new initializeNamed: aName attending: aCollectionOfDates > > It send the message new and the initializeXxx where Xxx is the same name of the instance creation message > We could provide default implementation for well know messages like #= or #hash (but this requires to generalize the implementation of #= and #hash using other objets...) > 4) Similar to the previous one but for classes. For example if I write: > InvalidNameException signalName: xxx > It could be inferred that we are creating an Exception, that the exception will have a class message that will signal the exception and an instance creation message (#name:) to create instances, and an initialization message (#initializeName:) and an instance variable called name. > (Of course one could argue that if this can be automatize, the we can create an abstraction for that and then we would not need a class per exception... but that is another discussion :-) ) > 5) Change how the categorization of a method works. It should suggest a category based on the automatic categorization and it should not show so many options as it does right now (it is really annoying to see so many options) > 6) Change the dialog for creating a class, it is too small > > I think that using TDD or BDD is another discussion... (for me there is no much different, that depends on what you understand with TDD...) > I don't know if I'd like the test to run automatically, never tried it, but it looks to me that it could be distractive... > > Bye > Hernan > > > 2010/6/3 Mariano Martinez Peck <marianopeck(a)gmail.com> > What HernÃ¡n did is here: http://www.squeaksource.com/TDDFacilities.html > > That was for Pharo 1.0. > > For those that want to help in this subject I think the first step could be to load such package in a PharoCore1.1 and fix it in case it doesn't work. > Then, it can be integrated as part of PharoCore. Although it may be cool to have a preference to enable or disable all this changes (more TDD oriented), as we are not doing TDD all the time and sometimes we want the normal behavior. > > Once we have that, we can start improving. For example, I would love also what Guille said: key bindings for the debugger. I would LOVE to have a Pharo less mouse oriented (I don't care who invented the mouse, I rather the keyboard). > > So..open a bug ticket and start to play. > > Cheers > > Mariano > > 2010/6/3 Denis Kudriashov <dionisiydk(a)gmail.com> > > Hello, No I dont. Who is it? > > 2010/6/3 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > do you happen to know tim mckinnon? > > Stef > On Jun 3, 2010, at 12:13 AM, Denis Kudriashov wrote: > > > I use Mockery - my implementation SSpec idies. It is realy more powerfull, transparency and flexibility. > > > > With Mockery you dont need any special base classes for TestCases or mocks factory variables in code. You just use mocks where you want by Block creation scenarios: > > > > [:mock | > > [sut doWith: mock] should lenient satisfy: [mock someMessage willReturn: #result] > > ] runScenario. > > > > State specs like "5 should be an instance of: Integer" can be easely added by pragmas. > > > > And Its work in Pharo 1.0. > > > > Of course, It's needs more good stuff. But now I dont have enough time. > > http://www.squeaksource.com/Mocketry.html > > > > 2010/6/3 Sean P. DeNigris <sean(a)clipperadams.com> > > > > > > StÃ©phane Ducasse wrote: > > > > > > Imagine that we would like to sell pharo (+ seaside) as THE agile platform > > > for doing TDD. > > > What would be the changes that we could do support it. > > > > > > > Coming from Ruby, it seemed like BDD was taking over the world, and was the > > next step in TDD evolution, but I found few mentions of it in the Squeak > > world. For my own projects, I use SSpec (which I have been fixing as I go > > along). I only use "tests" with SUnit assertions for community projects, as > > not to confuse or add additional dependencies. > > > > I think that core BDD support would be necessary to woo developers here, > > especially from Ruby, where all the passion and conversation is around BDD. > > > > Sean > > -- > > View this message in context: http://forum.world.st/About-TDD-and-Pharo-tp2240686p2240877.html > > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > > > _______________________________________________ > > 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 5, 2010

Re: [Pharo-project] About TDD and Pharo

by StÃ©phane Ducasse

On Jun 3, 2010, at 9:13 PM, Lukas Renggli wrote: >> -Suggest to delete accessors when deleting an IV > > You cannot delete an inst-var with the refactoring engine if there are > references. but lukas you can pipe them. first remove the iv second ask for removing accessors > >> -Be able to generate accessors for multiple IVs at the same time (like in eclipse!) > > This is built-in for several years now: refactor class | create accessors > >> -Have a preference that automatically generate accessors on addition of IVs / class definition > > I rarely use these accessor refactorings because I have to rewrite > each method by hand afterwards anyway to have a type-revealing > argument name and a comment. > > Lukas > > -- > 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

June 5, 2010

Re: [Pharo-project] About TDD and Pharo

by StÃ©phane Ducasse

I know that keith integrated SSpec and SUnit so probably there are enhancements there. Stef On Jun 3, 2010, at 2:16 PM, Sean P. DeNigris wrote: > > > StÃ©phane Ducasse wrote: >> >> but is it not just using SSpec? >> > SSpec is not bad, but needs some work. > > > StÃ©phane Ducasse wrote: >> >> Did SSpec still loads? >> > It loads, but most of the tests fail - even though the project itself mostly > works. > > > StÃ©phane Ducasse wrote: >> >> Does it load in pharo well? >> > It definitely works in 1.0. I don't remember if I loaded it in 1.1, I'll > try when I get a minute. > > > StÃ©phane Ducasse wrote: >> >> Where is it? >> > SqS. I will upload my fixes soon. > > Sean > -- > View this message in context: http://forum.world.st/About-TDD-and-Pharo-tp2240686p2241568.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 5, 2010

Re: [Pharo-project] About TDD and Pharo

by StÃ©phane Ducasse

Just pay attention that I already integrated some changes of Hernan (like the warning for the compiler). Stef On Jun 3, 2010, at 9:29 AM, Mariano Martinez Peck wrote: > What HernÃ¡n did is here: http://www.squeaksource.com/TDDFacilities.html > > That was for Pharo 1.0. > > For those that want to help in this subject I think the first step could be to load such package in a PharoCore1.1 and fix it in case it doesn't work. > Then, it can be integrated as part of PharoCore. Although it may be cool to have a preference to enable or disable all this changes (more TDD oriented), as we are not doing TDD all the time and sometimes we want the normal behavior. > > Once we have that, we can start improving. For example, I would love also what Guille said: key bindings for the debugger. I would LOVE to have a Pharo less mouse oriented (I don't care who invented the mouse, I rather the keyboard). > > So..open a bug ticket and start to play. > > Cheers > > Mariano > > 2010/6/3 Denis Kudriashov <dionisiydk(a)gmail.com> > Hello, No I dont. Who is it? > > 2010/6/3 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > do you happen to know tim mckinnon? > > Stef > On Jun 3, 2010, at 12:13 AM, Denis Kudriashov wrote: > > > I use Mockery - my implementation SSpec idies. It is realy more powerfull, transparency and flexibility. > > > > With Mockery you dont need any special base classes for TestCases or mocks factory variables in code. You just use mocks where you want by Block creation scenarios: > > > > [:mock | > > [sut doWith: mock] should lenient satisfy: [mock someMessage willReturn: #result] > > ] runScenario. > > > > State specs like "5 should be an instance of: Integer" can be easely added by pragmas. > > > > And Its work in Pharo 1.0. > > > > Of course, It's needs more good stuff. But now I dont have enough time. > > http://www.squeaksource.com/Mocketry.html > > > > 2010/6/3 Sean P. DeNigris <sean(a)clipperadams.com> > > > > > > StÃ©phane Ducasse wrote: > > > > > > Imagine that we would like to sell pharo (+ seaside) as THE agile platform > > > for doing TDD. > > > What would be the changes that we could do support it. > > > > > > > Coming from Ruby, it seemed like BDD was taking over the world, and was the > > next step in TDD evolution, but I found few mentions of it in the Squeak > > world. For my own projects, I use SSpec (which I have been fixing as I go > > along). I only use "tests" with SUnit assertions for community projects, as > > not to confuse or add additional dependencies. > > > > I think that core BDD support would be necessary to woo developers here, > > especially from Ruby, where all the passion and conversation is around BDD. > > > > Sean > > -- > > View this message in context: http://forum.world.st/About-TDD-and-Pharo-tp2240686p2240877.html > > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > > > _______________________________________________ > > 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

June 5, 2010

Re: [Pharo-project] pharo and stand along GUI projects

by Yanni Chiu

sergio_101 wrote: > are there some examples of stand alone apps i can see in real life? I'm not sure whether it's the kind of standalone application you have in mind, but there's PLOPP (built on Squeak, not Pharo, though). See: http://wiki.squeak.org/squeak/2431 http://www.planet-plopp.com/

June 5, 2010

[Pharo-project] pharo and stand along GUI projects

by sergio_101

at this point, the only exposure i have had to pharo is using seaside.. i hadn't thought much about using it to write stand alone apps. not that i don't think it would be a good idea, i just haven't needed to write and GUI apps in awhile.. anyway. i am thinking about starting an open source project to scratch an itch. i would imagine it will scratch a great deal of itches, so i would like it to be cross platform. i would like to make it look sharp on all platforms, and be easy to install.. should i consider pharo for such a project? are there some examples of stand alone apps i can see in real life? if you would like a little more background on this, you can check out: http://www.codingforhire.com/blog/The-Perfect-GTD-System thanks! -- ---- peace, sergio photographer, journalist, visionary http://www.CodingForHire.com http://www.coffee-black.com http://www.painlessfrugality.com http://www.twitter.com/sergio_101 http://www.facebook.com/sergio101

June 5, 2010

Re: [Pharo-project] SUnit Time out

by Hernan Wilkinson

On Fri, Jun 4, 2010 at 2:32 PM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > 2010/6/4 Hernan Wilkinson <hernan.wilkinson(a)gmail.com>: > > I dont think it is a necessary... I mean, if you are doing TDD, you write > > the test and you run it inmediatly, if it takes too much time to run > (that > > is, more than 2 seconds :-)) then you press ctrl+ . and problem solved... > > Pretend you are Stephane or Andreas and trying to integrate a bunch of > tests that you did not write. > How do you know whether the test programmer cared about shortness ? > How do you know whether the test is expected to be long or there is a > regression somewhere causing an infinite loop ? > > From integrator point of view, best strategy is to reject any long test. > So, the problem is not development, it is integration... so, it is not related to TDD but how to run tests when integrating In that case, if you are integrating the first thing you have to do is to verify that the change, package, etc you are about to integrate "runs", that is, the integrator should run all the tests before integrating if not after integrating when a test fails he will not know if that is due to an integration error or an error in the original change set. Therefore if you have to run the test in the change "original" environment you will know how long they will take after running them and also how long they should take after integrating them. Maybe changing the integration procedure avoids the need for this "feature", that could impact when developing because of a need when integrating... I worked in a system that had around 23.000 tests and when integrating never feel the necessity for something like this... but when we started to have so many tests running all of them before integration was taking more time than expected (even thoug the 23.000 tests run in about 10 minutes or so), so we decided to change our procedure in such a way that when a programmer versioned a change, with that change we added the test running information so the integrator did not need to run the test but only see how they ran before closing the version... the time to run the test could be added to that information and make the automatic running of test when integrating take those times into account. If you are a producer and want to produce a long test, then you MUST > declare it as such. > > Of course, that breaks a few legacy tests... > > > I'm saying this because the should:notTakeMoreThan: has some interesting > > implementation details, like running the test in another process and > > synchronizing them, etc... so running all the test would create a process > > for each test, etc. tacking more time unnecessarily in most of the > cases... > > unless the implementation takes care of only doing this special "feature" > > when needed (for example, when you have that pragma) but the, if you have > to > > write the pragma why not just send the message #should:notTakeMoreThan: > and > > problem solved? > > > > Your problem, probably, Andreas and Steph problem, I don't think so. > hmm well again, I thought we were talking about development, but I think that there are more developers that integrators and you spend more time developing than integrating so, I still think that the solution should not affect development but concentrate on the integration part of the development process Bye, Hernan. > > Implementation details should be discussed. > also the threshold is arbitrary and hardware dependent. > Maybe we could use the Dorado as unit of time ;) > but IMO, this feature is worth. > > Nicolas > > > On Sat, May 29, 2010 at 3:42 PM, StÃ©phane Ducasse > > <stephane.ducasse(a)inria.fr> wrote: > >> > >> For me the point is that I have the impression that this is an > interesting > >> feature to have > >> when we have a test server. Like that you make sure that you do not have > >> tests with infinite recursion > >> now this is also true that on a test server you do not really care if > your > >> tests take 30s or 2 min. > >> > >> Stef > >> > >> > 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. > >> > > >> > Lukas > >> > > >> > On 29 May 2010 16:43, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > >> >> Stef, > >> >> > >> >> Time to expose some of my ignorance (don't worry, I have plenty more > >> >> waiting where I found this): what is the tag concept? That sounds > very > >> >> Tweak-ish, and I am a real believer in doing things "with the > language, not > >> >> TO the language" whenever possible. That is not to say that > frameworks are > >> >> bad; in fact, it means that frameworks are good, language extensions > are > >> >> anywhere from suspect to evil. > >> >> > >> >> I have some code that I am still porting, but the basic idea is to be > >> >> able to write > >> >> > >> >> [ > >> >> "code that might not complete" > >> >> > >> >> ] tryForSeconds:10 onTimeOut:[ > >> >> > >> >> ]. > >> >> > >> >> With a robust capability to do such things, it is probably not > >> >> necessary (or even appropriate) for TestCase to enforce timeouts. > The > >> >> timeout block can simply raise an exception or assert false, and > there is no > >> >> need to disable timeouts where they do not belong. > >> >> > >> >> Bill > >> >> > >> >> ________________________________________ > >> >> From: pharo-project-bounces(a)lists.gforge.inria.fr > >> >> [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Michael > Roberts > >> >> [mike(a)mjr104.co.uk] > >> >> Sent: Saturday, May 29, 2010 6:17 AM > >> >> To: Pharo-project(a)lists.gforge.inria.fr > >> >> Subject: Re: [Pharo-project] SUnit Time out > >> >> > >> >> yes think it's a good idea. I'm not sure the granularity that's > >> >> required though. > >> >> > >> >> mike > >> >> > >> >> On Saturday, May 29, 2010, 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 > >> >> > >> > > >> > > >> > > >> > -- > >> > 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 > >> > >> > >> _______________________________________________ > >> 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 >

June 5, 2010

Re: [Pharo-project] Changes aren't saved in the default (unnamed) changeset on a new image

by Guillermo Polito

http://code.google.com/p/pharo/issues/detail?id=2504&colspec=ID%20Type%20St… :) 2010/6/4 Mariano Martinez Peck <marianopeck(a)gmail.com> > Hi Guille. I could reproduce the problem. Please create an issue and put > milestone 1.1. > > More investigation: in PharoCore it works perfect, the problem is with > PharoDev. > > More details: the problem is in ScriptLoader >> cleanUpForRelease > > This method is being call when the Dev image is created. If you take a > PharoCore, the changeset are working well. Take that image, and evaluate > ScriptLoader nwe cleanUpForRelease. After this, it should start the problem > you mention. Can you reproduce this? > > Now, we need to see where the problem is in cleanUpForRelease. We need some > debugging here. No time now. Maybe it is related to the lines: > > ChangeSet removeChangeSetsNamedSuchThat: [ :each | true ]. > ChangeSet resetCurrentToNewUnnamedChangeSet. > > but just a guess. > > Cheers > > mariano > > 2010/6/4 Guillermo Polito <guillermopolito(a)gmail.com> > > They are not saved :D, that's what motivated me to send this email :P. >> >> I'll open one :) >> >> >> On Fri, Jun 4, 2010 at 1:18 PM, StÃ©phane Ducasse < >> stephane.ducasse(a)inria.fr> wrote: >> >>> where is it saved? >>> it may be a bug >>> create a bug entry with a nice description :) >>> >>> Stef >>> On Jun 4, 2010, at 5:23 PM, Guillermo Polito wrote: >>> >>> > Hi! >>> > >>> > I'm using the develop Pharo-1.1-11367-Beta on windows. >>> > >>> > When I make a change with a fresh image, that change isn't saved in the >>> default changeset :(. In the Core image it's just ok. >>> > >>> > Is it a bug or a 'feature'? >>> > >>> > Cheers, >>> > Guille >>> > _______________________________________________ >>> > 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 >

June 4, 2010

Re: [Pharo-project] Changes aren't saved in the default (unnamed) changeset on a new image

by Mariano Martinez Peck

Hi Guille. I could reproduce the problem. Please create an issue and put milestone 1.1. More investigation: in PharoCore it works perfect, the problem is with PharoDev. More details: the problem is in ScriptLoader >> cleanUpForRelease This method is being call when the Dev image is created. If you take a PharoCore, the changeset are working well. Take that image, and evaluate ScriptLoader nwe cleanUpForRelease. After this, it should start the problem you mention. Can you reproduce this? Now, we need to see where the problem is in cleanUpForRelease. We need some debugging here. No time now. Maybe it is related to the lines: ChangeSet removeChangeSetsNamedSuchThat: [ :each | true ]. ChangeSet resetCurrentToNewUnnamedChangeSet. but just a guess. Cheers mariano 2010/6/4 Guillermo Polito <guillermopolito(a)gmail.com> > They are not saved :D, that's what motivated me to send this email :P. > > I'll open one :) > > > On Fri, Jun 4, 2010 at 1:18 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > >> where is it saved? >> it may be a bug >> create a bug entry with a nice description :) >> >> Stef >> On Jun 4, 2010, at 5:23 PM, Guillermo Polito wrote: >> >> > Hi! >> > >> > I'm using the develop Pharo-1.1-11367-Beta on windows. >> > >> > When I make a change with a fresh image, that change isn't saved in the >> default changeset :(. In the Core image it's just ok. >> > >> > Is it a bug or a 'feature'? >> > >> > Cheers, >> > Guille >> > _______________________________________________ >> > 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 >

June 4, 2010