- Pharo-dev - lists.pharo.org

Re: [Pharo-project] building the Mac Cog VM from Jenkins

by StÃ©phane Ducasse

Please igor Documentation is important. Once you are done tell me what I should read and try. > > On 2012-10-19, at 21:49, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> cmake . >> make >> is not longer valid. >> >> on mac one should use: >> cmake . >> make >> make install. >> >> or just use 'build.sh' >> script which autogenerated by image (in build directory). >> >> i added it, because i also forgetting that last step time to time >> (since the changes i did lately >> requires 'make install' step). > > so you should update the docs.... > I didn't know about that one until now... > > the clearly sucks! >

Oct. 20, 2012

Re: [Pharo-project] Yet another Notation format: Object literals

by Igor Stasenko

On 20 October 2012 03:17, Dale Henrichs <dhenrich(a)vmware.com> wrote: > > > ----- Original Message ----- > | From: "Igor Stasenko" <siguctua(a)gmail.com> > | To: Pharo-project(a)lists.gforge.inria.fr > | Sent: Friday, October 19, 2012 4:09:18 PM > | Subject: Re: [Pharo-project] Yet another Notation format: Object literals > | > | On 20 October 2012 00:26, Dale Henrichs <dhenrich(a)vmware.com> wrote: > | > Ah, > | > > | > So you are asking whether I think this: > | > > | > {1:[1,2,3],'foo':'bar',3:{1:2,3:[1,2,3]}} > | > > | > is more readable than this: > | > > | > #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar' 3 #(#Dictionary 1 2 3 > | > #(#Array 1 2 3))) > | > > | > My answer is that I find the JSON style more readable. > | > > | > With JSON, I can look a sequence from the middle of the character > | > sequence and recognize the syntactic elements: > | > > | > 'foo': bar', 3 > | > > | > as a key/value pair (foo/bar) and that 3 is probably a key ... > | > while the following sequence is not recognizable as anything: > | > > | > 'foo' 'bar' 3 > | > > | > is it 3 elements in an array? is foo, bar or 3 a key? To get it > | > right I have to count the key value pairs from the beginning of > | > the dictionary, something that only a machine can do or a human > | > presented with a small list of elements to look at. > | > > | > This readability is important when looking at larger structures > | > that may span a screen full of items in a text editor. > | > > | > The {} delimiting a dictionary allows me to recognize the following > | > sequence: > | > > | > 3]} > | > > | > as the end of an array and a dictionary whereas the following > | > sequence could mean anything in the literal Smalltalk array world: > | > > | > 3)) > | > > | > I can use a text editor to find the terminator for a dictionary or > | > an array. With a smalltalk literal array it isn't possible..again > | > the human must resort to careful counting. > | > > | > I wouldn't think that I would need to point out that the > | > #Dictionary and #Array also introduce quite a bit of visual > | > noise... and the JSON sequence is about half as long as the > | > literal array sequence and still quite readable... > | > > | > So, yes I find the JSON format more readable than Igor's suggested > | > format. > | > > | Frankly i do not see any difference between those two. > > Igor, It depends upon what you are looking for and what is important to you ... I have explained the syntax elements that make JSON more readable for me. > > Do you acknowledge that the syntax elements {}, [], :, and ,, provide additional syntactic structure that is lacking in the literal array syntax? Smalltalk is also famous for lacking curly-brace syntax {} for statement grouping and ';' as statement terminating symbol and of course missing '.' between receiver and 'member method call'. What is your point? :) Why space is worse that comma? If you can provide arguments for using commas, next thing which i will ask from you to apply same argumentation for using 'object.foo' instead of 'object foo' for message sends... and if you can argument that, then i will also ask argument writing 'object.foo()', as well, and then finally 'object.foo();' :) and then we will be very happy (assuming that i will accept your argumentation ;) Btw, one of the reasons why i hate Python is that they using white space for statement grouping. But that is slightly different: treating an arbitrary number of 'white space' characters as single white space is not the same as counting each white-space character to determine statement nesting. That's quite evil , and that's why i live with smalltalk not python. > > You may not agree that they are important, but can you at least acknowledge that they might provide useful information that is absent in the pure literal array syntax? > > If you cannot acknowledge this little bit, then I'm not sure that it is worth discussing any further... > You right, i cannot. But as i mentioned before , nothing prevents you from using punctuation to separate values (and throw them away after smalltalk parser did its job). And as you said then it is nothing better than STON: if STON syntax can be modified to be parsed using smalltalk parser (no matter what weird literal you will get as result), i think that would be just advantageous. > > | I think, if you ask an outsider who don't knows neither JS nor > | Smalltalk syntax (to have unbiased opinion), > | i bet he will not be able to easily interpret any of them. > > Of course .... and my _opinion_ is that the additional syntactic elements in JSON are very useful hints that makes it easier to interpret what you are looking at...when you know what you are looking at. > Hints only for those who know JSON :) But not for those who know smalltalk. Yesterday everyone was using XML, today its JSON.. tomorrow it will be another over-hyped format. Why we can't have own? Ah, yes we have it - STON :) > | > | Apart of that , is of course, being able to tell the class of object > | literal. > | Try to express that with JSON: > | > | #(IdentityDictionary 1 #(#OrderedCollection 1 2 3) 'foo' 'bar' 3 > | #(WeakKeyDictionary 1 2 3 #(#Set 1 2 3))) > > Sven implemented STON (which is actually the format that I prefer ... have you looked at STON?) and has inserted the class names into the format ... STON retains the [], : and {} elements to improve readability. > I looked at it briefly.. Sure thing i didn't read details. So, if you say STON can deal with that, then cool :) > | > | maybe you don't need that. But i think there's plenty of others who > | may find it very useful. > > Like I said I prefer STON because it does include class information, you should really take a look:) > Yes. As well as many other interesting stuff which happens around. > | > | I didn't wanted to turn this discussion into anti-JSON war. So sorry > | for that. > | (But you know, sometimes it is hard to stop fighting ;) > > I am shocked that a little bit of JSON on disk has created such waves ... If STON had existed at the time I started I would have used that, although I suspect the same animosity would be directed towards STON, because it is a superset of JSON... > If you want to understand why it created such waves, try to do: 'port install cairo' on your mac, which brings half of the unix distribution as dependencies including xml parser, python and god knows what else, just to build this library. While later i discovered that you can build it without having python installed neither xml parser, but just 3 other C libraries which are direct dependencies of it. This is where such way of thinking leads to, when you put extra dependencies without attempting to find a way how to stay minimalist. To me, i find it very compelling to find good arguments, why you needing JSON parser in a project which deals with smalltalk and only smalltalk and nothing else, in same way as why C library needs python in order to be built (while C compiler is sufficient for that). > | > | So, as i already demonstrated, this format, while maybe not best for > | humans having clear advantages comparing to have NOTHING at all: > | > | - you can use it for expressing literals in methods (and even easily > | extend compiler to pre-evaluate them at compile time) > > I don't put STON into literals ... in the smalltalk image, the STON is generated from the objects and written to disk where it may be read/editted by developers using a standard text editor, with emphasis on _may_. > > | - you can easily extend it to use for many different classes, > | without > | breaking anything. > > STON shares this feature... > > | - and finally, it is fairly small, and simple, because of code reuse > | (smalltalk parser) > > and we're back to where we started from 9 months ago ... GemStone does not have an accessible Smalltalk parser, and the number one requirement for this format is easy portability between dialects (7 smalltalk dialects are involved here...the JSON parser from Seaside with only 27 methods was easily ported to those dialects lacking their own JSON parser ... STON isn't quite as portable, but because of it's additional features will be worth the effort porting)... > Dale, i know that. Now, don't let me get started to enumerate numerous reasons why it is good to have parser implemented in language side (apart from being used for purposes we currently talking about). In your place, i would see it as a good opportunity for implementing new cross-dialect smalltalk parser, given that the one which we have in Pharo is not that good as we want it to be, and Pharoers (don't know how Squeakers), would be really happy seeing progress in that area, and would only welcome that. Having parser which can work across dialects is very good thing (tm), isn't? > Dale -- Best regards, Igor Stasenko.

