May 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Trait exclusions

by Frank Shearar

Hi Stef, Indeed you'd normally not double apply a trait. I want to do that here for explanatory purposes, to show that a field is the melding of two groups. As it turns out, this double application merely highlights my underlying issues. My problems would still be there whenever I wanted to compose traits that shared requirements. I had understood the "symmetric composition annihilates conflicting methods" in "Traits: composable units of behaviour" to mean that the composition would not have such methods _at all_. In Pharo, if you have two traits S and T, and a common method m, the composition S + T does contain m. If S and T implement m differently, the resulting m is "self traitConflict". If both S and T implement m as "self requirement", the resulting composition's m is also "self requirement". That surprised me, but it does actually make sense. It does mean that (S + T) != (S - m) + (T - m). What I'd also expected is that aliasing (say, S @ {#m -> #z}) would mean "the resulting composition does not understand m". But it does. So in my case, I had expected that TGroup @ {#identity->#zero. #* -> #+. #inverse->#negated} would result in a Trait that didn't define #identity or #inverse, and that TGroup @ {#identity->#one. #inverse->#reciprocal} would likewise not define #identity or #inverse. Then resulting composition would have no conflicts, and would simply understand #(#* #+ #negated #reciprocal #one #zero). frank On 30 May 2013, at 7:51, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > Hi frank > > normally it does not make sense to use two times the same trait. So I do not really understand > how it could work. > > So now when you have two traits > T1 > T2 > > minus lets you erase selectively one message x from T1 if it is also available in T2 > and without having to redefine it into the composite. > > Stef > >> I have a Trait TGroup that requires #*, #identity and #inverse. I want >> to construct a TField by composing TGroup with itself. One TGroup will >> form the operations #*, #one, and #reciprocal while the other will >> form #+, #zero and #negated. >> >> I don't want #identity or #inverse, because these apply to one >> operation, and it makes TField's API ambiguous. That's what >> TraitExclusion is for. >> >> I had thought I could say >> >> (TGroup @ {#identity->#zero. #* -> #+. #inverse->#negated} + TGroup @ >> {#identity->#one. #inverse->#reciprocal}) - {#identity. #inverse} >> >> but TraitComposition >> #- says that exclusion binds tighter than +. >> So in effect the above composition is the same as >> >> TGroup @ {#identity->#zero. #* -> #+. #inverse->#negated} + (TGroup @ >> {#identity->#one. #inverse->#reciprocal} - {#identity. #inverse}) >> >> In short, to remove the undesirable #identity and #inverse I have to >> exclude from both sides of the composition: >> >> TGroup @ {#identity->#zero. #* -> #+. #inverse->#negated} - >> {#identity. #inverse} + TGroup @ {#identity->#one. >> #inverse->#reciprocal} - {#identity. #inverse} >> >> My question is this: what is the reason for - binding more tightly >> than +? Why is it _not_ desirable to have - distribute over +? >

May 30, 2013

[update 3.0] #30174

by Marcus Denker

30174 ----- 10788 move CompiledMethod>>#protocol to Kernel https://pharo.fogbugz.com/f/cases/10788 10759 AnObsoleteDefaultCommandLineHandler is in the image https://pharo.fogbugz.com/f/cases/10759 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tests-MarcusDenker.547.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/System-CommandLine-MarcusDenk… http://smalltalkhub.com/mc/Pharo/Pharo30/main/NautilusCommon-MarcusDenker.1… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Kernel-MarcusDenker.1469.diff

May 30, 2013

Re: [Pharo-dev] RPackage and overrides

by Marcus Denker

On May 30, 2013, at 9:44 AM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > Le 29/05/2013 23:16, stephane ducasse a Ã©crit : >> >> On May 29, 2013, at 9:08 AM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: >> >>> Le 28/05/2013 22:23, stephane ducasse a Ã©crit : >>>> >>>> >>>>> I have a question about RPackage and overrides. >>>>> >>>>> RPackage consider that an override method is an extension, right? >>>> >>>> for RPackage a package is a list of method definitions and class definition. >>>> There is no specific tagging for overriding methods that would magically reappear when >>>> their overriding method would be unloaded. >>> >>> Ok. But in MC, a MethodDefinition has a way of telling if it is an override or not. >> >> We do not support this "feature" since it is bogus since years. > > Then you just have to ensure that integration rejects overrides (and that the IDE does as well: I'm sure I can create overrides in Pharo, isn't it?). > Yes. I can say true become: false, too. Overrides can be interesting as a temperer hack. E.g. in Opal development, I might add an override just to test. Then loading Opal makes the image package dirty. So later, when I know what I want, I will move that change to the image. You should not use overrides as a concept in delivered software (as it does not work), so modeling it is wrong as then people will use it. Yes making it impossible is not nice either, because temporarily I want to be able to just do it, like I can do all sorts of things. So this is more something we should add a rule for in Code Crititqueâ¦ Marcus

