October 2008 - Pharo-dev - lists.pharo.org

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

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