- Pharo-dev - lists.pharo.org

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

UndefinedObject(Object)>>doesNotUnderstand: #wait

by Yuriy Tymchuk

Sometimes when I save image I get this error: UndefinedObject(Object)>>doesNotUnderstand: #wait [ event wait. processSynchronizationDelay wait. "Avoids lost signals in heavy process switching" self changed: #childProcessStatus ] in [ [ event wait. processSynchronizationDelay wait. "Avoids lost signals in heavy process switching" self changed: #childProcessStatus ] repeat ] in UnixOSProcessAccessor>>grimReaperProcess in Block: [ ... BlockClosure>>repeat [ [ event wait. processSynchronizationDelay wait. "Avoids lost signals in heavy process switching" self changed: #childProcessStatus ] repeat ] in UnixOSProcessAccessor>>grimReaperProcess in Block: [ ... [ self value. Processor terminateActive ] in BlockClosure>>newProcess in Block: [ ... Is it a known problem? Uko

Aug. 29, 2014

Board clarification around Spec

by Esteban Lorenzano

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

ObjectLiterals thoughts....

by stepharo

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] Opal, custom compilers and class-side methods

by Tudor Girba

+1 Objects are always better than classes :) Doru On Thu, Aug 28, 2014 at 2:58 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 28 Aug 2014, at 15:54, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > > On 27 Aug 2014, at 17:53, Camille Teruel <camille.teruel(a)gmail.com> wrote: > > Hi all, > > With Opal, if you want to customize how methods are compiled into a class > you can override #compilerClass on class-side: > MyClass class>>#compilerClass > ^ MySpecialCompiler > > > Iâve missed this feature. This is super cool! > > > There is now in addition #compiler, an instance, not the class. > > This is useful as you can set compiler options this way. e.g. > InstructionStream does not need to use a subclass but can do > > compiler > "The JIT compiler needs to trap all reads to instance variables of > contexts. As this check is costly, it is only done > in the long form of the bytecodes, which are not used often. In this > hierarchy we force the compiler to always generate > long bytecodes" > ^super compiler options: #(+ optionLongIvarAccessBytecodes) > > -- www.tudorgirba.com "Every thing has its own flow"

Aug. 29, 2014

Re: [Pharo-dev] Future of Spec

by Tudor Girba

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] Issue 13941 [FEATURE]: Configuration Browser: Switch to Any Repository

by stepharo

Thanks Torsten. The best issues are the one with ready to integrate slices :) ... Soon close to you :) Stf On 29/8/14 10:41, Torsten Bergmann wrote: > Hi, > > no - there was only a context menu action to "Switch repository" so far (for instance when you > are in Pharo 4 you may still like to access repository of Pharo 3 to load, etc). > > I fixed the issue by adding an "Add repository" functionality. Details and screenshot > on https://pharo.fogbugz.com/f/cases/13941/FEATURE-Configuration-Browser-Switc… > > Have fun > T. > > > > Gesendet: Freitag, 29. August 2014 um 08:50 Uhr > Von: "phil(a)highoctane.be" <phil(a)highoctane.be> > An: "Discusses Development of Pharo" <pharo-dev(a)lists.pharo.org> > Betreff: Re: [Pharo-dev] Issue 13941 [FEATURE]: Configuration Browser: Switch to Any Repository > +1 > I remember that this can be done by some weird modified click on the configuration browser UI. > Phil > > Le 29 aoÃ»t 2014 08:35, "Sven Van Caekenberghe" <sven(a)stfx.eu> a Ã©crit :+1 > > And maybe remember manually entered URLs. > > On 29 Aug 2014, at 02:56, Sean P. DeNigris <sean@clipperadams.com[sean@clipperadams.com]> wrote: > >> It would be great to use the Configuration Browser on one's own meta reposâ¦ >> >> https://pharo.fogbugz.com/default.asp?13941[https://pharo.fogbugz.com/defau… >> >> >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: http://forum.world.st/Issue-13941-FEATURE-Configuration-Browser-Switch-to-A… >> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >> > > >

Aug. 29, 2014