Oct. 20, 2012

Re: [Pharo-project] Yet another Notation format: Object literals

by Igor Stasenko

On 20 October 2012 03:48, Dale Henrichs <dhenrich(a)vmware.com> wrote: > > > ----- Original Message ----- > | From: "Igor Stasenko" <siguctua(a)gmail.com> > | To: Pharo-project(a)lists.gforge.inria.fr > | Sent: Friday, October 19, 2012 4:46:47 PM > | Subject: Re: [Pharo-project] Yet another Notation format: Object literals > | > | On 20 October 2012 00:54, Dale Henrichs <dhenrich(a)vmware.com> wrote: > | > Igor, > | > > | > It's not clear that I need to be part of this discussion. > | > > | > If you want to invent a new serialization format, then go for it. > | > > | > I did chime in with my opinion that your suggested format was not > | > very readable. You happen to disagree with me. > | > > | > | Yes, i disagree. Tell me what is not readable in this: > | > | #( Dictionary > | > | yellow (Color 1 1 0) > | blue (Color 0 0 1) > | red (Color 1 0 0) > | > | ) fromObjectLiteral. > > Please read my earlier description of why I think JSON is more readable as you haven't addressed the main points with this format... yes, because i do not regarding them as significant. > | > | this is human-written object literal. It took me very little effort > | to > | express correctly the data structure i need to get out of it, with > | little chance of doing some syntax mistake. > | For smalltalker, like me, i find this expression is natural and > | straightforward to read. > > I understand that you can read this format, but I still maintain that in the end the lack of a few syntactic elements make this format ambiguous to read/write for the human...You need to full expression to make sense of it though. > > It is not the fact that the expression works evaluates correctly but the fact that the interpretation of all of the elements relies upon knowledge of the underlying implementation ... for example, I am not familiar with the Color class so: > > (Color 1 1 0) > > tells me nothing when I read it ... are those rgb values cyn or some other encoding the lack of the names causes me problems .... if the shape of the Color class changes, then this particular expression will be useless ... in the wild classes tend to change shape over time ... > But this is what conventions for (and conversions written to conform with conventions). I do not see a big problem here. Second, (and that's one of the reasons for not implementing generic Object>>asObjectLiteral), you can allow conversion only for certain set of classes, Point, Number, Collection(s) etc, i.e. the ones which has ~0 chance of changing shape/representation. Like in case of dictionary, we do not reflecting the shape of this class directly i.e. (tally and array ivars), but rather reflecting its data-structure, so internal representation is not very important there and hence ca be made highly portable across dialects. Third, if you are not familiar with Color , as long as you won't start using it in some of your project(s), i cannot see what should happen to make (Color 1 0 0) appear in the data what you dealing with in your projects. >From other side, for other person(s) it could be very important for them to be able to serialize colors. So they will be using it , but in their own project(s). Now since you never cross roads, i do not see how you can have any issues with that: it is not your data, therefore not your headache. Fourth, take CSS , for example. they having three ways defining color: #rrggbb #rgb or rgb(r,g,b) and same thing, as you may guess #75927 notation means nothing for somebody who not familiar with CSS. (he may also make a wild guess, maybe it is cyn? who knows.. ;) ) So, if you don't like (Color 1 0 0) nothing prevents you from denoting colors in more explicit way, like: (RGBColor 1 0 0) or (RGB 1 0 0) or (Color r 1 g 0 b 0 alpha 0) or whatever you see fit. In this notation use of class names is just a cheap and fast way to for denoting the stored object. With some little code, you can use arbitrary "type name" for denoting that, it is just your responsibility to recognize it and represent it with proper object at the end. But notation form don't needs to be altered, is will still stay (<data type name> <values>) and still smalltalk syntax. > | > | And do not discount the environment where people working in: it is > | smalltalk. > | So, even if i not understand what is inside, i can always select that > | piece of code and press Cmd-I > | to inspect it (or explore it) and then i will see everything very > | clear :) > > except when you sitting in a text editor or when you are in a Smalltalk dialect that doesn't have the class you are looking at or the shape of the class in that dialect is different ... in addition to my above comment: if your goal to make data dialect neutral, you making sure it is dialect neutral (no magic ;) , either by avoiding using non-compatible data structures, or represent them in a dialect-neutral way. Look what we actually doing with JSON: since in smalltalk we can't have native representation of JS object, we representing it with surrogate (either dictionary or instance of JSONObject class etc). > > | > | As well, as you can do reverse: you can craft a complex thingy, and > | then send #asObjectLiteral > | and after some prettyfying, you can make it clearly readable. (not > | mentioning that you can of course > | pretty-print it automatically). > | > | While with JSON, if you evaluate json code in JS, you will get same > | JSON as response.. > | which is cool, because of invariant, but won't make it easier to > | understand by any bit. > | > | > That's fine. > | > > | > I also mentioned that YAML is a standard format that is designed to > | > be very readable by humans while still being parsable by a > | > machine. You told me that I was missing the point. > | > > | yes, because my intent was to use smalltalk syntax (so that we > | reusing > | existing codebase, and keep uniformity, which is also important). > | > | > That's fine. > | > > | > You told me that the point is that you can encode arbitrary objects > | > in literal arrays and that this representation is optimizable by > | > the compiler. > | > > | > | right, but that's a side effect (which i discovered discussing here > | btw). I didn't had that in mind nor putting that as a requirement of > | design. Still, admit, that this side effect is quite nice :) > | > | > That's nice, but it is still not readable by humans (in my opinion) > | > and I don't want to involve the compiler ... I don't want to > | > execute code directly from the repository - I want to insert a > | > parser, so that we have control over the code that gets executed. > | > | i know. But my implementation does not evaluating any new code: it > | just parses the input and transforms it into objects. It doesn't > | installs new behavior to system. If you don't trust me, you're free > | to > | debug the code to see what it does. > | > | > | > > | > Obviously the goals that you have for this notation do not match up > | > with the requirements that I have. > | > > | > | my goal is just one: use smalltalk syntax to express data. > | If you take smalltalker who knows smalltalk and nothing else, i think > | he will learn to read that notation much faster comparing to learning > | JSON/STON/YAML first. > | Because it is already smalltalk and needs just a slight shift in POV > | to see through braces. > | That's the main point. > > Regarding this goal...you realize that you are entering the territory where you have a solution (using smalltalk syntax to express data) and are looking for a problem to solve. > > The problem I had (9 months ago, which was solved by using JSON/STON) is still not solved by your solution... you don't fail in terms of functionality, but in the simple fact that I value the extra syntax that STON/JSON provides that differentiates between arrays and dictionaries ... > > You create a literal dictionary/object syntax for Smalltalk and you might have a convert. > In that case, i think , better would be to stay with STON then. Dictionaries is quite complex data structure, comparing to lists (arrays) and basic values (numbers, strings and symbols). How many other languages, apart from JS, has syntax to denote dictionary-like structures? I do not see a need in having separate syntax for dictionary. Because this goes to nowhere in form of never-ending story: - tomorrow i want syntactic sugar for Sets - then for Colors - then for Points, Rectangles and Circles ... - and Pink Elephants one of the reasons, why i like smalltalk syntax, is small grammar, minimal syntactic constructs, yet high expressive power. Smalltalk (and LISP) is a good demonstration that massive set of different syntax sugars/rules and expressive power are not correlating values. If you think otherwise, i think you better start using Perl instead, where you can find sugars everywhere and will find that you can write same expression using infinite number of ways, up to the point that it is no longer possible to understand the code which you didn't wrote yourself. > | > | > That's fine. > | > > | > I am not in dire need of "yet another Notation format". STON > | > adequately fills the bill for what I need at the moment. > | > > | > I have responded to Eliot with more detail about why I consider > | > JSON to be more readable than your original suggestion. I haven't > | > commented on the readability of your other suggestions because I > | > am assuming that you don't have code written to actually parse the > | > different variations that you proposed. > | > > | > Sooo, it's not clear that I can contribute much more. > | > > | > | Dale i value your contribution. You know we can criticize and fight > | to death. > | But when i demonstrated that you can use > | #( Dictionary a -> b) > | instead of > | #( Dictionary a b) > | notation, i actually wanted your input from different perspective: > | if we going to introduce a smalltalk-based notation (one that using > | smalltalk syntax), > | is proposed variant good enough, or there can be alternative(s), > | which > | may be better than proposed. > | As i said, i didn't wanted to contrast it with JSON, and derail the > | whole thing into fight between camps > | with zero value for community. > > Igor, you are asking form my _opinion_ and I' giving you my _opinion_, and I will repeat it again, I think there needs to be a syntactic difference between dictionary and array ... only to make it possible for the poor human to make sense of things.... the lack of the syntactic demarcation is the weakness here. > > I really think that your current variant is way to dependent upon magical ordering...multiple platforms do not represent common classes the same way and positional parameters don't allow for shape changes over time ... way to rigid and structured... I think this don't needs additional comment(s) from me, since i answered to them above. > > Dale > -- Best regards, Igor Stasenko.

Oct. 20, 2012

Re: [Pharo-project] Yet another Notation format: Object literals

by Dale Henrichs

----- Original Message ----- | From: "Igor Stasenko" <siguctua(a)gmail.com> | To: Pharo-project(a)lists.gforge.inria.fr | Sent: Friday, October 19, 2012 4:46:47 PM | Subject: Re: [Pharo-project] Yet another Notation format: Object literals | | On 20 October 2012 00:54, Dale Henrichs <dhenrich(a)vmware.com> wrote: | > Igor, | > | > It's not clear that I need to be part of this discussion. | > | > If you want to invent a new serialization format, then go for it. | > | > I did chime in with my opinion that your suggested format was not | > very readable. You happen to disagree with me. | > | | Yes, i disagree. Tell me what is not readable in this: | | #( Dictionary | | yellow (Color 1 1 0) | blue (Color 0 0 1) | red (Color 1 0 0) | | ) fromObjectLiteral. Please read my earlier description of why I think JSON is more readable as you haven't addressed the main points with this format... | | this is human-written object literal. It took me very little effort | to | express correctly the data structure i need to get out of it, with | little chance of doing some syntax mistake. | For smalltalker, like me, i find this expression is natural and | straightforward to read. I understand that you can read this format, but I still maintain that in the end the lack of a few syntactic elements make this format ambiguous to read/write for the human...You need to full expression to make sense of it though. It is not the fact that the expression works evaluates correctly but the fact that the interpretation of all of the elements relies upon knowledge of the underlying implementation ... for example, I am not familiar with the Color class so: (Color 1 1 0) tells me nothing when I read it ... are those rgb values cyn or some other encoding the lack of the names causes me problems .... if the shape of the Color class changes, then this particular expression will be useless ... in the wild classes tend to change shape over time ... | | And do not discount the environment where people working in: it is | smalltalk. | So, even if i not understand what is inside, i can always select that | piece of code and press Cmd-I | to inspect it (or explore it) and then i will see everything very | clear :) except when you sitting in a text editor or when you are in a Smalltalk dialect that doesn't have the class you are looking at or the shape of the class in that dialect is different ... | | As well, as you can do reverse: you can craft a complex thingy, and | then send #asObjectLiteral | and after some prettyfying, you can make it clearly readable. (not | mentioning that you can of course | pretty-print it automatically). | | While with JSON, if you evaluate json code in JS, you will get same | JSON as response.. | which is cool, because of invariant, but won't make it easier to | understand by any bit. | | > That's fine. | > | > I also mentioned that YAML is a standard format that is designed to | > be very readable by humans while still being parsable by a | > machine. You told me that I was missing the point. | > | yes, because my intent was to use smalltalk syntax (so that we | reusing | existing codebase, and keep uniformity, which is also important). | | > That's fine. | > | > You told me that the point is that you can encode arbitrary objects | > in literal arrays and that this representation is optimizable by | > the compiler. | > | | right, but that's a side effect (which i discovered discussing here | btw). I didn't had that in mind nor putting that as a requirement of | design. Still, admit, that this side effect is quite nice :) | | > That's nice, but it is still not readable by humans (in my opinion) | > and I don't want to involve the compiler ... I don't want to | > execute code directly from the repository - I want to insert a | > parser, so that we have control over the code that gets executed. | | i know. But my implementation does not evaluating any new code: it | just parses the input and transforms it into objects. It doesn't | installs new behavior to system. If you don't trust me, you're free | to | debug the code to see what it does. | | | > | > Obviously the goals that you have for this notation do not match up | > with the requirements that I have. | > | | my goal is just one: use smalltalk syntax to express data. | If you take smalltalker who knows smalltalk and nothing else, i think | he will learn to read that notation much faster comparing to learning | JSON/STON/YAML first. | Because it is already smalltalk and needs just a slight shift in POV | to see through braces. | That's the main point. Regarding this goal...you realize that you are entering the territory where you have a solution (using smalltalk syntax to express data) and are looking for a problem to solve. The problem I had (9 months ago, which was solved by using JSON/STON) is still not solved by your solution... you don't fail in terms of functionality, but in the simple fact that I value the extra syntax that STON/JSON provides that differentiates between arrays and dictionaries ... You create a literal dictionary/object syntax for Smalltalk and you might have a convert. | | > That's fine. | > | > I am not in dire need of "yet another Notation format". STON | > adequately fills the bill for what I need at the moment. | > | > I have responded to Eliot with more detail about why I consider | > JSON to be more readable than your original suggestion. I haven't | > commented on the readability of your other suggestions because I | > am assuming that you don't have code written to actually parse the | > different variations that you proposed. | > | > Sooo, it's not clear that I can contribute much more. | > | | Dale i value your contribution. You know we can criticize and fight | to death. | But when i demonstrated that you can use | #( Dictionary a -> b) | instead of | #( Dictionary a b) | notation, i actually wanted your input from different perspective: | if we going to introduce a smalltalk-based notation (one that using | smalltalk syntax), | is proposed variant good enough, or there can be alternative(s), | which | may be better than proposed. | As i said, i didn't wanted to contrast it with JSON, and derail the | whole thing into fight between camps | with zero value for community. Igor, you are asking form my _opinion_ and I' giving you my _opinion_, and I will repeat it again, I think there needs to be a syntactic difference between dictionary and array ... only to make it possible for the poor human to make sense of things.... the lack of the syntactic demarcation is the weakness here. I really think that your current variant is way to dependent upon magical ordering...multiple platforms do not represent common classes the same way and positional parameters don't allow for shape changes over time ... way to rigid and structured... Dale

