February 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Example implementation of associations with Slots in Pharo 4.0

by Marcus Denker

> On 23 Feb 2015, at 19:33, Jan van de Sandt <jvdsandt(a)gmail.com> wrote: > > > On Mon, Feb 23, 2015 at 9:59 AM, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: > > > On 21 Feb 2015, at 21:11, Jan van de Sandt <jvdsandt(a)gmail.com <mailto:jvdsandt@gmail.com>> wrote: > > > > Today I experimented a little with the new Slots feature of Pharo 4.0. As an example I implemented support for associations/relationships. > > > > Very nice! Can I add this to Pharo4 as an example? > > Sure, cool! > Ok, I will do that. Marcus

Feb. 24, 2015

Re: [Pharo-dev] [pharo-project/pharo-core] 3fabea: 40497

by Marcus Denker

> On 24 Feb 2015, at 07:49, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > Just my 2 cents: > > I find this really useful and have already implemented this extension in a couple of my packages, as writing: > > RuleChecker check: (RPackageOrganizer default packageNamed: âKernelâ) > > is much worse than: > > RuleChecker check: âKernelâ asPackage > > Sometimes I wonder if Packages should not be part of the Smalltalk globals namespaceâ¦ e.g. packages could have a nice reflective API: MyPackage unload. and even an API for usingâ¦ e.g. a Compiler has a very tiny surface API: OpalCompiler compile: ââ¦.â (but I do not really like nested classes, which is what people will now suggestâ¦) Marcus

Feb. 24, 2015

Re: [Pharo-dev] [pharo-project/pharo-core] 3fabea: 40497

by Yuriy Tymchuk

Just my 2 cents: I find this really useful and have already implemented this extension in a couple of my packages, as writing: RuleChecker check: (RPackageOrganizer default packageNamed: âKernelâ) is much worse than: RuleChecker check: âKernelâ asPackage Uko > On 23 Feb 2015, at 23:27, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > Indeed, having all "asXYZ from the Earth" would not be desirable to have in the Kernel, but: > - asPackage is packaged in *RPackage-SystemIntegration, so it's not in the Kernel > - I think extending String is a cheap and rather elegant way to ease common access patterns, and in this case RPackage is a common thing to look at. > > So, from this perspective, I think it is good to have asPackage. > > If my main system would be something about Players, and I would need ways to script that be sure I would have an asPlayer in my image (not in Pharo though :)). > > I would have actually preferred to put this in Symbol, but I saw that asClass is in String and I implemented it in the same way. > > Cheers, > Doru > > On Mon, Feb 23, 2015 at 11:16 PM, stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>> wrote: > >> It is symmetrical to String>>asClass which proves rather elegant for scripting class lookup. >> >> Why is it not good? > Because you are binding RPackage (which is for now a layer on top of class) directly inside the kernel > and this should not be done like that. May be you defined it as a class extension (I hope) I could not see the code. > We should stop extending core classes. It makes the system more complex to maintain and decompose. > > String should not contain all the asXXXX methods from earth. > Why we do not have asMethod, asPoint, asPlayer, asSound ? > > Stef > >> >> >> Le 23/2/15 15:53, Sven Van Caekenberghe a Ã©crit : >> Cool, we're back in business ;-) >> >> yes but why having String>>asPackage is better? >> >> Stef >> >> >> >> >> -- >> www.tudorgirba.com <http://www.tudorgirba.com/> >> >> "Every thing has its own flow" > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com/> > > "Every thing has its own flow"

Feb. 24, 2015

Re: [Pharo-dev] GTInspector custom presentations discoverability idea

by Sean P. DeNigris

Ben Coman wrote > btw, At the end I felt like clapping with the audience. This sort of > overview it what has been missing from my understanding the overall > aim/architecture of GT Tools +100. I already knew the GT Toolkit was cool. But now I see how cool it really is! And have a dream about how cool it will be in the future ;) A few impressions... 1. When creating an instance-side method from within GT: a. BUG: When I select a method from the "Methods" pane, and write a new method in the "Source" pane, accepting doesn't seem to do anything i.e. the orange triangle is still there, and my new method doesn't appear in the "Methods" pane on the left. However, if I open a new Playground, the method is indeed saved. b. ENH Request: Selecting in the "Methods" pane is not a great way to specify which class a new method should be defined in. The target class may not have any existing methods, or the user may have to scroll extensively searching for it. 2. Also, it would be cool if previewing/diving into a menu item showed its builder. Right now the preview just shows the same thing as the previous column. 3. Previews of pragmas seem to be indented a lot for no reason, and then cut off the actual info with '...' <http://forum.world.st/file/n4807121/Screenshot_2015-02-23_18.png> ----- Cheers, Sean -- View this message in context: http://forum.world.st/GTInspector-custom-presentations-discoverability-idea… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Feb. 23, 2015

