- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Fwd: semantics of overrides

by StÃ©phane Ducasse

On Dec 23, 2009, at 1:15 PM, Lukas Renggli wrote: >>>>> May be this is MC that does this? Does anybody knows about it? >>> >>> MC uses the changes file to restore methods that are put into an >>> *packagename-override protocol, see MCMethodDefinition>>#unload. >>> Practically this does not work, because it makes all kind of generally >>> invalid assumptions. >> >> Thanks lukas. >> OK I have the impression that the package should know m1 is an override >> and when I unload I should put back the method I overrode but > > That is not that simple, because packages can be unloaded in a > different order they are installed. yes this was my example. > I think a better strategy is to > allow methods to be defined in multiple packages. I have that in RPackage but not the unload semantics and tagging of override

Dec. 23, 2009

[Pharo-project] What is the status of the methodTrailer

by StÃ©phane Ducasse

Igor I saw that method trailer were pushed into squeak. Do you plan to provide us a version for pharo? Or will we have to dig into squeak? Stef

Dec. 23, 2009

Re: [Pharo-project] Fwd: [squeak-dev] The Trunk: Collections-ul.260.mcz

by StÃ©phane Ducasse

http://code.google.com/p/pharo/issues/detail?id=1660 and in the inbox. Stef On Dec 23, 2009, at 1:22 PM, StÃ©phane Ducasse wrote: > Hi Levente > > why don't you help us too? > > Stef > > >> From: commits(a)source.squeak.org >> Date: December 23, 2009 12:29:08 PM GMT+01:00 >> To: squeak-dev(a)lists.squeakfoundation.org, packages(a)lists.squeakfoundation.org >> Subject: [squeak-dev] The Trunk: Collections-ul.260.mcz >> Reply-To: squeak-dev(a)lists.squeakfoundation.org >> >> Levente Uzonyi uploaded a new version of Collections to project The Trunk: >> http://source.squeak.org/trunk/Collections-ul.260.mcz >> >> ==================== Summary ==================== >> >> Name: Collections-ul.260 >> Author: ul >> Time: 23 December 2009, 12:23:32 pm >> UUID: de4b02f8-b0aa-5e47-93f7-4a3e3c300060 >> Ancestors: Collections-ul.259 >> >> - make sure that SortedCollection's #sort and #sort: update the sortBlock >> >> =============== Diff against Collections-ul.259 =============== >> >> Item was added: >> + ----- Method: SortedCollection>>sort: (in category 'sorting') ----- >> + sort: aSortBlock >> + "Sort this collection using aSortBlock. The block should take two arguments >> + and return true if the first element should preceed the second one. >> + If aSortBlock is nil then <= is used for comparison." >> + >> + super sort: aSortBlock. >> + sortBlock := aSortBlock! >> >> > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 23, 2009

[Pharo-project] Fwd: [squeak-dev] The Trunk: Collections-ul.260.mcz

by StÃ©phane Ducasse

Hi Levente why don't you help us too? Stef > From: commits(a)source.squeak.org > Date: December 23, 2009 12:29:08 PM GMT+01:00 > To: squeak-dev(a)lists.squeakfoundation.org, packages(a)lists.squeakfoundation.org > Subject: [squeak-dev] The Trunk: Collections-ul.260.mcz > Reply-To: squeak-dev(a)lists.squeakfoundation.org > > Levente Uzonyi uploaded a new version of Collections to project The Trunk: > http://source.squeak.org/trunk/Collections-ul.260.mcz > > ==================== Summary ==================== > > Name: Collections-ul.260 > Author: ul > Time: 23 December 2009, 12:23:32 pm > UUID: de4b02f8-b0aa-5e47-93f7-4a3e3c300060 > Ancestors: Collections-ul.259 > > - make sure that SortedCollection's #sort and #sort: update the sortBlock > > =============== Diff against Collections-ul.259 =============== > > Item was added: > + ----- Method: SortedCollection>>sort: (in category 'sorting') ----- > + sort: aSortBlock > + "Sort this collection using aSortBlock. The block should take two arguments > + and return true if the first element should preceed the second one. > + If aSortBlock is nil then <= is used for comparison." > + > + super sort: aSortBlock. > + sortBlock := aSortBlock! > >

Dec. 23, 2009

Re: [Pharo-project] SUnit

by Simon Denier

On 21 dÃ©c. 2009, at 18:04, StÃ©phane Ducasse wrote: > Hi adrian > > Pleaseeeeeeeee. > I would really like to also > - check what keith did on his Sunit extensions > - have expected failures > - have the possibility to know whether a test was red or green when it was saved and > now when I run it, is it my fault or what is just before like that This feature already exists in the TestRunner, unfortunately it is not well-known (as many features hidden in contextual menu) and not well integrated as you have to run tests through the test runner (I guess many people directly ran their test through the browser nowadays). So my point is: be careful about UI integration, but I guess that rethinking a bit the SUnit core to have the history allow us to remove the current hack. -- Simon