Oct. 20, 2012

Re: [Pharo-project] Yet another Notation format: Object literals

by Dale Henrichs

----- Original Message ----- | From: "Igor Stasenko" <siguctua(a)gmail.com> | To: Pharo-project(a)lists.gforge.inria.fr | Sent: Friday, October 19, 2012 4:09:18 PM | Subject: Re: [Pharo-project] Yet another Notation format: Object literals | | On 20 October 2012 00:26, Dale Henrichs <dhenrich(a)vmware.com> wrote: | > Ah, | > | > So you are asking whether I think this: | > | > {1:[1,2,3],'foo':'bar',3:{1:2,3:[1,2,3]}} | > | > is more readable than this: | > | > #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar' 3 #(#Dictionary 1 2 3 | > #(#Array 1 2 3))) | > | > My answer is that I find the JSON style more readable. | > | > With JSON, I can look a sequence from the middle of the character | > sequence and recognize the syntactic elements: | > | > 'foo': bar', 3 | > | > as a key/value pair (foo/bar) and that 3 is probably a key ... | > while the following sequence is not recognizable as anything: | > | > 'foo' 'bar' 3 | > | > is it 3 elements in an array? is foo, bar or 3 a key? To get it | > right I have to count the key value pairs from the beginning of | > the dictionary, something that only a machine can do or a human | > presented with a small list of elements to look at. | > | > This readability is important when looking at larger structures | > that may span a screen full of items in a text editor. | > | > The {} delimiting a dictionary allows me to recognize the following | > sequence: | > | > 3]} | > | > as the end of an array and a dictionary whereas the following | > sequence could mean anything in the literal Smalltalk array world: | > | > 3)) | > | > I can use a text editor to find the terminator for a dictionary or | > an array. With a smalltalk literal array it isn't possible..again | > the human must resort to careful counting. | > | > I wouldn't think that I would need to point out that the | > #Dictionary and #Array also introduce quite a bit of visual | > noise... and the JSON sequence is about half as long as the | > literal array sequence and still quite readable... | > | > So, yes I find the JSON format more readable than Igor's suggested | > format. | > | Frankly i do not see any difference between those two. Igor, It depends upon what you are looking for and what is important to you ... I have explained the syntax elements that make JSON more readable for me. Do you acknowledge that the syntax elements {}, [], :, and ,, provide additional syntactic structure that is lacking in the literal array syntax? You may not agree that they are important, but can you at least acknowledge that they might provide useful information that is absent in the pure literal array syntax? If you cannot acknowledge this little bit, then I'm not sure that it is worth discussing any further... | I think, if you ask an outsider who don't knows neither JS nor | Smalltalk syntax (to have unbiased opinion), | i bet he will not be able to easily interpret any of them. Of course .... and my _opinion_ is that the additional syntactic elements in JSON are very useful hints that makes it easier to interpret what you are looking at...when you know what you are looking at. | | Apart of that , is of course, being able to tell the class of object | literal. | Try to express that with JSON: | | #(IdentityDictionary 1 #(#OrderedCollection 1 2 3) 'foo' 'bar' 3 | #(WeakKeyDictionary 1 2 3 #(#Set 1 2 3))) Sven implemented STON (which is actually the format that I prefer ... have you looked at STON?) and has inserted the class names into the format ... STON retains the [], : and {} elements to improve readability. | | maybe you don't need that. But i think there's plenty of others who | may find it very useful. Like I said I prefer STON because it does include class information, you should really take a look:) | | I didn't wanted to turn this discussion into anti-JSON war. So sorry | for that. | (But you know, sometimes it is hard to stop fighting ;) I am shocked that a little bit of JSON on disk has created such waves ... If STON had existed at the time I started I would have used that, although I suspect the same animosity would be directed towards STON, because it is a superset of JSON... | | So, as i already demonstrated, this format, while maybe not best for | humans having clear advantages comparing to have NOTHING at all: | | - you can use it for expressing literals in methods (and even easily | extend compiler to pre-evaluate them at compile time) I don't put STON into literals ... in the smalltalk image, the STON is generated from the objects and written to disk where it may be read/editted by developers using a standard text editor, with emphasis on _may_. | - you can easily extend it to use for many different classes, | without | breaking anything. STON shares this feature... | - and finally, it is fairly small, and simple, because of code reuse | (smalltalk parser) and we're back to where we started from 9 months ago ... GemStone does not have an accessible Smalltalk parser, and the number one requirement for this format is easy portability between dialects (7 smalltalk dialects are involved here...the JSON parser from Seaside with only 27 methods was easily ported to those dialects lacking their own JSON parser ... STON isn't quite as portable, but because of it's additional features will be worth the effort porting)... Dale

