About Cypress [Was: Re: [ANN] Styled Text Editor for Cuis 4.0 Smalltalk]

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
73 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Re: About Cypress [Was: Re: [ANN] Styled Text Editor for Cuis 4.0 Smalltalk]

Stéphane Ducasse
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 <[hidden email]> wrote:
>> On 24 April 2012 14:17, Herby Vojčík <[hidden email]> wrote:
>>>
>>>
>>> Igor Stasenko wrote:
>>>>
>>>> On 24 April 2012 11:54, Dale Henrichs<[hidden email]>  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.
>>
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: Tirade!

Stéphane Ducasse
In reply to this post by Göran Krampe
Give us a break!

Stef

On Apr 24, 2012, at 1:39 PM, Göran Krampe wrote:

> On 04/24/2012 01:06 PM, H. Hirzel wrote:
>> On 4/24/12, Igor Stasenko<[hidden email]>  wrote:
>>> can you name just one which can be useful in this context???
>>> what tools, except written in smalltalk and used by smalltalkers you
>>> are expecting to use
>>> with smalltalk source code stored in source code repositories?
>>
>> JavaScript  :-)  in connection with Amber. And couchDB.
>
> I do notice that Igor mentions a specific use case here, but let me ignore that and just reflect on JSON in general:
>
> And Riak. And quite a few other NoSQL dbs use JSON. And lots of RESTful RPC backends tend to use JSON, we do in our C# backend here at my customer. And almost all web APIs on the net use JSON.
>
> And JSON pops up everywhere in fact. So personally, while I did actually implement Tirade, JSON is still a very nice format due to its ubiquity.
>
> The main reason I made Tirade was because JSON didn't handle linefeeds in strings so I couldn't store source code in JSON in a reasonably readable way. At least not per true JSON spec.
>
> Also, Tirade supports more atomic Smalltalk datatypes. And since it encodes keyword messages it simply offers more structure than JSON does. And it is streamable. And perhaps one or two more things.
>
> But in summary - JSON is generally a very good choice and IMHO Pharo should be *great* at handling JSON. It's not going away :)
>
> regards, Göran
>


Reply | Threaded
Open this post in threaded view
|

Re: Tirade!

Stéphane Ducasse
In reply to this post by Göran Krampe
I saw and I started to extract parts that I need and writing some texts.

Stef


> On 04/24/2012 12:57 PM, Stéphane Ducasse wrote:
>> Ok I will have a look. Because it would solve our problem.
>
> I just added first stab at supporting literal arrays, the following works:
>
> (TiradeParser parse: 'keyword: #(1 3.4 ''asd'' #jupp 2).') last value first      print it =>
>
> #(1 3.4 'asd' #jupp 2)
>
> The "last value first" is just because the result from TiradeParser contains Associations between the keyword and an array of arguments. It could in fact return instances of Message, that might be nice :)
>
> ...but nesting needs a bit more thought since one can ommit the # when nesting literal arrays inside literal arrays.
>
> regards, Göran


Reply | Threaded
Open this post in threaded view
|

Re: Tirade!

Stéphane Ducasse
In reply to this post by Göran Krampe
Thanks.
I saw that #(tire ) is interpreted as true so I will check and improve that.

tef
On Apr 24, 2012, at 3:18 PM, Göran Krampe wrote:

> Ok, I spent some time adding support for literal arrays to Tirade.
> It probably has bugs and I haven't written tests for them but it does parse this correctly:
>
>
> (TiradeParser parse: 'keyword: #(1 -2 3.4 -4.5 ''asd'' (2 nil true false 3) #jupp jupp jupp:tup: #''ju li'' jup:tu 2).') last value first
>
> ...produces this:
>
> #(1 -2 3.4 -4.5 'asd' #(2 nil true false 3) #jupp #jupp #jupp:tup: #'ju li' #'jup:tu' 2)
>
> So it handles integers, floats, nil, true, false, nested literal arrays and symbols. In fact it does handle some more than a true literal array does since Tirade supports { bla . bla } arrays also (but only of literals) and also treats key -> value as a literal syntax.
>
> Thus for example these work too:
>
> (TiradeParser parse: 'keyword: #(1->2 3->#ad).') last value first
>
> (TiradeParser parse: 'keyword: #({2 . 4}).') last value first
>
>
> regards, Göran