Re: [Pharo-dev] Athens/Morphic

by Nicolai Hess

No, it is not yet integrated. but this should work with pharo 40501 Merge (from pharo4 inbox): ConfigurationOfAthens-NicolaiHess.52 ConfigurationOfAthens loadVersion:'2.9' AthensWrapWorldMorph new openInWorld 2015-02-23 23:09 GMT+01:00 stepharo <stepharo(a)free.fr>: > I tried to load 2.9 from the athens repo into Latest update: #40501 and I > got > incompatibleLayoutConflict.... > because apparently I got some packages that were saved.... > > Well I got totally lost. > > > Le 23/2/15 23:06, stepharo a Ã©crit : > > > Le 23/2/15 09:59, Nicolai Hess a Ã©crit : > > Load the new configuration of athens (2.9) > > > I could not find it in the ConfigurationBrowser or in the Pharo40 main > repo. > I thought that it was integrated in Pharo (I used the latest version 40501) > > Open an AthensWorld: > AthensWrapWorldMorph new openInWorld > > > Drag and drop some morphs on this athens world. > (Nautilus /Old Workspace should fully work/ GT Inspector and Playground > not) > > > > 2015-02-23 9:51 GMT+01:00 stepharo <stepharo(a)free.fr>: > >> how can I play with that? >> >> even if I should not. >> >> Le 20/2/15 08:54, Marcus Denker a Ã©crit : >> >> Very nice! Works here (on Mac). >> >> I will integrate as soon as the CI is up againâ¦ >> >> Marcus >> >> On 19 Feb 2015, at 12:44, Nicolai Hess <nicolaihess(a)web.de> wrote: >> >> Most of this (without the test class (AthensTestDisplay)) is now >> ready for >> integration. >> >> A lot of changes for making Mophic and Text(Morphs) work on Athens >> (For testing purpose there is also the AthensWrapWorldMorph included). >> >> The Canvas wrapper (AthensCanvasWrapper) is not yet included and >> therefore >> all Morphs that do not explicit have a proper drawOnAthensCanvas method >> arent't drawn (or just like rectangles). >> >> Should work with any image >= 40490 >> Just load the latest ConfigurationOfAthens from pharo 40 inbox and >> load >> ConfigurationOfAthens loadVersion:'2.9' >> >> If this is working (or not:) ) please leave a note on fogbugz: >> "14954 load new configuration 2.9 (more morphic support)" >> >> >> nicolai >> >> >> 2015-01-31 11:54 GMT+01:00 Alain Plantec <alain.plantec(a)yahoo.com>: >> >>> >>> >>> Yes the HandMorph is handled like any other Morph, it draws itself >>> and >>> after that it draws all its submorphs. (And actually it does not use >>> any caching, and it is still quite fast) >>> >>> >>> the same in Bloc, no caching and it works just fine :) >>> >>> But yes, it needs a special drawOnAthens method. >>> >>> >>>> Do you plane to make a package for it ? >>>> I would like to integrate it in Bloc. >>>> >>> >>> What would like to integrate? >>> >>> In fact I do not see any change when in Bloc. >>> So I guess I will have to adapt Bloc to your changes. >>> >>> I will upload the changes in Athens-Morphic package to >>> the Athens repository. >>> >>> >>> cool. >>> >>> thanks >>> >>> Alain >>> >> >> >> >> > > >

Feb. 23, 2015

Re: [Pharo-dev] [pharo-project/pharo-core] 3fabea: 40497

by Tudor Girba

