- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Installer refactor

by StÃ©phane Ducasse

On Oct 10, 2008, at 10:27 AM, Matthew Fulmer wrote: > On Fri, Oct 10, 2008 at 07:31:23AM +0200, St?phane Ducasse wrote: >> Excellent! >> I will look at that. >> I never thought there were 14 classes :) >> >> You added aslo a factory? >> so that Installer squeaksource still work I imagine? > > But of course! it wouldn't be installer if the syntax changed. :) I will have to have a look at the code :) I plan to harvest some kernel extensions as soon as I have some time after the etoy cleanup. I would like to be able to get rid of PLF for loading MC1.6 or friend. > > It still runs LPF fine, which is the main thing > > -- > Matthew Fulmer -- http://mtfulmer.wordpress.com/ > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 10, 2008

Re: [Pharo-project] About trait mop

by StÃ©phane Ducasse

> > > I had a look and I like it, so I'll try to make your tests pass ;). > > I don't agree with the following, though: > >> self assert: (D>>#c3) origin = D. "this is a question because it >> could be " > > here I think it should be Trait2, not D. The alias c3->c2 does not > redefine the method in the class; the method still originates in > Trait2. Not really :) we discussed a lot with marcus and I think that I have a point :) the point is that since Compiled Method are copied so c3 is really different from c2 and c3 is not defined in Trait2 but this is realy because there is D that C3 exists. so tell me what you think. Stef > > > So: (D>>#c3) origin = Trait2. > Just like: (D>>#c2) origin = Trait2. > > Adrian > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 10, 2008

Re: [Pharo-project] History and SUnit

by Alexandre Bergel

> I tried your extension and have the following questions/problems: > - when I first run all the tests in the system, I get 4 failures (as > expected) but the bar on top stays green where it should be yellow > (it worked before) that's strange. I run all the test, and it turns yellow saying: "10 October 2008 1:07:37 pm 2286 run, 2279 passes, 4 expected failures, 3 failures, 0 errors, 0 unexpected passes" > - I don't understand the "Progress" feature. What I did is run the > tests, then "Store results", then I fixed a failing test, then "Run > Failures", then "Show progress". But nothing happens. Maybe I did > something wrong? Result is displayed in the Transcript. Sorry to not have said it before. We though first about opening a workspace with the result inside, but I did not find an easy way to do it. So, for now, it prints in the Transcript. Cheers, Alexandre > > On Oct 1, 2008, at 16:56 , Alexandre Bergel wrote: > >> Dear list, >> >> In PharoInbox Gwenael and I put an extension of SUnit that records >> results when running a set of test. >> Feel free to suggest improvement.... >> >> Open a TestRunner to enjoy its 'History' button. >> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 10, 2008

Re: [Pharo-project] [ANN] 10091

by Adrian Lienhard

Thanks for the explanation, Nicolas! This sounds reasonable. This kind of conclusion was missing for me when I read through the different bug reports on Mantis. Adrian On Oct 9, 2008, at 22:18 , nicolas cellier wrote: > >> http://bugs.squeak.org/view.php?id=7180 +6455 +1603 +1602 > >> > >> Patches for Interval indexOf: and includes: > > > > I wonder about these fixes because of http://code.google.com/p/pharo/issues/detail?id=35 > > > > Did you reconsider the correctness of these fixes? They seem > > complicated and after reading through the bug reports again > > (especially http://bugs.squeak.org/view.php?id=7180) I concluded > > that they may introduce more problems than they fix. > I know I tried to find my way there too. > Now I trusted nicolas. > Nicolas are you strong on these fixes? > > Stef > > > > > > > Adrian > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project at lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > Thank you Stef. > Yes, the fix is safe. > I develop here after these 3 points > A)- The code was wrong > B)- Discussions were too long, but the fixes are very easy > C)- library could be enhanced > > Adrian, hope I will convince you (also, read the code). > > Cheers > > Nicolas > > > > > A) The code was wrong > > Prior this patch: > - #includes: implementation were WRONG. > - #indexOf: was missing, falling back to naive super slow > implementation > > Try these two tests in any Squeak image of your choice (3.7 to: 3.10): > > "There is no reason that the first is true while the second is false" > {(Float pi to: 4*Float pi by: Float pi) includes: Float pi*2 + > 1.0e-11. > (Float pi to: 4*Float pi by: Float pi) includes: Float pi*2 - > 1.0e-11}. > > "There is no reason for this timeToRun to grow" > (1 to: 7) collect: [:i | > [(1 to: 10000000) indexOf: (10 raisedTo: i)] timeToRun] > > > > B)- the fixes are very easy > > I simply implemented indexOf: with same algorithm as #includes: > (corrected!). > Then removed includes: because super includes: is implemented > sending indexOf: > Then I removed valueIncludes: because includes: was sole sender. > You see, two methods removed, one fix added: no revolution > > > > C)- library could be enhanced > > What I would prefer is: > - implement a method with an argument so that user can choose > comparison tolerance > - expand this fuzzy inclusion test to any other collection > Maybe something like: > includes: aNumber moreOrLess: aTolerance. > Then Interval includes: could eventually use a default tolerance. > But the obvious bugs must first be corrected... > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 10, 2008

Re: [Pharo-project] Installer refactor

by Matthew Fulmer

On Fri, Oct 10, 2008 at 07:31:23AM +0200, St?phane Ducasse wrote: > Excellent! > I will look at that. > I never thought there were 14 classes :) > > You added aslo a factory? > so that Installer squeaksource still work I imagine? But of course! it wouldn't be installer if the syntax changed. It still runs LPF fine, which is the main thing -- Matthew Fulmer -- http://mtfulmer.wordpress.com/

