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

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

by GÃ¶ran Krampe

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

Aug. 29, 2014

Anonymous classes in Pharo 3 - must be instances of Class, not Behavior

by Oscar Nierstrasz

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] about to integrate GTools, there is a command conflict who needs attention

by Yuriy Tymchuk

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 >> >> > >

Aug. 29, 2014

Re: [Pharo-dev] Spec wiring

by ClÃ©ment Bera

Have you checked this website: http://spec.st/docs/home/ ? 2014-08-29 10:51 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: > Hi guys, > > I need a little help to understand how spec works. Iâve encountered a > problem, that when all children nodes of a tree are checked, the parent > node remains partially checked instead of going fully checked. Iâve tried > to figure out how to work with that, but failed. Any suggestions? > > Uko >

Aug. 29, 2014

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

by Esteban Lorenzano

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. 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 > >

Aug. 29, 2014

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

by Yuriy Tymchuk

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] ObjectLiterals thoughts....

by Sven Van Caekenberghe

Hi Thierry, It is good to discuss about this. But note that the ObjectLiterals idea is not mine, it is from Stef/Igor. My contribution was to quickly create a separate project for it and add a true parser (from textual input). A design for a serialisation format, like JSON, STON, FUEL and ObjectLiterals is always a compromise between different aspect (well any design is), with specific goals in mind. I think I more or less understand what you suggest, but I guess that would make things more complex - but that is just my initial opinion/reaction. The Array special case is related to the already existing Sven On 29 Aug 2014, at 11:53, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > Hi Sven, > > have you looked into some of the alternatives such as the ones I saw when porting Dolphin code to Pharo? > > Nominally the ##( ) (force evaluation of inside Smalltalk code) and [ ] once ? > > Regarding your proposal, I'm a bit worried about the logic of scanning for class names. How can I ensure that: > > #(Array 1) is the same as #(#Array 1) ? Because #() is a literal array that sees only the Symbol not the Class ? I mean, it is not { Array. 1 } is it ? > Thierry > > 2014-08-29 11:35 GMT+02:00 stepharo <stepharo(a)free.fr>: > Hi guys > > we are looking at STON and ObjectLiterals with Christophe and for handling metadata. > > > And I was brainstorming.... I was wondering if it would be possible to have a bit more use of self evaluating > > for example > 1@3 > #k -> 2 instead of (Association #k 123) > > > my brainstorming is how could we minimize new syntactic constructs and still support a literal object format. > So object literal cover that so may be this is good. > > 1@3 as (Point 1 3) > and > #k -> 123 as (Association #k 123) > > So I'm not clear but this is interesting to think about it. > I would like to have also a dictionary literal syntax.... but this another story. > > Stef > > PS: Sven I added support for Association into the ObjectLiteral project to see how it works. > > > > > > > > > > I took Igor's initial code and created a new project: > > http://smalltalkhub.com/#!/~SvenVanCaekenberghe/ObjectLiterals/ > > and I added ObjectLiteralParser to convert any Character Stream or String into a Smalltalk Literal Array and eventually into an Object. > > This proof of concept moves the ObjectLiteral format/notation away from the Smalltalk compiler and will help us discuss more concretely the actual details of the specification (which is still not 100% finished). > > I also added 12 unit tests and cleaned up the code and comments. > > Please have a look at the code. > > This is one of the tests: > > ObjectLiteralParserTests>>#testMixed1 > | input output | > input := ' > #(Array > 1 > foo > #''foo-#bar'' > true > false > nil > 3.14159 > -100 > ''string'' > (#OrderedCollection 7 8 9) > #(Set 10) > (Dictionary > x 1 > y 2) ) '. > output := { > 1. > #foo. > #'foo-#bar'. > true. > false. > nil. > 3.14159. > -100. > 'string'. > OrderedCollection withAll: #(7 8 9). > Set with: 10. > Dictionary newFromPairs: #(x 1 y 2 ). }. > self assert: (self parserOn: input) nextObjectLiteral equals: output > > I like this format, its simplicity and elegance is appealing, it offers distinctive advantages in the Smalltalk context while its slight readability disadvantage is acceptable. Like any format it is a compromise and a tradeoff, but a rather good one. > > > > > > > Regards, > > Sven > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > > >

Aug. 29, 2014

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

by Sven Van Caekenberghe

