- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] what is <localMetaclassMethod>

by HernÃ¡n Morales Durand

Hi Thierry, 2018-02-12 5:48 GMT-03:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > Hi Hernan, > > 2018-02-12 7:48 GMT+01:00 HernÃ¡n Morales Durand <hernan.morales(a)gmail.com>: >> Hi Eliot, >> >> One could say that a pragma is a message without a method? >> >> I think pragmas were never been integrated properly into the system >> browser. We can browses pragmas with the PragmaCollection but what I >> mean is a pragma-aware browser. See for example, there are some >> pragmas where is easy to infer the meaning: <magritteDescription>, >> <gtInspectorPresentationOrder:>, and others <eProperty> where is not >> so clear. So even if we take <gtInspectorPresentationOrder:> is not >> easy with the current tools to find of which parameters makes sense. I >> always missed something like the annotation pane plugin or the quality >> assistant plugin in Nautilus, but for pragmas. > > What Eliot is pointing out, is that integration is very easy to do as > long as you implement it the way Eliot describes it: you see a pragma, > you select it, search for implementors, and, voilÃ , you know what the > pragma is for and how it is used (and you may even get a comment for > the parameters). > > Now, you can try to do that in Pharo, and, of course that doesn't > work: I can select the pragma <gtInspectorPresentationOrder: 40>, > search for implementors, and I get none. If I search for senders, > among the few hundreds of senders I get into my pharo 6 image, and > knowing that this should be inside the GT-Inspector-Core package, I > find: > > #GTInspector class >>#extensionsPragma > > Now, following senders of #extensionsPragma, I find about a dozen > senders (because there are multiple implementors of #extensionsPragma, > probably). One of the senders is probably the key: > > ProtoObject>>#gtInspectorPresentationsIn:inContext: > > And the use of #allNamed:from:to:sortedUsing: should give you a clue > about the argument (because, yes there is no comment about the > argument... or even if the pragma should have one...). > As you noted, that's a long way to find a pragma information. It should be a lot easier. >> This could be an excellent opportunity for Calypso to see how pragmas >> can be exploited in the way you describe. > > As I said above, if used like Eliot describes, then it could be done > just by searching implementors of the pragma symbol. > > Now, implemented as it is in Pharo, I suspect it will be hard to do > even for Calypso. > I see. I would love a popup after each new pragma is defined to write some description. The system can enforce to write documentation! ;) Best regards, HernÃ¡n > Regards, > > Thierry > >> Thanks for the kind explanation. >> >> Cheers, >> >> HernÃ¡n >> >> >> 2018-02-12 1:09 GMT-03:00 Eliot Miranda <eliot.miranda(a)gmail.com>: >>> Hi Hernan, >>> >>> >>> >>> >>> _,,,^..^,,,_ (phone) >>>> On Feb 11, 2018, at 10:47 AM, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: >>>> >>>> I don't know, but how you you find documentation about specific pragmas? >>> >>> The best way is to ensure the pragma has at least one implementation, i.e. there is at least one method in the system that has the same signature as the pragma. This implementation should document the pragma, but even better it should be the method that extracts information from the pragma. >>> >>> An example will help. Imagine a pragma that specifies a method belongs on some menu. The method containing the pragma is intended to be an action of the menu, do that when the menu item is selected, the method containing the pragma will b executed. The pragma defines the menu the method belongs to, where in the method, the string to appear in the menu, the hot key for the menu item, etc. >>> >>> If the pragma is implemented by a menu builder then >>> - yes, certainly the pragma can be documented in the m by builder's implementation, but also >>> - the menu can be built by performing the pragma by the menu builder >>> >>> This was my intent when Steve Dahl and I invented pragmas, that there would always be implementations of the pragma in classes that were designed to extract the information from the pragma and add the method containing the pragma to whatever structure the pragma was intended to facilitate updating (menus, inspectors, exported apis, etc). So the most powerful way of use my pragmas is via a visitor pattern: >>> >>> When a method with a particular pragma is added or removed, the class containing the method triggers some action. This action collects all the relevant pragma methods in the class hierarchy, creates some builder object, and has the builder perform each method containing a relevant pragma. >>> >>> Using pragmas as arbitrary labels is fine, bug doesn't exploit the fact that pragmas are messages, and that hence one can do senders and implementors /and/ perform them. >>> >>> HTH >>> >>>> >>>> HernÃ¡n >>>> >>>> >>>> 2018-02-11 14:48 GMT-03:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >>>>> Hi >>>>> >>>>> what is this pragma in metaclass method? >>>>> >>>>> Stef >>>>> >>>> >>> >> >

Feb. 12, 2018

Point>>#rotateBy:about: has a bad comment

by Julien

