August 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] about to integrate GTools, there is a command conflict who needs attention

by Yuriy Tymchuk

On 29 Aug 2014, at 13:34, Nicolai Hess <nicolaihess(a)web.de> wrote: > 2014-08-29 12:26 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: > > On 29 Aug 2014, at 12:23, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > > > On 29 Aug 2014, at 12:19, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > > >> I have no idea what current (cmd+o+[w|t|etc]) stands for, so for me itâs ok to trash it. > > > > ehhhh, we are not talking about trash itâ¦ just remapping if needed :P > > and those are commands for opening transcript, workspace, etc. > > oh, then this is useful :) > > > > > Esteban > > > >> > >> I think that cmd+s can make sense. > >> > >> And as we are here, Iâd like to point out that I donât like this shortcut chains. Iâd prefer to have cmd+x to remove what is currently focused rather then > >> cmd+c+x, cmd+m+x and so on. > >> > >> Uko > >> > >> On 29 Aug 2014, at 11:54, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >> > >>> Hi guys, > >>> > >>> We are on our way to integrate (finally) GTools into Pharo. > >>> For now it will be the Playground and the Inspector, since the Debugger is still not ready. > >>> > >>> Now, Iâm facing a problem. The new command for playground (cmd+o) conflicts with some menyu commands: (cmd+o+[w|t|etc]). Since we cannot handle both, we need to choose one. > >>> I do not have a clear idea, so I want your opinions. > >>> So far, I think this: > >>> > >>> 1) cmd+o in playground is not so clear, maybe we could map thet to an âacceptâ (cmd+s) or an âexecureâ (cmd+e)â¦ > >>> 2) we could map cmd+o+etc. to something else. But I do not know to what. > >>> > >>> So, I hear opinions :) > >>> > >>> Esteban > >> > >> > > > > > > > > > What's the difference between cmd+o and cmd+d for the Playground? I guess that in case you want to still be able silently do something, you need a separate cmd+d. Otherwise new cmd+p should be good enough. >

Aug. 29, 2014

Re: [Pharo-dev] Anonymous classes in Pharo 3 - must be instances of Class, not Behavior

by Camille Teruel

On 29 aoÃ»t 2014, at 13:38, Oscar Nierstrasz <oscar.nierstrasz(a)gmail.com> wrote: > > Following up: > > Behavior new compile: 't ^ trueâ > > fails since #compile: is defined in TBehavior and depends on #basicLocalSelectors which is defined only in Class, MetaClass and TraitBehavior. > > It seems like #basicLocalSelectors should be abstract in TBehavior. > Alternatively the implementation should be moved to TBehavior and the field localSelectors should be pushed up to Behavior. Am I missing something? You're right, it should be possible to compile methods into an instance of behavior. IIRW, it was possible in Pharo 2 but we didn't pay enough attention to ensure that it is always possible. So if we can make it work again we should add your test somewhere for that. About moving localSelectors to Behavior: I'm not sure that Behavior should be aware of traits. I prefer to keep Behavior minimal (it is already too messy IMO). Also for Pharo 4 there is other issues introduced by the integration of slots (slots are now needed by Opal for compilation): - we should move slot API to Behavior - make sure that iv and format ivs are consistent with each other So there is some work to be done to make it work again... > Oscar > > On 29 Aug 2014, at 12:26 , Oscar Nierstrasz <oscar.nierstrasz(a)gmail.com> wrote: > >> >> Hi folks, >> >> I was updating my lecture on Reflection for the Software Design and Evolution course, and I see now that anonymous classes can no longer be instances of Behavior but must be instances of Class. If you try to compile a method on an instance of Behavior, it fails. (basicLocalSelectors is not understood) >> >> Am I missing something? >> >> Cheers, >> Oscar >> >> testPrimitiveChangeClassTo >> | anonClass browser | >> >> anonClass := Class new. âmust be Class, not Behavior" >> anonClass superclass: Browser. >> anonClass setFormat: Browser format. >> >> browser := Browser new. >> browser primitiveChangeClassTo: anonClass new. >> anonClass compile: 'thisIsATest ^ 2'. >> >> self assert: browser thisIsATest = 2. >> self should: [Browser new thisIsATest] >> raise: MessageNotUnderstood. >> >> > >

Aug. 29, 2014

Re: [Pharo-dev] Anonymous classes in Pharo 3 - must be instances of Class, not Behavior

by Sebastian Tleye

