October 2012 - Pharo-dev - lists.pharo.org

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

by Eliot Miranda

On Fri, Oct 19, 2012 at 2:42 PM, Dale Henrichs <dhenrich(a)vmware.com> wrote: > Eliot, > > STON (and JSON IIRC) allows either $" or $' as string literal delimiters, > so I am not holding onto the $" as a key readability component. > > For me: > > { 'category' : 'Topez-Client-Core'} > > is perfectly readable and could be accomplished with the JSON > reader/writer.... > agreed, but you're not answering my question. Is Igor's any the less readable? > > Dale > ----- Original Message ----- > | From: "Eliot Miranda" <eliot.miranda(a)gmail.com> > | To: Pharo-project(a)lists.gforge.inria.fr > | Sent: Friday, October 19, 2012 2:07:28 PM > | Subject: Re: [Pharo-project] Yet another Notation format: Object literals > | > | HI Dale, Hi Igor, > | > | > | On Fri, Oct 19, 2012 at 9:33 AM, Dale Henrichs < dhenrich(a)vmware.com > | > wrote: > | > | > | Igor, > | > | "you can do anything you like" ... you mean like choosing to use STON > | and not invent my own notation format? > | > | STON is a perfectly good notation format for Smalltalk... > | > | Methinks that with your recent suggestions are no longer using > | literal Smalltalk syntax which is fine, if we are not restricted to > | literal Smalltalk syntax, then the following should be a valid > | format: > | > | { > | "category" : "Topez-Client-Core", > | "classinstvars" : [ > | ], > | "classvars" : [ > | ], > | "commentStamp" : "", > | "instvars" : [ > | "project", > | "package", > | "currentClass", > | "classOrInstance", > | "category", > | "selector", > | "history", > | "currentWindowId", > | "windows", > | "namedWindows" ], > | "name" : "TZTopezStatus", > | "pools" : [ > | ], > | "super" : "Object", > | "type" : "normal" } > | > | which brings us back to were we started. > | > | > | > | Sorry to come late to the party and sorry to point out the obvious > | but the above is fine in Igor's scheme if one gives up double quotes > | (since these are comment characters). So the above, with single > | quotes replacing the double quotes, and #(...) replacing {...} is a > | valid Smalltalk literal. Is the latter any the less readable? I > | don't think so. Do you, Dale? (and sorry if the conversation has > | already moved on). > | > | > | > | > | Smalltalk does not have a literal syntax for dictionaries. While > | fabricating dictionaries from literal arrays is possible, the > | results are not very readable ... unless you start taking liberties > | with Smalltalk syntax... > | > | If you are no longer restricting yourself to Smalltalk syntax, then > | what's wrong with the STON notation above? > | > | > | Dale > | > | ----- Original Message ----- > | | From: "Igor Stasenko" < siguctua(a)gmail.com > > | > | > | | To: Pharo-project(a)lists.gforge.inria.fr > | | Sent: Friday, October 19, 2012 9:10:26 AM > | | Subject: Re: [Pharo-project] Yet another Notation format: Object > | | literals > | | > | | On 19 October 2012 16:55, Dale Henrichs < dhenrich(a)vmware.com > > | | wrote: > | | > Igor, > | | > > | | > I'm afraid that your notation is not very friendly to humans ... > | | > a > | | > computer can keep track of the key value pairs in the literal > | | > dictionary, but a human will fail very quickly... > | | > > | | > The appeal of JSON (and STON) is that the output is readable by > | | > mere mortals: > | | > > | | > (JavaScript Object Notation) is a lightweight > | | > data-interchange format. It is easy for humans to > | | > read and write. > | | > > | | > What we're missing from Smalltalk is a literal dictionary or > | | > literal map syntax ... without that I'm afraid that for human > | | > friendly, lightweight notations we have to step away from the > | | > Smalltalk syntax - STON does this very nicely BTW... > | | > | | no problem, Dale. > | | What symbol you want to have to separate keys from values? > | | is '->' ok? > | | > | | Dictionary>>asObjectLiteral > | | > | | "convert a receiver into an object literal " > | | > | | ^ Array streamContents: [:stream | > | | stream nextPut: self class name. > | | self keysAndValuesDo: [:key :value | > | | stream > | | nextPut: key asObjectLiteral; > | | nextPut: #->; > | | nextPut: value asObjectLiteral ] ] > | | > | | (Dictionary newFromPairs: #( a b c d)) asObjectLiteral > | | > | | #(#Dictionary > | | #a #'->' #b > | | #c #'->' #d) > | | > | | which if you pretty-print will look like: > | | > | | #( > | | Dictionary > | | a -> b > | | c -> d > | | ) > | | > | | is it better? > | | or you prefer this one: > | | > | | #( > | | Dictionary > | | (a -> b) > | | (c -> d) > | | ) > | | > | | you can do anything you like, by implementing the conversion > | | methods > | | in a way you like :) > | | > | | > > | | > Dale > | | > > | | > ----- Original Message ----- > | | > | From: "Igor Stasenko" < siguctua(a)gmail.com > > | | > | To: "Pharo Development" < Pharo-project(a)lists.gforge.inria.fr > > | | > | Sent: Friday, October 19, 2012 4:09:22 AM > | | > | Subject: [Pharo-project] Yet another Notation format: Object > | | > | literals > | | > | > | | > | 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. > | | > | > | | > | > | | > | -- > | | > | Best regards, > | | > | Igor Stasenko. > | | > | > | | > > | | > | | > | | > | | -- > | | Best regards, > | | Igor Stasenko. > | | > | | > | > | > | > | > | > | -- > | best, > | Eliot > | > > -- best, Eliot

Oct. 19, 2012

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

by Dale Henrichs

Eliot, STON (and JSON IIRC) allows either $" or $' as string literal delimiters, so I am not holding onto the $" as a key readability component. For me: { 'category' : 'Topez-Client-Core'} is perfectly readable and could be accomplished with the JSON reader/writer.... Dale ----- Original Message ----- | From: "Eliot Miranda" <eliot.miranda(a)gmail.com> | To: Pharo-project(a)lists.gforge.inria.fr | Sent: Friday, October 19, 2012 2:07:28 PM | Subject: Re: [Pharo-project] Yet another Notation format: Object literals | | HI Dale, Hi Igor, | | | On Fri, Oct 19, 2012 at 9:33 AM, Dale Henrichs < dhenrich(a)vmware.com | > wrote: | | | Igor, | | "you can do anything you like" ... you mean like choosing to use STON | and not invent my own notation format? | | STON is a perfectly good notation format for Smalltalk... | | Methinks that with your recent suggestions are no longer using | literal Smalltalk syntax which is fine, if we are not restricted to | literal Smalltalk syntax, then the following should be a valid | format: | | { | "category" : "Topez-Client-Core", | "classinstvars" : [ | ], | "classvars" : [ | ], | "commentStamp" : "", | "instvars" : [ | "project", | "package", | "currentClass", | "classOrInstance", | "category", | "selector", | "history", | "currentWindowId", | "windows", | "namedWindows" ], | "name" : "TZTopezStatus", | "pools" : [ | ], | "super" : "Object", | "type" : "normal" } | | which brings us back to were we started. | | | | Sorry to come late to the party and sorry to point out the obvious | but the above is fine in Igor's scheme if one gives up double quotes | (since these are comment characters). So the above, with single | quotes replacing the double quotes, and #(...) replacing {...} is a | valid Smalltalk literal. Is the latter any the less readable? I | don't think so. Do you, Dale? (and sorry if the conversation has | already moved on). | | | | | Smalltalk does not have a literal syntax for dictionaries. While | fabricating dictionaries from literal arrays is possible, the | results are not very readable ... unless you start taking liberties | with Smalltalk syntax... | | If you are no longer restricting yourself to Smalltalk syntax, then | what's wrong with the STON notation above? | | | Dale | | ----- Original Message ----- | | From: "Igor Stasenko" < siguctua(a)gmail.com > | | | | To: Pharo-project(a)lists.gforge.inria.fr | | Sent: Friday, October 19, 2012 9:10:26 AM | | Subject: Re: [Pharo-project] Yet another Notation format: Object | | literals | | | | On 19 October 2012 16:55, Dale Henrichs < dhenrich(a)vmware.com > | | wrote: | | > Igor, | | > | | > I'm afraid that your notation is not very friendly to humans ... | | > a | | > computer can keep track of the key value pairs in the literal | | > dictionary, but a human will fail very quickly... | | > | | > The appeal of JSON (and STON) is that the output is readable by | | > mere mortals: | | > | | > (JavaScript Object Notation) is a lightweight | | > data-interchange format. It is easy for humans to | | > read and write. | | > | | > What we're missing from Smalltalk is a literal dictionary or | | > literal map syntax ... without that I'm afraid that for human | | > friendly, lightweight notations we have to step away from the | | > Smalltalk syntax - STON does this very nicely BTW... | | | | no problem, Dale. | | What symbol you want to have to separate keys from values? | | is '->' ok? | | | | Dictionary>>asObjectLiteral | | | | "convert a receiver into an object literal " | | | | ^ Array streamContents: [:stream | | | stream nextPut: self class name. | | self keysAndValuesDo: [:key :value | | | stream | | nextPut: key asObjectLiteral; | | nextPut: #->; | | nextPut: value asObjectLiteral ] ] | | | | (Dictionary newFromPairs: #( a b c d)) asObjectLiteral | | | | #(#Dictionary | | #a #'->' #b | | #c #'->' #d) | | | | which if you pretty-print will look like: | | | | #( | | Dictionary | | a -> b | | c -> d | | ) | | | | is it better? | | or you prefer this one: | | | | #( | | Dictionary | | (a -> b) | | (c -> d) | | ) | | | | you can do anything you like, by implementing the conversion | | methods | | in a way you like :) | | | | > | | > Dale | | > | | > ----- Original Message ----- | | > | From: "Igor Stasenko" < siguctua(a)gmail.com > | | > | To: "Pharo Development" < Pharo-project(a)lists.gforge.inria.fr > | | > | Sent: Friday, October 19, 2012 4:09:22 AM | | > | Subject: [Pharo-project] Yet another Notation format: Object | | > | literals | | > | | | > | 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. | | > | | | > | | | > | -- | | > | Best regards, | | > | Igor Stasenko. | | > | | | > | | | | | | | | -- | | Best regards, | | Igor Stasenko. | | | | | | | | | | -- | best, | Eliot |

Oct. 19, 2012

Re: [Pharo-project] building the VM

by Igor Stasenko

On 19 October 2012 22:25, Craig Latta <craig(a)netjam.org> wrote: > > Hi Igor-- > >> [Igor refers to my first attempt with the gitorious approach.] >> >> Craig, that probably a sign that you using wrong version of >> CMakeVMMaker package not one which is used for the sources committed >> in git. > > Oh, okay, that's disturbing since I was going from the Metacello > configuration Mariano suggested. > >> For that there is codegen-scripts/LoadVMMaker.st script which >> loads exact version of all packages used to build VM. >> We usually don't commit code without changing LoadVMMaker.st, and >> making sure it builds VM with that version. > > Aha, okay. > >> for developers, best is , of course >> do >> git clone >> instead of >> git clone --depth=0 >> >> for non-developers, just download tarball from jenkins , >> change the paths in build/directories.cmake to your local ones >> and just build. (and you don't need an image in that case) >> >> (btw, i wonder, why we need that feature (to use arbitrary paths for >> sources/platform/build directories), >> if nobody using it.. which prevents us from having relative paths in >> directories.cmake file, >> like that people can build downloaded sources without any changes). > > Yeah, I would think a main feature of having a buildable snapshot > is that people can just grab it and build it without having to configure > anything. > That was the idea, but you see, some features (no matter how useful they are alone), sometimes can conflict with each other, like in this case.. and then you have no choice but to pick, which one should stay. > > thanks again, > > -C > > -- > Craig Latta > www.netjam.org/resume > +31 6 2757 7177 > + 1 415 287 3547 (no SMS) > > -- Best regards, Igor Stasenko.

Oct. 19, 2012

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

by Igor Stasenko

On 19 October 2012 22:20, Craig Latta <craig(a)netjam.org> wrote: > > Success! 3 + 4 = 7! Thanks! > music to my ears! :) Yes, we should improve status quo. What i would really like to do is to merge VMMaker sources and platform sources into a single git repository. Then we will not have issues with synchronization between smalltalk sources and platform sources anymore, as well as development process will be even more streamlined. So, i holding my breath for upcoming release of filetree (a monticello <-> git tool). > I'll buy you a beer the next time I see you, for sure. :) > > I wimped out and installed gcc 4.2 before I built, so I can't > report on any LLVM issues. > > As for the howto document, perhaps split it into two documents? One > for jenkins, one for gitorious. That would be better suited to reading > in a hurry. > > > thanks again! > > -C > > -- > Craig Latta > www.netjam.org/resume > +31 6 2757 7177 > + 1 415 287 3547 (no SMS) > > -- Best regards, Igor Stasenko.

Oct. 19, 2012

Re: [Pharo-project] Group metacello question

by Dale Henrichs

----- Original Message ----- | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> | To: "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr> | Sent: Friday, October 19, 2012 1:51:38 PM | Subject: [Pharo-project] Group metacello question | | Hi dale | | Q1: | can I have | group: 'Pharo' | | | group: 'Pharo2.0.x' | | will Pharo2.0.x only gets executed and not Pharo? when I load from | 2.0? Groups are not loaded unless you reference them in a load statement: load: #( 'Pharo2.0.x') or reference the group name in a `requires:` ... they are intended to be shortcuts or aliases for sets of packages like using the 'Tests' group for collecting all of the test packages. You _can_ use groups for naming sets of packages that refer to a platform, but the groups are _not_ automtically loaded ... | | Q2: | separated question | and how can I share spec between let say 1.4 and 2.0 | | group: 'Pharo1.4.x' | | self common: spec | the rest for 1.4 | | group: 'Pharo2.0.x | self common: spec | the rest for 2.0 | You should be using the for:do: for conditional stuff: spec for: #'pharo1.4.x' do: [ common specs for 1.4 ]. spec for: #'pharo2.0.x' do: [ common specs for 2.0 ]. If you want to know the exact platform atributes available then execute the following in an image: (ConfigurationOfYourProject) project attributes The attributes that apply: #pharo #pharo1.x, will be listed. Dale

Oct. 19, 2012

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

by Igor Stasenko

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] Yet another Notation format: Object literals

by Eliot Miranda

HI Dale, Hi Igor, On Fri, Oct 19, 2012 at 9:33 AM, Dale Henrichs <dhenrich(a)vmware.com> wrote: > Igor, > > "you can do anything you like" ... you mean like choosing to use STON and > not invent my own notation format? > > STON is a perfectly good notation format for Smalltalk... > > Methinks that with your recent suggestions are no longer using literal > Smalltalk syntax which is fine, if we are not restricted to literal > Smalltalk syntax, then the following should be a valid format: > > { > "category" : "Topez-Client-Core", > "classinstvars" : [ > ], > "classvars" : [ > ], > "commentStamp" : "", > "instvars" : [ > "project", > "package", > "currentClass", > "classOrInstance", > "category", > "selector", > "history", > "currentWindowId", > "windows", > "namedWindows" ], > "name" : "TZTopezStatus", > "pools" : [ > ], > "super" : "Object", > "type" : "normal" } > > which brings us back to were we started. > Sorry to come late to the party and sorry to point out the obvious but the above is fine in Igor's scheme if one gives up double quotes (since these are comment characters). So the above, with single quotes replacing the double quotes, and #(...) replacing {...} is a valid Smalltalk literal. Is the latter any the less readable? I don't think so. Do you, Dale? (and sorry if the conversation has already moved on). > Smalltalk does not have a literal syntax for dictionaries. While > fabricating dictionaries from literal arrays is possible, the results are > not very readable ... unless you start taking liberties with Smalltalk > syntax... > > If you are no longer restricting yourself to Smalltalk syntax, then what's > wrong with the STON notation above? > > Dale > > ----- Original Message ----- > | From: "Igor Stasenko" <siguctua(a)gmail.com> > | To: Pharo-project(a)lists.gforge.inria.fr > | Sent: Friday, October 19, 2012 9:10:26 AM > | Subject: Re: [Pharo-project] Yet another Notation format: Object literals > | > | On 19 October 2012 16:55, Dale Henrichs <dhenrich(a)vmware.com> wrote: > | > Igor, > | > > | > I'm afraid that your notation is not very friendly to humans ... a > | > computer can keep track of the key value pairs in the literal > | > dictionary, but a human will fail very quickly... > | > > | > The appeal of JSON (and STON) is that the output is readable by > | > mere mortals: > | > > | > (JavaScript Object Notation) is a lightweight > | > data-interchange format. It is easy for humans to > | > read and write. > | > > | > What we're missing from Smalltalk is a literal dictionary or > | > literal map syntax ... without that I'm afraid that for human > | > friendly, lightweight notations we have to step away from the > | > Smalltalk syntax - STON does this very nicely BTW... > | > | no problem, Dale. > | What symbol you want to have to separate keys from values? > | is '->' ok? > | > | Dictionary>>asObjectLiteral > | > | "convert a receiver into an object literal " > | > | ^ Array streamContents: [:stream | > | stream nextPut: self class name. > | self keysAndValuesDo: [:key :value | > | stream > | nextPut: key asObjectLiteral; > | nextPut: #->; > | nextPut: value asObjectLiteral ] ] > | > | (Dictionary newFromPairs: #( a b c d)) asObjectLiteral > | > | #(#Dictionary > | #a #'->' #b > | #c #'->' #d) > | > | which if you pretty-print will look like: > | > | #( > | Dictionary > | a -> b > | c -> d > | ) > | > | is it better? > | or you prefer this one: > | > | #( > | Dictionary > | (a -> b) > | (c -> d) > | ) > | > | you can do anything you like, by implementing the conversion methods > | in a way you like :) > | > | > > | > Dale > | > > | > ----- Original Message ----- > | > | From: "Igor Stasenko" <siguctua(a)gmail.com> > | > | To: "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr> > | > | Sent: Friday, October 19, 2012 4:09:22 AM > | > | Subject: [Pharo-project] Yet another Notation format: Object > | > | literals > | > | > | > | 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. > | > | > | > | > | > | -- > | > | Best regards, > | > | Igor Stasenko. > | > | > | > > | > | > | > | -- > | Best regards, > | Igor Stasenko. > | > | > > -- best, Eliot

Oct. 19, 2012

[Pharo-project] Group metacello question

by StÃ©phane Ducasse

Hi dale Q1: can I have group: 'Pharo' group: 'Pharo2.0.x' will Pharo2.0.x only gets executed and not Pharo? when I load from 2.0? Q2: separated question and how can I share spec between let say 1.4 and 2.0 group: 'Pharo1.4.x' self common: spec the rest for 1.4 group: 'Pharo2.0.x self common: spec the rest for 2.0 tx Stef

Oct. 19, 2012

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

by StÃ©phane Ducasse

>> Could not it be >> >> #( (category 'Topez-Client-Core') (classinstvars ) (classvars ) (commentStamp '') (instvars 'project' 'package') (name 'TZTopezStatus') (pools ) (super 'Object') (type 'normal')) >> >> Like this, no parser at all is required. >> By the way, why keep pools? should type be specified in case it is normal? > > I think someone whose initials are SD is smiling right now ;-) well I did not talk about that over lunch or any other moment. People know what I think and igor is a grown up with his own free mind :) Stef

Oct. 19, 2012

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

by Craig Latta

> and btw, Igor doesn't drink, but I can take the beer for the two ;) Yes, a round of beers for everyone, and I don't drink either. :) -C -- Craig Latta www.netjam.org/resume +31 6 2757 7177 + 1 415 287 3547 (no SMS)

Oct. 19, 2012