Oh, i'm not subscribed to that list. Anyways.. since i late on the party.. just wanna put my 2 cents here:
you don't need a literal dictionary syntax to be able to (de)serialize dictionaries. Just a simple example: we start from: #( propertyName value ) ok, some values can be arrays: #( propertyName ( array of values) ) and some values can be dictionaries: #( propertyName #dict ( key1 value1 key2 value2 ... ) ) and to avoid ambugility, you can just put #symbol, to indicate that next element is symbol: #( propertyName #symbol #dict) so it won't try to construct a dictionary, but just use #dict as a symbol value for propery, same for #symbol itself: #(propertyName #symbol #symbol) ... and of course there can be numerous other ways for doing that. On 24 April 2012 01:19, H. Hirzel <[email protected]> wrote: > You are right. It is hidden in another thread > > http://forum.world.st/FileTree-and-Cypress-status-td4543773.html > 'FileTree and Cypress status' > > The basic outcome was that it is a matter of taste and that Dale does > not want to be bothered. In addition other Smalltalkers support it. > See signatures on photo at the bottom of > https://github.com/CampSmalltalk/Cypress/wiki > > --Hannes > > > > On 4/24/12, Igor Stasenko <[email protected]> wrote: >> On 24 April 2012 00:56, H. Hirzel <[email protected]> wrote: >>> Hello Igor >>> >>> This has been discussed on the Metacello mailing list on the 11 and >>> 12th of this month. >> >> can you please give me a direct link to thread? >> too much mails.. too much mails. >> :) >> >>> >>> Regards >>> Hannes >>> >>> On 4/23/12, Igor Stasenko <[email protected]> wrote: >>>> Hi, Dale >>>> >>>> it is great to see an effort in such direction. >>>> I just wonder what .js files doing there? >>>> >>>> According to what i see, it is just a meta data which holding >>>> additional properties per entity.. >>>> >>>> { >>>> "category" : "Cypress-Tests", >>>> "classinstvars" : [ >>>> ], >>>> "classtraitcomposition" : "{}", >>>> "classvars" : [ >>>> ], >>>> "commentStamp" : "", >>>> "instvars" : [ >>>> ], >>>> "name" : "CypressPatchTest", >>>> "pools" : [ >>>> ], >>>> "super" : "CypressAbstractTest", >>>> "traitcomposition" : "{}", >>>> "type" : "normal" } >>>> >>>> why you cannot use a regular smalltalk literal syntax for this data? >>>> What/why there is need to store this data in json format? >>>> >>>> On 23 April 2012 23:57, Dale Henrichs <[email protected]> wrote: >>>>> Bernhard, >>>>> >>>>> With regards to sharing code between dialects, I'd like to recommend >>>>> that >>>>> you look into porting Cypress to Cuis (I'm willing to help as much as I >>>>> can). >>>>> >>>>> The Cypress project is aimed from the get go to enable sharing of >>>>> packages >>>>> between Smalltalk dialects with a recognition that possibly the most >>>>> important aspect is a shared VCS (git/github). >>>>> >>>>> If you look at the current code base in Cypress, you will see a >>>>> reference >>>>> implementation written against Pharo. The reference implementation is a >>>>> work in progress and the initial implementation was done for Amber[2]. >>>>> >>>>> Cypress has Monticello-like packages, but other than taking a few ideas >>>>> from Monticello (definitions, packages and snapshots ... more than a >>>>> few:)) the code base is independent of Monticello. The fact that Cypress >>>>> runs on top of Amber (sans file system access) speaks volumes for it's >>>>> portability. >>>>> >>>>> To paraphrase a point from my STIC talk[3] on this subject: >>>>> >>>>> Cypress is not intended to be the primary version control >>>>> system for any dialect, however, if you want to share code >>>>> between dialects you should allow your developers to import >>>>> and export code using the Cypress package format. >>>>> >>>>> If you are interested, there are bits and pieces of code in a few other >>>>> projects that I would want to pull into the Cypress project and couple >>>>> other things that I'd like to move out of the Cypress project before >>>>> tackling another port ... >>>>> >>>>> We can correspond via private email if you'd like to take me up on the >>>>> offer of help:) >>>>> >>>>> Dale >>>>> >>>>> [1] https://github.com/CampSmalltalk/Cypress >>>>> [2] https://github.com/CampSmalltalk/amber-cypress >>>>> [3] >>>>> http://portal.sliderocket.com/vmware/STIC-2012-Practical-Git-for-Smalltalk >>>>> >>>>> ----- Original Message ----- >>>>> | From: "Bernhard Pieber" <[email protected]> >>>>> | To: [email protected] >>>>> | Sent: Monday, April 23, 2012 9:53:35 AM >>>>> | Subject: Re: [Pharo-project] [ANN] Styled Text Editor for Cuis 4.0 >>>>> Smalltalk >>>>> | >>>>> | Hi Göran, >>>>> | >>>>> | Thanks for your question! I have posted the announcement of the >>>>> | Styled Text Editor to the Pharo list as well because I still have >>>>> | not given up on the idea to port it to Squeak and Pharo. It is not >>>>> | straightforward but I consider it possible. >>>>> | >>>>> | Currently the Styled Text Editor is an external package which is >>>>> | loaded on top of Cuis 4.0. The API it uses is quite specific to Cuis >>>>> | so to port it alone is probably too much effort. What I think can be >>>>> | done is the following: >>>>> | Split Cuis into three parts, >>>>> | a) the parts which are not needed for Styled Text Editor, like the >>>>> | Cuis tools >>>>> | b) the parts of Cuis Morphic the Styled Text Editor depends on – this >>>>> | is in my opinion the most valuable part of Cuis because Juan spent >>>>> | years cleaning it >>>>> | c) the Smalltalk kernel below >>>>> | >>>>> | The idea is to port only part b) and the Styled Text Editor. And it >>>>> | has to be done automatically by a tool which creates packages for >>>>> | Squeak and Pharo, always from the latest code base. In addition you >>>>> | will probably need small Cuis portability packages done manually, >>>>> | one for Squeak and one for Pharo. >>>>> | >>>>> | Being able to always load the latest code base of Styled Text Editor >>>>> | and Cuis Morphic as an external package in Pharo is a prerequisite >>>>> | to look into possibilities of sharing more of the code. >>>>> | >>>>> | I plan to write a more detailed proposal and then to approach ESUG >>>>> | and ask for support for the funding. Any ideas for other sources of >>>>> | funding are highly welcome and could speed things up considerably, >>>>> | of course! ;-) >>>>> | >>>>> | I for one have not given up on the idea that it might be possible to >>>>> | develop substantial components as you called it – thank you for that >>>>> | as well – in a more Squeak-dialect-independent way. ;-) >>>>> | >>>>> | Finally, I would like to take the opportunity and kindly ask everyone >>>>> | who has not done so yet: Please check out Cuis 4.0 and the Styled >>>>> | Text Editor and give us feedback, even if it does not (yet) run on >>>>> | your favourite Squeak dialect! Thank you! >>>>> | >>>>> | Peace, >>>>> | Bernhard >>>>> | >>>>> | P.S. Thanks to Göran and Janko for trying to establish different >>>>> | threads for the rather off-topic discussions that my announcement >>>>> | posting has caused. >>>>> | >>>>> | Am 23.04.2012 um 16:04 schrieb Göran Krampe: >>>>> | > Hi! >>>>> | > >>>>> | > On 04/23/2012 03:40 PM, Stéphane Ducasse wrote: >>>>> | >>> Just cloning it off into Pharo and forking seems... less optimal. >>>>> | >>> Any ideas or thoughts? >>>>> | >> >>>>> | >> I do not get what you mean. I just want to work on our roadmap and >>>>> | >> make it getting real. >>>>> | >> It is hard enough to get some momentum and to deliver for real. >>>>> | >> So can you help us to get focused? >>>>> | >> People can do what they want. I wrote a vision document. We have a >>>>> | >> roadmap >>>>> | >> and we will do it. >>>>> | > >>>>> | > Ok, let me clarify. I was just wondering how the Pharo community >>>>> | > wants to handle a case where a substantial component (in this >>>>> | > case, this new editor) is not *primarily* developed in Pharo (in >>>>> | > this case Cuis). >>>>> | > >>>>> | > The simple route is to just copy and fork. But IMHO this doesn't >>>>> | > leverage the team already around this editor, right? We (Pharo) >>>>> | > can't just go around and forking everything and maintaining >>>>> | > everything for ourselves, right? >>>>> | > >>>>> | > I just got interested in that problem - now, later replies >>>>> | > indicated that it would still need a substantial rewrite for >>>>> | > Pharo, so perhaps the situation I am describing is not really >>>>> | > applicable in this case. >>>>> | > >>>>> | > regards, Göran >>>>> | > >>>>> | >>>>> | >>>>> | >>>>> >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>>> >>>> >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> >> > -- Best regards, Igor Stasenko.
