- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Reflecting on data (literal) object syntax

by Christian Haider

Yes, Value (the superclass) is used for â Ã¤h :) - values, i.e. immutable literal objects, which aid me with a more functional programming style. The literal printing of Objects is possible for all objects, since the facilities are defined in Object (#asSource). And yes, it is the same as #storeString â in spirit and as fallback. But instead of using #instvarAt:put:, #asSource uses the constructor form instead. (I did not want to extend #storeString to not interfere with the systems use of it (lots).) So, instead of writing the infos (class names, selectors and arguments) in a new syntax, why not writing it as Smalltalk source? You just need to define a print method #printvalueWith: and implement the corresponding constructor(s). My question about the purpose was more from the user view. Is it for persisting settings or configurations outside an image? Or exchanging data between images / dialects? Or for interfacing with external systems? For these, I could recommend Values :). Cheers P.S. are you at ESUG? I could show you what I meanâ¦ Von: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] Im Auftrag von Norbert Hartl Gesendet: Dienstag, 4. Juli 2017 09:20 An: Pharo Dev <pharo-dev(a)lists.pharo.org> Betreff: Re: [Pharo-dev] Reflecting on data (literal) object syntax Hi Christian, thanks for the explanation. I see that Values serve a different purpose. We are looking for a compact form of object literal, the is not bound to the external interface and does not need to be subclassed. I'm interested how the printing of Values is different to #storeString. Norbert Am 04.07.2017 um 09:05 schrieb Christian Haider <christian.haider(a)smalltalked-visuals.com <mailto:christian.haider@smalltalked-visuals.com> >: Hi Norbert, yes, that is the point: it is a normal Smalltalk expression. It is trivial and every Smalltalk understands it. No need for special parsers; you just have class names and constructor methods. I believe this is a very compact and simple representation of Smalltalk objects. The Values package contains mainly the machinery to print an object (aka Value) as String so that it can be reconstructed from it. Exactly like Smalltalk prints literal objects like Array, Integer, Character, String, Symbol etc. The superclass Value makes sure that the object tree (remember â no cycles or references) will print properly (under consideration of namespaces). Also, many âsimpleâ base objects can be turned into Values by implementing constructors and the printer (like Date, Timestamp, Point, Rectangle, ColorValue etc.). Additionally, Values allow to declare optional instVars, so that the representation does not get too cluttered with boilerplate arguments. In the dev tools, there is a generator which produces the proper constructors (2**<number of defaults>). There is really not much to it, technically. Maybe it is just too simple. I would be interested in the differences to the other proposals â what should be achieved and what may be missing? HTH, Christian Von: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] Im Auftrag von Norbert Hartl Gesendet: Dienstag, 4. Juli 2017 08:14 An: Pharo Development List <pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org> > Betreff: Re: [Pharo-dev] Reflecting on data (literal) object syntax Hi Christian, Am 03.07.2017 um 11:06 schrieb Christian Haider < <mailto:christian.haider@smalltalked-visuals.com> christian.haider(a)smalltalked-visuals.com>: I solved this with Values[1] for VW and I am very happy with it (using it intensively/routinely). Your example would look like: (PointCollection points: (Array with: (Point x: 10 y: 20) with: (Point x: 5 y: 8) )) I do not understand your point. Above is a normal smalltalk expression. I skimmed through the Values document and I do not get how this is related to a discussion about compact object literal syntax. Can you elaborate a bit more? How do Values help here? Norbert As you see, it is the same except that lots of noise is gone. Drawbacks: only literal objects (like Values) are allowed; i.e. no cyclic structures (same with JSON etc.) and the order of arguments is fixed unlike JSON (but you can add constructors for every permutation :)). I think this is very clear and direct (no magic from parsers etc.). I like it most for configurations (see everything at a glance) and interface data. Best, Christian [1] <https://wiki.pdftalk.de/doku.php?id=complexvalues> https://wiki.pdftalk.de/doku.php?id=complexvalues Von: Pharo-dev [ <mailto:pharo-dev-bounces@lists.pharo.org> mailto:pharo-dev-bounces@lists.pharo.org] Im Auftrag von Norbert Hartl Gesendet: Montag, 3. Juli 2017 10:28 An: Pharo Dev < <mailto:pharo-dev@lists.pharo.org> pharo-dev(a)lists.pharo.org> Betreff: Re: [Pharo-dev] Reflecting on data (literal) object syntax Eliot, Am 01.07.2017 um 20:22 schrieb Eliot Miranda < <mailto:eliot.miranda@gmail.com> eliot.miranda(a)gmail.com>: Hi Norbert, On Jul 1, 2017, at 7:36 AM, Norbert Hartl < <mailto:norbert@hartl.name> norbert(a)hartl.name> wrote: Am 30.06.2017 um 21:14 schrieb Stephane Ducasse < <mailto:stepharo.self@gmail.com> stepharo.self(a)gmail.com>: But what is DataFrame? the new collection done by alesnedr from Lviv. It is really nice but does not solve the problem of the compact syntax. STON fromString: 'Point[10,20]' Same goes for JSON. We were brainstorming with marcus and we could have a first nice extension: { 'x' -> 10 .'y' -> 20 } asObjectOf: #Point. 10@20 Now in addition I think that there is a value in having an object literal syntax. I pasted the old mail of igor on object literals because I like the idea since it does not add any change in the parser. Do you remember what were the problem raised by this solution (beside the fact that it had too many # and the order was like in ston not explicit). I would love to have another pass on the idea of Igor. What I don't like about it is that the object literal exposes the internal implementation of the object. Everything is based on index. So it could suffer the same problem as fuel. When you don't have the exact same code the deserialization fails. Indeed this is why { 'x' -> 10 .'y' -> 20 } asObjectOf: #Point. could be more robust. We could extend the object literal syntax to use association for non collection. I think it is more robust and more explicit. I do not know what are the semantics of detecting something as #Point being a class name. Is it then forbidden to use symbols with uppercase letters? I think something like { #x -> 10 . #y -> 20} asObjectOf: #Point is handling the format with implicit knowledge of type. While the explicit version would be { #Point -> { #x -> 10 . #y -> 20}} asObject And then nested objects are as easy as {#PointCollection -> { #points -> { {#Point -> { #x -> 10 . #y -> 20} }. {#Point -> { #x -> 5 . #y -> 8} } } } asObject The -> messages are just noise and add additional processing for nothing. This is just as effective: { #Point. { #x. 10 . #y. 20}} asObject {#PointCollection. { #points. { {#Point. { #x. 10 . #y. 20} }. {#Point. { #x. 5 . #y. 8} } } } asObject So an object is a pair of a class name and an array of slot specifier pairs, and a slot specifier is a pair of a slot band and a value. And of course that means that many object specs can be literal, which is useful for storing in pragmas etc: #(PointCollection (points ((Point (x 10 y 20)) ((Point (x 5 y 8)))) asObject Agreed. My first impression was it should be something like S-expression which your example is. I was misled by the idea it should be closer to the programming syntax. But a parser does not care if implemented properly, that's right. I like the compactness of that format but still find it a bit hard to read if there is only pairs. As this object literal syntax is meant to be written in code it is important that it reads well even if there are noisy characters. would give a PointCollection of two point objects. My future wish would be that there is an object literal parser that takes all of the information from the format. And then a object literal parser that is aware of slot information. Meaning that the type information can be gathered from the object class instead having it to write in the format. In the PointCollection the slot for points would have the type information #Point attached. The format goes then to { #points -> { { #x -> 10 . #y -> 20 }. { #x -> 5 . #y -> 8 } } which would then the equivalent to something like JSON { "points" : [ { "x" : 10, "y" : 20 }, { "x" : 5, "y" : 8 } ] } What I don't know is how to solve the difference between a dictionary and an collection of associations. That's incidental to the format, internal to the parser. If the parser chooses to build a dictionary as it parses so be it. The point is that the output is as you specify; a tree of objects. The thing to think about is how to introduce labels so that sub objects can be shared in the graph, the naÃ¯ve deepCopy vs deepCopyUsing: issue. I'm not sure this is necessary. It should be a format to easily instantiate a small tree of objects. Making it build a graph instead of a tree makes everything much more complicated. Either we decide that STON can do the full set and in that case it is probably less valuable to have a simple syntax to write in code. Or we need to break pairs rule. In that case an object definition can have an optional third argument which would be the label for the object. The draback is that the label needs to be before the array of slots { :v1 #ValueHolder { 'contents' . { ValueHolder . { 'contents' . @v1 }}}} Or something like this. It would be in theory closer to STON using the @ reference. The difference is that STON has indexed object access and that variant would make it based on labels.Or something like this. Norbert Norbert As a dictionary is both, an array of associations and a key-value store, it works perfectly there. But for other objects I have doubts. Especially is in a lot of contexts you need to have a mapping of internal state to external representation. It can be applied afterwards but I'm not sure that can work all the time. Yes after we should focus on the frequent cases. And may be having a literal syntax for dictionary would be good enough. I will do another version of igor's proposal with associations to see how it feels. my 2 cents, Norbert Stef ---------- Forwarded message ---------- From: Igor Stasenko < <mailto:siguctua@gmail.com> siguctua(a)gmail.com> Date: Fri, Oct 19, 2012 at 1:09 PM Subject: [Pharo-project] Yet another Notation format: Object literals To: Pharo Development < <mailto:Pharo-project@lists.gforge.inria.fr> Pharo-project(a)lists.gforge.inria.fr> Hi, as i promised before, here the simple smalltalk-based literal format. It based on smalltalk syntax, and so, unlike JSON, it doesn't needs to have separate parser (a normal smalltalk parser used for that). The idea is quite simple: you can tell any object to represent itself as an 'object literal' , for example: (1@3) asObjectLiteral --> #(#Point 1 3) { 1@2. 3@4. true. false . nil } asObjectLiteral -> #(#Array #(#Point 1 2) #(#Point 3 4) true false nil) (Dictionary newFromPairs: { 1->#(1 2 3) . 'foo' -> 'bar' }) asObjectLiteral -> #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') Next thing, you can 'pretty-print' it (kinda): #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') printObjectLiteral '#(#Dictionary 1 (#Array 1 2 3) ''foo'' ''bar'')' and sure thing, you can do reverse conversion: '#(#Dictionary 1 (#Array 1 2 3) ''foo'' ''bar'')' parseAsObjectLiteral a Dictionary('foo'->'bar' 1->#(1 2 3) ) Initially, i thought that it could be generic (by implementing default Object>>#asObjectLiteral), but then after discussing it with others, we decided to leave Object>>#asObjectLiteral to be a subclass responsibility. So, potentially the format allows to represent any object(s) as literals, except from circular referencing objects, of course. The implementation is fairly simple, as you may guess and contains no new classes, but just extension methods here and there. Take it with grain and salt, since it is just a small proof of concept. (And if doing it for real it may need some changes etc). Since i am far from areas right now, where it can be used, i don't want to pursue it further or advocate if this is the right way to do things. Neither i having a public repository for this project.. So, if there anyone who willing to pick it up and pursue the idea further, please feel free to do so and make a public repository for project.

July 4, 2017

Re: [Pharo-dev] Reflecting on data (literal) object syntax

by Norbert Hartl

Hi Christian, thanks for the explanation. I see that Values serve a different purpose. We are looking for a compact form of object literal, the is not bound to the external interface and does not need to be subclassed. I'm interested how the printing of Values is different to #storeString. Norbert > Am 04.07.2017 um 09:05 schrieb Christian Haider <christian.haider(a)smalltalked-visuals.com>: > > Hi Norbert, > > yes, that is the point: it is a normal Smalltalk expression. > It is trivial and every Smalltalk understands it. > No need for special parsers; you just have class names and constructor methods. > I believe this is a very compact and simple representation of Smalltalk objects. > > The Values package contains mainly the machinery to print an object (aka Value) as String so that it can be reconstructed from it. > Exactly like Smalltalk prints literal objects like Array, Integer, Character, String, Symbol etc. > The superclass Value makes sure that the object tree (remember â no cycles or references) will print properly (under consideration of namespaces). > Also, many âsimpleâ base objects can be turned into Values by implementing constructors and the printer (like Date, Timestamp, Point, Rectangle, ColorValue etc.). > > Additionally, Values allow to declare optional instVars, so that the representation does not get too cluttered with boilerplate arguments. > In the dev tools, there is a generator which produces the proper constructors (2**<number of defaults>). > > There is really not much to it, technically. Maybe it is just too simple. > I would be interested in the differences to the other proposals â what should be achieved and what may be missing? > > HTH, > Christian > > Von: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] Im Auftrag von Norbert Hartl > Gesendet: Dienstag, 4. Juli 2017 08:14 > An: Pharo Development List <pharo-dev(a)lists.pharo.org> > Betreff: Re: [Pharo-dev] Reflecting on data (literal) object syntax > > Hi Christian, > > Am 03.07.2017 um 11:06 schrieb Christian Haider <christian.haider(a)smalltalked-visuals.com <mailto:christian.haider@smalltalked-visuals.com>>: > >> I solved this with Values[1] for VW and I am very happy with it (using it intensively/routinely). >> Your example would look like: >> >> (PointCollection points: (Array >> with: (Point x: 10 y: 20) >> with: (Point x: 5 y: 8) >> )) >> > I do not understand your point. Above is a normal smalltalk expression. I skimmed through the Values document and I do not get how this is related to a discussion about > compact object literal syntax. > Can you elaborate a bit more? How do Values help here? > > Norbert > >> As you see, it is the same except that lots of noise is gone. >> Drawbacks: only literal objects (like Values) are allowed; i.e. no cyclic structures (same with JSON etc.) >> and the order of arguments is fixed unlike JSON (but you can add constructors for every permutation J). >> >> I think this is very clear and direct (no magic from parsers etc.). I like it most for configurations (see everything at a glance) and interface data. >> >> Best, >> Christian >> >> [1] https://wiki.pdftalk.de/doku.php?id=complexvalues <https://wiki.pdftalk.de/doku.php?id=complexvalues> >> >> Von: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org <mailto:pharo-dev-bounces@lists.pharo.org>] Im Auftrag von Norbert Hartl >> Gesendet: Montag, 3. Juli 2017 10:28 >> An: Pharo Dev <pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org>> >> Betreff: Re: [Pharo-dev] Reflecting on data (literal) object syntax >> >> Eliot, >> >>> Am 01.07.2017 um 20:22 schrieb Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>>: >>> >>> Hi Norbert, >>> >>> >>> >>> >>>> On Jul 1, 2017, at 7:36 AM, Norbert Hartl <norbert(a)hartl.name <mailto:norbert@hartl.name>> wrote: >>>> >>>> >>>> >>>> >>>>>> Am 30.06.2017 um 21:14 schrieb Stephane Ducasse <stepharo.self(a)gmail.com <mailto:stepharo.self@gmail.com>>: >>>>>> >>>>>> But what is DataFrame? >>>>> >>>>> the new collection done by alesnedr from Lviv. It is really nice but >>>>> does not solve the problem of the compact syntax. >>>>> >>>>> >>>>> >>>>>>> >>>>>>> STON fromString: 'Point[10,20]' >>>>>>> >>>>>> Same goes for JSON. >>>>>> >>>>>> >>>>>> >>>>>>> We were brainstorming with marcus and we could have a first nice extension: >>>>>>> >>>>>>> { 'x' -> 10 .'y' -> 20 } asObjectOf: #Point. >>>>>>> >>>>>>> >>>>>>>>>> 10@20 >>>>>>> >>>>>>> Now in addition I think that there is a value in having an object >>>>>>> literal syntax. >>>>>>> >>>>>>> I pasted the old mail of igor on object literals because I like the >>>>>>> idea since it does not add any change in the parser. >>>>>>> Do you remember what were the problem raised by this solution (beside >>>>>>> the fact that it had too many # and the order was like in ston not >>>>>>> explicit). >>>>>>> >>>>>>> I would love to have another pass on the idea of Igor. >>>>>> >>>>>> What I don't like about it is that the object literal exposes the internal implementation of the object. Everything is based on index. So it could suffer the same problem as fuel. When you don't have the exact same code the deserialization fails. >>>>> >>>>> Indeed this is why >>>>> { 'x' -> 10 .'y' -> 20 } asObjectOf: #Point. >>>>> could be more robust. >>>>> We could extend the object literal syntax to use association for non >>>>> collection. >>>>> >>>> I think it is more robust and more explicit. I do not know what are the semantics of detecting something as #Point being a class name. Is it then forbidden to use symbols with uppercase letters? I think something like >>>> >>>> { #x -> 10 . #y -> 20} asObjectOf: #Point >>>> >>>> is handling the format with implicit knowledge of type. While the explicit version would be >>>> >>>> { #Point -> { #x -> 10 . #y -> 20}} asObject >>>> >>>> And then nested objects are as easy as >>>> >>>> {#PointCollection -> { >>>> #points -> { {#Point -> { #x -> 10 . #y -> 20} }. >>>> {#Point -> { #x -> 5 . #y -> 8} } } } asObject >>> >>> The -> messages are just noise and add additional processing for nothing. This is just as effective: >>> >>> { #Point. { #x. 10 . #y. 20}} asObject >>> >>> {#PointCollection. { #points. { {#Point. { #x. 10 . #y. 20} }. >>> {#Point. { #x. 5 . #y. 8} } } } asObject >>> >>> So an object is a pair of a class name and an array of slot specifier pairs, and a slot specifier is a pair of a slot band and a value. And of course that means that many object specs can be literal, which is useful for storing in pragmas etc: >>> >>> #(PointCollection >>> (points ((Point (x 10 y 20)) >>> ((Point (x 5 y 8)))) asObject >>> >>> >> Agreed. My first impression was it should be something like S-expression which your example is. I was misled by the idea it should be closer to the programming syntax. But a parser does not care if implemented properly, that's right. I like the compactness of that format but still find it a bit hard to read if there is only pairs. As this object literal syntax is meant to be written in code it is important that it reads well even if there are noisy characters. >> >> >>>> >>>> would give a PointCollection of two point objects. My future wish would be that there is an object literal parser that takes all of the information from the format. And then a object literal parser that is aware of slot information. Meaning that the type information can be gathered from the object class instead having it to write in the format. In the PointCollection the slot for points would have the type information #Point attached. The format goes then to >>>> >>>> { #points -> { >>>> { #x -> 10 . #y -> 20 }. >>>> { #x -> 5 . #y -> 8 } } >>>> >>>> which would then the equivalent to something like JSON >>>> >>>> { "points" : [ >>>> { "x" : 10, "y" : 20 }, >>>> { "x" : 5, "y" : 8 } ] } >>>> >>>> What I don't know is how to solve the difference between a dictionary and an collection of associations. >>> >>> That's incidental to the format, internal to the parser. If the parser chooses to build a dictionary as it parses so be it. The point is that the output is as you specify; a tree of objects. >>> >>> The thing to think about is how to introduce labels so that sub objects can be shared in the graph, the naÃ¯ve deepCopy vs deepCopyUsing: issue. >> >> I'm not sure this is necessary. It should be a format to easily instantiate a small tree of objects. Making it build a graph instead of a tree makes everything much more complicated. Either we decide that STON can do the full set and in that case it is probably less valuable to have a simple syntax to write in code. Or we need to break pairs rule. In that case an object definition can have an optional third argument which would be the label for the object. The draback is that the label needs to be before the array of slots >> >> { :v1 #ValueHolder { 'contents' . { ValueHolder . { 'contents' . @v1 }}}} >> >> Or something like this. It would be in theory closer to STON using the @ reference. The difference is that STON has indexed object access and that variant would make it based on labels.Or something like this. >> >> Norbert >> >>> >>> >>> >>>> >>>> Norbert >>>> >>>> >>>> >>>> >>>> >>>>>> As a dictionary is both, an array of associations and a key-value store, it works perfectly there. But for other objects I have doubts. Especially is in a lot of contexts you need to have a mapping of internal state to external representation. It can be applied afterwards but I'm not sure that can work all the time. >>>>> >>>>> Yes after we should focus on the frequent cases. And may be having a >>>>> literal syntax for dictionary would be good enough. >>>>> >>>>> I will do another version of igor's proposal with associations to see >>>>> how it feels. >>>>> >>>>> >>>>> >>>>>> >>>>>> my 2 cents, >>>>>> >>>>>> Norbert >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> Stef >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> ---------- Forwarded message ---------- >>>>>>> From: Igor Stasenko <siguctua(a)gmail.com <mailto:siguctua@gmail.com>> >>>>>>> Date: Fri, Oct 19, 2012 at 1:09 PM >>>>>>> Subject: [Pharo-project] Yet another Notation format: Object literals >>>>>>> To: Pharo Development <Pharo-project(a)lists.gforge.inria.fr <mailto:Pharo-project@lists.gforge.inria.fr>> >>>>>>> >>>>>>> >>>>>>> Hi, >>>>>>> as i promised before, here the simple smalltalk-based literal format. >>>>>>> It based on smalltalk syntax, and so, unlike JSON, it doesn't needs to >>>>>>> have separate parser (a normal smalltalk parser used for that). >>>>>>> >>>>>>> The idea is quite simple: >>>>>>> you can tell any object to represent itself as an 'object literal' , >>>>>>> for example: >>>>>>> >>>>>>> (1@3) asObjectLiteral >>>>>>> --> #(#Point 1 3) >>>>>>> >>>>>>> { 1@2. 3@4. true. false . nil } asObjectLiteral >>>>>>> >>>>>>> -> #(#Array #(#Point 1 2) #(#Point 3 4) true false nil) >>>>>>> >>>>>>> (Dictionary newFromPairs: { 1->#(1 2 3) . 'foo' -> 'bar' }) asObjectLiteral >>>>>>> -> >>>>>>> #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') >>>>>>> >>>>>>> Next thing, you can 'pretty-print' it (kinda): >>>>>>> >>>>>>> #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') printObjectLiteral >>>>>>> >>>>>>> '#(#Dictionary >>>>>>> 1 >>>>>>> (#Array 1 2 3) >>>>>>> ''foo'' ''bar'')' >>>>>>> >>>>>>> >>>>>>> and sure thing, you can do reverse conversion: >>>>>>> >>>>>>> '#(#Dictionary >>>>>>> 1 >>>>>>> (#Array 1 2 3) >>>>>>> ''foo'' ''bar'')' parseAsObjectLiteral >>>>>>> >>>>>>> a Dictionary('foo'->'bar' 1->#(1 2 3) ) >>>>>>> >>>>>>> Initially, i thought that it could be generic (by implementing default >>>>>>> Object>>#asObjectLiteral), >>>>>>> but then after discussing it with others, we decided to leave >>>>>>> >>>>>>> Object>>#asObjectLiteral to be a subclass responsibility. >>>>>>> So, potentially the format allows to represent any object(s) as >>>>>>> literals, except from circular referencing objects, of course. >>>>>>> >>>>>>> The implementation is fairly simple, as you may guess and contains no >>>>>>> new classes, but just extension methods here and there. >>>>>>> >>>>>>> Take it with grain and salt, since it is just a small proof of >>>>>>> concept. (And if doing it for real it may need some changes etc). >>>>>>> Since i am far from areas right now, where it can be used, i don't >>>>>>> want to pursue it further or advocate if this is the right way to do >>>>>>> things. >>>>>>> Neither i having a public repository for this project.. >>>>>>> >>>>>>> So, if there anyone who willing to pick it up and pursue the idea >>>>>>> further, please feel free to do so and make a public repository for >>>>>>> project.

July 4, 2017

Re: [Pharo-dev] Reflecting on data (literal) object syntax

by Christian Haider

Hi Norbert, yes, that is the point: it is a normal Smalltalk expression. It is trivial and every Smalltalk understands it. No need for special parsers; you just have class names and constructor methods. I believe this is a very compact and simple representation of Smalltalk objects. The Values package contains mainly the machinery to print an object (aka Value) as String so that it can be reconstructed from it. Exactly like Smalltalk prints literal objects like Array, Integer, Character, String, Symbol etc. The superclass Value makes sure that the object tree (remember â no cycles or references) will print properly (under consideration of namespaces). Also, many âsimpleâ base objects can be turned into Values by implementing constructors and the printer (like Date, Timestamp, Point, Rectangle, ColorValue etc.). Additionally, Values allow to declare optional instVars, so that the representation does not get too cluttered with boilerplate arguments. In the dev tools, there is a generator which produces the proper constructors (2**<number of defaults>). There is really not much to it, technically. Maybe it is just too simple. I would be interested in the differences to the other proposals â what should be achieved and what may be missing? HTH, Christian Von: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] Im Auftrag von Norbert Hartl Gesendet: Dienstag, 4. Juli 2017 08:14 An: Pharo Development List <pharo-dev(a)lists.pharo.org> Betreff: Re: [Pharo-dev] Reflecting on data (literal) object syntax Hi Christian, Am 03.07.2017 um 11:06 schrieb Christian Haider <christian.haider(a)smalltalked-visuals.com <mailto:christian.haider@smalltalked-visuals.com> >: I solved this with Values[1] for VW and I am very happy with it (using it intensively/routinely). Your example would look like: (PointCollection points: (Array with: (Point x: 10 y: 20) with: (Point x: 5 y: 8) )) I do not understand your point. Above is a normal smalltalk expression. I skimmed through the Values document and I do not get how this is related to a discussion about compact object literal syntax. Can you elaborate a bit more? How do Values help here? Norbert As you see, it is the same except that lots of noise is gone. Drawbacks: only literal objects (like Values) are allowed; i.e. no cyclic structures (same with JSON etc.) and the order of arguments is fixed unlike JSON (but you can add constructors for every permutation :)). I think this is very clear and direct (no magic from parsers etc.). I like it most for configurations (see everything at a glance) and interface data. Best, Christian [1] https://wiki.pdftalk.de/doku.php?id=complexvalues Von: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] Im Auftrag von Norbert Hartl Gesendet: Montag, 3. Juli 2017 10:28 An: Pharo Dev <pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org> > Betreff: Re: [Pharo-dev] Reflecting on data (literal) object syntax Eliot, Am 01.07.2017 um 20:22 schrieb Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com> >: Hi Norbert, On Jul 1, 2017, at 7:36 AM, Norbert Hartl <norbert(a)hartl.name <mailto:norbert@hartl.name> > wrote: Am 30.06.2017 um 21:14 schrieb Stephane Ducasse <stepharo.self(a)gmail.com <mailto:stepharo.self@gmail.com> >: But what is DataFrame? the new collection done by alesnedr from Lviv. It is really nice but does not solve the problem of the compact syntax. STON fromString: 'Point[10,20]' Same goes for JSON. We were brainstorming with marcus and we could have a first nice extension: { 'x' -> 10 .'y' -> 20 } asObjectOf: #Point. 10@20 Now in addition I think that there is a value in having an object literal syntax. I pasted the old mail of igor on object literals because I like the idea since it does not add any change in the parser. Do you remember what were the problem raised by this solution (beside the fact that it had too many # and the order was like in ston not explicit). I would love to have another pass on the idea of Igor. What I don't like about it is that the object literal exposes the internal implementation of the object. Everything is based on index. So it could suffer the same problem as fuel. When you don't have the exact same code the deserialization fails. Indeed this is why { 'x' -> 10 .'y' -> 20 } asObjectOf: #Point. could be more robust. We could extend the object literal syntax to use association for non collection. I think it is more robust and more explicit. I do not know what are the semantics of detecting something as #Point being a class name. Is it then forbidden to use symbols with uppercase letters? I think something like { #x -> 10 . #y -> 20} asObjectOf: #Point is handling the format with implicit knowledge of type. While the explicit version would be { #Point -> { #x -> 10 . #y -> 20}} asObject And then nested objects are as easy as {#PointCollection -> { #points -> { {#Point -> { #x -> 10 . #y -> 20} }. {#Point -> { #x -> 5 . #y -> 8} } } } asObject The -> messages are just noise and add additional processing for nothing. This is just as effective: { #Point. { #x. 10 . #y. 20}} asObject {#PointCollection. { #points. { {#Point. { #x. 10 . #y. 20} }. {#Point. { #x. 5 . #y. 8} } } } asObject So an object is a pair of a class name and an array of slot specifier pairs, and a slot specifier is a pair of a slot band and a value. And of course that means that many object specs can be literal, which is useful for storing in pragmas etc: #(PointCollection (points ((Point (x 10 y 20)) ((Point (x 5 y 8)))) asObject Agreed. My first impression was it should be something like S-expression which your example is. I was misled by the idea it should be closer to the programming syntax. But a parser does not care if implemented properly, that's right. I like the compactness of that format but still find it a bit hard to read if there is only pairs. As this object literal syntax is meant to be written in code it is important that it reads well even if there are noisy characters. would give a PointCollection of two point objects. My future wish would be that there is an object literal parser that takes all of the information from the format. And then a object literal parser that is aware of slot information. Meaning that the type information can be gathered from the object class instead having it to write in the format. In the PointCollection the slot for points would have the type information #Point attached. The format goes then to { #points -> { { #x -> 10 . #y -> 20 }. { #x -> 5 . #y -> 8 } } which would then the equivalent to something like JSON { "points" : [ { "x" : 10, "y" : 20 }, { "x" : 5, "y" : 8 } ] } What I don't know is how to solve the difference between a dictionary and an collection of associations. That's incidental to the format, internal to the parser. If the parser chooses to build a dictionary as it parses so be it. The point is that the output is as you specify; a tree of objects. The thing to think about is how to introduce labels so that sub objects can be shared in the graph, the naÃ¯ve deepCopy vs deepCopyUsing: issue. I'm not sure this is necessary. It should be a format to easily instantiate a small tree of objects. Making it build a graph instead of a tree makes everything much more complicated. Either we decide that STON can do the full set and in that case it is probably less valuable to have a simple syntax to write in code. Or we need to break pairs rule. In that case an object definition can have an optional third argument which would be the label for the object. The draback is that the label needs to be before the array of slots { :v1 #ValueHolder { 'contents' . { ValueHolder . { 'contents' . @v1 }}}} Or something like this. It would be in theory closer to STON using the @ reference. The difference is that STON has indexed object access and that variant would make it based on labels.Or something like this. Norbert Norbert As a dictionary is both, an array of associations and a key-value store, it works perfectly there. But for other objects I have doubts. Especially is in a lot of contexts you need to have a mapping of internal state to external representation. It can be applied afterwards but I'm not sure that can work all the time. Yes after we should focus on the frequent cases. And may be having a literal syntax for dictionary would be good enough. I will do another version of igor's proposal with associations to see how it feels. my 2 cents, Norbert Stef ---------- Forwarded message ---------- From: Igor Stasenko <siguctua(a)gmail.com <mailto:siguctua@gmail.com> > Date: Fri, Oct 19, 2012 at 1:09 PM Subject: [Pharo-project] Yet another Notation format: Object literals To: Pharo Development <Pharo-project(a)lists.gforge.inria.fr <mailto:Pharo-project@lists.gforge.inria.fr> > Hi, as i promised before, here the simple smalltalk-based literal format. It based on smalltalk syntax, and so, unlike JSON, it doesn't needs to have separate parser (a normal smalltalk parser used for that). The idea is quite simple: you can tell any object to represent itself as an 'object literal' , for example: (1@3) asObjectLiteral --> #(#Point 1 3) { 1@2. 3@4. true. false . nil } asObjectLiteral -> #(#Array #(#Point 1 2) #(#Point 3 4) true false nil) (Dictionary newFromPairs: { 1->#(1 2 3) . 'foo' -> 'bar' }) asObjectLiteral -> #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') Next thing, you can 'pretty-print' it (kinda): #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') printObjectLiteral '#(#Dictionary 1 (#Array 1 2 3) ''foo'' ''bar'')' and sure thing, you can do reverse conversion: '#(#Dictionary 1 (#Array 1 2 3) ''foo'' ''bar'')' parseAsObjectLiteral a Dictionary('foo'->'bar' 1->#(1 2 3) ) Initially, i thought that it could be generic (by implementing default Object>>#asObjectLiteral), but then after discussing it with others, we decided to leave Object>>#asObjectLiteral to be a subclass responsibility. So, potentially the format allows to represent any object(s) as literals, except from circular referencing objects, of course. The implementation is fairly simple, as you may guess and contains no new classes, but just extension methods here and there. Take it with grain and salt, since it is just a small proof of concept. (And if doing it for real it may need some changes etc). Since i am far from areas right now, where it can be used, i don't want to pursue it further or advocate if this is the right way to do things. Neither i having a public repository for this project.. So, if there anyone who willing to pick it up and pursue the idea further, please feel free to do so and make a public repository for project.

