April 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Compiler class>>closureParserClass

by StÃ©phane Ducasse

http://code.google.com/p/pharo/issues/detail?id=741 >>>> That is right? >>>> How to install "closureParserClass"?

April 15, 2009

Re: [Pharo-project] *overrides* in polymorph

by StÃ©phane Ducasse

> Will try to have a look tomorrow (the override does have the problem). > > Still waiting for a list of problematic overrides from the group... ahhh Ideally we would like to have none :) Stef > > The infrastructure is in place to make some "Squeak only". > > This one can apply to both Squeak and Pharo though. > > Regards, Gary > > ----- Original Message ----- > From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > To: "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr> > Sent: Monday, April 13, 2009 2:39 PM > Subject: [Pharo-project] *overrides* in polymorph > > >> Hi gary >> >> It seems that I already fixed >> SystemProgressMorph>>label:min:max: >> so that the bloack argument is not written. >> Can you check because if I redo it and it gets overridden I will have >> the smae problem. >> >> 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 >

April 15, 2009

Re: [Pharo-project] Fonts working great

by StÃ©phane Ducasse

disaser seems a strong word. It is far better than better. And now we will have another one based on alain's work. Now you can also help. On Apr 15, 2009, at 7:25 AM, Geert wrote: > > Scripts like this are indeed useful ... there should however not be > a need for such scripts if the "Preferences" were easier to manage. > From a usability point of view its not just the fonts that need > attention though, the whole preference browser is currently a bit of > a user experience disaster. > -- > View this message in context: http://n2.nabble.com/Fonts-working-great-tp2466458p2637029.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 >

April 15, 2009

[Pharo-project] [ANN] 10278 who and parser

by StÃ©phane Ducasse

who is now fixed as well as asiignemtn stef

April 15, 2009

Re: [Pharo-project] Fonts working great

by Geert

Scripts like this are indeed useful ... there should however not be a need for such scripts if the "Preferences" were easier to manage. From a usability point of view its not just the fonts that need attention though, the whole preference browser is currently a bit of a user experience disaster. -- View this message in context: http://n2.nabble.com/Fonts-working-great-tp2466458p2637029.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 15, 2009

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

by Geert

http://pharo-project.org/download Will there be pharo-web version too? What is actually the planned naming scheme for the various Pharo image versions? - Pharo-Core - Pharo (Pharo-Core + IDE?) - Pharo-Dev (Pharo-Core + IDE + Dev tools?) - Pharo-Web (Pharo-Core + IDE + Dev tools? + Web tools?) Is there really a need to have both Pharo-Dev and Pharo-Web or just a Pharo-Web? -- View this message in context: http://n2.nabble.com/New-Pharo-dev-based-on-10277-tp2633337p2636969.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 15, 2009

Re: [Pharo-project] question on traits

by Alexandre Bergel

> In 102077, btw, this test seems green. (But > strangely, #testFileOutCategory fails now.) Exact, but it failed in a 10259. > The former. LocatedMethod a simple (internal) class that encapsulates > a method and the behavior in which the method is implemented. > Nowadays, we could probably even avoid this since methods know the > behavior they are implemented in (this was not the case before). Ok. It is clearer now. > Looks good. Both traits tr2 and tr3 provide a method #foo. At the time > when LocatedMethod instances are created, no conflicts are resolved > (or methods merged) yet. The interesting logic is in > TraitMethodDescription (see class comment). If you are at fixing the > conflict of methods from the same origin, I think the right place is > TraitMethodDescription>>providedLocatedMethod. This method fails > (returns nil) if it finds more than one provided method. It should not > fail, though, if those methods have the same #origin. I extended few methods: TraitMethodDescription>>providedLocatedMethod | locatedMethod aLocatedMethod refOrigin | locatedMethod := nil. self locatedMethods ifEmpty: [ ^ nil]. self locatedMethods size > 1 ifTrue: [ aLocatedMethod := self locatedMethods anyOne. refOrigin := (aLocatedMethod location >> aLocatedMethod selector) origin. (self locatedMethods allSatisfy: [:each | each method origin == refOrigin]) ifTrue: [ ^ aLocatedMethod ]]. self locatedMethods do: [:each | each method isProvided ifTrue: [ locatedMethod isNil ifFalse: [^nil]. locatedMethod := each]]. ^locatedMethod TraitMethodDescription>>isConflict | count originMethodReferenciel | count := 0. self locatedMethods size > 1 ifTrue: ["If they are more than 1 located method, then check whether these methods have the same origin" originMethodReferenciel := self locatedMethods anyOne method origin. ((self locatedMethods collect: [:lm | lm method]) allSatisfy: [:each | each method origin == originMethodReferenciel]) ifTrue: [ ^ false ]]. self methodsDo: [:each | each isProvided ifTrue: [ count := count + 1. count > 1 ifTrue: [^true]]]. ^false In providedLocatedMethod, I am not sure about the "^ aLocatedMethod". This does not seem to be a big deal, since the result is checked for nullity only. These two enhanced methods makes testOrigin green. testOrigin is a new test that create a diamond made of 4 traits. The code is available in Traits@SqueakSource. Does this code looks okay? If yes, then I will put it in PharoInbox. Sorry for the long code excerpts. Cheers, Alexandre > > >> >> >> 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 > > > _______________________________________________ > 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] Problem with BlockClosure>>decompile

by StÃ©phane Ducasse

thanks nicolas I was just doing a release so I will harvest that now. Stef On Apr 14, 2009, at 6:31 PM, Nicolas Cellier wrote: > Issue http://code.google.com/p/pharo/issues/detail?id=738 > and PharoInbox/Compiler-nice.96 > > Cheers > > 2009/4/14 Dennis Schetinin <chaetal(a)gmail.com>: >>> 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 >> >> _______________________________________________ >> 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 >

April 14, 2009

Re: [Pharo-project] question on traits

by Adrian Lienhard

Hi Alex, On Apr 14, 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? No. This test finds methods that are implemented in a class (or trait) that are equal to a method that could be obtained from a trait. This can happen if you accidentally recompile a method in a class instead of in the trait. In 102077, btw, this test seems green. (But strangely, #testFileOutCategory fails now.) > 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? The former. LocatedMethod a simple (internal) class that encapsulates a method and the behavior in which the method is implemented. Nowadays, we could probably even avoid this since methods know the behavior they are implemented in (this was not the case before). > 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. Looks good. Both traits tr2 and tr3 provide a method #foo. At the time when LocatedMethod instances are created, no conflicts are resolved (or methods merged) yet. The interesting logic is in TraitMethodDescription (see class comment). If you are at fixing the conflict of methods from the same origin, I think the right place is TraitMethodDescription>>providedLocatedMethod. This method fails (returns nil) if it finds more than one provided method. It should not fail, though, if those methods have the same #origin. > locatedMethods is tested nowhere and there is no documentation. Well, it has a class comment and there are unit tests in the class LocatedMethodTest. (According to the test runner's "Run Coverage", the class even is completely covered.) HTH, Adrian > > > 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

April 14, 2009

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

by Ramiro Diaz Trepat

Thanks for your replies.I did install it and it works like a charm. Cheers r. On Tue, Apr 14, 2009 at 3:00 PM, Damien Cassou <damien.cassou(a)gmail.com>wrote: > 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 > > _______________________________________________ > 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