- Pharo-dev - lists.pharo.org

Re: [Pharo-project] How to declare Zinc/FS dependency in Metacello Configuration for 1.4

by Dale Henrichs

replies embedded ... ----- Original Message ----- | From: "Francois Stephany" <tulipe.moutarde(a)gmail.com> | To: pharo-project(a)lists.gforge.inria.fr | Sent: Tuesday, April 24, 2012 4:35:19 PM | Subject: Re: [Pharo-project] How to declare Zinc/FS dependency in Metacello Configuration for 1.4 | | Hi Dale, | | > If your project depends upon particular features or APIs in a | > project like Zinc or Seaside or FS, then you will be interested in | > referencing that particular version in your specification. | | Yep but what if I don't need to declare Zinc in the #stable version | of | my package for pharo 1.4 but I do need it for Pharo 1.3. So you are implying that you only have dependency on Zinc for the Pharo1.3 version of your project. Then you do something like the following in your baseline: spec for: #'pharo' do: [ spec package: 'that depends upon zinc' with: [ "the common required packages for your package" ]. ]. spec for: #'pharo1.3.x' do: [ spec project: 'Zinc' with: [ spec className: 'ConfigurationOfZinc'; versionString: #'stable'; repository: 'http://www.squeaksource.com/MetacelloRepository' ]. spec package: 'that depends upon zinc' with: [ spec requires: #('Zinc') ]. ]. If you use the #stable version in your baseline there is no need to anything special in your version spec. | | > On the other hand, if your project uses the standard API and has no | > special dependencies upon details of the project, then you should | > reference the #stable version from your configuration ... using | > #stable means that you don't have to fiddle with your | > configuration every time a new version is released and using | > #stable means that your configuration will work with multiple | > platform versions. | | Mmm. I still reluctant to specify a dependency against #stable. | A package that makes a bump in its version number because of changing | API will load the wrong version. If they update the #stable version at the same time then that is what you want ... To be fair, I will be changing the "automatic upgrade" behavior when I come out with the next release of Metacello ... it will include a Metacello scripting API and you will have more control over how Metacello will treat already loaded projects ... basically you will have to explicitly upgrade a project ... | | > Once you have verified that your project is working on pharo1.4, | > then you should publish a #stable version for #pharo1.4, so that | > users of your project will know that they can safely move to pharo | > 1.4 ... | | Right. That works fine if I use the #stable symbolic version to | declare | the dependency. | | Francois | | > | > ----- Original Message ----- | > | From: "Francois Stephany"<tulipe.moutarde(a)gmail.com> | > | To: pharo-project(a)lists.gforge.inria.fr | > | Sent: Tuesday, April 24, 2012 3:06:03 PM | > | Subject: [Pharo-project] How to declare Zinc/FS dependency in | > | Metacello Configuration for 1.4 | > | | > | I'm updating some Metacello configurations and I'm wondering how | > | to | > | declare the dependencies on stuff that have been integrated into | > | Pharo | > | 1.4 (e.g., Zinc, FS). | > | | > | Should I declare those dependencies into my configuration? If | > | yes, | > | against with version? | > | | > | My gut feeling is that I should create a new baseline that does | > | not | > | require any Zinc of FS. | > | That becomes a pain in the ass when developing in parallel for | > | 1.3 | > | and | > | 1.4. Is the only place where I can differentiate 1.3 and 1.4 is | > | in | > | the | > | stable symbolic version, right? | > | | > | What are people generally doing? | > | | > | | > | Cheers, | > | Francois | > | | > | | > | | -- | http://tulipemoutarde.be | CA: +1 778 558 3225 | BE: +32 65 709 131 | |

April 24, 2012

Re: [Pharo-project] How to declare Zinc/FS dependency in Metacello Configuration for 1.4

by Francois Stephany

