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.