Hi, I had a quick look at the ObjectLiterals project - I must admit that I forgot most about it ;-) Now that I see it again, one of the things that strikes me is that there is no such thing as a general object fallback, as far as I can see - that is a choice of course. Note that I did answer your earlier mail about STON http://forum.world.st/About-STON-td4772934.html Sven On 29 Aug 2014, at 11:35, stepharo <stepharo(a)free.fr> wrote: > Hi guys > > we are looking at STON and ObjectLiterals with Christophe and for handling metadata. > > > And I was brainstorming.... I was wondering if it would be possible to have a bit more use of self evaluating > > for example > 1@3 > #k -> 2 instead of (Association #k 123) > > > my brainstorming is how could we minimize new syntactic constructs and still support a literal object format. > So object literal cover that so may be this is good. > > 1@3 as (Point 1 3) > and > #k -> 123 as (Association #k 123) > > So I'm not clear but this is interesting to think about it. > I would like to have also a dictionary literal syntax.... but this another story. > > Stef > > PS: Sven I added support for Association into the ObjectLiteral project to see how it works. > > > > > > > > > > I took Igor's initial code and created a new project: > > http://smalltalkhub.com/#!/~SvenVanCaekenberghe/ObjectLiterals/ > > and I added ObjectLiteralParser to convert any Character Stream or String into a Smalltalk Literal Array and eventually into an Object. > > This proof of concept moves the ObjectLiteral format/notation away from the Smalltalk compiler and will help us discuss more concretely the actual details of the specification (which is still not 100% finished). > > I also added 12 unit tests and cleaned up the code and comments. > > Please have a look at the code. > > This is one of the tests: > > ObjectLiteralParserTests>>#testMixed1 > | input output | > input := ' > #(Array > 1 > foo > #''foo-#bar'' > true > false > nil > 3.14159 > -100 > ''string'' > (#OrderedCollection 7 8 9) > #(Set 10) > (Dictionary > x 1 > y 2) ) '. > output := { > 1. > #foo. > #'foo-#bar'. > true. > false. > nil. > 3.14159. > -100. > 'string'. > OrderedCollection withAll: #(7 8 9). > Set with: 10. > Dictionary newFromPairs: #(x 1 y 2 ). }. > self assert: (self parserOn: input) nextObjectLiteral equals: output > > I like this format, its simplicity and elegance is appealing, it offers distinctive advantages in the Smalltalk context while its slight readability disadvantage is acceptable. Like any format it is a compromise and a tradeoff, but a rather good one. > > Regards, > > Sven > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > >

Aug. 29, 2014

about to integrate GTools, there is a command conflict who needs attention

by Esteban Lorenzano

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] ObjectLiterals thoughts....

by Thierry Goubier

Hi Sven, have you looked into some of the alternatives such as the ones I saw when porting Dolphin code to Pharo? Nominally the ##( ) (force evaluation of inside Smalltalk code) and [ ] once ? Regarding your proposal, I'm a bit worried about the logic of scanning for class names. How can I ensure that: #(Array 1) is the same as #(#Array 1) ? Thierry 2014-08-29 11:35 GMT+02:00 stepharo <stepharo(a)free.fr>: > Hi guys > > we are looking at STON and ObjectLiterals with Christophe and for handling > metadata. > > > And I was brainstorming.... I was wondering if it would be possible to > have a bit more use of self evaluating > > for example > 1@3 > #k -> 2 instead of (Association #k 123) > > > my brainstorming is how could we minimize new syntactic constructs and > still support a literal object format. > So object literal cover that so may be this is good. > > 1@3 as (Point 1 3) > and > #k -> 123 as (Association #k 123) > > So I'm not clear but this is interesting to think about it. > I would like to have also a dictionary literal syntax.... but this another > story. > > Stef > > PS: Sven I added support for Association into the ObjectLiteral project to > see how it works. > > > > > > > > > > I took Igor's initial code and created a new project: > > http://smalltalkhub.com/#!/~SvenVanCaekenberghe/ObjectLiterals/ > > and I added ObjectLiteralParser to convert any Character Stream or String > into a Smalltalk Literal Array and eventually into an Object. > > This proof of concept moves the ObjectLiteral format/notation away from > the Smalltalk compiler and will help us discuss more concretely the actual > details of the specification (which is still not 100% finished). > > I also added 12 unit tests and cleaned up the code and comments. > > Please have a look at the code. > > This is one of the tests: > > ObjectLiteralParserTests>>#testMixed1 > | input output | > input := ' > #(Array > 1 > foo > #''foo-#bar'' > true > false > nil > 3.14159 > -100 > ''string'' > (#OrderedCollection 7 8 9) > #(Set 10) > (Dictionary > x 1 > y 2) ) '. > output := { > 1. > #foo. > #'foo-#bar'. > true. > false. > nil. > 3.14159. > -100. > 'string'. > OrderedCollection withAll: #(7 8 9). > Set with: 10. > Dictionary newFromPairs: #(x 1 y 2 ). }. > self assert: (self parserOn: input) nextObjectLiteral equals: output > > I like this format, its simplicity and elegance is appealing, it offers > distinctive advantages in the Smalltalk context while its slight > readability disadvantage is acceptable. Like any format it is a compromise > and a tradeoff, but a rather good one. > > > Regards, > > Sven > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > > >

Aug. 29, 2014