May 30, 2013

Re: [Pharo-dev] [ANN] A small Filetree extension for git integration

by Goubier Thierry

Le 29/05/2013 17:43, Max Leske a Ã©crit : > Cool! Thanks > Just so you know: I'm working on FileSystem-Git which will use LibGit bindings through NativeBoost. But it will take me quite a while to finish. I tried FileSystem-Git (not sure I tried the best version) but didn't managed to get it to work with my pre-existing git repo. Not tried much, because I got FileTree to work as I used to in 1.4. > Thanks for the effort! It will make my work easier too since I can now update my filetree repo better :) Tell me if it works the way you would expect it to. I don't really know my way around git apart from the basics common to all version systems, and I'll be willing for suggestions. Thierry > Cheers, > Max > > > On 29.05.2013, at 17:31, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > >> Hi all, >> >> I've added an extension to filetree:// in Monticello, named gitfiletree://, which adds the git commands to automagically commit new versions of packages in a filetree repository inside a larger git repository (i.e. Pharo + any fun and interesting language I have to use such as C under git). >> >> It relies on OS-Process (to be able to send git commands over a shell) and Filetree (of course), and it's on SmalltalkHub. >> >> http://smalltalkhub.com/#!/~ThierryGoubier/MonticelloFileTree-Git/ >> >> If anybody is interested in suggesting improvements (such as how to query and load specific versions or better ways to use git commands)? >> >> At the moment, it should be able to handle mixed MC and others repositories, and multiple packages in the same git. >> >> Thierry >> -- >> Thierry Goubier >> CEA list >> Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s >> 91191 Gif sur Yvette Cedex >> France >> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >> > > > -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

May 30, 2013

Re: [Pharo-dev] RPackage and overrides

by Goubier Thierry

Le 29/05/2013 23:16, stephane ducasse a Ã©crit : > > On May 29, 2013, at 9:08 AM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > >> Le 28/05/2013 22:23, stephane ducasse a Ã©crit : >>> >>> >>>> I have a question about RPackage and overrides. >>>> >>>> RPackage consider that an override method is an extension, right? >>> >>> for RPackage a package is a list of method definitions and class definition. >>> There is no specific tagging for overriding methods that would magically reappear when >>> their overriding method would be unloaded. >> >> Ok. But in MC, a MethodDefinition has a way of telling if it is an override or not. > > We do not support this "feature" since it is bogus since years. Then you just have to ensure that integration rejects overrides (and that the IDE does as well: I'm sure I can create overrides in Pharo, isn't it?). >> RPackage does not (and list -overrides as extensions, as for example in Keymapping). >> >>> I do not know if this answer your question. >> >> Not sure :) I wondered if I should bother with overrides or let them as extensions, as RPackage seems to be considering them the same. >> >> What do you think? Is it important to classify overrides as such, or just let them be extensions ? > > just extensions. Makes my life simpler ;) Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

May 30, 2013

Re: [Pharo-dev] New mailing list on Gmane

by Marcus Denker

Hello, In general it seems that at Gmane the lists are not owned by anyone but instead you need to ask the admins. Yesterday I used the UI here: http://gmane.org/info.php?group=gmane.comp.lang.smalltalk.pharo.devel to send a request to update the list. I have not heard anything yet. For importing, there is a description here: http://gmane.org/import.php We should check it when the list is working again. Marcus On May 30, 2013, at 8:38 AM, Jimmie Houchin <jlhouchin(a)gmail.com> wrote: > Hello, > > I frequently read the Pharo list on Gmane. Since the mailing list move to a new server, none of the messages are being sent to Gmane. > > There have been no new messages since May 15. It would be nice if the service to Gmane could be resumed. And if possible to populate the missed messages. > > Just wanted to let the list know. > > Thanks. > > Jimmie >

May 30, 2013

