Stef, ... JSON is and was a pragmatic choice... GemStone produces methods from source via a primitive call... it is what it is ... JSON is and was a pragmatic choice...
Dale ----- Original Message ----- | From: "Stéphane Ducasse" <[email protected]> | To: [email protected] | Sent: Monday, April 23, 2012 10:28:00 PM | Subject: Re: [Pharo-project] About Cypress [Was: Re: [ANN] Styled Text Editor for Cuis 4.0 Smalltalk] | | | On Apr 24, 2012, at 2:32 AM, Dale Henrichs wrote: | | > Igor, | > | > GemStone's Smalltalk parser/compiler is implemented in C … | | This puzzled me a lot: | so you cannot invoke it from Smalltalk? | | Then how do you compile code in Gemstome? Via the command line? | | As I said if this is only that we can write a parser for literal | array. | But yo should not say that you need a literal array syntax that | support dictionaries | because syntax and semantics are two different things. | (x 33) | (z 24) | can be binding for dictionary. | | Stef | | | > I told you that JSON is and was a pragmatic choice ... | > | > The seaside JSON parser is 27 methods and runs without change in | > GemStone ... this is all covered in the other two threads, so | > maybe you should spend some time reading up on the issues that | > have already been hashed over twice so far... Oh wait, now there | > are now three threads that are covering the "why JSON" question:) | > | > Dale | > | > ----- Original Message ----- | > | From: "Igor Stasenko" <[email protected]> | > | To: [email protected] | > | Sent: Monday, April 23, 2012 5:21:57 PM | > | Subject: Re: [Pharo-project] About Cypress [Was: Re: [ANN] Styled | > | Text Editor for Cuis 4.0 Smalltalk] | > | | > | 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. | > | | > | | > | | |