Oct. 20, 2012

Re: [Pharo-project] building the Mac Cog VM from Jenkins

by Igor Stasenko

On 20 October 2012 00:35, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > On 2012-10-19, at 21:49, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> cmake . >> make >> is not longer valid. >> >> on mac one should use: >> cmake . >> make >> make install. >> >> or just use 'build.sh' >> script which autogenerated by image (in build directory). >> >> i added it, because i also forgetting that last step time to time >> (since the changes i did lately >> requires 'make install' step). > > so you should update the docs.... > I didn't know about that one until now... > I mentioned it here: http://dailyvmotion.wordpress.com/2012/09/18/new-vms-with-nativeboost-callb… > the clearly sucks! > -- Best regards, Igor Stasenko.

Oct. 19, 2012

Re: [Pharo-project] Yet another Notation format: Object literals

by Igor Stasenko

On 20 October 2012 00:54, Dale Henrichs <dhenrich(a)vmware.com> wrote: > Igor, > > It's not clear that I need to be part of this discussion. > > If you want to invent a new serialization format, then go for it. > > I did chime in with my opinion that your suggested format was not very readable. You happen to disagree with me. > Yes, i disagree. Tell me what is not readable in this: #( Dictionary yellow (Color 1 1 0) blue (Color 0 0 1) red (Color 1 0 0) ) fromObjectLiteral. this is human-written object literal. It took me very little effort to express correctly the data structure i need to get out of it, with little chance of doing some syntax mistake. For smalltalker, like me, i find this expression is natural and straightforward to read. And do not discount the environment where people working in: it is smalltalk. So, even if i not understand what is inside, i can always select that piece of code and press Cmd-I to inspect it (or explore it) and then i will see everything very clear :) As well, as you can do reverse: you can craft a complex thingy, and then send #asObjectLiteral and after some prettyfying, you can make it clearly readable. (not mentioning that you can of course pretty-print it automatically). While with JSON, if you evaluate json code in JS, you will get same JSON as response.. which is cool, because of invariant, but won't make it easier to understand by any bit. > That's fine. > > I also mentioned that YAML is a standard format that is designed to be very readable by humans while still being parsable by a machine. You told me that I was missing the point. > yes, because my intent was to use smalltalk syntax (so that we reusing existing codebase, and keep uniformity, which is also important). > That's fine. > > You told me that the point is that you can encode arbitrary objects in literal arrays and that this representation is optimizable by the compiler. > right, but that's a side effect (which i discovered discussing here btw). I didn't had that in mind nor putting that as a requirement of design. Still, admit, that this side effect is quite nice :) > That's nice, but it is still not readable by humans (in my opinion) and I don't want to involve the compiler ... I don't want to execute code directly from the repository - I want to insert a parser, so that we have control over the code that gets executed. i know. But my implementation does not evaluating any new code: it just parses the input and transforms it into objects. It doesn't installs new behavior to system. If you don't trust me, you're free to debug the code to see what it does. > > Obviously the goals that you have for this notation do not match up with the requirements that I have. > my goal is just one: use smalltalk syntax to express data. If you take smalltalker who knows smalltalk and nothing else, i think he will learn to read that notation much faster comparing to learning JSON/STON/YAML first. Because it is already smalltalk and needs just a slight shift in POV to see through braces. That's the main point. > That's fine. > > I am not in dire need of "yet another Notation format". STON adequately fills the bill for what I need at the moment. > > I have responded to Eliot with more detail about why I consider JSON to be more readable than your original suggestion. I haven't commented on the readability of your other suggestions because I am assuming that you don't have code written to actually parse the different variations that you proposed. > > Sooo, it's not clear that I can contribute much more. > Dale i value your contribution. You know we can criticize and fight to death. But when i demonstrated that you can use #( Dictionary a -> b) instead of #( Dictionary a b) notation, i actually wanted your input from different perspective: if we going to introduce a smalltalk-based notation (one that using smalltalk syntax), is proposed variant good enough, or there can be alternative(s), which may be better than proposed. As i said, i didn't wanted to contrast it with JSON, and derail the whole thing into fight between camps with zero value for community. > Dale > -- Best regards, Igor Stasenko.