July 4, 2017

Re: [Pharo-dev] Reflecting on data (literal) object syntax

by Norbert Hartl

Hi Christian, > Am 03.07.2017 um 11:06 schrieb Christian Haider <christian.haider(a)smalltalked-visuals.com>: > > I solved this with Values[1] for VW and I am very happy with it (using it intensively/routinely). > Your example would look like: > > (PointCollection points: (Array > with: (Point x: 10 y: 20) > with: (Point x: 5 y: 8) > )) > I do not understand your point. Above is a normal smalltalk expression. I skimmed through the Values document and I do not get how this is related to a discussion about compact object literal syntax. Can you elaborate a bit more? How do Values help here? Norbert > As you see, it is the same except that lots of noise is gone. > Drawbacks: only literal objects (like Values) are allowed; i.e. no cyclic structures (same with JSON etc.) > and the order of arguments is fixed unlike JSON (but you can add constructors for every permutation J). > > I think this is very clear and direct (no magic from parsers etc.). I like it most for configurations (see everything at a glance) and interface data. > > Best, > Christian > > [1] https://wiki.pdftalk.de/doku.php?id=complexvalues > > Von: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] Im Auftrag von Norbert Hartl > Gesendet: Montag, 3. Juli 2017 10:28 > An: Pharo Dev <pharo-dev(a)lists.pharo.org> > Betreff: Re: [Pharo-dev] Reflecting on data (literal) object syntax > > Eliot, > > Am 01.07.2017 um 20:22 schrieb Eliot Miranda <eliot.miranda(a)gmail.com>: > > Hi Norbert, > > > > On Jul 1, 2017, at 7:36 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > > > > Am 30.06.2017 um 21:14 schrieb Stephane Ducasse <stepharo.self(a)gmail.com>: > > But what is DataFrame? > > the new collection done by alesnedr from Lviv. It is really nice but > does not solve the problem of the compact syntax. > > > > STON fromString: 'Point[10,20]' > > Same goes for JSON. > > > We were brainstorming with marcus and we could have a first nice extension: > > { 'x' -> 10 .'y' -> 20 } asObjectOf: #Point. > > 10@20 > > Now in addition I think that there is a value in having an object > literal syntax. > > I pasted the old mail of igor on object literals because I like the > idea since it does not add any change in the parser. > Do you remember what were the problem raised by this solution (beside > the fact that it had too many # and the order was like in ston not > explicit). > > I would love to have another pass on the idea of Igor. > > What I don't like about it is that the object literal exposes the internal implementation of the object. Everything is based on index. So it could suffer the same problem as fuel. When you don't have the exact same code the deserialization fails. > > Indeed this is why > { 'x' -> 10 .'y' -> 20 } asObjectOf: #Point. > could be more robust. > We could extend the object literal syntax to use association for non > collection. > > I think it is more robust and more explicit. I do not know what are the semantics of detecting something as #Point being a class name. Is it then forbidden to use symbols with uppercase letters? I think something like > > { #x -> 10 . #y -> 20} asObjectOf: #Point > > is handling the format with implicit knowledge of type. While the explicit version would be > > { #Point -> { #x -> 10 . #y -> 20}} asObject > > And then nested objects are as easy as > > {#PointCollection -> { > #points -> { {#Point -> { #x -> 10 . #y -> 20} }. > {#Point -> { #x -> 5 . #y -> 8} } } } asObject > > The -> messages are just noise and add additional processing for nothing. This is just as effective: > > { #Point. { #x. 10 . #y. 20}} asObject > > {#PointCollection. { #points. { {#Point. { #x. 10 . #y. 20} }. > {#Point. { #x. 5 . #y. 8} } } } asObject > > So an object is a pair of a class name and an array of slot specifier pairs, and a slot specifier is a pair of a slot band and a value. And of course that means that many object specs can be literal, which is useful for storing in pragmas etc: > > #(PointCollection > (points ((Point (x 10 y 20)) > ((Point (x 5 y 8)))) asObject > > Agreed. My first impression was it should be something like S-expression which your example is. I was misled by the idea it should be closer to the programming syntax. But a parser does not care if implemented properly, that's right. I like the compactness of that format but still find it a bit hard to read if there is only pairs. As this object literal syntax is meant to be written in code it is important that it reads well even if there are noisy characters. > > > would give a PointCollection of two point objects. My future wish would be that there is an object literal parser that takes all of the information from the format. And then a object literal parser that is aware of slot information. Meaning that the type information can be gathered from the object class instead having it to write in the format. In the PointCollection the slot for points would have the type information #Point attached. The format goes then to > > { #points -> { > { #x -> 10 . #y -> 20 }. > { #x -> 5 . #y -> 8 } } > > which would then the equivalent to something like JSON > > { "points" : [ > { "x" : 10, "y" : 20 }, > { "x" : 5, "y" : 8 } ] } > > What I don't know is how to solve the difference between a dictionary and an collection of associations. > > That's incidental to the format, internal to the parser. If the parser chooses to build a dictionary as it parses so be it. The point is that the output is as you specify; a tree of objects. > > The thing to think about is how to introduce labels so that sub objects can be shared in the graph, the naÃ¯ve deepCopy vs deepCopyUsing: issue. > > I'm not sure this is necessary. It should be a format to easily instantiate a small tree of objects. Making it build a graph instead of a tree makes everything much more complicated. Either we decide that STON can do the full set and in that case it is probably less valuable to have a simple syntax to write in code. Or we need to break pairs rule. In that case an object definition can have an optional third argument which would be the label for the object. The draback is that the label needs to be before the array of slots > > { :v1 #ValueHolder { 'contents' . { ValueHolder . { 'contents' . @v1 }}}} > > Or something like this. It would be in theory closer to STON using the @ reference. The difference is that STON has indexed object access and that variant would make it based on labels.Or something like this. > > Norbert > > > > > Norbert > > > > > As a dictionary is both, an array of associations and a key-value store, it works perfectly there. But for other objects I have doubts. Especially is in a lot of contexts you need to have a mapping of internal state to external representation. It can be applied afterwards but I'm not sure that can work all the time. > > Yes after we should focus on the frequent cases. And may be having a > literal syntax for dictionary would be good enough. > > I will do another version of igor's proposal with associations to see > how it feels. > > > > my 2 cents, > > Norbert > > > > Stef > > > > > ---------- Forwarded message ---------- > From: Igor Stasenko <siguctua(a)gmail.com> > Date: Fri, Oct 19, 2012 at 1:09 PM > Subject: [Pharo-project] Yet another Notation format: Object literals > To: Pharo Development <Pharo-project(a)lists.gforge.inria.fr> > > > Hi, > as i promised before, here the simple smalltalk-based literal format. > It based on smalltalk syntax, and so, unlike JSON, it doesn't needs to > have separate parser (a normal smalltalk parser used for that). > > The idea is quite simple: > you can tell any object to represent itself as an 'object literal' , > for example: > > (1@3) asObjectLiteral > --> #(#Point 1 3) > > { 1@2. 3@4. true. false . nil } asObjectLiteral > > -> #(#Array #(#Point 1 2) #(#Point 3 4) true false nil) > > (Dictionary newFromPairs: { 1->#(1 2 3) . 'foo' -> 'bar' }) asObjectLiteral > -> > #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') > > Next thing, you can 'pretty-print' it (kinda): > > #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') printObjectLiteral > > '#(#Dictionary > 1 > (#Array 1 2 3) > ''foo'' ''bar'')' > > > and sure thing, you can do reverse conversion: > > '#(#Dictionary > 1 > (#Array 1 2 3) > ''foo'' ''bar'')' parseAsObjectLiteral > > a Dictionary('foo'->'bar' 1->#(1 2 3) ) > > Initially, i thought that it could be generic (by implementing default > Object>>#asObjectLiteral), > but then after discussing it with others, we decided to leave > > Object>>#asObjectLiteral to be a subclass responsibility. > So, potentially the format allows to represent any object(s) as > literals, except from circular referencing objects, of course. > > The implementation is fairly simple, as you may guess and contains no > new classes, but just extension methods here and there. > > Take it with grain and salt, since it is just a small proof of > concept. (And if doing it for real it may need some changes etc). > Since i am far from areas right now, where it can be used, i don't > want to pursue it further or advocate if this is the right way to do > things. > Neither i having a public repository for this project.. > > So, if there anyone who willing to pick it up and pursue the idea > further, please feel free to do so and make a public repository for > project. >