Hi, Indeed, having all "asXYZ from the Earth" would not be desirable to have in the Kernel, but: - asPackage is packaged in *RPackage-SystemIntegration, so it's not in the Kernel - I think extending String is a cheap and rather elegant way to ease common access patterns, and in this case RPackage is a common thing to look at. So, from this perspective, I think it is good to have asPackage. If my main system would be something about Players, and I would need ways to script that be sure I would have an asPlayer in my image (not in Pharo though :)). I would have actually preferred to put this in Symbol, but I saw that asClass is in String and I implemented it in the same way. Cheers, Doru On Mon, Feb 23, 2015 at 11:16 PM, stepharo <stepharo(a)free.fr> wrote: > > It is symmetrical to String>>asClass which proves rather elegant for > scripting class lookup. > > Why is it not good? > > Because you are binding RPackage (which is for now a layer on top of > class) directly inside the kernel > and this should not be done like that. May be you defined it as a class > extension (I hope) I could not see the code. > We should stop extending core classes. It makes the system more complex to > maintain and decompose. > > String should not contain all the asXXXX methods from earth. > Why we do not have asMethod, asPoint, asPlayer, asSound ? > > Stef > > > >> Le 23/2/15 15:53, Sven Van Caekenberghe a Ã©crit : >> >>> Cool, we're back in business ;-) >>> >> >> yes but why having String>>asPackage is better? >> >> Stef >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > > -- www.tudorgirba.com "Every thing has its own flow"

Feb. 23, 2015

Re: [Pharo-dev] [pharo-project/pharo-core] 3fabea: 40497

by stepharo

> It is symmetrical to String>>asClass which proves rather elegant for > scripting class lookup. > > Why is it not good? Because you are binding RPackage (which is for now a layer on top of class) directly inside the kernel and this should not be done like that. May be you defined it as a class extension (I hope) I could not see the code. We should stop extending core classes. It makes the system more complex to maintain and decompose. String should not contain all the asXXXX methods from earth. Why we do not have asMethod, asPoint, asPlayer, asSound ? Stef > > > Le 23/2/15 15:53, Sven Van Caekenberghe a Ã©crit : > > Cool, we're back in business ;-) > > > yes but why having String>>asPackage is better? > > Stef > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow"

Feb. 23, 2015

Re: [Pharo-dev] [pharo-project/pharo-core] 3fabea: 40497

by stepharo

I know! Now I wanted to say that we are binding everything together. We are just making the job of people like Pavel and Guille more difficult. We should not expect that they will continue to produce a modular core if we do not pay attention like that. At least I would be them, I would stop. If we decide to bind package that deep into the system (because String is deep) then may be we should have package inside Class definition themselves. Stef Le 23/2/15 15:53, Sven Van Caekenberghe a Ã©crit : >>> Cool, we're back in business ;-) >> yes but why having String>>asPackage is better? >> >> Stef > I was commenting on the CI/Integration process, not this particular issue. > > > >

Feb. 23, 2015

Re: [Pharo-dev] Example implementation of associations with Slots in Pharo 4.0

by Tudor Girba

Exactly :). In Fame, there is a FMMultivalueLink hierarchy that implement many to one and many to many relations. This implementation exists since before slots and now we should reimplement them with slots. It will make the code so much nicer :). Anyone interested in picking this up? Cheers, Doru On Mon, Feb 23, 2015 at 10:34 PM, Ben Coman <btc(a)openinworld.com> wrote: > I haven't played with the relation example yet, but will real soon. Just > some initial thoughts... > > I like RelationSlot. To me association seems one-way while a relation is > two-way. > > btw, Is there some reason to not match the syntax of the often cited paper > "Flexible Object Layout" ? > I see one advantage is that its easier to read all the slot names > vertically aligned. > > Object subclass: #SlotExampleMovie > slots: { > #name. > #year. > #director => ToOneRelationSlot opposite: #directedMovies class: > #SlotExamplePerson. > #actors => ToManyRelationSlot opposite: #actedInMovies class: #SlotExamplePerson. > } > classVariables: { } > category: 'SlotAssociations-Tests-Example' > > > Also maybe an alternative slot class name so that it reads more like a > sentence... "#director related to one #directedMovies in class > #SlotExamplePerson" > > Object subclass: #SlotExampleMovie > slots: { > #name. > #year. > #director => RelatedToOne inverse: #directedMovies inClass: > #SlotExamplePerson. > #actors => RelatedToMany inverse: #actedInMovies inClass: #SlotExamplePerson. > } > classVariables: { } > category: 'SlotAssociations-Tests-Example' > > Or even... > > Object subclass: #SlotExampleMovie > slots: { > #name. > #year. > #director => OneRelatedTo many: #directedMovies inClass: > #SlotExamplePerson. > #actors => ManyRelatedTo many: #actedInMovies inClass: #SlotExamplePerson. > } > classVariables: { } > category: 'SlotAssociations-Tests-Example' > > cheers -ben > > > On Tue, Feb 24, 2015 at 2:33 AM, Jan van de Sandt <jvdsandt(a)gmail.com> > wrote: > >> >> On Mon, Feb 23, 2015 at 9:59 AM, Marcus Denker <marcus.denker(a)inria.fr> >> wrote: >> >>> >>> > On 21 Feb 2015, at 21:11, Jan van de Sandt <jvdsandt(a)gmail.com> wrote: >>> > >>> > Today I experimented a little with the new Slots feature of Pharo 4.0. >>> As an example I implemented support for associations/relationships. >>> > >>> >>> Very nice! Can I add this to Pharo4 as an example? >>> >>> Sure, cool! >> >> >>> My idea is that at first we add these things as examples, and then later >>> take the examples and distill a library of >>> generally useful slots. >>> >>> >>> >> That sounds like a good approach to get familiar with these kind of new >> features. >> >> Some things I can do to improve the Example >> - Add an option to make one side of the association readonly. In most >> situations I think it's a good idea to update an association only from one >> side to keep things simple. >> - Whats a better name AssociationSlot or RelationSlot? I'm not sure >> - As StÃ©phane said, isn't there a nicer way to declare the associations? >> - Better error handling >> >> Jan. >> >> >> >> >> >> >> >> >> >> >> >> > -- www.tudorgirba.com "Every thing has its own flow"

