Stef,
We are all on the same side ... I like to say that we are in "screaming
agreement"...
Dale
----- Original Message -----
| From: "Stéphane Ducasse" <stephane.duca...@inria.fr>
| To: Pharo-project@lists.gforge.inria.fr
| Sent: Tuesday, April 24, 2012 2:50:51 PM
| Subject: Re: [Pharo-project] About Cypress [Was: Re: [ANN] Styled Text
Editor for Cuis 4.0 Smalltalk]
|
| We will write a parser because we do not want a JSON syntax.
| I started and I will continue.
|
| Hannes I think that igor did a lot for us and that he knows probably
| more
| than you what is to work for the community. Because Igor could be
| working for Google
| right now without any problem. So let us appreciate to have guys like
| him in our community.
|
| Stef
|
| > Igor,
| >
| > Let me rephrase the context. It is that you started this thread
| > yesterday Monday Apr 23, 2012 at 11:34 .You said that you are not
| > pleased with storing Smalltalk meta data in JSON format.
| >
| > You gave the example
| >
| > {
| > "category" : "Cypress-Tests",
| > "classinstvars" : [
| > ],
| > "classtraitcomposition" : "{}",
| > "classvars" : [
| > ],
| > "commentStamp" : "",
| > "instvars" : [
| > ],
| > "name" : "CypressPatchTest",
| > "pools" : [
| > ],
| > "super" : "CypressAbstractTest",
| > "traitcomposition" : "{}",
| > "type" : "normal" }
| >
| > The cypress project URL is
| >
| > https://github.com/CampSmalltalk/Cypress
| >
| > This is Dale Henrichs' work.
| >
| > Cypress uses JSON for storing the meta data.
| >
| > There is a button called 'Fork' on the git hub project.
| >
| > Dale is willing to take arguments if they are based on code.
| > For many people JSON is fine.
| >
| > HTH :-)
| >
| > Hannes
| >
| > On 4/24/12, Igor Stasenko <siguc...@gmail.com> wrote:
| >> On 24 April 2012 14:17, Herby Vojčík <he...@mailbox.sk> wrote:
| >>>
| >>>
| >>> Igor Stasenko wrote:
| >>>>
| >>>> On 24 April 2012 11:54, Dale Henrichs<dhenr...@vmware.com>
| >>>> wrote:
| >>>>>
| >>>>> Stef,
| >>>>>
| >>>>> There is no Parser class and there is no Compiler class. There
| >>>>> is a
| >>>>> primitive call that takes method source, class,
| >>>>> methodDictionary, etc.
| >>>>> and
| >>>>> produces a method installed in the methodDictionary.
| >>>>>
| >>>> so you can take 1st literal from such method and you done. or
| >>>> you
| >>>> cannot access method's literals?
| >>>> it of course not as simple as parsing the source, but if you
| >>>> cannot
| >>>> avoid compilation..
| >>>>
| >>>>> ... JSON is and was a pragmatic choice...
| >>>>>
| >>>> well, i did not realized that GemStone have no own
| >>>> parser/compiler
| >>>> written in smalltalk.
| >>>
| >>>
| >>> Neither does Amber in deploy mode, unless I am mistaken.
| >>>
| >>> Why do you ever think there must be a Smalltalk parser in any
| >>> Smalltalk?
| >>> You
| >>> get used to it, I understand, but it is by no means a required
| >>> thing.
| >>> Smalltalk is Smalltalk without parser as well.
| >>>
| >>> JSON is great choice. Much better than anything proprietary,
| >>> because of
| >>> world-wide interoperability.
| >>>
| >>
| >> Sorry, but you seem even more out of the context than me.
| >> We're talking about tools for storing and loading smalltalk code..
| >> which implies having a working smalltalk
| >> parser and compiler toolchain.
| >> How else you can load smalltalk source code without having the way
| >> to parse
| >> it?
| >> If you don't parse nor compile it, it is just a bunch of letters.
| >>
| >>> Herby
| >>>
| >>
| >>
| >>
| >> --
| >> Best regards,
| >> Igor Stasenko.
| >>
| >>
| >
|
|
|
