Igor I completely agree and I propose to write a literal array platform independent parser but I gave up because this is discussion was emotional like let us JSON to attract people to Smalltalk wonderful idea.
I think that it is stupid to use another syntax for storing meta-data. Stef On Apr 24, 2012, at 1:07 AM, Igor Stasenko wrote: > 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. >