Re: [Pharo-dev] [ANN]: ValidationRevisited (alpha)

by Max Leske

I love the music you used in your screencast :D Sounds a bit like a telephone waiting line On 30.05.2013, at 08:52, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > I started to read the chapter to understand. > > Stef > > >> stephane ducasse wrote >>> show us how you specify that? >> >> It's a simple Spec UI, receiving announcements from the domain object. >> Whenever the model changes, the UI receives: >> modelChanged: anAnnouncement >> >> failureList items: model validate failures. >> >> #validate is the main entry point for the framework. You can call this on >> any domain object and the validation rules will be run. Under the hood are >> specialized SUnit classes. Here (on Nabble) is a screenshot of the validator >> class, a specialized TestCase which holds the rules for the object in the >> screencast: >> <http://forum.world.st/file/n4690694/Screen_Shot_2013-05-29_at_5.37.12_PM.png> >> >> The really cool thing which is not shown in the video is that the failures >> are real objects which hold the domain object, the property that failed >> (called an 'aspect'), and the description shown in the UI. So you could do a >> lot more than show the description... >> >> >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: http://forum.world.st/ANN-ValidationRevisited-alpha-tp4690680p4690694.html >> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >> > >

May 30, 2013

Re: [Pharo-dev] [ANN]: ValidationRevisited (alpha)

by stephane ducasse

I started to read the chapter to understand. Stef > stephane ducasse wrote >> show us how you specify that? > > It's a simple Spec UI, receiving announcements from the domain object. > Whenever the model changes, the UI receives: > modelChanged: anAnnouncement > > failureList items: model validate failures. > > #validate is the main entry point for the framework. You can call this on > any domain object and the validation rules will be run. Under the hood are > specialized SUnit classes. Here (on Nabble) is a screenshot of the validator > class, a specialized TestCase which holds the rules for the object in the > screencast: > <http://forum.world.st/file/n4690694/Screen_Shot_2013-05-29_at_5.37.12_PM.png> > > The really cool thing which is not shown in the video is that the failures > are real objects which hold the domain object, the property that failed > (called an 'aspect'), and the description shown in the UI. So you could do a > lot more than show the description... > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/ANN-ValidationRevisited-alpha-tp4690680p4690694.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

May 30, 2013

Re: [Pharo-dev] Trait exclusions

by stephane ducasse

Hi frank normally it does not make sense to use two times the same trait. So I do not really understand how it could work. So now when you have two traits T1 T2 minus lets you erase selectively one message x from T1 if it is also available in T2 and without having to redefine it into the composite. Stef > I have a Trait TGroup that requires #*, #identity and #inverse. I want > to construct a TField by composing TGroup with itself. One TGroup will > form the operations #*, #one, and #reciprocal while the other will > form #+, #zero and #negated. > > I don't want #identity or #inverse, because these apply to one > operation, and it makes TField's API ambiguous. That's what > TraitExclusion is for. > > I had thought I could say > > (TGroup @ {#identity->#zero. #* -> #+. #inverse->#negated} + TGroup @ > {#identity->#one. #inverse->#reciprocal}) - {#identity. #inverse} > > but TraitComposition >> #- says that exclusion binds tighter than +. > So in effect the above composition is the same as > > TGroup @ {#identity->#zero. #* -> #+. #inverse->#negated} + (TGroup @ > {#identity->#one. #inverse->#reciprocal} - {#identity. #inverse}) > > In short, to remove the undesirable #identity and #inverse I have to > exclude from both sides of the composition: > > TGroup @ {#identity->#zero. #* -> #+. #inverse->#negated} - > {#identity. #inverse} + TGroup @ {#identity->#one. > #inverse->#reciprocal} - {#identity. #inverse} > > My question is this: what is the reason for - binding more tightly > than +? Why is it _not_ desirable to have - distribute over +?

May 30, 2013

Re: [Pharo-dev] Livecoding - Fluxus - Athens?

by kilon

or something like that http://openendedgroup.com/field/OverviewBanners2.html <http://openendedgroup.com/field/OverviewBanners2.html> my project (Ephestos) has similar goal for Pharo, but it will take me time. I am still learning Opengl and Nativeboost and NBOpengl. -- View this message in context: http://forum.world.st/Pharo-dev-Livecoding-Fluxus-Athens-tp4690677p4690696.… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

May 29, 2013