Hello, Concerning this case I just opened: https://pharo.fogbugz.com/f/cases/21329/Point-rotateBy-about-has-a-bad-comm… <https://pharo.fogbugz.com/f/cases/21329/Point-rotateBy-about-has-a-bad-comm…> Iâd like your opinion about it. I just copy in this mail what I said on the case: rotateBy: angle about: center "Even though Point.theta is measured CW, this rotates with the more conventional CCW interpretateion of angle." [...] I think this comment does not explain what this method does. What should be something like: This method returns the point obtained after rotating myself around #center point of an #angle given as parameter. The #angle provided as parameter is interpreted as being in radian. Additionally, I think the name of this method is bad, maybe it should be renamed to something more explicit like #rotateBy:around: or #rotateByRadians:around:. Maybe, if this method is renamed as #rotateByRadians:around:, the method #rotateByDegrees:around: should be added as well. Cheers, Julien --- Julien Delplanque Doctorant Ã lâUniversitÃ© de Lille 1 http://juliendelplanque.be/phd.html Equipe Rmod, Inria BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq NumÃ©ro de tÃ©lÃ©phone: +333 59 35 86 40

Feb. 12, 2018

Re: [Pharo-dev] what is <localMetaclassMethod>

by Nicolas Cellier

It sounds like thinking data vs thinking behavior. Eliot teaches that pragmas should better be used as behavior. >From what you describe, some of Pharo usage is like behaviorless metadata... 2018-02-12 9:48 GMT+01:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > Hi Hernan, > > 2018-02-12 7:48 GMT+01:00 HernÃ¡n Morales Durand <hernan.morales(a)gmail.com > >: > > Hi Eliot, > > > > One could say that a pragma is a message without a method? > > > > I think pragmas were never been integrated properly into the system > > browser. We can browses pragmas with the PragmaCollection but what I > > mean is a pragma-aware browser. See for example, there are some > > pragmas where is easy to infer the meaning: <magritteDescription>, > > <gtInspectorPresentationOrder:>, and others <eProperty> where is not > > so clear. So even if we take <gtInspectorPresentationOrder:> is not > > easy with the current tools to find of which parameters makes sense. I > > always missed something like the annotation pane plugin or the quality > > assistant plugin in Nautilus, but for pragmas. > > What Eliot is pointing out, is that integration is very easy to do as > long as you implement it the way Eliot describes it: you see a pragma, > you select it, search for implementors, and, voilÃ , you know what the > pragma is for and how it is used (and you may even get a comment for > the parameters). > > Now, you can try to do that in Pharo, and, of course that doesn't > work: I can select the pragma <gtInspectorPresentationOrder: 40>, > search for implementors, and I get none. If I search for senders, > among the few hundreds of senders I get into my pharo 6 image, and > knowing that this should be inside the GT-Inspector-Core package, I > find: > > #GTInspector class >>#extensionsPragma > > Now, following senders of #extensionsPragma, I find about a dozen > senders (because there are multiple implementors of #extensionsPragma, > probably). One of the senders is probably the key: > > ProtoObject>>#gtInspectorPresentationsIn:inContext: > > And the use of #allNamed:from:to:sortedUsing: should give you a clue > about the argument (because, yes there is no comment about the > argument... or even if the pragma should have one...). > > > This could be an excellent opportunity for Calypso to see how pragmas > > can be exploited in the way you describe. > > As I said above, if used like Eliot describes, then it could be done > just by searching implementors of the pragma symbol. > > Now, implemented as it is in Pharo, I suspect it will be hard to do > even for Calypso. > > Regards, > > Thierry > > > Thanks for the kind explanation. > > > > Cheers, > > > > HernÃ¡n > > > > > > 2018-02-12 1:09 GMT-03:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > >> Hi Hernan, > >> > >> > >> > >> > >> _,,,^..^,,,_ (phone) > >>> On Feb 11, 2018, at 10:47 AM, HernÃ¡n Morales Durand < > hernan.morales(a)gmail.com> wrote: > >>> > >>> I don't know, but how you you find documentation about specific > pragmas? > >> > >> The best way is to ensure the pragma has at least one implementation, > i.e. there is at least one method in the system that has the same signature > as the pragma. This implementation should document the pragma, but even > better it should be the method that extracts information from the pragma. > >> > >> An example will help. Imagine a pragma that specifies a method belongs > on some menu. The method containing the pragma is intended to be an action > of the menu, do that when the menu item is selected, the method containing > the pragma will b executed. The pragma defines the menu the method belongs > to, where in the method, the string to appear in the menu, the hot key for > the menu item, etc. > >> > >> If the pragma is implemented by a menu builder then > >> - yes, certainly the pragma can be documented in the m by builder's > implementation, but also > >> - the menu can be built by performing the pragma by the menu builder > >> > >> This was my intent when Steve Dahl and I invented pragmas, that there > would always be implementations of the pragma in classes that were designed > to extract the information from the pragma and add the method containing > the pragma to whatever structure the pragma was intended to facilitate > updating (menus, inspectors, exported apis, etc). So the most powerful way > of use my pragmas is via a visitor pattern: > >> > >> When a method with a particular pragma is added or removed, the class > containing the method triggers some action. This action collects all the > relevant pragma methods in the class hierarchy, creates some builder > object, and has the builder perform each method containing a relevant > pragma. > >> > >> Using pragmas as arbitrary labels is fine, bug doesn't exploit the fact > that pragmas are messages, and that hence one can do senders and > implementors /and/ perform them. > >> > >> HTH > >> > >>> > >>> HernÃ¡n > >>> > >>> > >>> 2018-02-11 14:48 GMT-03:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > >>>> Hi > >>>> > >>>> what is this pragma in metaclass method? > >>>> > >>>> Stef > >>>> > >>> > >> > > > >