Reply | Threaded
Open this post in threaded view
|

Re: Tirade!

Stéphane Ducasse
In reply to this post by Igor Stasenko
I do not think it works for gemstone because apparently they cannot access the parser
or at least wants to make sure that you cannot write code that can break the server
        scenario: you are mean that you write a strange meta data that is executed on the server
        so I will take tirade parser and make sure that we get one that only parse literal arrays.

On Apr 24, 2012, at 3:23 PM, Igor Stasenko wrote:

> Here the the snippet to parse array literals.. based on existing parser..
> i only had to add a #parseNode accessor to Parser to make it work:
>
>
> | parser|
> parser :=
> (Parser new
> init: '#(1 2 3 (ab bc de))' readStream notifying: nil failBlock: []
> ).
>
> parser encoder initScopeAndLiteralTables.
> parser primaryExpression.
> parser parseNode key
>
>
>
> On 24 April 2012 15:19, Stéphane Ducasse <[hidden email]> wrote:
>> goran could I extract the parser? and rename it in another package?
>>
>> Stef
>>
>> On Apr 24, 2012, at 12:00 PM, Göran Krampe wrote:
>>
>>> On 04/24/2012 11:52 AM, Göran Krampe wrote:
>>>> On 04/24/2012 11:51 AM, Göran Krampe wrote:
>>>>> On 04/24/2012 11:46 AM, Stéphane Ducasse wrote:
>>>>>> Where is the code?
>>>>>
>>>>> On SS. But it seems... down? Project is called "Tirade".
>>>>
>>>> http://www.squeaksource.com/Tirade.html
>>>
>>> Eh, oops. I just realized that TiradeParser uses dynamic arrays { } and does not have current support for literal Arrays. Duh. Sorry about that, but feel free to use the code anyways, adding #parseLiteralArray should not be hard.
>>>
>>> regards, Göran
>>>
>>
>>
>
>
>
> --
> Best regards,
> Igor Stasenko.
>


Reply | Threaded
Open this post in threaded view
|

Re: Tirade!

Dale Henrichs
In reply to this post by Stéphane Ducasse
Stef,

It is starting to look like STON will be a good option ... it has the advantage of having an existing implementation and provides much more functionality than a simple literal array parser ... Oh and it looks a lot like Smalltalk ...

BTW, I am still interested in seeing how Tirade would provide the same functionality as STON...

I suggest that you take a deep breath and relax a bit:)

Dale

----- Original Message -----
| From: "Stéphane Ducasse" <[hidden email]>
| To: [hidden email]
| Sent: Tuesday, April 24, 2012 2:52:05 PM
| Subject: Re: [Pharo-project] Tirade!
|
| Give us a break!
|
| Stef
|
| On Apr 24, 2012, at 1:39 PM, Göran Krampe wrote:
|
| > On 04/24/2012 01:06 PM, H. Hirzel wrote:
| >> On 4/24/12, Igor Stasenko<[hidden email]>  wrote:
| >>> can you name just one which can be useful in this context???
| >>> what tools, except written in smalltalk and used by smalltalkers
| >>> you
| >>> are expecting to use
| >>> with smalltalk source code stored in source code repositories?
| >>
| >> JavaScript  :-)  in connection with Amber. And couchDB.
| >
| > I do notice that Igor mentions a specific use case here, but let me
| > ignore that and just reflect on JSON in general:
| >
| > And Riak. And quite a few other NoSQL dbs use JSON. And lots of
| > RESTful RPC backends tend to use JSON, we do in our C# backend
| > here at my customer. And almost all web APIs on the net use JSON.
| >
| > And JSON pops up everywhere in fact. So personally, while I did
| > actually implement Tirade, JSON is still a very nice format due to
| > its ubiquity.
| >
| > The main reason I made Tirade was because JSON didn't handle
| > linefeeds in strings so I couldn't store source code in JSON in a
| > reasonably readable way. At least not per true JSON spec.
| >
| > Also, Tirade supports more atomic Smalltalk datatypes. And since it
| > encodes keyword messages it simply offers more structure than JSON
| > does. And it is streamable. And perhaps one or two more things.
| >
| > But in summary - JSON is generally a very good choice and IMHO
| > Pharo should be *great* at handling JSON. It's not going away :)
| >
| > regards, Göran
| >
|
|
|