Hi Dale, > If your project depends upon particular features or APIs in a project like Zinc or Seaside or FS, then you will be interested in referencing that particular version in your specification. Yep but what if I don't need to declare Zinc in the #stable version of my package for pharo 1.4 but I do need it for Pharo 1.3. > On the other hand, if your project uses the standard API and has no special dependencies upon details of the project, then you should reference the #stable version from your configuration ... using #stable means that you don't have to fiddle with your configuration every time a new version is released and using #stable means that your configuration will work with multiple platform versions. Mmm. I still reluctant to specify a dependency against #stable. A package that makes a bump in its version number because of changing API will load the wrong version. > Once you have verified that your project is working on pharo1.4, then you should publish a #stable version for #pharo1.4, so that users of your project will know that they can safely move to pharo 1.4 ... Right. That works fine if I use the #stable symbolic version to declare the dependency. Francois > > ----- Original Message ----- > | From: "Francois Stephany"<tulipe.moutarde(a)gmail.com> > | To: pharo-project(a)lists.gforge.inria.fr > | Sent: Tuesday, April 24, 2012 3:06:03 PM > | Subject: [Pharo-project] How to declare Zinc/FS dependency in Metacello Configuration for 1.4 > | > | I'm updating some Metacello configurations and I'm wondering how to > | declare the dependencies on stuff that have been integrated into > | Pharo > | 1.4 (e.g., Zinc, FS). > | > | Should I declare those dependencies into my configuration? If yes, > | against with version? > | > | My gut feeling is that I should create a new baseline that does not > | require any Zinc of FS. > | That becomes a pain in the ass when developing in parallel for 1.3 > | and > | 1.4. Is the only place where I can differentiate 1.3 and 1.4 is in > | the > | stable symbolic version, right? > | > | What are people generally doing? > | > | > | Cheers, > | Francois > | > | > -- http://tulipemoutarde.be CA: +1 778 558 3225 BE: +32 65 709 131

April 24, 2012

Re: [Pharo-project] STON (was Re: SimpleLiteralArray Spec)

by H. Hirzel