Oct. 19, 2012

Re: [Pharo-project] Yet another Notation format: Object literals

by Igor Stasenko

On 20 October 2012 00:26, Dale Henrichs <dhenrich(a)vmware.com> wrote: > Ah, > > So you are asking whether I think this: > > {1:[1,2,3],'foo':'bar',3:{1:2,3:[1,2,3]}} > > is more readable than this: > > #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar' 3 #(#Dictionary 1 2 3 #(#Array 1 2 3))) > > My answer is that I find the JSON style more readable. > > With JSON, I can look a sequence from the middle of the character sequence and recognize the syntactic elements: > > 'foo': bar', 3 > > as a key/value pair (foo/bar) and that 3 is probably a key ... while the following sequence is not recognizable as anything: > > 'foo' 'bar' 3 > > is it 3 elements in an array? is foo, bar or 3 a key? To get it right I have to count the key value pairs from the beginning of the dictionary, something that only a machine can do or a human presented with a small list of elements to look at. > > This readability is important when looking at larger structures that may span a screen full of items in a text editor. > > The {} delimiting a dictionary allows me to recognize the following sequence: > > 3]} > > as the end of an array and a dictionary whereas the following sequence could mean anything in the literal Smalltalk array world: > > 3)) > > I can use a text editor to find the terminator for a dictionary or an array. With a smalltalk literal array it isn't possible..again the human must resort to careful counting. > > I wouldn't think that I would need to point out that the #Dictionary and #Array also introduce quite a bit of visual noise... and the JSON sequence is about half as long as the literal array sequence and still quite readable... > > So, yes I find the JSON format more readable than Igor's suggested format. > Frankly i do not see any difference between those two. I think, if you ask an outsider who don't knows neither JS nor Smalltalk syntax (to have unbiased opinion), i bet he will not be able to easily interpret any of them. Apart of that , is of course, being able to tell the class of object literal. Try to express that with JSON: #(IdentityDictionary 1 #(#OrderedCollection 1 2 3) 'foo' 'bar' 3 #(WeakKeyDictionary 1 2 3 #(#Set 1 2 3))) maybe you don't need that. But i think there's plenty of others who may find it very useful. I didn't wanted to turn this discussion into anti-JSON war. So sorry for that. (But you know, sometimes it is hard to stop fighting ;) So, as i already demonstrated, this format, while maybe not best for humans having clear advantages comparing to have NOTHING at all: - you can use it for expressing literals in methods (and even easily extend compiler to pre-evaluate them at compile time) - you can easily extend it to use for many different classes, without breaking anything. - and finally, it is fairly small, and simple, because of code reuse (smalltalk parser) > Dale -- Best regards, Igor Stasenko.

