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

Re: [Pharo-project] Traits...

by Adrian Lienhard

I found it... Adrian > From: Adrian Lienhard <alienhard(a)netstyle.ch> > Date: October 13, 2006 3:10:18 PM GMT+02:00 > To: tim Rowledge <tim(a)rowledge.org> > Cc: Marcus Denker <denker(a)iam.unibe.ch> > Subject: Re: sq 3.9 compiledmethod #sourceClass and #methodClass > > Hi Tim, > > With respect to the sharing of methods between traits and its users, > its a bit more complicated than what I thought yesterday evening... > I had a closer look now. So, I changed how methods are propagated > from traits to their users as follows. Compiled methods are not > shared anymore. As a result the methodClass of a method is correct > in all cases (that is, the class in which the method is installed > rather in which it is defined). Before installing a method from a > trait, it is copied (including copying of its method properties). > This means, we do not need to recompile at all. As a consequence, > the copied and the original method share its sources, i.e., they > have the identical source pointer. > > To install my changes in a recent 3.9 image I created a changeset > (note, the order is done by hand to make it load...). Then, the > following code should fix up all existing methods to comply with the > new strategy: > > TraitDescription allSubInstancesDo: [ :each | > each notifyUsersOfChangedSelectors: each selectors ]. > TPureBehavior compileAll > > The last statement fixes wrong methodClass references in local > methods of TPureBehavior (this is something else, but when we are at > it, lets fix that too) > > The following code tests whether all users of a trait have correct > methodClass bindings. > > behaviorsUsingTraits := (TraitDescription allSubInstances gather: > [:each | each users]) asSet. > behaviorsUsingTraits do: [ :each | > each selectorsDo: [ :selector | > (each >> selector) methodClass == each ifFalse: [ > Transcript show: each name , '>>' , selector , ' ---methodClass: > ' , > (each >> selector) methodClass name ] ] ] > > > > I've committed the code in the SqueakSource Trait repository, the > one I work with before pushing stuff over to the 3.9 repository for > inclusion. If you have changes you can commit directly into this > repository. > > MCHttpRepository > location: 'http://squeaksource.com/Traits' > user: 'squeak' > password: 'squeak' > > The versions corresponding with the changes loaded by the cs are: > Kernel-al.149 > Traits-al.226 > > All my traits-tests (68) run green, however, I've not further tested > this. > > There is one problem I can think of right now: when moving sources > and condensing changes only those methods are processed which are > defined locally (that is, which do not come from a trait) to make > sure the same source is not moved twice (see for example > #fileOutCategory:on:moveSource:toFile:). Now, in case of moving > sources the source pointers are changed (see > #printMethodChunk:withPreamble:on:moveSource:toFile:). Methods from > traits in this case, since they are excluded, will still point to > the old position! > > Cheers, > Adrian On Aug 20, 2008, at 16:40 , StÃ©phane Ducasse wrote: > If you find it please send it ;) > > On Aug 20, 2008, at 4:32 PM, Adrian Lienhard wrote: > >> That shouldn't be hard. >> >> I even did it some time ago because Tim asked me as he was working >> on a new source management. As it goes, this code was never >> integrated but it should be around somewhere (I think I mailed it >> also to Marcus). >> >> Adrian >> >> On Aug 20, 2008, at 16:20 , Alexandre Bergel wrote: >> >>> Hi! >>> >>> Marcus, Stef and I were wondering whether there is fix for copying >>> compile methods instead of sharing when using traits. >>> The idea is to prevent a shared compiled method to answer wrongly >>> when asking for its properties, class belonging ... >>> >>> 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 >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 20, 2008

Re: [Pharo-project] Bigger than Squeak?

by Adrian Lienhard