GÃ¶ran Thank you for this illustration. http://goran.krampe.se/blog/Squeak/Tirade.rdoc I understand that 1) the Tirade parser parses a subset of regular Smalltalk messages. 2) the receiver is not given as it is assumed to be always the Tirade parser object. 3) the Tirade parser acts like a builder for objects? 4) It solves problems JSON and STON do not. I think this idea is very worth to pursue. --Hannes On 4/25/12, GÃ¶ran Krampe <goran(a)krampe.se> wrote: > On 04/24/2012 07:28 PM, Dale Henrichs wrote: >> Sven, >> >> For tODE I am very interested having something with this kind of potential >> ... shipping "real" ST objects back and forth between Amber and Pharo or >> GemStone has some real appeal... >> >> So Goran, the STON format looks somewhat similar to Tirade ... what would >> Tirade look like for the same data set? > > Hmmm, let's see. > >> | TestDomainObject { >> | #created : DateAndTime [ '2012-02-14T16:40:15+01:00' ], >> | #modified : DateAndTime [ '2012-02-14T16:40:18+01:00' ], >> | #integer : 39581, >> | #float : 73.84789359463944, >> | #description : 'This is a test', >> | #color : #green, >> | #tags : [ >> | #two, >> | #beta, >> | #medium >> | ], >> | #bytes : ByteArray [ 'afabfdf61d030f43eb67960c0ae9f39f' ], >> | #boolean : false >> | } > > It is an interesting question since Tirade is not meant to be parsed by > a generic parser like JSON or STON. Tirade is a series of Smalltalk > messages (unary or keyword) with arguments limited to literals (although > with some subtle additions to regular Smalltalk literals, like for > example Associations). > > These messages give Tirade semantics and thus we do not normally add > "types" to the Tirade input. > > So the above could be encoded as a single Tirade message like this: > > created: '2012-02-14T16:40:15+01:00' > modified: '2012-02-14T16:40:18+01:00' > integer: 39581 > float: 73.84789359463944 > description: 'This is a test' > color: #green > tags: #(two beta medium) > bytes: 'afabfdf61d030f43eb67960c0ae9f39f' > boolean: false. > > Note that the above syntactically is a regular Smalltalk keyword message > with no receiver to the left and ended with a "." (mandatory in Tirade). > Also, the tags could also be represented as {#two . #beta . #medium} but > although the syntax is like dynamic arrays in Pharo that does not mean > expressions are allowed in Tirade - only literals. > > Normally there would be a subclass of TiradeReader that implements the > above message and then does the appropriate instantiations for #created, > #modified and #bytes given the string input for those arguments. This > method could look something like this (just pseudo code): > > created: created > modified: modified > integer: int > float: float > description: description > color: color > tags: tags > bytes: bytes > boolean: boolean > > result := TestDomainObject new > created: (TimeStamp fromString: created); > modified: (TimeStamp fromString: modified). > result integer: int; float: float; description: description; > color: color; tags: tags; > bytes: bytes asByteArray; boolean: boolean > > > If one instead uses a plain TiradeParser to parse the above it will of > course not have an implementation of the above method and will instead > by default produce an OrderedCollection of "messages" where each message > is an Association with the keyword selector as key and an array of > arguments as the value. So running TiradeParser>>parse: on the above > input gives: > > an > OrderedCollection(#created:modified:integer:float:description:color:tags:bytes:boolean:->#('2012-02-14T16:40:15+01:00' > '2012-02-14T16:40:18+01:00' 39581 73.84789359463944 'This is a test' > #green #(true #beta #medium) 'afabfdf61d030f43eb67960c0ae9f39f' false)) > > Finally a totally different approach is to encode the above object as a > nested array with Associations, thus mimicking JSON/STON and it could > look like this: > > testdomainobject: { > #created -> '2012-02-14T16:40:15+01:00'. > #modified -> '2012-02-14T16:40:18+01:00'. > #integer -> 39581. > #float -> 73.84789359463944. > #description -> 'This is a test'. > #color -> #green. > #tags -> #(two beta medium). > #bytes -> 'afabfdf61d030f43eb67960c0ae9f39f'. > #boolean -> false > }. > > NOTE: The -> syntax is added to Tirade as a "literal syntax" although it > is in fact a binary message in Pharo. This will create an Array with > Associations in it. > > Again, if the reader implements the selector #testdomainobject: it will > know what to do with the argument. Again, using only TiradeParser it > would parse into: > > an OrderedCollection(#testdomainobject:->{((Array new: 9) at: 1 put: > (#created->'2012-02-14T16:40:15+01:00'); at: 2 put: > (#modified->'2012-02-14T16:40:18+01:00'); at: 3 put: (#integer->39581); > at: 4 put: (#float->73.84789359463944); at: 5 put: (#description->'This > is a test'); at: 6 put: (#color->#green); at: 7 put: (#tags->#(true > #beta #medium )); at: 8 put: > (#bytes->'afabfdf61d030f43eb67960c0ae9f39f'); at: 9 put: > (#boolean->false); yourself)}) > > Oh, funky. Obviously that is how print-it behaves on an Array of > Assocations :) > > Hopefully this gives a better idea of how Tirade works. Again, the three > articles on Tirade from my blog explains more details: > > http://goran.krampe.se/blog/Squeak/Tirade.rdoc > http://goran.krampe.se/blog/Squeak/Tirade2.rdoc > http://goran.krampe.se/blog/Squeak/Tirade3.rdoc > > NOTE: The part on "receiver juggling" was way crazy, forget that :) > > regards, GÃ¶ran > >

April 24, 2012

Re: [Pharo-project] STON (was Re: SimpleLiteralArray Spec)

by Dale Henrichs

