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

Re: [Pharo-project] packages :)

by Lukas Renggli

>> - The fact that compiled methods are stored in the model is very >> dangerous. You might hold onto compiled methods that have long been >> replaced with other ones. Just by playing a bit with the model I run >> into that situation (I don't know how). I think just keeping the >> selector internally would be much safer and solve all kinds of >> troubles (exactly like this is done for the classes). You'll have to >> check anyway if the method is still present when you iterate over the >> methods. A single use of #doSilently: (and there are lots of them in >> the image) can completely screw up the complete package model. > > The model does not store compiled methods, or classes. It only stores > symbols. True, sorry about that. I did not open the inspector wide enough and I somehow made that conclusion from the public API :-) Lukas -- Lukas Renggli http://www.lukas-renggli.ch

March 16, 2010

Re: [Pharo-project] packages :)

by Tudor Girba

Hi Lukas, On 16 Mar 2010, at 21:50, Lukas Renggli wrote: > I have some comments, to both the package implementation and the > Glamour browser. The other browser didn't work, I guess I miss some > extra package. > > - I used the code below to import the existing packages into the new > model. Maybe something like this should be included on the class side > of RPackageOrganizer to have a realistic model? > > | package | > PackageOrganizer default packages > do: [ :info | > package := RPackage2 named: info packageName. > info classes do: [ :each | package addClassDefinition: each ]. > info coreMethods do: [ :each | > each isValid > ifTrue: [ package addMethod: each compiledMethod isExtension: > false ] ]. > info extensionMethods do: [ :each | > each isValid > ifTrue: [ package addMethod: each compiledMethod isExtension: > true ] ] ] > displayingProgress: 'Importing' > > Then I opened the glamour browser using: > > GTCoder openOn: RPackageOrganizer default > > - I find it quite strange that I have to declare if a method is an > extension or not. Isn't a that obvious when looking at the defined > classes? Stef said that this was a reminiscent from before deciding he wants to declare the class explicitly, but we agreed that specifying the extension explicitly is not necessary. > Having two dictionaries for methods makes it extremely > difficult to move stuff around because always 4 separate cases need to > be handled. I also do not like this part either. > - The fact that compiled methods are stored in the model is very > dangerous. You might hold onto compiled methods that have long been > replaced with other ones. Just by playing a bit with the model I run > into that situation (I don't know how). I think just keeping the > selector internally would be much safer and solve all kinds of > troubles (exactly like this is done for the classes). You'll have to > check anyway if the method is still present when you iterate over the > methods. A single use of #doSilently: (and there are lots of them in > the image) can completely screw up the complete package model. The model does not store compiled methods, or classes. It only stores symbols. > - The browser displays nicely the extended classes, but for the > methods I don't see the protocols and the complete set of selectors > implemented. I think these things should be part of the browser, > otherwise we don't see if the package model can answer these queries > quick enough. I agree, but this was just a quick thing to see what kind of navigation methods are needed to get the classes and methods. Categories are still to be added. > - The browser displays extension methods on both instance and > class-side. When browsing an extended class, the extensions are not > displayed. Yes, these were bugs :). I tried to fix these, but I think I bumped into other problems, so I will stop for now. Cheers, Doru > That's it for the moment. I see a cool model emerging :-) > > Lukas > > -- > Lukas Renggli > http://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 -- www.tudorgirba.com "Sometimes the best solution is not the best solution."

March 16, 2010

Re: [Pharo-project] [enh] Cleaning of and test for MessageTally

by Alexandre Bergel

> If you understand it well then may be you can write a better comment > than mine about the implementation. :) Writing is like coding: it is an incremental engineering process. I will have a good description because you provided a good foundation. :-) Alexandre > > On Mar 16, 2010, at 8:30 PM, Alexandre Bergel wrote: > >> I removed the duplicated code in SLICE-MessageTallyCleaningAndTest- >> Alexandre_Bergel.2 >> MessageTally is a nice piece of code, but a bit messy on some part. >> And some further cleaning is needed (e.g., the way the time is >> computed). >> >> I did this to fully understand how MessageTally works. This will be >> helpful for Pharo By Example. >> >> Cheers, >> Alexandre >> >> >> On 16 Mar 2010, at 13:24, StÃ©phane Ducasse wrote: >> >>> You have some duplicated code >>> >>> spyOn: aBlock reportOtherProcesses: aBoolean cutoff: aNumber >>> openResultWindow: openResultWindow >>> >>> | node result | >>> node := self new. >>> node reportOtherProcesses: aBoolean. >>> result := node spyEvery: self defaultPollPeriod on: aBlock. >>> >>> openResultWindow ifTrue: >>> [ (CodeHolder new contents: (String streamContents: [:s | node >>> report: s cutoff: aNumber; close])) >>> openLabel: 'Spy Results' wrap: false ]. >>> >>> ^ node >>> "^ result" >>> >>> spyOn: aBlock reportOtherProcesses: aBoolean cutoff: aNumber >>> openResultWindow: openResultWindow closeAfter: closeAfter >>> >>> | node result | >>> node := self new. >>> node reportOtherProcesses: aBoolean. >>> result := node spyEvery: self defaultPollPeriod on: aBlock. >>> >>> openResultWindow ifTrue: >>> [ (CodeHolder new contents: (String streamContents: [:s | node >>> report: s cutoff: aNumber])) >>> openLabel: 'Spy Results' wrap: false ]. >>> >>> closeAfter ifTrue: [ node close ]. >>> >>> ^ node >>> "^ result" >>> >>> It is a good idea to have some tests. Now maybe you should not >>> rely on float printString but >>> one a mock class else if we change float printing these tests will >>> break. >>> >>> Stef >>> >>> >>> On Mar 16, 2010, at 2:15 AM, Alexandre Bergel wrote: >>> >>>> Waiting in PharoInbox. This fix has been developed in a 11271. >>>> >>>> SLICE-MessageTallyCleaningAndTest-Alexandre_Bergel.1 >>>> >>>> >>>> This slices comprises an update for two packages, Tools and >>>> ToolsTest. >>>> The new version of Tools clean MessageTally. A user of >>>> MessageTally may now decide whether he >>>> wants to close the tally. Although it is convenient to close it >>>> (in order to not keep a reference of the >>>> compiled method and the class), this behavior is not always >>>> wished. Especially when test have to be >>>> written! >>>> The user has now the option to not open the result window. >>>> >>>> ToolsTest contains few and simple tests. >>>> >>>> Cheers, >>>> Alexandre >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> 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 >>> >>> >>> _______________________________________________ >>> 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 > > > _______________________________________________ > 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 16, 2010

