On 4/24/12, Janko Mivšek <[email protected]> wrote: > Hi Igor, > > It is pretty clear that JSON is slowly replacing even XML elsewhere and > if I for instance have to chose between XML and JSON, I'd certainly > choose later. Our chunk format is, well, ours only. VW is using XML, > others are using anything else. Something as neutral and as simple as > JSON-based format can therefore become a bridge even between us. > > JSON is now becoming defacto standard for any interoperability scenario > in cloud world, so IMO Dale did a right decision to choose it. +1 We will > be much closer to other words with Smalltalk that way and even more by > using GitHub for code repository. +1
> Best regards > Janko > > > Dne 24. 04. 2012 01:07, piše Igor Stasenko: >> 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. >>> | >>> | >>> >> >> >> > > -- > Janko Mivšek > Aida/Web > Smalltalk Web Application Server > http://www.aidaweb.si > >