Oct. 10, 2008

Re: [Pharo-project] History and SUnit

by Adrian Lienhard

Hi Alex, I tried your extension and have the following questions/problems: - when I first run all the tests in the system, I get 4 failures (as expected) but the bar on top stays green where it should be yellow (it worked before) - I don't understand the "Progress" feature. What I did is run the tests, then "Store results", then I fixed a failing test, then "Run Failures", then "Show progress". But nothing happens. Maybe I did something wrong? Thanks, Adrian On Oct 1, 2008, at 16:56 , Alexandre Bergel wrote: > Dear list, > > In PharoInbox Gwenael and I put an extension of SUnit that records > results when running a set of test. > Feel free to suggest improvement.... > > Open a TestRunner to enjoy its 'History' button. > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > 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

Oct. 10, 2008

Re: [Pharo-project] About trait mop

by Adrian Lienhard

Hi Stef, I had a look and I like it, so I'll try to make your tests pass ;). I don't agree with the following, though: > self assert: (D>>#c3) origin = D. "this is a question because it > could be " here I think it should be Trait2, not D. The alias c3->c2 does not redefine the method in the class; the method still originates in Trait2. So: (D>>#c3) origin = Trait2. Just like: (D>>#c2) origin = Trait2. Adrian

Oct. 10, 2008

Re: [Pharo-project] Installer refactor

by Alexandre Bergel

Excellent!!! Alexandre On 10 Oct 2008, at 04:24, Matthew Fulmer wrote: > I spent most of the day yesterday refactoring Installer. I split > it up into 14 classes, so now it should be a bit easier to > understand. I'll fix badly categorized methods and add some > comments. > > -- > Matthew Fulmer -- http://mtfulmer.wordpress.com/ > > _______________________________________________ > 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 10, 2008

Re: [Pharo-project] Monticello: an idealist question

by Alexandre Bergel

Hi! I gave a try few years ago: http://www.squeaksource.com/PackagesForSqueak The last version is: Package-alexandrebergel.56.mcz I also did an experiment to have binary format for packages in .mcz, instead of text source. Cheers, Alexandre On 9 Oct 2008, at 01:52, Bill Schwab wrote: > Colin, > > Among many useful things in Dolphin is an ability to assign multiple > categories to any given method; Squeak and Pharo allow only one > category, and it promptly gets chewed up by PackageInfo. Multiple > categories would be a nice addition to Squeak and Pharo. > > How hard would it be to change Monticello to take its input not from > PackageInfo and its (pardon me) abuse of category names, but from > reifications of the categories? The new objects would form the basis > for packaging system, and free method categories to do what they do > best: aid in browsing and understanding code. > > In transition, a future version of Monticello could create the needed > objects using the same rules as PackageInfo (or any time it is > instructed to do so). > > Comments? > > Bill > > > > > Wilhelm K. Schwab, Ph.D. > University of Florida > Department of Anesthesiology > PO Box 100254 > Gainesville, FL 32610-0254 > > Email: bschwab(a)anest.ufl.edu > Tel: (352) 273-6785 > FAX: (352) 392-7029 > > > _______________________________________________ > 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 10, 2008

Re: [Pharo-project] About trait mop

by StÃ©phane Ducasse

We change it with marcus Now we do not have reachHome. If you want to know load the MopTraits package in PharoTaskForces in the manifesto package you can get a nice UML diagram showing the config used for the tests :) Here are the test testClass "self debug: #testClass" "The class of a compiled method is the class that contains it. A compiled method is shared." "methodClass could call -> methodClassOrTrait" self assert: (Trait1>>#c) methodClass = Trait1. self assert: (Trait2>>#c) methodClass = Trait2. self assert: (C>>#c) methodClass = C. self assert: (C>>#c2) methodClass = C. self assert: (D>>#c) methodClass = D. self assert: (D>>#c2) methodClass = D. self assert: (D>>#c3) methodClass = D. self assert: (A>>#c2) methodClass = A. testOrigin "self debug: #testClass" "The origin of a compiledMethod is its defining class or trait." self assert: (C>>#c) origin = C. self assert: (A>>#c) origin = Trait3. self assert: (Trait3>>#c2) origin = Trait2. self assert: (A>>#c2) origin = Trait2. self assert: (B>>#c) origin = Trait1. self assert: (D>>#c3) origin = D. "this is a question because it could be " self assert: (D>>#c2) origin = Trait2. testSelector "self debug: #testSelector" "The selector of a compiled method should be its name. An aliased method should have the name of its alias name." self assert: (A>>#c) selector = #c. self assert: (C>>#c) selector = #c. self assert: (Trait3>>#c) selector = #c. self assert: (Trait3>>#c2) selector = #c2. self assert: (D>>#c3) selector = #c3. On Oct 10, 2008, at 9:10 AM, Alexandre Bergel wrote: >> we have >> >> - The selector of a compiled method should be its name. >> An aliased method should have the name of its alias name. >> - The class of a compiled method is the class that contains it. >> A compiled method cannot be shared. >> - The origin of a compiledMethod is its defining class or trait. >> >> - The reachHome of a compiled method is class or traits that you >> changed >> (and not override) when you want to change a method in the flat >> view. > > > It makes sense to me. > What the reachHome is for? > > Alexandre > > > >> >> >> T1 >> c >> c1 >> T2 >> c >> c3 >> uses: T1 >> Class A >> foo >> uses: T2 >> >> testSelectorT11T2 >> "self debug: #testSelectorT11T2" >> "The selector of a compiled method should be its name. >> An aliased method should have the name of its alias name." >> >> self assert: (AUsingTrait2>>#foo) selector = #foo. >> self assert: (Trait1>>#c) selector = #c. >> self assert: (Trait2>>#c) selector = #c. >> self assert: (AUsingTrait2>>#c) selector = #c. >> self assert: (AUsingTrait2>>#c3) selector = #c2. >> self assert: (BUsingTrait1>>#c) selector = #c. >> >> testClassT11T2 >> "The class of a compiled method is the class that contains it. >> A compiled method cannot be shared." >> >> self assert: (AUsingTrait2>>#foo) methodClass = AUsingTrait2. >> self assert: (AUsingTrait2>>#c) methodClass = AUsingTrait2. >> self assert: (AUsingTrait1>>#c3) methodClass = AUsingTrait2. >> self assert: (AUsingTrait2>>#c1) methodClass = AUsingTrait2. >> self assert: (BUsingTrait1>>#c) methodClass = BUsingTrait1. >> >> self should: (Trait1>>#c1) methodClass = nil. "T1 or nil" >> self should: (Trait2>>#c2) methodClass = nil. "T2 or nil" >> self should: (Trait2>>#c1) methodClass = nil. "T2 or nil or T1" >> >> >> >> >> >> >> >> >> >> >> testReachHome >> "self debug: #testReachHome" >> " The reachHome is the method that you changed >> (and not override) when you want to change a method in the flat >> view." >> >> self assert: (AUsingTrait2>>#foo) reachHome = AUsingTrait2. >> self assert: (AUsingTrait2>>#c3) reachHome = Trait2. >> self assert: (AUsingTrait2>>#c1) reachHome = Trait1. >> >> self assert: (AUsingTrait2>>#c) reachHome = Trait2. >> >> self assert: (Trait11>>#c) reachHome = Trait11. >> self assert: (Trait2>>#c) reachHome = Trait2. >> self assert: (Trait2>>#c1) reachHome = Trait11. >> >> >> self assert: (AUsingTrait1>>#c2) reachHome = AUsingTrait1. >> >> >> testOrigin >> "self debug: #testClass" >> "The origin of a compiledMethod is its defining class or trait." >> >> self assert: (AUsingTrait2>>#foo) origin = AUsingTrait2. >> self assert: (AUsingTrait2>>#c3) origin = Trait2. >> self assert: (AUsingTrait2>>#c1) origin = Trait11. >> >> self assert: (AUsingTrait2>>#c) origin = Trait11. >> >> >> self assert: (BUsingTrait1>>#c) origin = Trait1. >> >> self assert: (Trait2>>#c3) origin = Trait2. >> self assert: (Trait11>>#c1) origin = Trait11. >> self assert: (Trait2>>#c1) origin = Trait11. >> >> "since it introduced the alias it is its origin" >> self assert: (AUsingTrait1>>#c2) origin = AUsingTrait1. >> >> >> >> >> testTraitT11T2 >> >> "it seems to me that we do not need trait: but we need origin and >> reachHome" >> >> "(A>>foo) trait -> nil >> (A>>c3) trait -> T2 >> (A>>c) trait -> T2 >> (A>>c1) trait -> T2 ***** since it is flat >> (T1>>c1) trait -> ???? T1 or nil >> (T2>>c1) trait >> (T2>>c2) trait -> ???? T2 or nil" >> >> self assert: (AUsingTrait2>>#foo) trait isNil. >> >> self assert: (AUsingTrait2>>#c3) trait = Trait2 >> >> >> _______________________________________________ >> 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 >

Oct. 10, 2008