Igor, The short answer is:
We could have used literal arrays, but it would have taken more work up front than using the existing (portable) Seaside JSON parser. At this point we have working implementations in 5 different Smalltalk dialects written to use JSON for properties files. Cypress is designed to be flexible. FileTree the original Cypress implementation reads 3 different disk-based package. We're going to stick with the current implementation for the foreseeable future while we expend our effort on problems for which we don't have ready-made solutions. Hannes has the correct link for the latter discussion, but the original discussion took place at the beginning of Feb[1]. Dale [1] http://forum.world.st/feedback-on-using-JSON-to-specify-baselines-for-git-repository-td4356301.html ----- Original Message ----- | From: "Igor Stasenko" <siguc...@gmail.com> | To: Pharo-project@lists.gforge.inria.fr | Sent: Monday, April 23, 2012 2:34:54 PM | Subject: [Pharo-project] About Cypress [Was: Re: [ANN] Styled Text Editor for Cuis 4.0 Smalltalk] | | 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 <dhenr...@vmware.com> 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" <bernh...@pieber.com> | > | To: Pharo-project@lists.gforge.inria.fr | > | 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. | |