July 4, 2017

Re: [Pharo-dev] Reflecting on data (literal) object syntax

by Christian Haider

Hi Thorsten. c) both are licensed with the MIT license Values since 2009 and PDF4Smalltalk since 2011 The current versions are in the Public Store at Cincom: Bundle {Values Development} (1.2.0.0, chaider) 12.5.2017 and Bundle {PDF Development} (1.4.5.0, chaider) 1.12.2016 The current landing pages are [1] and [2]. Values should be very easy to port. It does not use namespaces and is rather trivial. [1] https://wiki.pdftalk.de/doku.php?id=complexvalues [2] http://christianhaider.de/dokuwiki/doku.php?id=pdf:pdf4smalltalk > -----UrsprÃ¼ngliche Nachricht----- > Von: Torsten Bergmann [mailto:astares@gmx.de] > Gesendet: Montag, 3. Juli 2017 21:36 > An: pharo-dev(a)lists.pharo.org > Cc: Pharo Development List <pharo-dev(a)lists.pharo.org>; > christian.haider(a)smalltalked-visuals.com > Betreff: Re: [Pharo-dev] Reflecting on data (literal) object syntax > > Hi Christian, > > just to avoid confusions: What was released with MIT license now: > > a) the Values code > b) the pdf4smalltalk code > c) or both > > and where can one find the latest release in case interested people want to > start a port to Pharo? > > Thanks in advance for any clarification! > > Bye > Torsten > > > > Gesendet: Montag, 03. Juli 2017 um 18:54 Uhr > Von: "Ben Coman" <btc(a)openinworld.com> > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > Betreff: Re: [Pharo-dev] Reflecting on data (literal) object syntax > > Thanks Christian for the open release of pdf4smalltalk. Sorry I aborted the > two times I started to port it to Pharo. The task of dealing with both file > format and namespace differences to synchronise with VW was too big for > me. Now with Iceberg, if VisualWorks might work with git that would knock > down one barrier and I might have another go. > > On Mon, Jul 3, 2017 at 5:45 PM, Christian Haider > <christian.haider@smalltalked- > visuals.com[mailto:christian.haider@smalltalked-visuals.com]> wrote: > > I did > > > Von: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org[mailto:pharo- > dev-bounces(a)lists.pharo.org]] Im Auftrag von Serge Stinckwich > Gesendet: Montag, 3. Juli 2017 11:40 > An: Pharo Development List <pharo-dev@lists.pharo.org[mailto:pharo- > dev(a)lists.pharo.org]> > > Betreff: Re: [Pharo-dev] Reflecting on data (literal) object syntax > > > > > Hi Christian, > > > > interesting ! Maybe you can release your software with an MIT licence ? > > > > Regards, > > > > On Mon, Jul 3, 2017 at 10:06 AM, Christian Haider > <christian.haider@smalltalked- > visuals.com[mailto:christian.haider@smalltalked-visuals.com]> wrote: > > I solved this with Values[1] for VW and I am very happy with it (using it > intensively/routinely). > Your example would look like: > > (PointCollection points: (Array > with: (Point x: 10 y: 20) > with: (Point x: 5 y: 8) > )) > > > And I remember you saying pdf4smalltalk relied heavily on this, so having > Values integrated (if it was broadly useful) would also be a minor step in > porting pdf4smalltalk to Pharo. > > cheers -ben > > > > As you see, it is the same except that lots of noise is gone. > Drawbacks: only literal objects (like Values) are allowed; i.e. no cyclic > structures (same with JSON etc.) and the order of arguments is fixed unlike > JSON (but you can add constructors for every permutation J). > > I think this is very clear and direct (no magic from parsers etc.). I like it most > for configurations (see everything at a glance) and interface data. > > Best, > Christian > > [1] > https://wiki.pdftalk.de/doku.php?id=complexvalues[https://wiki.pdftalk.de > /doku.php?id=complexvalues] > > > Von: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org[mailto:pharo- > dev-bounces(a)lists.pharo.org]] Im Auftrag von Norbert Hartl > Gesendet: Montag, 3. Juli 2017 10:28 > An: Pharo Dev <pharo-dev@lists.pharo.org[mailto:pharo- > dev(a)lists.pharo.org]> > Betreff: Re: [Pharo-dev] Reflecting on data (literal) object syntax > > > Eliot, > > > > Am 01.07.2017 um 20:22 schrieb Eliot Miranda > <eliot.miranda@gmail.com[mailto:eliot.miranda@gmail.com]>: > > > Hi Norbert, > > > On Jul 1, 2017, at 7:36 AM, Norbert Hartl > <norbert@hartl.name[mailto:norbert@hartl.name]> wrote: > > > Am 30.06.2017 um 21:14 schrieb Stephane Ducasse > <stepharo.self@gmail.com[mailto:stepharo.self@gmail.com]>: > > But what is DataFrame? > > the new collection done by alesnedr from Lviv. It is really nice but does not > solve the problem of the compact syntax. > > > STON fromString: 'Point[10,20]' > Same goes for JSON. > > We were brainstorming with marcus and we could have a first nice > extension: > > { 'x' -> 10 .'y' -> 20 } asObjectOf: #Point. > 10@20 > > Now in addition I think that there is a value in having an object literal syntax. > > I pasted the old mail of igor on object literals because I like the idea since it > does not add any change in the parser. > Do you remember what were the problem raised by this solution (beside the > fact that it had too many # and the order was like in ston not explicit). > > I would love to have another pass on the idea of Igor. > > What I don't like about it is that the object literal exposes the internal > implementation of the object. Everything is based on index. So it could suffer > the same problem as fuel. When you don't have the exact same code the > deserialization fails. > > Indeed this is why > { 'x' -> 10 .'y' -> 20 } asObjectOf: #Point. > could be more robust. > We could extend the object literal syntax to use association for non > collection. > I think it is more robust and more explicit. I do not know what are the > semantics of detecting something as #Point being a class name. Is it then > forbidden to use symbols with uppercase letters? I think something like > > { #x -> 10 . #y -> 20} asObjectOf: #Point > > is handling the format with implicit knowledge of type. While the explicit > version would be > > { #Point -> { #x -> 10 . #y -> 20}} asObject > > And then nested objects are as easy as > > {#PointCollection -> { > #points -> { {#Point -> { #x -> 10 . #y -> 20} }. > {#Point -> { #x -> 5 . #y -> 8} } } } asObject > > The -> messages are just noise and add additional processing for > nothing. This is just as effective: > > { #Point. { #x. 10 . #y. 20}} asObject > > {#PointCollection. { #points. { {#Point. { #x. 10 . #y. 20} }. > {#Point. { #x. 5 . #y. 8} } } } asObject > > So an object is a pair of a class name and an array of slot specifier pairs, and a > slot specifier is a pair of a slot band and a value. And of course that means > that many object specs can be literal, which is useful for storing in pragmas > etc: > > #(PointCollection > (points ((Point (x 10 y 20)) > ((Point (x 5 y 8)))) asObject Agreed. My first impression was it > should be something like S-expression which your example is. I was misled > by the idea it should be closer to the programming syntax. But a parser does > not care if implemented properly, that's right. I like the compactness of that > format but still find it a bit hard to read if there is only pairs. As this object > literal syntax is meant to be written in code it is important that it reads well > even if there are noisy characters. > > would give a PointCollection of two point objects. My future wish would be > that there is an object literal parser that takes all of the information from the > format. And then a object literal parser that is aware of slot information. > Meaning that the type information can be gathered from the object class > instead having it to write in the format. In the PointCollection the slot for > points would have the type information #Point attached. The format goes > then to > > { #points -> { > { #x -> 10 . #y -> 20 }. > { #x -> 5 . #y -> 8 } } > > which would then the equivalent to something like JSON > > { "points" : [ > { "x" : 10, "y" : 20 }, > { "x" : 5, "y" : 8 } ] } > > What I don't know is how to solve the difference between a dictionary and > an collection of associations. > > That's incidental to the format, internal to the parser. If the parser chooses > to build a dictionary as it parses so be it. The point is that the output is as you > specify; a tree of objects. > > The thing to think about is how to introduce labels so that sub objects can be > shared in the graph, the naÃ¯ve deepCopy vs deepCopyUsing: issue. > > > I'm not sure this is necessary. It should be a format to easily instantiate a > small tree of objects. Making it build a graph instead of a tree makes > everything much more complicated. Either we decide that STON can do the > full set and in that case it is probably less valuable to have a simple syntax to > write in code. Or we need to break pairs rule. In that case an object definition > can have an optional third argument which would be the label for the object. > The draback is that the label needs to be before the array of slots > > > > { :v1 #ValueHolder { 'contents' . { ValueHolder . { 'contents' . @v1 }}}} > > > > Or something like this. It would be in theory closer to STON using the @ > reference. The difference is that STON has indexed object access and that > variant would make it based on labels.Or something like this. > > > > Norbert > > > > > > Norbert > > > > As a dictionary is both, an array of associations and a key-value store, it works > perfectly there. But for other objects I have doubts. Especially is in a lot of > contexts you need to have a mapping of internal state to external > representation. It can be applied afterwards but I'm not sure that can work > all the time. > > Yes after we should focus on the frequent cases. And may be having a literal > syntax for dictionary would be good enough. > > I will do another version of igor's proposal with associations to see how it > feels. > > > my 2 cents, > > Norbert > > > Stef > > > > > ---------- Forwarded message ---------- > From: Igor Stasenko <siguctua@gmail.com[mailto:siguctua@gmail.com]> > Date: Fri, Oct 19, 2012 at 1:09 PM > Subject: [Pharo-project] Yet another Notation format: Object literals > To: Pharo Development <Pharo-project@lists.gforge.inria.fr[mailto:Pharo- > project(a)lists.gforge.inria.fr]> > > > Hi, > as i promised before, here the simple smalltalk-based literal format. > It based on smalltalk syntax, and so, unlike JSON, it doesn't needs to have > separate parser (a normal smalltalk parser used for that). > > The idea is quite simple: > you can tell any object to represent itself as an 'object literal' , for example: > > (1@3) asObjectLiteral > --> #(#Point 1 3) > > { 1@2. 3@4. true. false . nil } asObjectLiteral > > -> #(#Array #(#Point 1 2) #(#Point 3 4) true false nil) > > (Dictionary newFromPairs: { 1->#(1 2 3) . 'foo' -> 'bar' }) asObjectLiteral > -> > #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') > > Next thing, you can 'pretty-print' it (kinda): > > #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') printObjectLiteral > > '#(#Dictionary > 1 > (#Array 1 2 3) > ''foo'' ''bar'')' > > > and sure thing, you can do reverse conversion: > > '#(#Dictionary > 1 > (#Array 1 2 3) > ''foo'' ''bar'')' parseAsObjectLiteral > > a Dictionary('foo'->'bar' 1->#(1 2 3) ) > > Initially, i thought that it could be generic (by implementing default > Object>>#asObjectLiteral), > but then after discussing it with others, we decided to leave > > Object>>#asObjectLiteral to be a subclass responsibility. > So, potentially the format allows to represent any object(s) as literals, except > from circular referencing objects, of course. > > The implementation is fairly simple, as you may guess and contains no new > classes, but just extension methods here and there. > > Take it with grain and salt, since it is just a small proof of concept. (And if > doing it for real it may need some changes etc). > Since i am far from areas right now, where it can be used, i don't want to > pursue it further or advocate if this is the right way to do things. > Neither i having a public repository for this project.. > > So, if there anyone who willing to pick it up and pursue the idea further, > please feel free to do so and make a public repository for project. > > > > > > -- > > Serge Stinckwich > UCN & UMI UMMISCO 209 (IRD/UPMC) > Every DSL ends up being Smalltalk > http://www.doesnotunderstand.org/[http://www.doesnotunderstand.org/ > ]