Reply | Threaded
Open this post in threaded view
|

Re: About Cypress [Was: Re: [ANN] Styled Text Editor for Cuis 4.0 Smalltalk]

Dale Henrichs
In reply to this post by Stéphane Ducasse
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" <[hidden email]>
| To: [hidden email]
| 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 <[hidden email]> wrote:
| >> On 24 April 2012 14:17, Herby Vojčík <[hidden email]> wrote:
| >>>
| >>>
| >>> Igor Stasenko wrote:
| >>>>
| >>>> On 24 April 2012 11:54, Dale Henrichs<[hidden email]>
| >>>>  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.
| >>
| >>
| >
|
|
|

Reply | Threaded
Open this post in threaded view
|

Re: Tirade!

Stéphane Ducasse
In reply to this post by Dale Henrichs

On Apr 24, 2012, at 11:58 PM, Dale Henrichs wrote:

> Stef,
>
> It is starting to look like STON will be a good option ... it has the advantage of having an existing implementation and provides much more functionality than a simple literal array parser ... Oh and it looks a lot like Smalltalk ...
>
> BTW, I am still interested in seeing how Tirade would provide the same functionality as STON...
>
> I suggest that you take a deep breath and relax a bit:)

I see the advantage of ston to be able to specify class as in the
        Bitmap [
                        ]
        example

Now it means that we will have the parser of ston loaded to load code… :(
Ston can be a format for objects exchange but I still do not see why VW like literal arrays do not work.



> Dale
>
> ----- Original Message -----
> | From: "Stéphane Ducasse" <[hidden email]>
> | To: [hidden email]
> | Sent: Tuesday, April 24, 2012 2:52:05 PM
> | Subject: Re: [Pharo-project] Tirade!
> |
> | Give us a break!
> |
> | Stef
> |
> | On Apr 24, 2012, at 1:39 PM, Göran Krampe wrote:
> |
> | > On 04/24/2012 01:06 PM, H. Hirzel wrote:
> | >> On 4/24/12, Igor Stasenko<[hidden email]>  wrote:
> | >>> can you name just one which can be useful in this context???
> | >>> what tools, except written in smalltalk and used by smalltalkers
> | >>> you
> | >>> are expecting to use
> | >>> with smalltalk source code stored in source code repositories?
> | >>
> | >> JavaScript  :-)  in connection with Amber. And couchDB.
> | >
> | > I do notice that Igor mentions a specific use case here, but let me
> | > ignore that and just reflect on JSON in general:
> | >
> | > And Riak. And quite a few other NoSQL dbs use JSON. And lots of
> | > RESTful RPC backends tend to use JSON, we do in our C# backend
> | > here at my customer. And almost all web APIs on the net use JSON.
> | >
> | > And JSON pops up everywhere in fact. So personally, while I did
> | > actually implement Tirade, JSON is still a very nice format due to
> | > its ubiquity.
> | >
> | > The main reason I made Tirade was because JSON didn't handle
> | > linefeeds in strings so I couldn't store source code in JSON in a
> | > reasonably readable way. At least not per true JSON spec.
> | >
> | > Also, Tirade supports more atomic Smalltalk datatypes. And since it
> | > encodes keyword messages it simply offers more structure than JSON
> | > does. And it is streamable. And perhaps one or two more things.
> | >
> | > But in summary - JSON is generally a very good choice and IMHO
> | > Pharo should be *great* at handling JSON. It's not going away :)
> | >
> | > regards, Göran
> | >
> |
> |
> |
>