2014-08-29 13:38 GMT+02:00 Oscar Nierstrasz <oscar.nierstrasz(a)gmail.com>: > > Following up: > > Behavior new compile: 't ^ trueâ > > fails since #compile: is defined in TBehavior and depends on > #basicLocalSelectors which is defined only in Class, MetaClass and > TraitBehavior. > > It seems like #basicLocalSelectors should be abstract in TBehavior. > Alternatively the implementation should be moved to TBehavior and the field > localSelectors should be pushed up to Behavior. Am I missing something? > Yep, I think you are right. Last year I did a lot of modifications in Behavior, TBehavior, Class, etc. These changes were made to make classes and traits polymorphic. If I remember correctly, the instance variable localSelectors was not moved to Behavior because it was not possible to push up that instance variable (there were a lot of errors since it is one of the core classes). If you look at the traits hierarchy, localSelectors is in TraitBehavior, not in Trait. So moving the instance variable localSelectors to Behavior and then abstract basicLocalSelectors in TBehavior would be very good > Oscar > > On 29 Aug 2014, at 12:26 , Oscar Nierstrasz <oscar.nierstrasz(a)gmail.com> > wrote: > > > > > Hi folks, > > > > I was updating my lecture on Reflection for the Software Design and > Evolution course, and I see now that anonymous classes can no longer be > instances of Behavior but must be instances of Class. If you try to > compile a method on an instance of Behavior, it fails. > (basicLocalSelectors is not understood) > > > > Am I missing something? > > > > Cheers, > > Oscar > > > > testPrimitiveChangeClassTo > > | anonClass browser | > > > > anonClass := Class new. âmust be Class, not Behavior" > > anonClass superclass: Browser. > > anonClass setFormat: Browser format. > > > > browser := Browser new. > > browser primitiveChangeClassTo: anonClass new. > > anonClass compile: 'thisIsATest ^ 2'. > > > > self assert: browser thisIsATest = 2. > > self should: [Browser new thisIsATest] > > raise: MessageNotUnderstood. > > > > > > >

Aug. 29, 2014

Re: [Pharo-dev] Future of Spec

by Alexandre Bergel

+1 > Le 29-08-2014 Ã 4:17, Tudor Girba <tudor(a)tudorgirba.com> a Ã©crit : > > I like this spirit :) > > >> On Fri, Aug 29, 2014 at 9:46 AM, stepharo <stepharo(a)free.fr> wrote: >> the future is bright and shinning :) >> >> Stef > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

Aug. 29, 2014

Re: [Pharo-dev] Anonymous classes in Pharo 3 - must be instances of Class, not Behavior

by Oscar Nierstrasz

Following up: Behavior new compile: 't ^ trueâ fails since #compile: is defined in TBehavior and depends on #basicLocalSelectors which is defined only in Class, MetaClass and TraitBehavior. It seems like #basicLocalSelectors should be abstract in TBehavior. Alternatively the implementation should be moved to TBehavior and the field localSelectors should be pushed up to Behavior. Am I missing something? Oscar On 29 Aug 2014, at 12:26 , Oscar Nierstrasz <oscar.nierstrasz(a)gmail.com> wrote: > > Hi folks, > > I was updating my lecture on Reflection for the Software Design and Evolution course, and I see now that anonymous classes can no longer be instances of Behavior but must be instances of Class. If you try to compile a method on an instance of Behavior, it fails. (basicLocalSelectors is not understood) > > Am I missing something? > > Cheers, > Oscar > > testPrimitiveChangeClassTo > | anonClass browser | > > anonClass := Class new. âmust be Class, not Behavior" > anonClass superclass: Browser. > anonClass setFormat: Browser format. > > browser := Browser new. > browser primitiveChangeClassTo: anonClass new. > anonClass compile: 'thisIsATest ^ 2'. > > self assert: browser thisIsATest = 2. > self should: [Browser new thisIsATest] > raise: MessageNotUnderstood. > >

Aug. 29, 2014

Re: [Pharo-dev] Board clarification around Spec

by Alexandre Bergel

Thanks Esteban. This kind of message are really important. Thanks to let us know Cheers, Alexandre > Le 29-08-2014 Ã 4:38, Esteban Lorenzano <estebanlm(a)gmail.com> a Ã©crit : > > Hi, > > Due the recent known success, the board feels some clarification is needed. > So, here it is: > > Spec is integral part of Pharo, and we will keep it as part of our distribution. > Is our intention that community continues enhancing it, since like always, there is room for improvement. > > just that :) > > Esteban

Aug. 29, 2014

Re: [Pharo-dev] about to integrate GTools, there is a command conflict who needs attention

by Alexandre Bergel

+1 Alexandre > Le 29-08-2014 Ã 5:19, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> a Ã©crit : > > I have no idea what current (cmd+o+[w|t|etc]) stands for, so for me itâs ok to trash it. > > I think that cmd+s can make sense. > > And as we are here, Iâd like to point out that I donât like this shortcut chains. Iâd prefer to have cmd+x to remove what is currently focused rather then > cmd+c+x, cmd+m+x and so on. > > Uko > >> On 29 Aug 2014, at 11:54, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> Hi guys, >> >> We are on our way to integrate (finally) GTools into Pharo. >> For now it will be the Playground and the Inspector, since the Debugger is still not ready. >> >> Now, Iâm facing a problem. The new command for playground (cmd+o) conflicts with some menyu commands: (cmd+o+[w|t|etc]). Since we cannot handle both, we need to choose one. >> I do not have a clear idea, so I want your opinions. >> So far, I think this: >> >> 1) cmd+o in playground is not so clear, maybe we could map thet to an âacceptâ (cmd+s) or an âexecureâ (cmd+e)â¦ >> 2) we could map cmd+o+etc. to something else. But I do not know to what. >> >> So, I hear opinions :) >> >> Esteban > >