July 4, 2017

Re: [Pharo-dev] Reflecting on data (literal) object syntax - porting PDF

by Christian Haider

Hi Ben, at ESUG I will hopefully show the new version of the library with a new PDF type implementation which allows the classes to be freely (re)named. This should make a port a lot easier. Currently I am working on the port for Gemstone. If that works, it could be more than half the way towards a Pharo/Squeak version. cheers Von: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] Im Auftrag von Ben Coman Gesendet: Montag, 3. Juli 2017 18:54 An: Pharo Development List <pharo-dev(a)lists.pharo.org> Betreff: Re: [Pharo-dev] Reflecting on data (literal) object syntax Thanks Christian for the open release of pdf4smalltalk. Sorry I aborted the two times I started to port it to Pharo. The task of dealing with both file format and namespace differences to synchronise with VW was too big for me. Now with Iceberg, if VisualWorks might work with git that would knock down one barrier and I might have another go. On Mon, Jul 3, 2017 at 5:45 PM, Christian Haider <christian.haider(a)smalltalked-visuals.com <mailto:christian.haider@smalltalked-visuals.com> > wrote: I did Von: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org <mailto:pharo-dev-bounces@lists.pharo.org> ] Im Auftrag von Serge Stinckwich Gesendet: Montag, 3. Juli 2017 11:40 An: Pharo Development List <pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org> > Betreff: Re: [Pharo-dev] Reflecting on data (literal) object syntax Hi Christian, interesting ! Maybe you can release your software with an MIT licence ? Regards, On Mon, Jul 3, 2017 at 10:06 AM, Christian Haider <christian.haider(a)smalltalked-visuals.com <mailto:christian.haider@smalltalked-visuals.com> > wrote: I solved this with Values[1] for VW and I am very happy with it (using it intensively/routinely). Your example would look like: (PointCollection points: (Array with: (Point x: 10 y: 20) with: (Point x: 5 y: 8) )) And I remember you saying pdf4smalltalk relied heavily on this, so having Values integrated (if it was broadly useful) would also be a minor step in porting pdf4smalltalk to Pharo. cheers -ben As you see, it is the same except that lots of noise is gone. Drawbacks: only literal objects (like Values) are allowed; i.e. no cyclic structures (same with JSON etc.) and the order of arguments is fixed unlike JSON (but you can add constructors for every permutation :)). I think this is very clear and direct (no magic from parsers etc.). I like it most for configurations (see everything at a glance) and interface data. Best, Christian [1] https://wiki.pdftalk.de/doku.php?id=complexvalues Von: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org <mailto:pharo-dev-bounces@lists.pharo.org> ] Im Auftrag von Norbert Hartl Gesendet: Montag, 3. Juli 2017 10:28 An: Pharo Dev <pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org> > Betreff: Re: [Pharo-dev] Reflecting on data (literal) object syntax Eliot, Am 01.07.2017 um 20:22 schrieb Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com> >: Hi Norbert, On Jul 1, 2017, at 7:36 AM, Norbert Hartl <norbert(a)hartl.name <mailto:norbert@hartl.name> > wrote: Am 30.06.2017 um 21:14 schrieb Stephane Ducasse <stepharo.self(a)gmail.com <mailto:stepharo.self@gmail.com> >: But what is DataFrame? the new collection done by alesnedr from Lviv. It is really nice but does not solve the problem of the compact syntax. STON fromString: 'Point[10,20]' Same goes for JSON. We were brainstorming with marcus and we could have a first nice extension: { 'x' -> 10 .'y' -> 20 } asObjectOf: #Point. 10@20 Now in addition I think that there is a value in having an object literal syntax. I pasted the old mail of igor on object literals because I like the idea since it does not add any change in the parser. Do you remember what were the problem raised by this solution (beside the fact that it had too many # and the order was like in ston not explicit). I would love to have another pass on the idea of Igor. What I don't like about it is that the object literal exposes the internal implementation of the object. Everything is based on index. So it could suffer the same problem as fuel. When you don't have the exact same code the deserialization fails. Indeed this is why { 'x' -> 10 .'y' -> 20 } asObjectOf: #Point. could be more robust. We could extend the object literal syntax to use association for non collection. I think it is more robust and more explicit. I do not know what are the semantics of detecting something as #Point being a class name. Is it then forbidden to use symbols with uppercase letters? I think something like { #x -> 10 . #y -> 20} asObjectOf: #Point is handling the format with implicit knowledge of type. While the explicit version would be { #Point -> { #x -> 10 . #y -> 20}} asObject And then nested objects are as easy as {#PointCollection -> { #points -> { {#Point -> { #x -> 10 . #y -> 20} }. {#Point -> { #x -> 5 . #y -> 8} } } } asObject The -> messages are just noise and add additional processing for nothing. This is just as effective: { #Point. { #x. 10 . #y. 20}} asObject {#PointCollection. { #points. { {#Point. { #x. 10 . #y. 20} }. {#Point. { #x. 5 . #y. 8} } } } asObject So an object is a pair of a class name and an array of slot specifier pairs, and a slot specifier is a pair of a slot band and a value. And of course that means that many object specs can be literal, which is useful for storing in pragmas etc: #(PointCollection (points ((Point (x 10 y 20)) ((Point (x 5 y 8)))) asObject Agreed. My first impression was it should be something like S-expression which your example is. I was misled by the idea it should be closer to the programming syntax. But a parser does not care if implemented properly, that's right. I like the compactness of that format but still find it a bit hard to read if there is only pairs. As this object literal syntax is meant to be written in code it is important that it reads well even if there are noisy characters. would give a PointCollection of two point objects. My future wish would be that there is an object literal parser that takes all of the information from the format. And then a object literal parser that is aware of slot information. Meaning that the type information can be gathered from the object class instead having it to write in the format. In the PointCollection the slot for points would have the type information #Point attached. The format goes then to { #points -> { { #x -> 10 . #y -> 20 }. { #x -> 5 . #y -> 8 } } which would then the equivalent to something like JSON { "points" : [ { "x" : 10, "y" : 20 }, { "x" : 5, "y" : 8 } ] } What I don't know is how to solve the difference between a dictionary and an collection of associations. That's incidental to the format, internal to the parser. If the parser chooses to build a dictionary as it parses so be it. The point is that the output is as you specify; a tree of objects. The thing to think about is how to introduce labels so that sub objects can be shared in the graph, the naÃ¯ve deepCopy vs deepCopyUsing: issue. I'm not sure this is necessary. It should be a format to easily instantiate a small tree of objects. Making it build a graph instead of a tree makes everything much more complicated. Either we decide that STON can do the full set and in that case it is probably less valuable to have a simple syntax to write in code. Or we need to break pairs rule. In that case an object definition can have an optional third argument which would be the label for the object. The draback is that the label needs to be before the array of slots { :v1 #ValueHolder { 'contents' . { ValueHolder . { 'contents' . @v1 }}}} Or something like this. It would be in theory closer to STON using the @ reference. The difference is that STON has indexed object access and that variant would make it based on labels.Or something like this. Norbert Norbert As a dictionary is both, an array of associations and a key-value store, it works perfectly there. But for other objects I have doubts. Especially is in a lot of contexts you need to have a mapping of internal state to external representation. It can be applied afterwards but I'm not sure that can work all the time. Yes after we should focus on the frequent cases. And may be having a literal syntax for dictionary would be good enough. I will do another version of igor's proposal with associations to see how it feels. my 2 cents, Norbert Stef ---------- Forwarded message ---------- From: Igor Stasenko <siguctua(a)gmail.com <mailto:siguctua@gmail.com> > Date: Fri, Oct 19, 2012 at 1:09 PM Subject: [Pharo-project] Yet another Notation format: Object literals To: Pharo Development <Pharo-project(a)lists.gforge.inria.fr <mailto:Pharo-project@lists.gforge.inria.fr> > Hi, as i promised before, here the simple smalltalk-based literal format. It based on smalltalk syntax, and so, unlike JSON, it doesn't needs to have separate parser (a normal smalltalk parser used for that). The idea is quite simple: you can tell any object to represent itself as an 'object literal' , for example: (1@3) asObjectLiteral --> #(#Point 1 3) { 1@2. 3@4. true. false . nil } asObjectLiteral -> #(#Array #(#Point 1 2) #(#Point 3 4) true false nil) (Dictionary newFromPairs: { 1->#(1 2 3) . 'foo' -> 'bar' }) asObjectLiteral -> #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') Next thing, you can 'pretty-print' it (kinda): #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') printObjectLiteral '#(#Dictionary 1 (#Array 1 2 3) ''foo'' ''bar'')' and sure thing, you can do reverse conversion: '#(#Dictionary 1 (#Array 1 2 3) ''foo'' ''bar'')' parseAsObjectLiteral a Dictionary('foo'->'bar' 1->#(1 2 3) ) Initially, i thought that it could be generic (by implementing default Object>>#asObjectLiteral), but then after discussing it with others, we decided to leave Object>>#asObjectLiteral to be a subclass responsibility. So, potentially the format allows to represent any object(s) as literals, except from circular referencing objects, of course. The implementation is fairly simple, as you may guess and contains no new classes, but just extension methods here and there. Take it with grain and salt, since it is just a small proof of concept. (And if doing it for real it may need some changes etc). Since i am far from areas right now, where it can be used, i don't want to pursue it further or advocate if this is the right way to do things. Neither i having a public repository for this project.. So, if there anyone who willing to pick it up and pursue the idea further, please feel free to do so and make a public repository for project. -- Serge Stinckwich UCN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

