On 24 April 2012 03:17, Dale Henrichs <[email protected]> wrote: > Igor, > > A lot of your questions/assertions were addressed in the two existing threads > ... > > Smalltalk parsers are not available in all Smalltalk dialects, so again, JSON > is and was a pragmatic choice, pure and simple. > what? how is that? smalltalk which cannot parse smalltalk? but can parse JSON? ;)
> The entire disk-based package structure has a number of warts of varying > sizes and qualities, but the one thing that is true is that we have 5 > Smalltalk dialects (with more coming) sharing the same package structure and > the same version control system ... something that has never been true before > and _that_ is the most important thing right now... > that's out of the question > Dale > > ----- Original Message ----- > | From: "Igor Stasenko" <[email protected]> > | To: [email protected] > | Sent: Monday, April 23, 2012 4:07:04 PM > | Subject: Re: [Pharo-project] About Cypress [Was: Re: [ANN] Styled Text > Editor for Cuis 4.0 Smalltalk] > | > | On 24 April 2012 01:54, Dale Henrichs <[email protected]> wrote: > | > 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. > | > > | umm.. what more work? Use if existing Smalltalk parser is more work? > | > | IMO, binding to JSON format and introducing dependency is more like a > | problem to me.. > | > | but anyways, since i late on party.. i don't wanna put sticks into > | already rotating wheel.. > | > | you made a decision, if it works for you, fine. > | > | P.S. I dealt with JSON when playing with SCouchDB project.. i > | wouldn't > | say that i adore this format. > | but it ok.. yeah.. everyone using it. Still s-expressions is IMO far > | more elegant. > | > | > | > 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" <[email protected]> > | > | To: [email protected] > | > | 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 <[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.