Thanks, I forgot about the changesets! After "ScriptLoader new cleaningCS" the size of my Pharo 10061 image drops to 13.3MB on disk. Not bad. Adrian ___________________ http://www.adrian-lienhard.ch/ On Aug 20, 2008, at 16:38 , Marcus Denker wrote: > > On 20.08.2008, at 15:13, Adrian Lienhard wrote: > >> Pharo images should be smaller than 3.9.1 images since code was >> removed. The Pharo image 10061 that I build from the very beginning >> through the update stream is 14.2 MB after I did the following >> cleanup (can you try if it helps? I guess MC holds versions in its >> cache). Squeak 3.9.1 final is 15.6 MB. I don't understand how you >> get images that are smaller than 10MB? >> > > > Didyou try to remove all changesets? I think these take quite some > space... > > Marcus > >> Adrian >> >> >> >> RequiredSelectors initialize. >> >> ProvidedSelectors initialize. >> >> LocalSends initialize. >> >> Utilities cleanseOtherworldlySteppers. >> >> Smalltalk organization removeEmptyCategories. >> >> SystemBrowser removeObsolete. >> >> TheWorldMenu removeObsolete. >> >> AppRegistry removeObsolete. >> >> SystemNavigation default obsoleteBehaviors. >> >> MCFileBasedRepository flushAllCaches. >> >> MCDefinition clearInstances. >> >> Symbol compactSymbolTable. >> >> Set rehashAllSets. >> >> Smalltalk garbageCollect. >> >> >> >> On Aug 20, 2008, at 14:54 , Damien Cassou wrote: >> >>> Hi, >>> >>> according to stats I did about Squeak and Pharo >>> (http://damiencassou.dabbledb.com/publish/dev-imagesdownloads) >>> Pharo >>> images are always bigger than Squeak images. This does not seem to >>> be >>> related to the dev-images themselves because the latest base Pharo >>> image is bigger (8.79 MB) than Squeak 3.10.2 (7.1MB) and Squeak >>> 3.9.1 >>> (also 7.1MB). >>> >>> Is there any method to call to clean the image? Would be interesting >>> to systematically clean the releases you build. >>> >>> Bye >>> >>> -- >>> Damien Cassou >>> Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good >>> luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu) >>> _______________________________________________ >>> 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 20, 2008

Re: [Pharo-project] New pharo-dev based on latest version

by laurent laffont

test report: http://www.adhocmusic.net/squeak/pharo0.1-10061dev08.08.2.tests.html passed: 3419 failures: 42 errors: 41 As for pharo-web & squeak images I had to delete: MCPackageTest>>#testUnload {tests} RxPaserTest>>#testMatchesInwW and also (this is new, regression ?): MCFileInTest>>testStWriter On Wed, Aug 20, 2008 at 3:26 PM, Damien Cassou <damien.cassou(a)gmail.com>wrote: > I've just published a new pharo-dev version on: > http://code.google.com/p/pharo/wiki/Downloads?tm=2. It is based on > version 10061. > > -- > Damien Cassou > Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good > luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu) > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- Laurent Laffont <l.laffont(a)temis-france.com> TEMIS 48, Avenue Jean JaurÃ¨s 74800 La Roche sur Foron TÃ©l. : 04 50 97 49 91 Fax : 04 50 97 49 94 http://www.temis-france.com

Aug. 20, 2008

Re: [Pharo-project] LargePositiveInteger new: 4 => crash

by StÃ©phane Ducasse

Nicolas sent me a fix we will integrate it. Stef On Aug 20, 2008, at 3:06 PM, Adrian Lienhard wrote: > This is due to the changes introduced by > > http://code.google.com/p/pharo/issues/detail?id=114 > > Printing not initialized Large*Integers does not work anymore. I > don't know whether this is important because in practice you > probably neven have such instances. We can either implement the old > behavior or remove the tests. What do others think? > > Adrian > > > On Aug 20, 2008, at 14:08 , StÃ©phane Ducasse wrote: > >> Hi >> >> I checked and between 10050 and 10055 >> we introduce a bug >> >> LargePositiveInteger new: 4 >> >> Stef >> >> _______________________________________________ >> 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 >

Aug. 20, 2008

Re: [Pharo-project] Traits...

by StÃ©phane Ducasse

If you find it please send it ;) On Aug 20, 2008, at 4:32 PM, Adrian Lienhard wrote: > That shouldn't be hard. > > I even did it some time ago because Tim asked me as he was working > on a new source management. As it goes, this code was never > integrated but it should be around somewhere (I think I mailed it > also to Marcus). > > Adrian > > On Aug 20, 2008, at 16:20 , Alexandre Bergel wrote: > >> Hi! >> >> Marcus, Stef and I were wondering whether there is fix for copying >> compile methods instead of sharing when using traits. >> The idea is to prevent a shared compiled method to answer wrongly >> when asking for its properties, class belonging ... >> >> 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 >

Aug. 20, 2008

Re: [Pharo-project] Bigger than Squeak?

by Marcus Denker