Okay, so Tirade isn't a generic parser for a well-defined syntax like STON and it looks like it really shines when it comes to doing dynamic interpretation of streams of messages .... now I better understand how Tirade can be applied to deltas or creating executable logs that can be replayed ... At this point in time for disk-based structures that humans and computers are expected to understand it seems that a well-defined syntax is useful. Dale ----- Original Message ----- | From: "GÃ¶ran Krampe" <goran(a)krampe.se> | To: pharo-project(a)lists.gforge.inria.fr | Sent: Tuesday, April 24, 2012 3:56:36 PM | Subject: Re: [Pharo-project] STON (was Re: SimpleLiteralArray Spec) | | On 04/24/2012 07:28 PM, Dale Henrichs wrote: | > Sven, | > | > For tODE I am very interested having something with this kind of | > potential ... shipping "real" ST objects back and forth between | > Amber and Pharo or GemStone has some real appeal... | > | > So Goran, the STON format looks somewhat similar to Tirade ... what | > would Tirade look like for the same data set? | | Hmmm, let's see. | | > | TestDomainObject { | > | #created : DateAndTime [ '2012-02-14T16:40:15+01:00' ], | > | #modified : DateAndTime [ '2012-02-14T16:40:18+01:00' ], | > | #integer : 39581, | > | #float : 73.84789359463944, | > | #description : 'This is a test', | > | #color : #green, | > | #tags : [ | > | #two, | > | #beta, | > | #medium | > | ], | > | #bytes : ByteArray [ 'afabfdf61d030f43eb67960c0ae9f39f' ], | > | #boolean : false | > | } | | It is an interesting question since Tirade is not meant to be parsed | by | a generic parser like JSON or STON. Tirade is a series of Smalltalk | messages (unary or keyword) with arguments limited to literals | (although | with some subtle additions to regular Smalltalk literals, like for | example Associations). | | These messages give Tirade semantics and thus we do not normally add | "types" to the Tirade input. | | So the above could be encoded as a single Tirade message like this: | | created: '2012-02-14T16:40:15+01:00' | modified: '2012-02-14T16:40:18+01:00' | integer: 39581 | float: 73.84789359463944 | description: 'This is a test' | color: #green | tags: #(two beta medium) | bytes: 'afabfdf61d030f43eb67960c0ae9f39f' | boolean: false. | | Note that the above syntactically is a regular Smalltalk keyword | message | with no receiver to the left and ended with a "." (mandatory in | Tirade). | Also, the tags could also be represented as {#two . #beta . #medium} | but | although the syntax is like dynamic arrays in Pharo that does not | mean | expressions are allowed in Tirade - only literals. | | Normally there would be a subclass of TiradeReader that implements | the | above message and then does the appropriate instantiations for | #created, | #modified and #bytes given the string input for those arguments. This | method could look something like this (just pseudo code): | | created: created | modified: modified | integer: int | float: float | description: description | color: color | tags: tags | bytes: bytes | boolean: boolean | | result := TestDomainObject new | created: (TimeStamp fromString: created); | modified: (TimeStamp fromString: modified). | result integer: int; float: float; description: description; | color: color; tags: tags; | bytes: bytes asByteArray; boolean: boolean | | | If one instead uses a plain TiradeParser to parse the above it will | of | course not have an implementation of the above method and will | instead | by default produce an OrderedCollection of "messages" where each | message | is an Association with the keyword selector as key and an array of | arguments as the value. So running TiradeParser>>parse: on the above | input gives: | | an | OrderedCollection(#created:modified:integer:float:description:color:tags:bytes:boolean:->#('2012-02-14T16:40:15+01:00' | '2012-02-14T16:40:18+01:00' 39581 73.84789359463944 'This is a test' | #green #(true #beta #medium) 'afabfdf61d030f43eb67960c0ae9f39f' | false)) | | Finally a totally different approach is to encode the above object as | a | nested array with Associations, thus mimicking JSON/STON and it could | look like this: | | testdomainobject: { | #created -> '2012-02-14T16:40:15+01:00'. | #modified -> '2012-02-14T16:40:18+01:00'. | #integer -> 39581. | #float -> 73.84789359463944. | #description -> 'This is a test'. | #color -> #green. | #tags -> #(two beta medium). | #bytes -> 'afabfdf61d030f43eb67960c0ae9f39f'. | #boolean -> false | }. | | NOTE: The -> syntax is added to Tirade as a "literal syntax" although | it | is in fact a binary message in Pharo. This will create an Array with | Associations in it. | | Again, if the reader implements the selector #testdomainobject: it | will | know what to do with the argument. Again, using only TiradeParser it | would parse into: | | an OrderedCollection(#testdomainobject:->{((Array new: 9) at: 1 put: | (#created->'2012-02-14T16:40:15+01:00'); at: 2 put: | (#modified->'2012-02-14T16:40:18+01:00'); at: 3 put: | (#integer->39581); | at: 4 put: (#float->73.84789359463944); at: 5 put: | (#description->'This | is a test'); at: 6 put: (#color->#green); at: 7 put: (#tags->#(true | #beta #medium )); at: 8 put: | (#bytes->'afabfdf61d030f43eb67960c0ae9f39f'); at: 9 put: | (#boolean->false); yourself)}) | | Oh, funky. Obviously that is how print-it behaves on an Array of | Assocations :) | | Hopefully this gives a better idea of how Tirade works. Again, the | three | articles on Tirade from my blog explains more details: | | http://goran.krampe.se/blog/Squeak/Tirade.rdoc | http://goran.krampe.se/blog/Squeak/Tirade2.rdoc | http://goran.krampe.se/blog/Squeak/Tirade3.rdoc | | NOTE: The part on "receiver juggling" was way crazy, forget that :) | | regards, GÃ¶ran | |

April 24, 2012

Re: [Pharo-project] SimpleLiteralArray Spec

by Dale Henrichs

Stef, I mentioned several weeks ago that the Cypress implementation takes advantage of the fact that the JSON parser produces dictionaries ... this is a bit of functionality that I called out as critical ... STON is the first Smalltalk-centric text format that I've seen that has a nice syntax for producing Dictionaries. Of course, I think it is a bonus that you can use it to represent specific class instances as that can prove to be very useful. Of course I am a Smalltalk programmer, so if you give me STON, instead of meticulously constructing a JSON structure that matches the fields of the classes (for each dialect) I think that we would be inclined to ask the class to create a STON representation and dump that to disk ... So the immediate value of STON would be that we'd be sending messages to objects instead of translating formats .... the messages that we send will end up creating a nice human-readable format ... win-win. Of course for multiple dialects we agreed that we would use the same set of field names for the class attributes so that a dialect could create the class using the fields that it recognized ... so that would imply some level of standardization of the STON field names to be used, but that shouldn't be too hard since there aren't that many fields to monkey with for classes ... Dale ----- Original Message ----- | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> | To: Pharo-project(a)lists.gforge.inria.fr | Sent: Tuesday, April 24, 2012 3:36:47 PM | Subject: Re: [Pharo-project] SimpleLiteralArray Spec | | | On Apr 25, 2012, at 12:17 AM, Dale Henrichs wrote: | | > Stef, | > | > Which is more important: | > | > implementation or functionality? | | functionality: how to store meta data of class or method. So far I do | not see why I need ston. | | Now if you tell me that you need a textual serializer then this is | another story and scenario. | But this is not the one we need to store meta data of class and | method. | | I'm not that approximate to mix the two. | | Stef | > | > You appear to be fixated on a particular solution and seem to be | > ignoring the actual problems. | > | > Dale | > | > ----- Original Message ----- | > | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> | > | To: Pharo-project(a)lists.gforge.inria.fr | > | Sent: Tuesday, April 24, 2012 3:13:20 PM | > | Subject: Re: [Pharo-project] SimpleLiteralArray Spec | > | | > | | > | On Apr 24, 2012, at 1:26 PM, Sven Van Caekenberghe wrote: | > | | > | > OK, just to get started, let try to write a spec for | > | > SimpleLiteralArray, this is based on JSON (and my own STON, not | > | > ready for public consumption). It will soon become clear that | > | > this | > | > is slightly harder than expected, IMO a writer is needed as | > | > well. | > | > | > | > S y n t a x | > | > | > | > value | > | > primitive-value | > | > list | > | > nil | > | > primitive-value | > | > number | > | > true | > | > false | > | > symbol | > | > string | > | > classname | > | | > | In a literal array a class name is just a symbol | > | | > | #(Foo) first | > | #Foo | > | | > | > list | > | > #() | > | > #( elements ) | > | > elements | > | > value | > | > value , elements | > | > string | > | > '' | > | > ' chars ' | > | > chars | > | > char | > | > char chars | > | > char | > | > any-printable-ASCII-character- | > | > except-"-or-\ | > | > \" | > | > \\ | > | > \/ | > | > \b | > | > \f | > | > \n | > | > \r | > | > \t | > | > \u four-hex-digits | > | | > | why do we need that? | > | | > | > symbol | > | > # chars-limited | > | > # ' chars ' | > | > chars-limited | > | > char-limited | > | > char-limited chars-limited | > | > char-limited | > | > a-z A-Z 0-9 - _ . / | > | > classname | > | > uppercase-alpha-char alphanumeric-char | > | | > | there is not need for classname as element | > | classname is just a pair that the interpretation should handle if | > | necessary | > | | > | | > | > number | > | > int | > | > int frac | > | > int exp | > | > int frac exp | > | > int | > | > digit | > | > digit1-9 digits | > | > - digit | > | > - digit1-9 digits | > | > frac | > | > . digits | > | > exp | > | > e digits | > | > digits | > | > digit | > | > digit digits | > | > e | > | > e | > | > e+ | > | > e- | > | > E | > | > E+ | > | > E- | > | > | > | > | > | > Questions remain: | > | > | > | > - is the escaping OK ? | > | | > | I do not know but in literal array there is no escaping. Now if | > | you | > | want to put a cr into a string you probably need that | > | | > | > - what about symbols without a leading # ? | > | | > | #(foo) -> #(#foo) | > | #(true nil false 1 'n') -> #(true nil false 1 'n') | > | | > | > - what should be allowed in unquoted symbols ? | > | I did not get the question | > | | > | > - what should be allowed for classnames ? | > | Nothing | > | | > | > - what about namespaces ? | > | Nothing no need I do not think that they are in literal arrays. | > | (may | > | be in VW but I did not check) | > | | > | > - do we allow infinite precision integers ? | > | Yes | > | | > | > - maybe the toplevel should always be an array ? | > | | > | I would say so else this is not a literalArray but a literal. | > | | > | | > | > | > | > | > | > Now: shoot! | > | > | > | > | > | > Sven | > | > | > | > | > | > -- | > | > Sven Van Caekenberghe | > | > http://stfx.eu | > | > Smalltalk is the Red Pill | > | > | > | > | > | > | > | > | > | > | > | | > | | > | | > | | |

April 24, 2012

Re: [Pharo-project] STON (was Re: SimpleLiteralArray Spec)

by GÃ¶ran Krampe

On 04/24/2012 07:28 PM, Dale Henrichs wrote: > Sven, > > For tODE I am very interested having something with this kind of potential ... shipping "real" ST objects back and forth between Amber and Pharo or GemStone has some real appeal... > > So Goran, the STON format looks somewhat similar to Tirade ... what would Tirade look like for the same data set? Hmmm, let's see. > | TestDomainObject { > | #created : DateAndTime [ '2012-02-14T16:40:15+01:00' ], > | #modified : DateAndTime [ '2012-02-14T16:40:18+01:00' ], > | #integer : 39581, > | #float : 73.84789359463944, > | #description : 'This is a test', > | #color : #green, > | #tags : [ > | #two, > | #beta, > | #medium > | ], > | #bytes : ByteArray [ 'afabfdf61d030f43eb67960c0ae9f39f' ], > | #boolean : false > | } It is an interesting question since Tirade is not meant to be parsed by a generic parser like JSON or STON. Tirade is a series of Smalltalk messages (unary or keyword) with arguments limited to literals (although with some subtle additions to regular Smalltalk literals, like for example Associations). These messages give Tirade semantics and thus we do not normally add "types" to the Tirade input. So the above could be encoded as a single Tirade message like this: created: '2012-02-14T16:40:15+01:00' modified: '2012-02-14T16:40:18+01:00' integer: 39581 float: 73.84789359463944 description: 'This is a test' color: #green tags: #(two beta medium) bytes: 'afabfdf61d030f43eb67960c0ae9f39f' boolean: false. Note that the above syntactically is a regular Smalltalk keyword message with no receiver to the left and ended with a "." (mandatory in Tirade). Also, the tags could also be represented as {#two . #beta . #medium} but although the syntax is like dynamic arrays in Pharo that does not mean expressions are allowed in Tirade - only literals. Normally there would be a subclass of TiradeReader that implements the above message and then does the appropriate instantiations for #created, #modified and #bytes given the string input for those arguments. This method could look something like this (just pseudo code): created: created modified: modified integer: int float: float description: description color: color tags: tags bytes: bytes boolean: boolean result := TestDomainObject new created: (TimeStamp fromString: created); modified: (TimeStamp fromString: modified). result integer: int; float: float; description: description; color: color; tags: tags; bytes: bytes asByteArray; boolean: boolean If one instead uses a plain TiradeParser to parse the above it will of course not have an implementation of the above method and will instead by default produce an OrderedCollection of "messages" where each message is an Association with the keyword selector as key and an array of arguments as the value. So running TiradeParser>>parse: on the above input gives: an OrderedCollection(#created:modified:integer:float:description:color:tags:bytes:boolean:->#('2012-02-14T16:40:15+01:00' '2012-02-14T16:40:18+01:00' 39581 73.84789359463944 'This is a test' #green #(true #beta #medium) 'afabfdf61d030f43eb67960c0ae9f39f' false)) Finally a totally different approach is to encode the above object as a nested array with Associations, thus mimicking JSON/STON and it could look like this: testdomainobject: { #created -> '2012-02-14T16:40:15+01:00'. #modified -> '2012-02-14T16:40:18+01:00'. #integer -> 39581. #float -> 73.84789359463944. #description -> 'This is a test'. #color -> #green. #tags -> #(two beta medium). #bytes -> 'afabfdf61d030f43eb67960c0ae9f39f'. #boolean -> false }. NOTE: The -> syntax is added to Tirade as a "literal syntax" although it is in fact a binary message in Pharo. This will create an Array with Associations in it. Again, if the reader implements the selector #testdomainobject: it will know what to do with the argument. Again, using only TiradeParser it would parse into: an OrderedCollection(#testdomainobject:->{((Array new: 9) at: 1 put: (#created->'2012-02-14T16:40:15+01:00'); at: 2 put: (#modified->'2012-02-14T16:40:18+01:00'); at: 3 put: (#integer->39581); at: 4 put: (#float->73.84789359463944); at: 5 put: (#description->'This is a test'); at: 6 put: (#color->#green); at: 7 put: (#tags->#(true #beta #medium )); at: 8 put: (#bytes->'afabfdf61d030f43eb67960c0ae9f39f'); at: 9 put: (#boolean->false); yourself)}) Oh, funky. Obviously that is how print-it behaves on an Array of Assocations :) Hopefully this gives a better idea of how Tirade works. Again, the three articles on Tirade from my blog explains more details: http://goran.krampe.se/blog/Squeak/Tirade.rdoc http://goran.krampe.se/blog/Squeak/Tirade2.rdoc http://goran.krampe.se/blog/Squeak/Tirade3.rdoc NOTE: The part on "receiver juggling" was way crazy, forget that :) regards, GÃ¶ran

April 24, 2012

Re: [Pharo-project] How to declare Zinc/FS dependency in Metacello Configuration for 1.4

by Dale Henrichs

Francois, The #stable symbolic version is the key when dealing with a new platform version like pharo 1.4 ... if a configuration does not have a #stable version for #pharo1.4 then it is not likely that the configuration has been tested on pharo1.4 ... If it does have a #stable version then it is likely to have been tested. At this point you have a decision to make ... If your project depends upon particular features or APIs in a project like Zinc or Seaside or FS, then you will be interested in referencing that particular version in your specification. Nonetheless if there is no #stable version specified for the project, then you can't be sure that the project has been ported. On the other hand, if your project uses the standard API and has no special dependencies upon details of the project, then you should reference the #stable version from your configuration ... using #stable means that you don't have to fiddle with your configuration every time a new version is released and using #stable means that your configuration will work with multiple platform versions. Once you have verified that your project is working on pharo1.4, then you should publish a #stable version for #pharo1.4, so that users of your project will know that they can safely move to pharo 1.4 ... Dale ----- Original Message ----- | From: "Francois Stephany" <tulipe.moutarde(a)gmail.com> | To: pharo-project(a)lists.gforge.inria.fr | Sent: Tuesday, April 24, 2012 3:06:03 PM | Subject: [Pharo-project] How to declare Zinc/FS dependency in Metacello Configuration for 1.4 | | I'm updating some Metacello configurations and I'm wondering how to | declare the dependencies on stuff that have been integrated into | Pharo | 1.4 (e.g., Zinc, FS). | | Should I declare those dependencies into my configuration? If yes, | against with version? | | My gut feeling is that I should create a new baseline that does not | require any Zinc of FS. | That becomes a pain in the ass when developing in parallel for 1.3 | and | 1.4. Is the only place where I can differentiate 1.3 and 1.4 is in | the | stable symbolic version, right? | | What are people generally doing? | | | Cheers, | Francois | |

April 24, 2012

Re: [Pharo-project] JSON, Smalltalk parser and no-point wars

by Camillo Bruni

April 24, 2012

Re: [Pharo-project] SimpleLiteralArray Spec

by StÃ©phane Ducasse

On Apr 25, 2012, at 12:17 AM, Dale Henrichs wrote: > Stef, > > Which is more important: > > implementation or functionality? functionality: how to store meta data of class or method. So far I do not see why I need ston. Now if you tell me that you need a textual serializer then this is another story and scenario. But this is not the one we need to store meta data of class and method. I'm not that approximate to mix the two. Stef > > You appear to be fixated on a particular solution and seem to be ignoring the actual problems. > > Dale > > ----- Original Message ----- > | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > | To: Pharo-project(a)lists.gforge.inria.fr > | Sent: Tuesday, April 24, 2012 3:13:20 PM > | Subject: Re: [Pharo-project] SimpleLiteralArray Spec > | > | > | On Apr 24, 2012, at 1:26 PM, Sven Van Caekenberghe wrote: > | > | > OK, just to get started, let try to write a spec for > | > SimpleLiteralArray, this is based on JSON (and my own STON, not > | > ready for public consumption). It will soon become clear that this > | > is slightly harder than expected, IMO a writer is needed as well. > | > > | > S y n t a x > | > > | > value > | > primitive-value > | > list > | > nil > | > primitive-value > | > number > | > true > | > false > | > symbol > | > string > | > classname > | > | In a literal array a class name is just a symbol > | > | #(Foo) first > | #Foo > | > | > list > | > #() > | > #( elements ) > | > elements > | > value > | > value , elements > | > string > | > '' > | > ' chars ' > | > chars > | > char > | > char chars > | > char > | > any-printable-ASCII-character- > | > except-"-or-\ > | > \" > | > \\ > | > \/ > | > \b > | > \f > | > \n > | > \r > | > \t > | > \u four-hex-digits > | > | why do we need that? > | > | > symbol > | > # chars-limited > | > # ' chars ' > | > chars-limited > | > char-limited > | > char-limited chars-limited > | > char-limited > | > a-z A-Z 0-9 - _ . / > | > classname > | > uppercase-alpha-char alphanumeric-char > | > | there is not need for classname as element > | classname is just a pair that the interpretation should handle if > | necessary > | > | > | > number > | > int > | > int frac > | > int exp > | > int frac exp > | > int > | > digit > | > digit1-9 digits > | > - digit > | > - digit1-9 digits > | > frac > | > . digits > | > exp > | > e digits > | > digits > | > digit > | > digit digits > | > e > | > e > | > e+ > | > e- > | > E > | > E+ > | > E- > | > > | > > | > Questions remain: > | > > | > - is the escaping OK ? > | > | I do not know but in literal array there is no escaping. Now if you > | want to put a cr into a string you probably need that > | > | > - what about symbols without a leading # ? > | > | #(foo) -> #(#foo) > | #(true nil false 1 'n') -> #(true nil false 1 'n') > | > | > - what should be allowed in unquoted symbols ? > | I did not get the question > | > | > - what should be allowed for classnames ? > | Nothing > | > | > - what about namespaces ? > | Nothing no need I do not think that they are in literal arrays. (may > | be in VW but I did not check) > | > | > - do we allow infinite precision integers ? > | Yes > | > | > - maybe the toplevel should always be an array ? > | > | I would say so else this is not a literalArray but a literal. > | > | > | > > | > > | > Now: shoot! > | > > | > > | > Sven > | > > | > > | > -- > | > Sven Van Caekenberghe > | > http://stfx.eu > | > Smalltalk is the Red Pill > | > > | > > | > > | > > | > > | > | > | >

April 24, 2012

Re: [Pharo-project] How to declare Zinc/FS dependency in Metacello Configuration for 1.4

by StÃ©phane Ducasse

On Apr 25, 2012, at 12:06 AM, Francois Stephany wrote: > I'm updating some Metacello configurations and I'm wondering how to declare the dependencies on stuff that have been integrated into Pharo 1.4 (e.g., Zinc, FS). excellent question. So far you cannot but what we discussed with esteban is that we want to have the configurationOf the project loaded so that when we move to a smaller kernel we do not have to reinvent them and more important we can code against and use them as milestone. > Should I declare those dependencies into my configuration? If yes, against with version? > > My gut feeling is that I should create a new baseline that does not require any Zinc of FS. yes > That becomes a pain in the ass when developing in parallel for 1.3 and 1.4. yes same feeling here. > Is the only place where I can differentiate 1.3 and 1.4 is in the stable symbolic version, right? > > What are people generally doing? grumbling :( May be dale know but I don't > > > Cheers, > Francois >

April 24, 2012