Feb. 12, 2018

[Pharo 7.0-dev] Build #536: 21315 Remove unnecessary "self run:" in ChangeSetClassChangesTest

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #536 was: FAILURE. The Pull Request #841 was integrated: "21315 Remove unnecessary "self run:" in ChangeSetClassChangesTest" Pull request url: https://github.com/pharo-project/pharo/pull/841 Issue Url: https://pharo.fogbugz.com/f/cases/21315 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Feb. 12, 2018

[Pharo 7.0-dev] Build #535: 21299 Remove unnecessary "self run:" in ClassTest

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #535 was: FAILURE. The Pull Request #857 was integrated: "21299 Remove unnecessary "self run:" in ClassTest" Pull request url: https://github.com/pharo-project/pharo/pull/857 Issue Url: https://pharo.fogbugz.com/f/cases/21299 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Feb. 12, 2018

[Pharo 7.0-dev] Build #534: 21294 Remove unnecessary "self run:" in HeapTest

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #534 was: SUCCESS. The Pull Request #863 was integrated: "21294 Remove unnecessary "self run:" in HeapTest" Pull request url: https://github.com/pharo-project/pharo/pull/863 Issue Url: https://pharo.fogbugz.com/f/cases/21294 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Feb. 12, 2018

Re: [Pharo-dev] Cleaning up... baseClass, instanceSide, theNonMetaclass

by Ben Coman

I found it quite insightful when I read someone describe that the way Smalltalk uses Classes is essentially the Factory Pattern. That makes me wonder whether classClass and classSide of a class might confuse newcomers and maybe factorySide of a class would make more sense. The again... https://xkcd.com/927/ cheers -ben On 12 February 2018 at 16:45, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > In my code I use to use instanceSide and classSide. don't know why. Maybe > they are clearer to me? > > On Sun, Feb 11, 2018 at 8:59 PM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > >> 2018-02-11 18:14 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >> >>> Hi >>> >>> We already got this discussion and I plan to address it. >>> Now I discovered that in addition to instanceSide and theNonMetaclass we >>> have >>> >>> - classClass and baseClass >>> - theMetaclass and theNonMetaclass >>> - instanceSide and classSide >>> >>> https://pharo.fogbugz.com/f/cases/20941/deprecate-theMetacla >>> ss-and-the-theNonMeta >>> >>> Even if instanceSide and classSide come from UI concerns I think that >>> there are much >>> better than the others. >>> >> >> + 100 >> >> >>> >>> So have you any concerns and prefer one of the other couples? Because >>> we should stop >>> accumulate cruft in the system. We do not need three ways to do the same. >>> >>> Stef >>> >>> >> > > > -- > > > > Guille Polito > > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > > CRIStAL - UMR 9189 > > French National Center for Scientific Research - *http://www.cnrs.fr > <http://www.cnrs.fr>* > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >

Feb. 12, 2018

[Pharo 7.0-dev] Build #533: 21310 Remove unnecessary "self run:" in WeakMessageSendTest

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #533 was: SUCCESS. The Pull Request #845 was integrated: "21310 Remove unnecessary "self run:" in WeakMessageSendTest" Pull request url: https://github.com/pharo-project/pharo/pull/845 Issue Url: https://pharo.fogbugz.com/f/cases/21310 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Feb. 12, 2018

[Pharo 7.0-dev] Build #532: 21312 Remove unnecessary "self run:" in ClassTraitTest

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #532 was: FAILURE. The Pull Request #844 was integrated: "21312 Remove unnecessary "self run:" in ClassTraitTest" Pull request url: https://github.com/pharo-project/pharo/pull/844 Issue Url: https://pharo.fogbugz.com/f/cases/21312 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Feb. 12, 2018

Re: [Pharo-dev] Do we remove TClass?

by tesonep＠gmail.com

Hi Stef, in the new implementation of Traits I have moved that traits to a package, they are not used at all in the image but they are used by other projects. For example, they are used by Ficus. Cheers, Pablo On Sun, Feb 11, 2018 at 6:01 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Then I do not get it what it this > > Trait >> private_subclass: t instanceVariableNames: f > classVariableNames: d poolDictionaries: s package: cat > "Compatibility purposes" > ^self error: 'Traits cannot have subclasses'. > > How raising an error would make something compatible???? > To be this is stupid code. > > Stef > > > > On Sun, Feb 11, 2018 at 5:51 PM, Stephane Ducasse > <stepharo.self(a)gmail.com> wrote: > > Hi Happy core developers > > > > do we remove TClass? Because it is duplicated code, no? > > > > Stef > > -- Pablo Tesone. tesonep(a)gmail.com

Feb. 12, 2018