- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Problem with BlockClosure>>decompile

by Dennis Schetinin

> > This is because #who was deprecated in squeak 3.9 and removed in pharo... > ... but the closure work by Eliot is based on a 3.8 image... > > Solution is simple: replace: > (homeClass := home who first) == #unknown ifTrue: [^ nil]. > with: > (homeClass := home methodClass) ifNil: [^ nil]. > Thank you very much! -- Dennis Schetinin

April 14, 2009

Re: [Pharo-project] Problem with BlockClosure>>decompile

by Nicolas Cellier

This is because #who was deprecated in squeak 3.9 and removed in pharo... ... but the closure work by Eliot is based on a 3.8 image... Solution is simple: replace: (homeClass := home who first) == #unknown ifTrue: [^ nil]. with: (homeClass := home methodClass) ifNil: [^ nil]. I note that in 3.8 #who did scan all the methodDictionary | sel | self systemNavigation allBehaviorsDo: [:class | (sel := class methodDict keyAtIdentityValue: self ifAbsent: [nil]) ifNotNil: [^Array with: class with: sel]]. ^Array with: #unknown with: #unknown But in 3.9 #who did rely only in hasNewPropertyFormat (a MethodProperty is put in last but one literal, receiver class is put in last literal) and would never scan... Nicolas 2009/4/14 Dennis Schetinin <chaetal(a)gmail.com>: > ... because there is no method #who... Can anybody please help to fix it > quickly? TIA > > -- > Dennis Schetinin > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 14, 2009

[Pharo-project] New Pharo-dev based on 10277

by Damien Cassou

http://pharo-project.org/download -- Damien Cassou http://damiencassou.seasidehosting.st

April 14, 2009

Re: [Pharo-project] Universe browser on Damien's dev image

by Damien Cassou

2009/4/14 Mariano Martinez Peck <marianopeck(a)gmail.com>: > There is something I don't understand. Which is the diference between: > > ScriptLoader new installingXXXÂ Â Â (example: ScriptLoader new > installingUniverse) > > and > > ScriptLoader loadXXXÂ Â Â (example: ScriptLoader loadFFI)) > > > If it is the same, shouldn't we decide only one way to to this ? I agree this is the same and should be cleaned. However, the ScriptLoader is for the core developers only, not for end-users. -- Damien Cassou http://damiencassou.seasidehosting.st

April 14, 2009

Re: [Pharo-project] linux version download problem

by Damien Cassou

On Tue, Apr 14, 2009 at 3:23 AM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Are you sure about the cd to get a local path to the image? Â I just give the full path to both the vm and image, and it seems to work. do you get the directory package-cache in the image directory if you load things through monticello? -- Damien Cassou http://damiencassou.seasidehosting.st

April 14, 2009

[Pharo-project] Problem with BlockClosure>>decompile

by Dennis Schetinin

... because there is no method #who... Can anybody please help to fix it quickly? TIA -- Dennis Schetinin

April 14, 2009

Re: [Pharo-project] question on traits

by Alexandre Bergel

I saved this code in www.squeakSource.com/Traits Cheers, Alexandre On 14 Apr 2009, at 15:14, Alexandre Bergel wrote: > Hi Adrian and all traits friends, > > The test TraitTest>>testLocalMethodWithSameCodeInTrait is yellow. I > guess this is because there is no sharing of compiled methods. This > test is therefore not irrelevant right? Can be safely removed? > > Something slightly more technical. What providedLocatedMethod should > return? What a LocatedMethod should refer to? A location of a method > in a trait, or where the method is defined for the first time? > An example. Let's assume I have: > > tr1 := self createTraitNamed: #T1 uses: {}. > tr2 := self createTraitNamed: #T2 uses: {tr1}. > tr3 := self createTraitNamed: #T3 uses: {tr1}. > tr23 := self createTraitNamed: #T23 uses: {tr3 + tr2}. > tr1 compile: 'foo ^ 4'. > > aMethodDescription := tr23 traitComposition > methodDescriptionForSelector: #foo. > self assert: (aMethodDescription locatedMethods size = 2). > self assert: (aMethodDescription locatedMethods > includes: (LocatedMethod location: tr2 selector: #foo)). > self assert: (aMethodDescription locatedMethods > includes: (LocatedMethod location: tr3 selector: #foo)). > > The last two assertion pass. However, is it that intended? I would > have expected only one locatedMethod, which is (LocatedMethod > location: tr1 selector: #foo), however I am not sure. > locatedMethods is tested nowhere and there is no documentation. > > Cheers, > Alexandre > > > On 10 Apr 2009, at 14:32, Adrian Lienhard wrote: > >> Yes, this should not be a conflict. I think I had implemented it that >> way. Probably it was broken in the recent refactoring that I did for >> method sharing... >> >> Adrian >> >> On Apr 10, 2009, at 13:47 , Alexandre Bergel wrote: >> >>> Hi All, >>> >>> Apparently, the way a conflict may be triggered is slightly >>> different >>> from what is described in the toplas paper. >>> in the paper, it is said that a compiled method that is inherited >>> from >>> more than one path does not trigger a conflict. With the current >>> implementation this trigger a conflict. >>> >>> For example: >>> T1 defines foo >>> T2 uses T1 >>> T3 uses T1 >>> T23 uses T2 + T3 >>> C uses T23 >>> >>> C new foo => conflict error. >>> >>> One would expect no conflict since there is only one definition of >>> foo >>> Just wondering... >>> >>> 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 > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 14, 2009