[Pharo-project] classNameCache/classNames problem

by Pavel Krivanek

Hi, I tried to run tests in Pharo 1.1 #11275 and then I got an error when trying to open Message Names. The reason is that if you evaluate Smalltalk classNames includes: #C1 you got true so Smalltalk classNames includes it however it is not present in Smalltalk globals. After Smalltalk flushClassNameCache the problem disapeared. If I tried to create a class named SomeClass, the result was: Smalltalk classNames includes: #SomeClass -> false Smalltalk globals at: #SomeClass -> SomeClass I had to remove Object>>#initialExtent because of neverending deperecation warning (a methods tries respondsTo: #initialExtent on a model. I don't know which one because Recent Submissions doesn't work because of method reference AutoGeneratedClassForTestingSystemChanges>>#Comment anwered nil on actualClass message) -- Pavel

March 16, 2010

Re: [Pharo-project] packages :)

by Lukas Renggli

I have some comments, to both the package implementation and the Glamour browser. The other browser didn't work, I guess I miss some extra package. - I used the code below to import the existing packages into the new model. Maybe something like this should be included on the class side of RPackageOrganizer to have a realistic model? | package | PackageOrganizer default packages do: [ :info | package := RPackage2 named: info packageName. info classes do: [ :each | package addClassDefinition: each ]. info coreMethods do: [ :each | each isValid ifTrue: [ package addMethod: each compiledMethod isExtension: false ] ]. info extensionMethods do: [ :each | each isValid ifTrue: [ package addMethod: each compiledMethod isExtension: true ] ] ] displayingProgress: 'Importing' Then I opened the glamour browser using: GTCoder openOn: RPackageOrganizer default - I find it quite strange that I have to declare if a method is an extension or not. Isn't a that obvious when looking at the defined classes? Having two dictionaries for methods makes it extremely difficult to move stuff around because always 4 separate cases need to be handled. - The fact that compiled methods are stored in the model is very dangerous. You might hold onto compiled methods that have long been replaced with other ones. Just by playing a bit with the model I run into that situation (I don't know how). I think just keeping the selector internally would be much safer and solve all kinds of troubles (exactly like this is done for the classes). You'll have to check anyway if the method is still present when you iterate over the methods. A single use of #doSilently: (and there are lots of them in the image) can completely screw up the complete package model. - The browser displays nicely the extended classes, but for the methods I don't see the protocols and the complete set of selectors implemented. I think these things should be part of the browser, otherwise we don't see if the package model can answer these queries quick enough. - The browser displays extension methods on both instance and class-side. When browsing an extended class, the extensions are not displayed. That's it for the moment. I see a cool model emerging :-) Lukas -- Lukas Renggli http://www.lukas-renggli.ch

March 16, 2010

Re: [Pharo-project] About long tests.

by StÃ©phane Ducasse

On Mar 16, 2010, at 9:06 PM, Jorge Ressia wrote: > Sorry Stef, couldn't resist :) I know the syndrom (noooooooI do not want to open latex to write........ . . .) I saw the picture on your board :) Ok once your oopsla paper is done, I would do discuss with you how we integrate - adrian kuhn changes - have a look at SUnit Extension made by Keith I will start to look at that (once I'm with some other papers to write :) Stef > > Now there is a distinction between unit tests and the rest of them. > Unit tests are depicted as fast and model oriented tests. Later we > will have to introduce more kinds of test for enriching our build and > development process, tests like functional, architectural, lint, etc. > > 6942 unit tests run in 34 secs instead than 2:25 min running all > tests. I think this will encourage developers to run the tests a > little more often. > > I implemented a fix in the next slice. > > Name: SLICE-FastAndSlowTestDisociation-JorgeRessia.1 > Author: JorgeRessia > Time: 16 March 2010, 8:50:41 pm > UUID: 9c44289b-bccb-4198-9a98-6dd9979e9bdd > Ancestors: > Dependencies: Gofer-Tests-JorgeRessia.117, > KernelTests-JorgeRessia.164, SUnit-JorgeRessia.86, > SUnitGUI-JorgeRessia.45, Tests-JorgeRessia.48 > > Test cases now answer the message isUnitTest in order to differentiate > the unit test from the rest of the tests. > > - The tests that take too long are no more considered unit tests. > - Some test were functional test so there are not considered unit tests. > - The TestRunner was modified. A new menu entry can be found in the > class pane for selecting all unit tests. > > > Some more fixes here: > > Name: SLICE-FastAndSlowTestDisociation-JorgeRessia.2 > Author: JorgeRessia > Time: 16 March 2010, 8:58:11 pm > UUID: 86461af2-534b-4091-8f2e-973b650db098 > Ancestors: SLICE-FastAndSlowTestDisociation-JorgeRessia.1 > Dependencies: Gofer-Tests-JorgeRessia.117, > KernelTests-JorgeRessia.164, SUnit-JorgeRessia.87, > SUnitGUI-JorgeRessia.45, Tests-JorgeRessia.48 > > - test fixed > > Cheers, > > Jorge > > On Tue, Mar 16, 2010 at 3:18 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> focus on the paper jorge coding only for the fun :) >> We have time. >> >> Stef >> >> On Mar 16, 2010, at 9:35 AM, Jorge Ressia wrote: >> >>> Hi, >>> >>> No, I have to finish that. Is still in my todo list. >>> I'll try to make some time today to look into that. >>> >>> Cheers, >>> >>> Jorge >>> >>> On Tue, Mar 16, 2010 at 9:32 AM, Adrian Lienhard <adi(a)netstyle.ch> wrote: >>>> Yes, it would be very good to have faster tests. In my experience, if tests take too long to run, you don't use them. >>>> >>>> During the sprint in Lille, Jorge started to sort out long running tests from the rest and make them subclass from SlowTestCase (or something similar). >>>> >>>> Cheers, >>>> Adrian >>>> >>>> >>>> On Mar 16, 2010, at 09:13 , Lukas Renggli wrote: >>>> >>>>> Btw, I am running the Pharo tests in my builds now too: >>>>> >>>>> http://hudson.lukas-renggli.ch/job/Pharo/lastCompletedBuild/testReport/(roo… >>>>> >>>>> Click on duration twice to see the tests sorted by run-time. I feel a >>>>> bit bad that the slowest test case is one that I wrote. I'll see if I >>>>> can speed that up some more. >>>>> >>>>> Lukas >>>>> >>>>> On 15 March 2010 20:56, stephane ducasse <stephane.ducasse(a)free.fr> wrote: >>>>>> Hi jorge >>>>>> >>>>>> did you publish the cleans for the tests you did during the sprint? >>>>>> >>>>>> Thanks Stef >>>>>> >>>>>> _______________________________________________ >>>>>> Pharo-project mailing list >>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Lukas Renggli >>>>> http://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

