Hello Igor This has been discussed on the Metacello mailing list on the 11 and 12th of this month.
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. > >