Reply | Threaded
Open this post in threaded view
|

Re: About Cypress [Was: Re: [ANN] Styled Text Editor for Cuis 4.0 Smalltalk]

Igor Stasenko
In reply to this post by Stéphane Ducasse
On 24 April 2012 23:50, Stéphane Ducasse <[hidden email]> wrote:
> 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, i see nothing disrespectful in Hannes reply.
Also, i'd prefer to be not put in a role of high authority. If i could
work on Google, it doesn't makes
any of my arguments stronger or weaker.

> 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 <[hidden email]> wrote:
>>> On 24 April 2012 14:17, Herby Vojčík <[hidden email]> wrote:
>>>>
>>>>
>>>> Igor Stasenko wrote:
>>>>>
>>>>> On 24 April 2012 11:54, Dale Henrichs<[hidden email]>  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.
>>>
>>>
>>
>
>



--
Best regards,
Igor Stasenko.

Reply | Threaded
Open this post in threaded view
|

Re: Tirade!

Göran Krampe
In reply to this post by Stéphane Ducasse
On 04/24/2012 11:52 PM, Stéphane Ducasse wrote:
> Give us a break!

I have all respect for you Stéphane but you really have a way with words
sometimes.

regards, Göran

Reply | Threaded
Open this post in threaded view
|

Re: About Cypress [Was: Re: [ANN] Styled Text Editor for Cuis 4.0 Smalltalk]

NorbertHartl
In reply to this post by Stéphane Ducasse


Am 24.04.2012 um 23:50 schrieb Stéphane Ducasse <[hidden email]>:

> 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, the last paragraph has an unfortunate ratio. The last sentence is fine but the first two are not. You have the right to be stubborn but I don't think you have the right to be so arrogant and unfair.

Norbert

>
>> 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 <[hidden email]> wrote:
>>> On 24 April 2012 14:17, Herby Vojčík <[hidden email]> wrote:
>>>>
>>>>
>>>> Igor Stasenko wrote:
>>>>>
>>>>> On 24 April 2012 11:54, Dale Henrichs<[hidden email]>  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.
>>>
>>>
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Tirade!

Stéphane Ducasse
In reply to this post by Göran Krampe
Yes! I agree with you.
Now let us make progress on that point.

On Apr 25, 2012, at 2:00 AM, Göran Krampe wrote:

> On 04/24/2012 11:52 PM, Stéphane Ducasse wrote:
>> Give us a break!
>
> I have all respect for you Stéphane but you really have a way with words sometimes.
>
> regards, Göran
>


Reply | Threaded
Open this post in threaded view
|

Re: About Cypress [Was: Re: [ANN] Styled Text Editor for Cuis 4.0 Smalltalk]

NorbertHartl
In reply to this post by Igor Stasenko


Am 25.04.2012 um 00:26 schrieb Igor Stasenko <[hidden email]>:

> On 24 April 2012 23:50, Stéphane Ducasse <[hidden email]> wrote:
>> 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, i see nothing disrespectful in Hannes reply.
> Also, i'd prefer to be not put in a role of high authority. If i could
> work on Google, it doesn't makes
> any of my arguments stronger or weaker.
>
Exactly. And google is no indicator of quality. Sure it is said that they hire the best ones. But first you need a certain degree in information science otherwise they won't employ you. It is that easy. To be honest the most clever guys I met in my life had no degree at all ;)

Norbert

>> 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 <[hidden email]> wrote:
>>>> On 24 April 2012 14:17, Herby Vojčík <[hidden email]> wrote:
>>>>>
>>>>>
>>>>> Igor Stasenko wrote:
>>>>>>
>>>>>> On 24 April 2012 11:54, Dale Henrichs<[hidden email]>  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.
>>>>
>>>>
>>>
>>
>>
>
>
>
> --
> Best regards,
> Igor Stasenko.
>

1234