Re: [Pharo-project] question on traits

by Alexandre Bergel

Hi Adrian and all traits friends, The test TraitTest>>testLocalMethodWithSameCodeInTrait is yellow. I guess this is because there is no sharing of compiled methods. This test is therefore not irrelevant right? Can be safely removed? Something slightly more technical. What providedLocatedMethod should return? What a LocatedMethod should refer to? A location of a method in a trait, or where the method is defined for the first time? An example. Let's assume I have: tr1 := self createTraitNamed: #T1 uses: {}. tr2 := self createTraitNamed: #T2 uses: {tr1}. tr3 := self createTraitNamed: #T3 uses: {tr1}. tr23 := self createTraitNamed: #T23 uses: {tr3 + tr2}. tr1 compile: 'foo ^ 4'. aMethodDescription := tr23 traitComposition methodDescriptionForSelector: #foo. self assert: (aMethodDescription locatedMethods size = 2). self assert: (aMethodDescription locatedMethods includes: (LocatedMethod location: tr2 selector: #foo)). self assert: (aMethodDescription locatedMethods includes: (LocatedMethod location: tr3 selector: #foo)). The last two assertion pass. However, is it that intended? I would have expected only one locatedMethod, which is (LocatedMethod location: tr1 selector: #foo), however I am not sure. locatedMethods is tested nowhere and there is no documentation. Cheers, Alexandre On 10 Apr 2009, at 14:32, Adrian Lienhard wrote: > Yes, this should not be a conflict. I think I had implemented it that > way. Probably it was broken in the recent refactoring that I did for > method sharing... > > Adrian > > On Apr 10, 2009, at 13:47 , Alexandre Bergel wrote: > >> Hi All, >> >> Apparently, the way a conflict may be triggered is slightly different >> from what is described in the toplas paper. >> in the paper, it is said that a compiled method that is inherited >> from >> more than one path does not trigger a conflict. With the current >> implementation this trigger a conflict. >> >> For example: >> T1 defines foo >> T2 uses T1 >> T3 uses T1 >> T23 uses T2 + T3 >> C uses T23 >> >> C new foo => conflict error. >> >> One would expect no conflict since there is only one definition of >> foo >> Just wondering... >> >> 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 14, 2009

[Pharo-project] Dear Santa please include ...

by Torsten Bergmann

the new preference allowing one to set if the fonts will be updated at image startup (default) or not. See pharo inbox and http://code.google.com/p/pharo/issues/detail?id=689 Bye T. -- Psssst! Schon vom neuen GMX MultiMessenger gehÃ¶rt? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01

April 14, 2009

Re: [Pharo-project] It seems that Pharo 09.04.1 (with Seaside and Pier) broken

by Igor Stasenko

2009/4/14 Baskakov Daniel <gdaniq(a)gmail.com>: > Hi, > I've downloaded Pharo 09.04.1 (with Seaside and Pier) > [http://gforge.inria.fr/frs/download.php/20710/pharo0.1-10268web09.04.1.zip] > and it fails to open on my Ubuntu 8.10 (same as in Windows Vista). I > get the following error: > > This interpreter (vers. 6502) cannot read image file (vers. 6504). > Press CR to quit... > > Any ideas? > You need to use proper VM, which supports closures. > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

April 14, 2009