March 16, 2010

Re: [Pharo-project] Fixed strange coloring in TestRunner

by StÃ©phane Ducasse

Thanks On Mar 16, 2010, at 7:42 PM, Lukas Renggli wrote: > Name: SUnitGUI-LukasRenggli.61 > Author: lr > Time: 16 March 2010, 7:42:35 pm > UUID: afa7782a-a37f-4607-8d44-6d03d0f847d6 > Ancestors: SUnitGUI-StephaneDucasse.60 > > - fixed priority of coloring test result: > > if there are errors then red > else if there are failures then yellow > else -> green > > -- > Lukas Renggli > http://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

March 16, 2010

Re: [Pharo-project] [enh] Cleaning of and test for MessageTally

by StÃ©phane Ducasse

Cool thanks alex. If you understand it well then may be you can write a better comment than mine about the implementation. :) Stef On Mar 16, 2010, at 8:30 PM, Alexandre Bergel wrote: > I removed the duplicated code in SLICE-MessageTallyCleaningAndTest-Alexandre_Bergel.2 > MessageTally is a nice piece of code, but a bit messy on some part. > And some further cleaning is needed (e.g., the way the time is computed). > > I did this to fully understand how MessageTally works. This will be helpful for Pharo By Example. > > Cheers, > Alexandre > > > On 16 Mar 2010, at 13:24, StÃ©phane Ducasse wrote: > >> You have some duplicated code >> >> spyOn: aBlock reportOtherProcesses: aBoolean cutoff: aNumber openResultWindow: openResultWindow >> >> | node result | >> node := self new. >> node reportOtherProcesses: aBoolean. >> result := node spyEvery: self defaultPollPeriod on: aBlock. >> >> openResultWindow ifTrue: >> [ (CodeHolder new contents: (String streamContents: [:s | node report: s cutoff: aNumber; close])) >> openLabel: 'Spy Results' wrap: false ]. >> >> ^ node >> "^ result" >> >> spyOn: aBlock reportOtherProcesses: aBoolean cutoff: aNumber openResultWindow: openResultWindow closeAfter: closeAfter >> >> | node result | >> node := self new. >> node reportOtherProcesses: aBoolean. >> result := node spyEvery: self defaultPollPeriod on: aBlock. >> >> openResultWindow ifTrue: >> [ (CodeHolder new contents: (String streamContents: [:s | node report: s cutoff: aNumber])) >> openLabel: 'Spy Results' wrap: false ]. >> >> closeAfter ifTrue: [ node close ]. >> >> ^ node >> "^ result" >> >> It is a good idea to have some tests. Now maybe you should not rely on float printString but >> one a mock class else if we change float printing these tests will break. >> >> Stef >> >> >> On Mar 16, 2010, at 2:15 AM, Alexandre Bergel wrote: >> >>> Waiting in PharoInbox. This fix has been developed in a 11271. >>> >>> SLICE-MessageTallyCleaningAndTest-Alexandre_Bergel.1 >>> >>> >>> This slices comprises an update for two packages, Tools and ToolsTest. >>> The new version of Tools clean MessageTally. A user of MessageTally may now decide whether he >>> wants to close the tally. Although it is convenient to close it (in order to not keep a reference of the >>> compiled method and the class), this behavior is not always wished. Especially when test have to be >>> written! >>> The user has now the option to not open the result window. >>> >>> ToolsTest contains few and simple tests. >>> >>> Cheers, >>> Alexandre >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> 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 >> >> >> _______________________________________________ >> 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