Dec. 23, 2009

Re: [Pharo-project] Fwd: semantics of overrides

by Lukas Renggli

>>>> May be this is MC that does this? Does anybody knows about it? >> >> MC uses the changes file to restore methods that are put into an >> *packagename-override protocol, see MCMethodDefinition>>#unload. >> Practically this does not work, because it makes all kind of generally >> invalid assumptions. > > Thanks lukas. > OK I have the impression that the package should know m1 is an override > and when I unload I should put back the method I overrode but That is not that simple, because packages can be unloaded in a different order they are installed. I think a better strategy is to allow methods to be defined in multiple packages. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Dec. 23, 2009

Re: [Pharo-project] [update 1.1] #11112

by StÃ©phane Ducasse

Yes! We remove all the updates during the release phase of 1.1 Stef On Dec 23, 2009, at 12:36 PM, Stan Shepherd wrote: > > Thanks Marcus. > > ScriptLoader>>update11086 > "self new update11086" > SystemChangeNotifier uniqueInstance noMoreNotificationsFor: > TheWorldMainDockingBar. > > seems to be holding an obsolete reference to TheWorldMainDockingBar. Do > these methods get cleaned out at some point? > > ...Stan > > > > > Marcus Denker-4 wrote: >> >> 11112 >> ----- >> >> Issue 1652: Behavior >> #allSubclassesDo: depends on #subclassesDo: which >> is defined in Class and friends only >> Thanks, Adrian Kuhn >> Issue 1633: Object allSubInstances appears to loop forever >> Thanks, Eliot Miranda (from Squeak) >> Issue 1655: MethodFinder Fixes >> Thanks, Bert Freudenberg (from Squeak) >> Issue 1654: SpeedUpCommandHistory >> Thanks, Eliot Miranda (from Squeak) >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> > > -- > View this message in context: http://n2.nabble.com/update-1-1-11112-tp4207680p4208235.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

Dec. 23, 2009

Re: [Pharo-project] Fwd: A design question

by StÃ©phane Ducasse

On Dec 23, 2009, at 12:35 PM, Henrik Johansen wrote: > > On Dec 23, 2009, at 12:30 51PM, Alexandre Bergel wrote: > >>> Ok but in that case I do not tests the behavior on class >>> But this is an idea (Now I generate all the classes on the fly so I >>> would have >>> to compile all the methods). >> >> In that case, you cannot test your behavior on existing class. Note >> that you can also in the setUp method recompile >> ClassDescription>>package and reinstall the original version in >> tearDown. >> >> Cheers, >> Alexandre > And please remember to use compileSilently: if doing this as part of tests ;) :) Yes I know this is major speed up. > > Cheers, > Henry > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 23, 2009

Re: [Pharo-project] [update 1.1] #11112

by Stan Shepherd

Thanks Marcus. ScriptLoader>>update11086 "self new update11086" SystemChangeNotifier uniqueInstance noMoreNotificationsFor: TheWorldMainDockingBar. seems to be holding an obsolete reference to TheWorldMainDockingBar. Do these methods get cleaned out at some point? ...Stan Marcus Denker-4 wrote: > > 11112 > ----- > > Issue 1652: Behavior >> #allSubclassesDo: depends on #subclassesDo: which > is defined in Class and friends only > Thanks, Adrian Kuhn > Issue 1633: Object allSubInstances appears to loop forever > Thanks, Eliot Miranda (from Squeak) > Issue 1655: MethodFinder Fixes > Thanks, Bert Freudenberg (from Squeak) > Issue 1654: SpeedUpCommandHistory > Thanks, Eliot Miranda (from Squeak) > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- View this message in context: http://n2.nabble.com/update-1-1-11112-tp4207680p4208235.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 23, 2009

Re: [Pharo-project] Fwd: A design question

by Henrik Johansen

On Dec 23, 2009, at 12:30 51PM, Alexandre Bergel wrote: >> Ok but in that case I do not tests the behavior on class >> But this is an idea (Now I generate all the classes on the fly so I >> would have >> to compile all the methods). > > In that case, you cannot test your behavior on existing class. Note > that you can also in the setUp method recompile > ClassDescription>>package and reinstall the original version in > tearDown. > > Cheers, > Alexandre And please remember to use compileSilently: if doing this as part of tests ;) Cheers, Henry

Dec. 23, 2009