July 4, 2017

Re: [Pharo-dev] P6 crashed image

by David T. Lewis

Hi Hilaire, I do not know if it will help in this case, but sometimes I have recovered from similar problems by temporarily deleting a problem plugin (probably FT2Plugin.so in this case). Sometimes that will allow you to open the image and save it again. After that, you may be able to put the plugin back and run the image again. Dave On Sun, Jul 02, 2017 at 05:56:05PM +0200, Hilaire wrote: > Hi, > > I got problem with my Pharo6 image when I save it, after some Glamour > try out, don't know if it is related. > > When I saved the image, it grows to 292MB then stalled, with the mouse > writing pointer. Then Pharo display became garbage. I have to kill the > process. > > The image does not start anymore, get segmentation fault with Smalltalk > stack dump, Freetype seems to be involved: > > Segmentation fault Sun Jul 2 17:52:39 2017 > > > /home/hilaire/Travaux/Developpement/Pharo/vm/pharo64-linux-threaded-stable/lib/pharo/5.0-201705310241/pharo > Pharo VM version: 5.0-201705310241 Wed May 31 04:43:29 UTC 2017 gcc 4.6.3 [Production Spur 64-bit VM] > Built from: CoInterpreter VMMaker.oscog-eem.2231 uuid: de62947a-7f40-4977-a232-e06a3a80c939 May 31 2017 > With: StackToRegisterMappingCogit VMMaker.oscog-eem.2227 uuid: 7ea146b4-39ce-4de7-afa3-a76ed1d1da35 May 31 2017 > Revision: VM: 201705310241 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Tue May 30 19:41:27 2017 -0700 $ > Plugins: 201705310241 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ > Build host: Linux testing-gce-7baaea33-cad4-44b6-b0e5-7ad5f93c3335 3.13.0-115-generic #162~precise1-Ubuntu SMP Fri Mar 24 16:47:06 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux > plugin path: /home/hilaire/Travaux/Developpement/Pharo/vm/pharo64-linux-threaded-stable/bin/../lib/pharo/5.0-201705310241 [default: /home/hilaire/Travaux/Developpement/Pharo/vm/pharo64-linux-threaded-stable/lib/pharo/5.0-201705310241/] > > > C stack backtrace & registers: > rax 0x49063940 rbx 0x490637d0 rcx 0x490639f8 rdx 0x49063888 > rdi 0x490635a8 rsi 0x490635a8 rbp 0x49063718 rsp 0x49063ab0 > r8 0x49062fe8 r9 0x490630a0 r10 0x49063158 r11 0x49063210 > r12 0x490632c8 r13 0x49063380 r14 0x49063438 r15 0x490634f0 > rip 0x49063b68 > *[0x7fff49063b68] > /home/hilaire/Travaux/Developpement/Pharo/vm/pharo64-linux-threaded-stable/bin/../lib/pharo/5.0-201705310241/pharo[0x41cac1] > /home/hilaire/Travaux/Developpement/Pharo/vm/pharo64-linux-threaded-stable/bin/../lib/pharo/5.0-201705310241/pharo[0x41ce4f] > /lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7f4e70d53330] > /usr/lib/x86_64-linux-gnu/libfreetype.so.6(FT_Stream_ReadULong+0x78)[0x7f4e6cc9c168] > /usr/lib/x86_64-linux-gnu/libfreetype.so.6(+0x52116)[0x7f4e6ccdb116] > /usr/lib/x86_64-linux-gnu/libfreetype.so.6(+0x26742)[0x7f4e6ccaf742] > /usr/lib/x86_64-linux-gnu/libfreetype.so.6(+0x152e3)[0x7f4e6cc9e2e3] > /usr/lib/x86_64-linux-gnu/libfreetype.so.6(FT_Open_Face+0x2a0)[0x7f4e6cca0070] > /usr/lib/x86_64-linux-gnu/libfreetype.so.6(FT_New_Memory_Face+0x39)[0x7f4e6cca0669] > /home/hilaire/Travaux/Developpement/Pharo/vm/pharo64-linux-threaded-stable/bin/../lib/pharo/5.0-201705310241/FT2Plugin.so(primitiveNewMemoryFaceFromExternalMemoryAndIndex+0xea)[0x7f4e6cf309aa] > /home/hilaire/Travaux/Developpement/Pharo/vm/pharo64-linux-threaded-stable/bin/../lib/pharo/5.0-201705310241/pharo[0x4572a7] > /home/hilaire/Travaux/Developpement/Pharo/vm/pharo64-linux-threaded-stable/bin/../lib/pharo/5.0-201705310241/pharo(interpret+0xbd80)[0x467d80] > /home/hilaire/Travaux/Developpement/Pharo/vm/pharo64-linux-threaded-stable/bin/../lib/pharo/5.0-201705310241/pharo[0x468651] > /home/hilaire/Travaux/Developpement/Pharo/vm/pharo64-linux-threaded-stable/bin/../lib/pharo/5.0-201705310241/pharo(interpret+0x268)[0x45c268] > /home/hilaire/Travaux/Developpement/Pharo/vm/pharo64-linux-threaded-stable/bin/../lib/pharo/5.0-201705310241/pharo(main+0x2ab)[0x419d6b] > /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f4e70695f45] > /home/hilaire/Travaux/Developpement/Pharo/vm/pharo64-linux-threaded-stable/bin/../lib/pharo/5.0-201705310241/pharo[0x41a055] > [0x7fff49061d60] > > > Smalltalk stack dump: > 0x7fff490695d8 I FreeTypeFace(FT2Face)>newFaceFromExternalMemory:index: 0x4a83478: a(n) FreeTypeFace > 0x7fff49069628 I FreeTypeFace>create 0x4a83478: a(n) FreeTypeFace > 0x7fff49069668 I FreeTypeFace>validate 0x4a83478: a(n) FreeTypeFace > 0x7fff490696a8 I FreeTypeFont>face 0x13c41758: a(n) FreeTypeFont > 0x7fff490696e8 I FreeTypeFont>validate 0x13c41758: a(n) FreeTypeFont > 0x7fff49069728 I LogicalFont>realFont 0x3015870: a(n) LogicalFont > 0x7fff49069768 I LogicalFont>descent 0x3015870: a(n) LogicalFont > > > -- > Dr. Geo > http://drgeo.eu >