On 20.08.2008, at 15:13, Adrian Lienhard wrote: > Pharo images should be smaller than 3.9.1 images since code was > removed. The Pharo image 10061 that I build from the very beginning > through the update stream is 14.2 MB after I did the following > cleanup (can you try if it helps? I guess MC holds versions in its > cache). Squeak 3.9.1 final is 15.6 MB. I don't understand how you > get images that are smaller than 10MB? > Didyou try to remove all changesets? I think these take quite some space... Marcus > Adrian > > > > RequiredSelectors initialize. > > ProvidedSelectors initialize. > > LocalSends initialize. > > Utilities cleanseOtherworldlySteppers. > > Smalltalk organization removeEmptyCategories. > > SystemBrowser removeObsolete. > > TheWorldMenu removeObsolete. > > AppRegistry removeObsolete. > > SystemNavigation default obsoleteBehaviors. > > MCFileBasedRepository flushAllCaches. > > MCDefinition clearInstances. > > Symbol compactSymbolTable. > > Set rehashAllSets. > > Smalltalk garbageCollect. > > > > On Aug 20, 2008, at 14:54 , Damien Cassou wrote: > >> Hi, >> >> according to stats I did about Squeak and Pharo >> (http://damiencassou.dabbledb.com/publish/dev-imagesdownloads) Pharo >> images are always bigger than Squeak images. This does not seem to be >> related to the dev-images themselves because the latest base Pharo >> image is bigger (8.79 MB) than Squeak 3.10.2 (7.1MB) and Squeak 3.9.1 >> (also 7.1MB). >> >> Is there any method to call to clean the image? Would be interesting >> to systematically clean the releases you build. >> >> Bye >> >> -- >> Damien Cassou >> Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good >> luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu) >> _______________________________________________ >> 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

Aug. 20, 2008

Re: [Pharo-project] Traits...

by StÃ©phane Ducasse

Yes we should do that and do not share the compile method for alias too, just share the source code This way if r is an alias to foo (A>>r) selector should return r and not foo Stef On Aug 20, 2008, at 4:20 PM, Alexandre Bergel wrote: > Hi! > > Marcus, Stef and I were wondering whether there is fix for copying > compile methods instead of sharing when using traits. > The idea is to prevent a shared compiled method to answer wrongly > when asking for its properties, class belonging ... > > 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 >

Aug. 20, 2008

Re: [Pharo-project] Traits...

by Adrian Lienhard

That shouldn't be hard. I even did it some time ago because Tim asked me as he was working on a new source management. As it goes, this code was never integrated but it should be around somewhere (I think I mailed it also to Marcus). Adrian On Aug 20, 2008, at 16:20 , Alexandre Bergel wrote: > Hi! > > Marcus, Stef and I were wondering whether there is fix for copying > compile methods instead of sharing when using traits. > The idea is to prevent a shared compiled method to answer wrongly > when asking for its properties, class belonging ... > > 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

Aug. 20, 2008

[Pharo-project] Fwd: besoin d'un peu d'aide

by StÃ©phane Ducasse

Begin forwarded message: > From: nicolas cellier <ncellier(a)ifrance.com> > Date: August 20, 2008 2:56:22 PM CEDT > To: stephane ducasse <stephane.ducasse(a)free.fr> > Subject: Re: besoin d'un peu d'aide > > stephane ducasse a Ã©crit : >> bonjour nicolas >> >> dans pharo on a un probleme avec un le print de largepositiveInteger. >> Si tu pouvais jeter un oeil cela nous aiderait. >> http://code.google.com/p/pharo/wiki/Downloads?tm=2 >> + update >> >> - LargePositiveInteger new: 4 >> + printString => boum >> >> merci par avance. >> >> Stef >> > Salut Stef, > La version Integer-fastPrint-M6887-nice.8.cs ( http://bugs.squeak.org/file_download.php?file_id=3430&type=bug > ) corrige ce cas avec les deux lignes suivantes au dÃ©but de > LargePositiveInteger>>#printOn:base: > > "Don't engage any arithmetic if not normalized" > (self digitLength = 0 or: [(self digitAt: self digitLength) = 0]) > ifTrue: [^self normalize printOn: aStream base: b]. > > Le script d'installation a Ã©tÃ© mis Ã jour le 21 juillet Ã http://bugs.squeak.org/view.php?id=6887 > > > J'ai aussi proposÃ© une version .9.cs qui remplace le test par plus > explicite: > > "Don't engage any arithmetic if not normalized" > self isNormalized ifFalse: [^self normalize printOn: aStream base: > b]. > > Mais ma version de #isNormalized bien que suffisante pour cette > utilisation, n'est pas complÃ¨te: elle ne teste pas si le nombre peut > Ãªtre rÃ©duit en SmallInteger... > Il faudrait la complÃ©ter, ce qui a peu d'intÃ©rÃªt tant qu'il y a un > seul sender. > Je recommande donc plutÃ´t la version .8.cs > A toi de voir. > > Bon courage pour la suite > >

Aug. 20, 2008

[Pharo-project] Traits...

by Alexandre Bergel

Hi! Marcus, Stef and I were wondering whether there is fix for copying compile methods instead of sharing when using traits. The idea is to prevent a shared compiled method to answer wrongly when asking for its properties, class belonging ... Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Aug. 20, 2008