Aug. 29, 2014

Re: [Pharo-dev] about to integrate GTools, there is a command conflict who needs attention

by Nicolai Hess

2014-08-29 12:26 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: > > On 29 Aug 2014, at 12:23, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > > > On 29 Aug 2014, at 12:19, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > > >> I have no idea what current (cmd+o+[w|t|etc]) stands for, so for me > itâs ok to trash it. > > > > ehhhh, we are not talking about trash itâ¦ just remapping if needed :P > > and those are commands for opening transcript, workspace, etc. > > oh, then this is useful :) > > > > > Esteban > > > >> > >> I think that cmd+s can make sense. > >> > >> And as we are here, Iâd like to point out that I donât like this > shortcut chains. Iâd prefer to have cmd+x to remove what is currently > focused rather then > >> cmd+c+x, cmd+m+x and so on. > >> > >> Uko > >> > >> On 29 Aug 2014, at 11:54, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > >> > >>> Hi guys, > >>> > >>> We are on our way to integrate (finally) GTools into Pharo. > >>> For now it will be the Playground and the Inspector, since the > Debugger is still not ready. > >>> > >>> Now, Iâm facing a problem. The new command for playground (cmd+o) > conflicts with some menyu commands: (cmd+o+[w|t|etc]). Since we cannot > handle both, we need to choose one. > >>> I do not have a clear idea, so I want your opinions. > >>> So far, I think this: > >>> > >>> 1) cmd+o in playground is not so clear, maybe we could map thet to an > âacceptâ (cmd+s) or an âexecureâ (cmd+e)â¦ > >>> 2) we could map cmd+o+etc. to something else. But I do not know to > what. > >>> > >>> So, I hear opinions :) > >>> > >>> Esteban > >> > >> > > > > > > > What's the difference between cmd+o and cmd+d for the Playground?

Aug. 29, 2014

Re: [Pharo-dev] ObjectLiterals thoughts....

by Thierry Goubier

2014-08-29 13:16 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > On 29 Aug 2014, at 12:53, GÃ¶ran Krampe <goran(a)krampe.se> wrote: > > > Hey! > > > > Just for some "food for thought", you may want to read the parts under > heading "Literal Smalltalk arrays" and the section following - "Sidestory: > Adding literal Dictionaries to Smalltalk?" > > > > ...at: > > > > > http://goran.krampe.se/2012/05/08/literal-arrays-vs-json-vs-ston-vs-tirade/ > > > > regards, GÃ¶ran > > Yes, that is a good write up, touching on all kinds of aspects, balanced > too. > Pretty complicated subject, right ? ;-) > As you mention it is quite hard to reach an agreement. > Objectives/goals are different for everybody. > Yes, a good read as well. > > Since we had those discussions long ago, I've actually grown quite used to > writing > > { #foo->1. #bar->2 } asDictionary > > I know it is not super efficient, or super compact, but I can certainly > live with it. > I know. But I was a bit sad, when porting SmaCC from Dolphin to Pharo, to have to remove all the literals optimisations John Brant has added in the code generation, such as: ^ [ Dictionary new at: #foo put: #a; at: #bar put: #b; yourself ] once [1] and: ##(Character value: 16rXXXX) [2] (I have a framework of thought where it would be possible, for the pharo compiler, to track and optimise such methods as [1] without requiring the "once" above, but I have no idea if the gain would be worth the pain) Thierry

Aug. 29, 2014

Re: [Pharo-dev] ObjectLiterals thoughts....

by Sven Van Caekenberghe

On 29 Aug 2014, at 12:53, GÃ¶ran Krampe <goran(a)krampe.se> wrote: > Hey! > > Just for some "food for thought", you may want to read the parts under heading "Literal Smalltalk arrays" and the section following - "Sidestory: Adding literal Dictionaries to Smalltalk?" > > ...at: > > http://goran.krampe.se/2012/05/08/literal-arrays-vs-json-vs-ston-vs-tirade/ > > regards, GÃ¶ran Yes, that is a good write up, touching on all kinds of aspects, balanced too. Pretty complicated subject, right ? ;-) As you mention it is quite hard to reach an agreement. Objectives/goals are different for everybody. Since we had those discussions long ago, I've actually grown quite used to writing { #foo->1. #bar->2 } asDictionary I know it is not super efficient, or super compact, but I can certainly live with it.

Aug. 29, 2014