July 4, 2017

Re: [Pharo-dev] Pharo 7 provisional HOWTO

by Nicolai Hess

2017-06-28 18:25 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > > On 28 Jun 2017, at 18:21, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > And if I only want to contribute by reviewing a fix. Do I have to go the > git-path ? > Or is there a way to just start up an image and load and review the change? > > > right now, you can review by going to github and seeing. > I will add a âPR toolâ to view/load PRs into an image, but thatâs not > ready. If someone wants to take a hit on itâ¦ the idea is to extend the > github plugin with it :) > > cheers! > Esteban > Anyone got this working on windows (32) ? I followed this guide, enabled the ssh key setting for iceberg. But I still got the error : Image: Pharo7.0SNAPSHOT [Latest update: #0] LGitReturnCodeEnum>>handleLGitReturnCode Receiver: a LGitReturnCodeEnum(#git_error [-1]) Arguments and temporary variables: handler: LGit_GIT_ERROR Receiver's instance variables: value: -1 LGitRepository(LGitExternalObject)>>withReturnHandlerDo: Receiver: a LGitRepository (<not initialized>) Arguments and temporary variables: callBlock: [ self clone: self url: aString local_path: aFileReference pathSt...etc... Receiver's instance variables: handle: @ 16r00000000 repositoryPath: File @ pharo-core isOpen: nil workingDirectory: nil LGitRepository>>clone:options:to: Receiver: a LGitRepository (<not initialized>) Arguments and temporary variables: aString: 'git@github.com:pharo-project/pharo.git' cloneOptions: a LGitCloneOptions () aFileReference: File @ pharo-core Receiver's instance variables: handle: @ 16r00000000 repositoryPath: File @ pharo-core isOpen: nil workingDirectory: nil And finally after some more tries, the vm crashed (crash.dmp attached). If this only happens on windows, what else would be an option to start with contributing for pharo 7 ? > > > Am 28.06.2017 5:26 nachm. schrieb "Pavel Krivanek" < > pavel.krivanek(a)gmail.com>: > > > > 2017-06-28 17:06 GMT+02:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: > >> Hi all, >> >> Just to be clear, in Pharo 7, if I want to get some code integrated: >> - I *have to* use the pull request process described by Pavel >> OR >> - I *can* use the pull request process, but I can also use the old slice >> monticello process >> ? >> >> What is the answer to the first question now, and what will be the answer >> of this question in 6 months from now ? >> > > You should use the pull request process. > > It is possible to create a standard slice BUT it must be done from Pharo 6 > and then sent into Pharo60Inbox. And then you need to wait until somebody > converts this slice to pull request. That means that it will be harder and > harder to contribute this way because the code-base is moving. > > No slice will be integrated into Pharo 7 with the old process directly. > > Cheers, > -- Pavel > > > >> >> Thanks >> >> >> On Wed, Jun 28, 2017 at 3:42 PM, Ben Coman <btc(a)openinworld.com> wrote: >> >>> >>> >>> On Wed, Jun 28, 2017 at 3:46 PM, Juraj Kubelka <juraj.kubelka(a)icloud.com >>> > wrote: >>> >>>> >>>> El 28-06-2017, a las 02:57, Ben Coman <btc(a)openinworld.com> escribiÃ³: >>>> >>>> >>>> >>>> On Tue, Jun 27, 2017 at 10:35 PM, Pavel Krivanek < >>>> pavel.krivanek(a)gmail.com> wrote: >>>> >>>>> >>>>> >>>>> 2017-06-27 16:17 GMT+02:00 Serge Stinckwich < >>>>> serge.stinckwich(a)gmail.com>: >>>>> >>>>>> On Tue, Jun 27, 2017 at 3:10 PM, Pavel Krivanek >>>>>> <pavel.krivanek(a)gmail.com> wrote: >>>>>> > >>>>>> > >>>>>> > 2017-06-27 15:57 GMT+02:00 Serge Stinckwich < >>>>>> serge.stinckwich(a)gmail.com>: >>>>>> >> >>>>>> >> On Mon, Jun 26, 2017 at 12:14 PM, Pavel Krivanek >>>>>> >> <pavel.krivanek(a)gmail.com> wrote: >>>>>> >> > Hi, >>>>>> >> > >>>>>> >> > this mail describes how to start to send pull requests to Pharo >>>>>> 7 Github >>>>>> >> > repository from Pharo 7. >>>>>> >> >>>>>> >> Thank you for the great explanation Pavel. >>>>>> >> >>>>>> >> > Preparations >>>>>> >> > ===================== >>>>>> >> > >>>>>> >> > - you need to have a Github account and set SSH keys. See >>>>>> >> > https://help.github.com/articles/connecting-to-github-with-ssh/ >>>>>> >> > - create own pharo-project/pharo repository fork. Go to >>>>>> >> > https://github.com/pharo-project/pharo, click on "Fork" button >>>>>> and >>>>>> >> > follow >>>>>> >> > the instructions >>>>>> >> >>>>>> >> [ ... ] >>>>>> >> >>>>>> >> > Issue processing >>>>>> >> > ===================== >>>>>> >> > >>>>>> >> > - create new case on FogBugz to get the issue number >>>>>> >> > - open Iceberg and from the context menu on the 'pharo' >>>>>> repository do: >>>>>> >> > Pharo >>>>>> >> > - Create new branch from FogBugz issue, enter the issue ID and >>>>>> it will >>>>>> >> > fill >>>>>> >> > the full branch name for you >>>>>> >> > - create your changes (you can do it before the creation of the >>>>>> branch >>>>>> >> > too) >>>>>> >> > - commit and push your changes in Iceberg, this way you will >>>>>> commit your >>>>>> >> > branch to your fork repository. Remember that the Iceberg commit >>>>>> window >>>>>> >> > has >>>>>> >> > two buttons, one for local commit, the second for commit with >>>>>> immediate >>>>>> >> > push. They can be very long because they contain the full branch >>>>>> (issue) >>>>>> >> > name >>>>>> >> > - in Iceberg in the 'pharo' repository context menu do: Pharo - >>>>>> Create >>>>>> >> > pull >>>>>> >> > request, fill your >>>>>> >> > - fill your Github credentials >>>>>> >> > - leave the PR title, comment is not required, check the pull >>>>>> request >>>>>> >> > head >>>>>> >> > and base. The base MUST be pharo-project/pharo development. >>>>>> Create the >>>>>> >> > pull >>>>>> >> > requests >>>>>> >> > - go to https://github.com/pharo-project/pharo/pulls, check >>>>>> your pull >>>>>> >> > requests and put URL of it into the issue record on FogBugz (as a >>>>>> >> > comment). >>>>>> >> > Resolve the issue as Fix review needed >>>>>> >> >>>>>> >> It means, there is no PR without a corresponding FogBugz issue ? >>>>>> > >>>>>> > >>>>>> > Yes, at least for code changes we would like to keep this relation. >>>>>> If it is >>>>>> > a really trivial change in readme or something like that, we can >>>>>> accept no >>>>>> > related issue record. >>>>>> > Please prefer to comment the issues instead of PRs directly to have >>>>>> all >>>>>> > information at one place. >>>>>> >>>>>> Thank you Pavel for the explanation. >>>>>> >>>>>> Maybe in the future, it will make sense to put everything in the PR >>>>>> and use github issues. >>>>>> You will use CI travis builds for all PR ? >>>>>> >>>>> >>>>> For now we will use FogBugz because it has a lot of nice features and >>>>> good API. Maybe we will switch it in future but now we should not change >>>>> too many things at once :-) >>>>> For several reasons we now prefer to use own infrastructure for >>>>> checking of PRs (mainly because of MacOS issues on Travis). But again, it >>>>> can be changed in future. >>>>> >>>>> >>>> It would be interesting to see how this might fit in with our >>>> workflow... >>>> https://blog.fogcreek.com/fogbugz-github-integration/ >>>> >>>> >>>> >>>> What is the benefit of the integration? I do not understand it from the >>>> given link. >>>> >>>> >>> When you submit a PR on github, Fogbugz is automatically updated with a >>> link to the PR. >>> Presumably this makes it easier for people reviewing cases in Fogbugz to >>> identify the slice to test. >>> This is a better link... >>> https://blog.fogcreek.com/improved-github-integration-automa >>> tically-create-bug-events-with-commits/ >>> >>> cheers -ben >>> >> >> > > >

July 3, 2017

Re: [Pharo-dev] Reflecting on data (literal) object syntax

by Torsten Bergmann

Hi Christian, justÂ to avoid confusions: What was released with MIT license now: a) the Values code b) the pdf4smalltalk code c) or both and where can one find the latest release in case interested people want to start a port to Pharo? Thanks in advance for any clarification! Bye Torsten Gesendet:Â Montag, 03. Juli 2017 um 18:54 Uhr Von:Â "Ben Coman" <btc(a)openinworld.com> An:Â "Pharo Development List" <pharo-dev(a)lists.pharo.org> Betreff:Â Re: [Pharo-dev] Reflecting on data (literal) object syntax Thanks Christian for the open release of pdf4smalltalk.Â Sorry I aborted the two times I started to port it to Pharo.Â The task of dealing with both file format and namespace differences to synchronise with VWÂ was too big for me.Â Now with Iceberg, if VisualWorks might work with git that would knock down one barrier and I might have another go. Â On Mon, Jul 3, 2017 at 5:45 PM, Christian Haider <christian.haider@smalltalked-visuals.com[mailto:christian.haider@smalltalked-visuals.com]> wrote: I did Â Von: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org[mailto:pharo-dev-bounces@lists.pharo.org]] Im Auftrag von Serge Stinckwich Gesendet: Montag, 3. Juli 2017 11:40 An: Pharo Development List <pharo-dev@lists.pharo.org[mailto:pharo-dev@lists.pharo.org]> Betreff: Re: [Pharo-dev] Reflecting on data (literal) object syntax Â Â Hi Christian, Â interesting ! Maybe you can release your software with an MIT licence ? Â Regards, Â On Mon, Jul 3, 2017 at 10:06 AM, Christian Haider <christian.haider@smalltalked-visuals.com[mailto:christian.haider@smalltalked-visuals.com]> wrote: I solved this with Values[1] for VW and I am very happy with it (using it intensively/routinely). Your example would look like: Â (PointCollection points: (Array Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â with: (Point x: 10 y: 20) Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â with: (Point x: 5 y: 8) )) Â And I remember you saying pdf4smalltalk relied heavily on this, so having Values integrated (if it was broadly useful) would also be a minor step in porting pdf4smalltalk to Pharo.Â Â cheers -ben Â Â As you see, it is the same except that lots of noise is gone. Drawbacks: only literal objects (like Values) are allowed; i.e. no cyclic structures (same with JSON etc.) and the order of arguments is fixed unlike JSON (but you can add constructors for every permutation J). Â I think this is very clear and direct (no magic from parsers etc.). I like it most for configurations (see everything at a glance) and interface data. Â Best, Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Christian Â [1] https://wiki.pdftalk.de/doku.php?id=complexvalues[https://wiki.pdftalk.de/d… Â Von: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org[mailto:pharo-dev-bounces@lists.pharo.org]] Im Auftrag von Norbert Hartl Gesendet: Montag, 3. Juli 2017 10:28 An: Pharo Dev <pharo-dev@lists.pharo.org[mailto:pharo-dev@lists.pharo.org]> Betreff: Re: [Pharo-dev] Reflecting on data (literal) object syntax Â Eliot, Â Am 01.07.2017 um 20:22 schrieb Eliot Miranda <eliot.miranda@gmail.com[mailto:eliot.miranda@gmail.com]>: Â Hi Norbert, Â On Jul 1, 2017, at 7:36 AM, Norbert Hartl <norbert@hartl.name[mailto:norbert@hartl.name]> wrote: Â Am 30.06.2017 um 21:14 schrieb Stephane Ducasse <stepharo.self@gmail.com[mailto:stepharo.self@gmail.com]>: But what is DataFrame? the new collection done by alesnedr from Lviv. It is really nice but does not solve the problem of the compact syntax. Â STON fromString: 'Point[10,20]' Same goes for JSON. Â We were brainstorming with marcus and we could have a first nice extension: { 'x' -> 10 .'y' -> 20 } asObjectOf: #Point. 10@20 Now in addition I think that there is a value in having an object literal syntax. I pasted the old mail of igor on object literals because I like the idea since it does not add any change in the parser. Do you remember what were the problem raised by this solution (beside the fact that it had too many # and the order was like in ston not explicit). I would love to have another pass on the idea of Igor. What I don't like about it is that the object literal exposes the internal implementation of the object. Everything is based on index. So it could suffer the same problem as fuel. When you don't have the exact same code the deserialization fails. Indeed this is why { 'x' -> 10 .'y' -> 20 } asObjectOf: #Point. could be more robust. We could extend the object literal syntax to use association for non collection. I think it is more robust and more explicit. I do not know what are the semantics of detecting something as #Point being a class name. Is it then forbidden to use symbols with uppercase letters? I think something like { #x -> 10 . #y -> 20} asObjectOf: #Point is handling the format with implicit knowledge of type. While the explicit version would be { #Point -> { #x -> 10 . #y -> 20}} asObject And then nested objects are as easy as {#PointCollection -> {Â Â Â #points -> { {#Point -> { #x -> 10 . #y -> 20} }. Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â {#Point -> { #x -> 5 . #y -> 8} } } } Â asObject The -> messages are just noise and add additional processing for nothing.Â This is just as effective: { #Point. { #x. 10 . #y. 20}} asObject {#PointCollection. { Â Â #points. { {#Point. { #x. 10 . #y. 20} }. Â Â Â Â Â Â Â Â Â Â Â Â Â Â {#Point. { #x. 5 . #y. 8} } } } Â asObject So an object is a pair of a class name and an array of slot specifier pairs, and a slot specifier is a pair of a slot band and a value.Â And of course that means that many object specs can be literal, which is useful for storing in pragmas etc: Â Â Â #(PointCollection Â Â Â Â Â Â Â (points ((Point (x 10 y 20)) Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ((Point (x 5 y 8)))) Â asObject Agreed. My first impression was it should be something like S-expression which your example is. I was misled by the idea it should be closer to the programming syntax. But a parser does not care if implemented properly, that's right. I like the compactness of that format but still find it a bit hard to read if there is only pairs. As this object literal syntax is meant to be written in code it is important that it reads well even if there are noisy characters.Â would give a PointCollection of two point objects. My future wish would be that there is an object literal parser that takes all of the information from the format. And then a object literal parser that is aware of slot information. Meaning that the type information can be gathered from the object class instead having it to write in the format. In the PointCollection the slot for points would have the type information #Point attached. The format goes then to { #points -> { Â Â { #x -> 10 . #y -> 20 }. Â Â Â Â Â Â { #x -> 5 . #y -> 8 } } which would then the equivalent to something like JSON { "points" : [ Â Â Â Â { "x" : 10, "y" : 20 }, Â Â Â Â { "x" : 5, "y" : 8 } ] } What I don't know is how to solve the difference between a dictionary and an collection of associations. That's incidental to the format, internal to the parser.Â If the parser chooses to build a dictionary as it parses so be it.Â The point is that the output is as you specify; a tree of objects. The thing to think about is how to introduce labels so that sub objects can be shared in the graph, the naÃ¯ve deepCopy vs deepCopyUsing: issue. Â I'm not sure this is necessary. It should be a format to easily instantiate a small tree of objects. Making it build a graph instead of a tree makes everything much more complicated. Either we decide that STON can do the full set and in that case it is probably less valuable to have a simple syntax to write in code. Or we need to break pairs rule. In that case an object definition can have an optional third argument which would be the label for the object. The draback is that the label needs to be before the array of slots Â { :v1 #ValueHolder { 'contents' . { ValueHolder . { 'contents' . @v1 }}}}Â Â Or something like this. It would be in theory closer to STON using the @ reference. The difference is that STON has indexed object access and that variant would make it based on labels.Or something like this. Â Norbert Â Â Norbert Â As a dictionary is both, an array of associations and a key-value store, it works perfectly there. But for other objects I have doubts. Especially is in a lot of contexts you need to have a mapping of internal state to external representation. It can be applied afterwards but I'm not sure that can work all the time. Yes after we should focus on the frequent cases. And may be having a literal syntax for dictionary would be good enough. I will do another version of igor's proposal with associations to see how it feels. Â my 2 cents, Norbert Â Stef ---------- Forwarded message ---------- From: Igor Stasenko <siguctua@gmail.com[mailto:siguctua@gmail.com]> Date: Fri, Oct 19, 2012 at 1:09 PM Subject: [Pharo-project] Yet another Notation format: Object literals To: Pharo Development <Pharo-project@lists.gforge.inria.fr[mailto:Pharo-project@lists.gforge.inria.fr]> Hi, as i promised before, here the simple smalltalk-based literal format. It based on smalltalk syntax, and so, unlike JSON, it doesn't needs to have separate parser (a normal smalltalk parser used for that). The idea is quite simple: you can tell any object to represent itself as an 'object literal' , for example: (1@3) asObjectLiteral --> Â #(#Point 1 3) { 1@2. Â 3@4. true. false . nil Â } asObjectLiteral -> #(#Array #(#Point 1 2) #(#Point 3 4) true false nil) (Dictionary newFromPairs: { 1->#(1 2 3) . 'foo' -> 'bar' }) asObjectLiteral -> #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') Next thing, you can 'pretty-print' it (kinda): #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') printObjectLiteral '#(#Dictionary Â Â Â Â 1 Â Â Â Â (#Array 1 2 3) Â Â Â Â ''foo'' ''bar'')' and sure thing, you can do reverse conversion: '#(#Dictionary Â Â Â Â 1 Â Â Â Â (#Array 1 2 3) Â Â Â Â ''foo'' ''bar'')' Â parseAsObjectLiteral a Dictionary('foo'->'bar' 1->#(1 2 3) ) Initially, i thought that it could be generic (by implementing default Object>>#asObjectLiteral), but then after discussing it with others, we decided to leave Object>>#asObjectLiteral to be a subclass responsibility. So, potentially the format allows to represent any object(s) as literals, except from circular referencing objects, of course. The implementation is fairly simple, as you may guess and contains no new classes, but just extension methods here and there. Take it with grain and salt, since it is just a small proof of concept. (And if doing it for real it may need some changes etc). Since i am far from areas right now, where it can be used, i don't want to pursue it further or advocate if this is the right way to do things. Neither i having a public repository for this project.. So, if there anyone who willing to pick it up and pursue the idea further, please feel free to do so and make a public repository for project. Â Â Â -- Serge Stinckwich UCN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/[http://www.doesnotunderstand.org/]

July 3, 2017

Re: [Pharo-dev] Recommended production VM on latest macOS Sierra?

by Esteban Lorenzano

Hi, > On 3 Jul 2017, at 20:08, Bernhard Pieber <bernhard(a)pieber.com> wrote: > > Hi, > > What VM would you recommend for a production app on macOS Sierra? > - Pharo 6, right? yes > - I assume 32-bit because 64-bit is still experimental, right? not particularly, you can download it and use it. some tests fails but people is already using it (iceberg will not work, but AFAIK, is the only thing that does not works). > - The one I get with âcurl get.pharo.org | bashâ has a reproducible crash when typing (https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/141) So it canât be the recommended one, right? nevertheless is the current recommended one, and that bug is annoying us all :) but we hope to be able to fix it eventually, of course :) cheers! Esteban > > I must admit I am quite confused. > > Cheers, > Bernhard

July 3, 2017