Oct. 19, 2012

Re: [Pharo-project] Yet another Notation format: Object literals

by Dale Henrichs

Igor, It's not clear that I need to be part of this discussion. If you want to invent a new serialization format, then go for it. I did chime in with my opinion that your suggested format was not very readable. You happen to disagree with me. That's fine. I also mentioned that YAML is a standard format that is designed to be very readable by humans while still being parsable by a machine. You told me that I was missing the point. That's fine. You told me that the point is that you can encode arbitrary objects in literal arrays and that this representation is optimizable by the compiler. That's nice, but it is still not readable by humans (in my opinion) and I don't want to involve the compiler ... I don't want to execute code directly from the repository - I want to insert a parser, so that we have control over the code that gets executed. Obviously the goals that you have for this notation do not match up with the requirements that I have. That's fine. I am not in dire need of "yet another Notation format". STON adequately fills the bill for what I need at the moment. I have responded to Eliot with more detail about why I consider JSON to be more readable than your original suggestion. I haven't commented on the readability of your other suggestions because I am assuming that you don't have code written to actually parse the different variations that you proposed. Sooo, it's not clear that I can contribute much more. Dale ----- Original Message ----- | From: "Igor Stasenko" <siguctua(a)gmail.com> | To: Pharo-project(a)lists.gforge.inria.fr | Sent: Friday, October 19, 2012 2:11:37 PM | Subject: Re: [Pharo-project] Yet another Notation format: Object literals | | On 19 October 2012 22:15, Dale Henrichs <dhenrich(a)vmware.com> wrote: | > Igor, | > | > I think we can agree that readability is subjective, beyond that | > I'm afraid that we aren't going to see eye to eye. | > | > Put us in the same room with a whiteboard and we might be able to | > understand each other's perspective if not come to see eye to eye. | > | > Separated by thousands of miles...the best we can hope for is to | > agree to disagree. | > | | For me it is important for discussion to have decision point, a way | to go. | If discussion ends with just "we disagree" this is useless discussion | then, and we just losing time here. | | One of the decisions, we got is that Sven will take an effort | implementing that. | So, we have a practical outcome. Which is best one i ever expected. | :) | This is matters. And whether we agree or disagree it doesn't :) | | We can disagree on zillions of things (and this is good btw), but | when | people joining forces to develop something together, | they should come to some agreement otherwise they will be unable to | even start doing anything :) | | > Dale | | | -- | Best regards, | Igor Stasenko. | |

Oct. 19, 2012

Re: [Pharo-project] building the Mac Cog VM from Jenkins

by Camillo Bruni

On 2012-10-19, at 21:49, Igor Stasenko <siguctua(a)gmail.com> wrote: > cmake . > make > is not longer valid. > > on mac one should use: > cmake . > make > make install. > > or just use 'build.sh' > script which autogenerated by image (in build directory). > > i added it, because i also forgetting that last step time to time > (since the changes i did lately > requires 'make install' step). so you should update the docs.... I didn't know about that one until now... the clearly sucks!

Oct. 19, 2012