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. > >