March 16, 2010

Re: [Pharo-project] BTree packaging

by StÃ©phane Ducasse

On Mar 16, 2010, at 7:16 PM, Chris Muller wrote: > Hi Lukas, are there plans to include BTree standard in the Pharo > image? I was just wondering whether that was why the package is named > Collections-BTree, or if you would renaming it to simply BTree. > > It's mostly intangible that I have a dirty Collections package in many > image (because I often use BTree). Except that, I do find myself > sometimes checking in Monticello, "did I change something in > Collections? Oh, no, it's just BTree.. Or is it? Let me scroll this > list to be sure....." :) Kind of inconvenient, kind of inconsistent > for an external package. What do you think? MC is from time to time marking dirty packages are not. But in your case is it that? Or is there some methods compiled? For the inclusion into pharo here is my take: - if this is important for some internal applications we can the idea is that we copy but lukas keeps control and we merge from time to time as we do with gofer. - Now our goal is to make Pharo-Core smaller and smaller (but slowly) so probably BTree should not be in the core but it could be a package to load into the pharo (core + maintained by us package) or Pharo-dev (core+ maintainedby us + external). Now once we get a nice map of published packages for a release (aka universe browser) it should be easier for people to find/load.... packages. Stef

March 16, 2010

Re: [Pharo-project] About long tests.