Feb. 23, 2015

Re: [Pharo-dev] Athens/Morphic

by stepharo

I tried to load 2.9 from the athens repo into Latest update: #40501 and I got incompatibleLayoutConflict.... because apparently I got some packages that were saved.... Well I got totally lost. Le 23/2/15 23:06, stepharo a Ã©crit : > > Le 23/2/15 09:59, Nicolai Hess a Ã©crit : >> Load the new configuration of athens (2.9) > > I could not find it in the ConfigurationBrowser or in the Pharo40 main > repo. > I thought that it was integrated in Pharo (I used the latest version > 40501) > >> Open an AthensWorld: >> AthensWrapWorldMorph new openInWorld >> >> >> Drag and drop some morphs on this athens world. >> (Nautilus /Old Workspace should fully work/ GT Inspector and >> Playground not) >> >> >> >> 2015-02-23 9:51 GMT+01:00 stepharo <stepharo(a)free.fr >> <mailto:stepharo@free.fr>>: >> >> how can I play with that? >> >> even if I should not. >> >> Le 20/2/15 08:54, Marcus Denker a Ã©crit : >>> Very nice! Works here (on Mac). >>> >>> I will integrate as soon as the CI is up againâ¦ >>> >>> Marcus >>> >>>> On 19 Feb 2015, at 12:44, Nicolai Hess <nicolaihess(a)web.de >>>> <mailto:nicolaihess@web.de>> wrote: >>>> >>>> Most of this (without the test class (AthensTestDisplay)) is >>>> now ready for >>>> integration. >>>> >>>> A lot of changes for making Mophic and Text(Morphs) work on Athens >>>> (For testing purpose there is also the AthensWrapWorldMorph >>>> included). >>>> >>>> The Canvas wrapper (AthensCanvasWrapper) is not yet included >>>> and therefore >>>> all Morphs that do not explicit have a proper >>>> drawOnAthensCanvas method arent't drawn (or just like rectangles). >>>> >>>> Should work with any image >= 40490 >>>> Just load the latest ConfigurationOfAthens from pharo 40 inbox and >>>> load >>>> ConfigurationOfAthens loadVersion:'2.9' >>>> >>>> If this is working (or not:) ) please leave a note on fogbugz: >>>> "14954 load new configuration 2.9 (more morphic support)" >>>> >>>> >>>> nicolai >>>> >>>> >>>> 2015-01-31 11:54 GMT+01:00 Alain Plantec >>>> <alain.plantec(a)yahoo.com <mailto:alain.plantec@yahoo.com>>: >>>> >>>> >>>>> >>>>> Yes the HandMorph is handled like any other Morph, it >>>>> draws itself and >>>>> after that it draws all its submorphs. (And actually it >>>>> does not use any caching, and it is still quite fast) >>>> >>>> the same in Bloc, no caching and it works just fine :) >>>> >>>>> But yes, it needs a special drawOnAthens method. >>>>> >>>>> Do you plane to make a package for it ? >>>>> I would like to integrate it in Bloc. >>>>> >>>>> >>>>> What would like to integrate? >>>> In fact I do not see any change when in Bloc. >>>> So I guess I will have to adapt Bloc to your changes. >>>> >>>>> I will upload the changes in Athens-Morphic package to >>>>> the Athens repository. >>>> >>>> cool. >>>> >>>> thanks >>>> >>>> Alain >>>> >>>> >>> >> >> >

Feb. 23, 2015