- Pharo-dev - lists.pharo.org

Re: [Pharo-project] About trait mop

by Alexandre Bergel

> 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 10, 2008

Re: [Pharo-project] would be good to check the brekapoint behavior

by Marcus Denker

On 09.10.2008, at 21:12, StÃ©phane Ducasse wrote: > do you know if this code in ok for pharo? > The fix I posted? Yes, we should add that and later then see if it makes sense to keep the whole breakpoint implemenation or not. Marcus > Stef > > On Oct 9, 2008, at 8:40 PM, Marcus Denker wrote: > >> >> On 09.10.2008, at 18:37, StÃ©phane Ducasse wrote: >> >>> Hi marcus >>> >>> you told me once that they was a breakpoint support in squeak. >>> It would be great to have it because removing self halt in the >>> code is a pain. >>> >> >> There is a very simple breakpoint mechanism in Squeak. It allows to >> set breakpoints >> on method entry, and clear all at once. >> >> There is an enty in the menu in the browser to toggle the >> breakpoint, attached is a >> changeset that fixes some small things so that it actually works. >> >> >> <BreakPointFixes.1.cs> >> >> >> >> The whole implementation is maybe a bit too simple, though. On the >> other hand, it's a start. >> >> Marcus >> >> >> -- >> Marcus Denker -- denker(a)iam.unibe.ch >> http://www.iam.unibe.ch/~denker >> >> _______________________________________________ >> 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 -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Oct. 10, 2008

Re: [Pharo-project] Installer refactor

by StÃ©phane Ducasse

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? Stef On Oct 10, 2008, at 4:24 AM, 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 >

Oct. 10, 2008

Re: [Pharo-project] using this mailing list

by StÃ©phane Ducasse

On Oct 9, 2008, at 10:44 PM, nicolas cellier wrote: > > Apologies for previous ugly formatted post... > I have problems using this mailing list because: > > 1) I do not receive the posts directly (ncellier at ifrance dot com) > I tried twice to subscribe, but did not receive any answer This is strange since you are in the list ncellier(a)ifrance.com The mailing-list is pharo-project(a)lists.gforge.inria.fr I will remove pharo-devl > 2) I can not use news.gmane.org through thunderbird like other > squeak lists > Why? Can you check again. > > > 3) I can not use http://blog.gmane.org/gmane.comp.lang.smalltalk.pharo.devel > It does not seem to be updated frequently enough. > > If someone could fix one of these problems, that would be super cool. > > Nicolas > > _______________________________________________ > 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] using this mailing list

by StÃ©phane Ducasse

This is strange we will check. Stef On Oct 9, 2008, at 10:44 PM, nicolas cellier wrote: > > Apologies for previous ugly formatted post... > I have problems using this mailing list because: > > 1) I do not receive the posts directly (ncellier at ifrance dot com) > I tried twice to subscribe, but did not receive any answer > > 2) I can not use news.gmane.org through thunderbird like other > squeak lists > Why? > > 3) I can not use http://blog.gmane.org/gmane.comp.lang.smalltalk.pharo.devel > It does not seem to be updated frequently enough. > > If someone could fix one of these problems, that would be super cool. > > Nicolas > > _______________________________________________ > 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] [ANN] 10091

by StÃ©phane Ducasse

Thanks this is great mail! Stef On Oct 9, 2008, at 10:18 PM, 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

[Pharo-project] Installer refactor

by Matthew Fulmer

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/

Oct. 10, 2008

[Pharo-project] using this mailing list

by nicolas cellier

Apologies for previous ugly formatted post... I have problems using this mailing list because: 1) I do not receive the posts directly (ncellier at ifrance dot com) I tried twice to subscribe, but did not receive any answer 2) I can not use news.gmane.org through thunderbird like other squeak lists Why? 3) I can not use http://blog.gmane.org/gmane.comp.lang.smalltalk.pharo.devel It does not seem to be updated frequently enough. If someone could fix one of these problems, that would be super cool. Nicolas

Oct. 9, 2008

[Pharo-project] [ANN] 10091

by nicolas cellier

>>/ 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> />/ 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... /

Oct. 9, 2008

Re: [Pharo-project] would be good to check the brekapoint behavior

by StÃ©phane Ducasse

do you know if this code in ok for pharo? Stef On Oct 9, 2008, at 8:40 PM, Marcus Denker wrote: > > On 09.10.2008, at 18:37, StÃ©phane Ducasse wrote: > >> Hi marcus >> >> you told me once that they was a breakpoint support in squeak. >> It would be great to have it because removing self halt in the code >> is a pain. >> > > There is a very simple breakpoint mechanism in Squeak. It allows to > set breakpoints > on method entry, and clear all at once. > > There is an enty in the menu in the browser to toggle the > breakpoint, attached is a > changeset that fixes some small things so that it actually works. > > > <BreakPointFixes.1.cs> > > > > The whole implementation is maybe a bit too simple, though. On the > other hand, it's a start. > > Marcus > > > -- > Marcus Denker -- denker(a)iam.unibe.ch > http://www.iam.unibe.ch/~denker > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 9, 2008