by Jorge Ressia

Sorry Stef, couldn't resist :) Now there is a distinction between unit tests and the rest of them. Unit tests are depicted as fast and model oriented tests. Later we will have to introduce more kinds of test for enriching our build and development process, tests like functional, architectural, lint, etc. 6942 unit tests run in 34 secs instead than 2:25 min running all tests. I think this will encourage developers to run the tests a little more often. I implemented a fix in the next slice. Name: SLICE-FastAndSlowTestDisociation-JorgeRessia.1 Author: JorgeRessia Time: 16 March 2010, 8:50:41 pm UUID: 9c44289b-bccb-4198-9a98-6dd9979e9bdd Ancestors: Dependencies: Gofer-Tests-JorgeRessia.117, KernelTests-JorgeRessia.164, SUnit-JorgeRessia.86, SUnitGUI-JorgeRessia.45, Tests-JorgeRessia.48 Test cases now answer the message isUnitTest in order to differentiate the unit test from the rest of the tests. - The tests that take too long are no more considered unit tests. - Some test were functional test so there are not considered unit tests. - The TestRunner was modified. A new menu entry can be found in the class pane for selecting all unit tests. Some more fixes here: Name: SLICE-FastAndSlowTestDisociation-JorgeRessia.2 Author: JorgeRessia Time: 16 March 2010, 8:58:11 pm UUID: 86461af2-534b-4091-8f2e-973b650db098 Ancestors: SLICE-FastAndSlowTestDisociation-JorgeRessia.1 Dependencies: Gofer-Tests-JorgeRessia.117, KernelTests-JorgeRessia.164, SUnit-JorgeRessia.87, SUnitGUI-JorgeRessia.45, Tests-JorgeRessia.48 - test fixed Cheers, Jorge On Tue, Mar 16, 2010 at 3:18 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > focus on the paper jorge coding only for the fun :) > We have time. > > Stef > > On Mar 16, 2010, at 9:35 AM, Jorge Ressia wrote: > >> Hi, >> >> No, I have to finish that. Is still in my todo list. >> I'll try to make some time today to look into that. >> >> Cheers, >> >> Jorge >> >> On Tue, Mar 16, 2010 at 9:32 AM, Adrian Lienhard <adi(a)netstyle.ch> wrote: >>> Yes, it would be very good to have faster tests. In my experience, if tests take too long to run, you don't use them. >>> >>> During the sprint in Lille, Jorge started to sort out long running tests from the rest and make them subclass from SlowTestCase (or something similar). >>> >>> Cheers, >>> Adrian >>> >>> >>> On Mar 16, 2010, at 09:13 , Lukas Renggli wrote: >>> >>>> Btw, I am running the Pharo tests in my builds now too: >>>> >>>> Â Â http://hudson.lukas-renggli.ch/job/Pharo/lastCompletedBuild/testReport/(roo… >>>> >>>> Click on duration twice to see the tests sorted by run-time. I feel a >>>> bit bad that the slowest test case is one that I wrote. I'll see if I >>>> can speed that up some more. >>>> >>>> Lukas >>>> >>>> On 15 March 2010 20:56, stephane ducasse <stephane.ducasse(a)free.fr> wrote: >>>>> Hi jorge >>>>> >>>>> did you publish the cleans for the tests you did during the sprint? >>>>> >>>>> Thanks Stef >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>> >>>> >>>> >>>> -- >>>> Lukas Renggli >>>> http://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 >

March 16, 2010