Discussion:
[Pharo-project] About Cypress [Was: Re: [ANN] Styled Text Editor for Cuis 4.0 Smalltalk]
Igor Stasenko
2012-04-23 21:34:54 UTC
Permalink
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?
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.
?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" <bernhard at pieber.com>
| To: Pharo-project at lists.gforge.inria.fr
| 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
| 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.
|
| > Hi!
| >
| >>> 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.
H. Hirzel
2012-04-23 21:56:12 UTC
Permalink
Hello Igor

This has been discussed on the Metacello mailing list on the 11 and
12th of this month.

Regards
Hannes
Post by Igor Stasenko
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?
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.
?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" <bernhard at pieber.com>
| To: Pharo-project at lists.gforge.inria.fr
| 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
| 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.
|
| > Hi!
| >
| >>> 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.
Igor Stasenko
2012-04-23 22:10:52 UTC
Permalink
Post by H. Hirzel
Hello Igor
This has been discussed on the Metacello mailing list on the 11 and
12th of this month.
can you please give me a direct link to thread?
too much mails.. too much mails.
:)
Post by H. Hirzel
Regards
Hannes
Post by Igor Stasenko
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?
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.
?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" <bernhard at pieber.com>
| To: Pharo-project at lists.gforge.inria.fr
| 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
| 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.
|
| > Hi!
| >
| >>> 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.
H. Hirzel
2012-04-23 22:19:43 UTC
Permalink
You are right. It is hidden in another thread

http://forum.world.st/FileTree-and-Cypress-status-td4543773.html
'FileTree and Cypress status'

The basic outcome was that it is a matter of taste and that Dale does
not want to be bothered. In addition other Smalltalkers support it.
See signatures on photo at the bottom of
https://github.com/CampSmalltalk/Cypress/wiki

--Hannes
Post by Igor Stasenko
Post by H. Hirzel
Hello Igor
This has been discussed on the Metacello mailing list on the 11 and
12th of this month.
can you please give me a direct link to thread?
too much mails.. too much mails.
:)
Post by H. Hirzel
Regards
Hannes
Post by Igor Stasenko
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?
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.
?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" <bernhard at pieber.com>
| To: Pharo-project at lists.gforge.inria.fr
| 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
| 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.
|
| > Hi!
| >
| >>> 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.
Igor Stasenko
2012-04-23 22:57:45 UTC
Permalink
Oh, i'm not subscribed to that list.

Anyways..
since i late on the party.. just wanna put my 2 cents here:

you don't need a literal dictionary syntax to be able to (de)serialize
dictionaries.

Just a simple example:

we start from:

#( propertyName value )

ok, some values can be arrays:

#( propertyName ( array of values) )

and some values can be dictionaries:

#( propertyName #dict ( key1 value1 key2 value2 ... ) )

and to avoid ambugility, you can just put #symbol, to indicate that
next element is symbol:

#( propertyName #symbol #dict)

so it won't try to construct a dictionary, but just use #dict as a
symbol value for propery,
same for #symbol itself:

#(propertyName #symbol #symbol)

... and of course there can be numerous other ways for doing that.
Post by H. Hirzel
You are right. It is hidden in another thread
http://forum.world.st/FileTree-and-Cypress-status-td4543773.html
'FileTree and Cypress status'
The basic outcome was that it is a matter of taste and that Dale does
not want to be bothered. In addition other Smalltalkers support it.
See signatures on photo at the bottom of
https://github.com/CampSmalltalk/Cypress/wiki
--Hannes
Post by Igor Stasenko
Post by H. Hirzel
Hello Igor
This has been discussed on the Metacello mailing list on the 11 and
12th of this month.
can you please give me a direct link to thread?
too much mails.. too much mails.
:)
Post by H. Hirzel
Regards
Hannes
Post by Igor Stasenko
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?
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.
?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" <bernhard at pieber.com>
| To: Pharo-project at lists.gforge.inria.fr
| 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
| 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.
|
| > Hi!
| >
| >>> 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.
Igor Stasenko
2012-04-23 23:02:31 UTC
Permalink
Post by Igor Stasenko
Oh, i'm not subscribed to that list.
Anyways..
you don't need a literal dictionary syntax to be able to (de)serialize
dictionaries.
#( propertyName value )
#( propertyName ( array of values) )
#( propertyName #dict ( key1 value1 key2 value2 ... ) )
and to avoid ambugility, you can just put #symbol, to indicate that
#( propertyName #symbol #dict)
so it won't try to construct a dictionary, but just use #dict as a
symbol value for propery,
#(propertyName #symbol #symbol)
... and of course there can be numerous other ways for doing that.
and sure.. you're free to introduce any other keywords to meet your
needs... i.e.

#( top #point (10 20))
will produce:

{ #top. 10 at 20 }.
--
Best regards,
Igor Stasenko.
H. Hirzel
2012-04-23 23:12:35 UTC
Permalink
Yes, this was part of the discussion there.

--Hannes
Post by Igor Stasenko
Post by Igor Stasenko
Oh, i'm not subscribed to that list.
Anyways..
you don't need a literal dictionary syntax to be able to (de)serialize
dictionaries.
#( propertyName value )
#( propertyName ( array of values) )
#( propertyName #dict ( key1 value1 key2 value2 ... ) )
and to avoid ambugility, you can just put #symbol, to indicate that
#( propertyName #symbol #dict)
so it won't try to construct a dictionary, but just use #dict as a
symbol value for propery,
#(propertyName #symbol #symbol)
... and of course there can be numerous other ways for doing that.
and sure.. you're free to introduce any other keywords to meet your
needs... i.e.
#( top #point (10 20))
{ #top. 10 at 20 }.
--
Best regards,
Igor Stasenko.
Dale Henrichs
2012-04-23 22:54:13 UTC
Permalink
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.

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" <siguctua at gmail.com>
| To: Pharo-project at lists.gforge.inria.fr
| 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 <dhenrich at vmware.com> 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" <bernhard at pieber.com>
| > | To: Pharo-project at lists.gforge.inria.fr
| > | 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.
|
|
Igor Stasenko
2012-04-23 23:07:04 UTC
Permalink
Igor,
?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" <siguctua at gmail.com>
| To: Pharo-project at lists.gforge.inria.fr
| 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?
|
| > 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.
| >
| >
| > ?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" <bernhard at pieber.com>
| > | To: Pharo-project at lists.gforge.inria.fr
| > | 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
| > | 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.
| > |
| > | > Hi!
| > | >
| > | >>> 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.
Stéphane Ducasse
2012-04-24 05:25:01 UTC
Permalink
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
Post by Igor Stasenko
Post by Dale Henrichs
Igor,
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.
Post by Dale Henrichs
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" <siguctua at gmail.com>
| To: Pharo-project at lists.gforge.inria.fr
| 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?
|
| > 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.
| >
| >
| > 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" <bernhard at pieber.com>
| > | To: Pharo-project at lists.gforge.inria.fr
| > | 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
| > | 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.
| > |
| > | > Hi!
| > | >
| > | >>> 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.
Göran Krampe
2012-04-24 06:58:00 UTC
Permalink
Post by Stéphane Ducasse
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.
And yet again I point to Tirade :)

http://goran.krampe.se/blog/Squeak/Tirade.rdoc
http://goran.krampe.se/blog/Squeak/Tirade2.rdoc
http://goran.krampe.se/blog/Squeak/Tirade3.rdoc

Especially Tirade2 above shows a bit about size (4 classes, 500 loc)
speed and portability. Tirade is basically a parser for Smalltalk
messages that only are allowed to use literals as arguments (although
arbitrarily nested literals).

Which is exactly what Stef describes + a bit more. :)

regards, G?ran
Sven Van Caekenberghe
2012-04-24 08:04:27 UTC
Permalink
Post by Göran Krampe
And yet again I point to Tirade :)
http://goran.krampe.se/blog/Squeak/Tirade.rdoc
http://goran.krampe.se/blog/Squeak/Tirade2.rdoc
http://goran.krampe.se/blog/Squeak/Tirade3.rdoc
Especially Tirade2 above shows a bit about size (4 classes, 500 loc) speed and portability. Tirade is basically a parser for Smalltalk messages that only are allowed to use literals as arguments (although arbitrarily nested literals).
Which is exactly what Stef describes + a bit more. :)
Yeah, I remember reading that a long time ago. It is indeed a cool idea, G?ran. Reminds me of the Erlang related UBF (http://www.sics.se/~joe/ubf/site/home.html).

I think the JSON choise is not bad: it is simple and universally accepted.

Sven
Göran Krampe
2012-04-24 08:15:10 UTC
Permalink
Post by Sven Van Caekenberghe
Post by Göran Krampe
And yet again I point to Tirade :)
http://goran.krampe.se/blog/Squeak/Tirade.rdoc
http://goran.krampe.se/blog/Squeak/Tirade2.rdoc
http://goran.krampe.se/blog/Squeak/Tirade3.rdoc
Especially Tirade2 above shows a bit about size (4 classes, 500 loc) speed and portability. Tirade is basically a parser for Smalltalk messages that only are allowed to use literals as arguments (although arbitrarily nested literals).
Which is exactly what Stef describes + a bit more. :)
Yeah, I remember reading that a long time ago. It is indeed a cool idea, G?ran. Reminds me of the Erlang related UBF (http://www.sics.se/~joe/ubf/site/home.html).
I think the JSON choise is not bad: it is simple and universally accepted.
Sven
Yeah, personally I am not upset over JSON - but if one would really want
something more Smalltalkish - then Tirade is exactly that IMHO.

regards, G?ran
Stéphane Ducasse
2012-04-24 09:10:51 UTC
Permalink
Post by Sven Van Caekenberghe
Post by Göran Krampe
And yet again I point to Tirade :)
http://goran.krampe.se/blog/Squeak/Tirade.rdoc
http://goran.krampe.se/blog/Squeak/Tirade2.rdoc
http://goran.krampe.se/blog/Squeak/Tirade3.rdoc
Especially Tirade2 above shows a bit about size (4 classes, 500 loc) speed and portability. Tirade is basically a parser for Smalltalk messages that only are allowed to use literals as arguments (although arbitrarily nested literals).
Which is exactly what Stef describes + a bit more. :)
Yeah, I remember reading that a long time ago. It is indeed a cool idea, G?ran. Reminds me of the Erlang related UBF (http://www.sics.se/~joe/ubf/site/home.html).
I think the JSON choise is not bad: it is simple and universally accepted.
But you can express **EXACTLY** the same with
#(


)

So what is the point?

Stef
Tobias Pape
2012-04-24 09:21:37 UTC
Permalink
Post by Stéphane Ducasse
But you can express **EXACTLY** the same with
#(
)
So what is the point?
You can do stuff with it outside an image?

Best
-Tobias
Stéphane Ducasse
2012-04-24 09:27:55 UTC
Permalink
Post by Tobias Pape
Post by Stéphane Ducasse
But you can express **EXACTLY** the same with
#(
)
So what is the point?
You can do stuff with it outside an image?
Why not?
I have problem to get all the meta-data of our system getting stored in
a foreign language. This means that I will also have to have this parser
while we have one that is working.

In that case why not saving Smalltalk methods in Javascript syntax.
Because this is basically what is happening with the class definition.


Stef
Norbert Hartl
2012-04-24 09:24:35 UTC
Permalink
Post by Stéphane Ducasse
Post by Sven Van Caekenberghe
Post by Göran Krampe
And yet again I point to Tirade :)
http://goran.krampe.se/blog/Squeak/Tirade.rdoc
http://goran.krampe.se/blog/Squeak/Tirade2.rdoc
http://goran.krampe.se/blog/Squeak/Tirade3.rdoc
Especially Tirade2 above shows a bit about size (4 classes, 500 loc) speed and portability. Tirade is basically a parser for Smalltalk messages that only are allowed to use literals as arguments (although arbitrarily nested literals).
Which is exactly what Stef describes + a bit more. :)
Yeah, I remember reading that a long time ago. It is indeed a cool idea, G?ran. Reminds me of the Erlang related UBF (http://www.sics.se/~joe/ubf/site/home.html).
I think the JSON choise is not bad: it is simple and universally accepted.
But you can express **EXACTLY** the same with
#(
)
So what is the point?
The two points are still the same, Stef. The lesser important point was the absence of a cross platform parser for that format. Here I understand Dale. He spawns of project after project that depend on each other. I think he is not willing to yet postpone this project only to create such a parser when there is a usable alternativ. Others might create it and convince him afterwards which isn't very difficult if I take my experience until now. That would be the easier part.
The harder part is security. The security standpoints always divide between white lists and black lists. Meaning a white list forbids everything and allows things on a white list. Or vice versa you allow everything and put things you don't like on a black list. Having a Smalltalk format means I have two options: "Read and parse it" or "Read and evaluate it". As far as I understand Dale he sees a big problem if people just evaluate configurations which contain bogus code. It is just so easy to introduce code that borkes your system.
While I really can understand the security concerns I personally think that having two options is better. The standard tools should just take parse route.

Norbert
Stéphane Ducasse
2012-04-24 09:43:03 UTC
Permalink
Post by Norbert Hartl
The two points are still the same, Stef. The lesser important point was the absence of a cross platform parser for that format. Here I understand Dale. He spawns of project after project that depend on each other. I think he is not willing to yet postpone this project only to create such a parser when there is a usable alternativ. Others might create it and convince him afterwards which isn't very difficult if I take my experience until now. That would be the easier part.
The harder part is security. The security standpoints always divide between white lists and black lists. Meaning a white list forbids everything and allows things on a white list. Or vice versa you allow everything and put things you don't like on a black list. Having a Smalltalk format means I have two options: "Read and parse it" or "Read and evaluate it". As far as I understand Dale he sees a big problem if people just evaluate configurations which contain bogus code. It is just so easy to introduce code that borkes your system.
While I really can understand the security concerns I personally think that having two options is better. The standard tools should just take parse route.
I will develop a literal parser and this is solved.
No security hole no JSON. Easy.
Sven Van Caekenberghe
2012-04-24 09:25:29 UTC
Permalink
Post by Stéphane Ducasse
Post by Sven Van Caekenberghe
Post by Göran Krampe
And yet again I point to Tirade :)
http://goran.krampe.se/blog/Squeak/Tirade.rdoc
http://goran.krampe.se/blog/Squeak/Tirade2.rdoc
http://goran.krampe.se/blog/Squeak/Tirade3.rdoc
Especially Tirade2 above shows a bit about size (4 classes, 500 loc) speed and portability. Tirade is basically a parser for Smalltalk messages that only are allowed to use literals as arguments (although arbitrarily nested literals).
Which is exactly what Stef describes + a bit more. :)
Yeah, I remember reading that a long time ago. It is indeed a cool idea, G?ran. Reminds me of the Erlang related UBF (http://www.sics.se/~joe/ubf/site/home.html).
I think the JSON choise is not bad: it is simple and universally accepted.
But you can express **EXACTLY** the same with
#(
)
So what is the point?
Stef
Yes, you are right, they are technically mostly equivalent. (JSON has simpler primitive types, clear escapes, lists/arrays and maps/dictionaries).

But the point is, there are so many formats out there, and everybody likes to make there own.

If you pick JSON, the discussion ends. It is an RFC standard.
If you pick something that looks suspiciously like some (for most people) weird programming language you will get discussions, always.

Dale said so: it is a pragmatic choice.

Now, given the fact that the domain here is Smalltalk anyway, there is something to say for using a Smalltalk based representation.

But then you need to write a clear spec and a non-compiler based parser.

With the JSON meta data, you could envision other non-Smalltalk tools using it more easily.

Sven

--
Sven Van Caekenberghe
http://stfx.eu
Smalltalk is the Red Pill
Göran Krampe
2012-04-24 09:33:56 UTC
Permalink
Post by Sven Van Caekenberghe
But then you need to write a clear spec and a non-compiler based parser.
Ok, perhaps you all understood this from my links etc, but Tirade *is* a
non-compiler based parser. It *is* safe. It only allows literals. It is
*much* faster than the Compiler. It is very small, code is simple and it
is trivial to port to ANY Smalltalk.

Now, for the other arguments - I agree, JSON is "good enough" for many
things and universally accepted in almost all camps these days. Just
don't want people to reinvent Tirade :)

regards, G?ran
Stéphane Ducasse
2012-04-24 09:46:00 UTC
Permalink
Where is the code?
Do you have tests?
Can we extract a parser for literal array?

Stef
Post by Sven Van Caekenberghe
But then you need to write a clear spec and a non-compiler based parser.
Ok, perhaps you all understood this from my links etc, but Tirade *is* a non-compiler based parser. It *is* safe. It only allows literals. It is *much* faster than the Compiler. It is very small, code is simple and it is trivial to port to ANY Smalltalk.
Now, for the other arguments - I agree, JSON is "good enough" for many things and universally accepted in almost all camps these days. Just don't want people to reinvent Tirade :)
regards, G?ran
Göran Krampe
2012-04-24 09:51:20 UTC
Permalink
Post by Stéphane Ducasse
Where is the code?
On SS. But it seems... down? Project is called "Tirade".
Post by Stéphane Ducasse
Do you have tests?
Yes, IIRC I do. Perhaps not as many as one would like. Did you check my
articles I posted links to?
Post by Stéphane Ducasse
Can we extract a parser for literal array?
Yes, should be trivial.
Post by Stéphane Ducasse
Stef
regards, G?ran
Göran Krampe
2012-04-24 09:52:39 UTC
Permalink
Post by Göran Krampe
Post by Stéphane Ducasse
Where is the code?
On SS. But it seems... down? Project is called "Tirade".
http://www.squeaksource.com/Tirade.html

regards, G?ran
Göran Krampe
2012-04-24 10:00:28 UTC
Permalink
Post by Göran Krampe
Post by Göran Krampe
Post by Stéphane Ducasse
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
Stéphane Ducasse
2012-04-24 10:57:10 UTC
Permalink
Ok I will have a look. Because it would solve our problem.

Stef
Post by Göran Krampe
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
Göran Krampe
2012-04-24 12:02:00 UTC
Permalink
Post by Stéphane Ducasse
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
Göran Krampe
2012-04-24 13:18:49 UTC
Permalink
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
Stéphane Ducasse
2012-04-24 21:54:05 UTC
Permalink
Thanks.
I saw that #(tire ) is interpreted as true so I will check and improve that.

tef
Post by Göran Krampe
Ok, I spent some time adding support for literal arrays to Tirade.
(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
#(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.
(TiradeParser parse: 'keyword: #(1->2 3->#ad).') last value first
(TiradeParser parse: 'keyword: #({2 . 4}).') last value first
regards, G?ran
Stéphane Ducasse
2012-04-24 21:52:59 UTC
Permalink
I saw and I started to extract parts that I need and writing some texts.

Stef
Post by Stéphane Ducasse
Ok I will have a look. Because it would solve our problem.
(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
Stéphane Ducasse
2012-04-24 13:19:34 UTC
Permalink
goran could I extract the parser? and rename it in another package?

Stef
Post by Göran Krampe
Post by Göran Krampe
Post by Stéphane Ducasse
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
Igor Stasenko
2012-04-24 13:23:59 UTC
Permalink
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
Post by Stéphane Ducasse
goran could I extract the parser? and rename it in another package?
Stef
Post by Göran Krampe
Post by Göran Krampe
Post by Stéphane Ducasse
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.
Göran Krampe
2012-04-24 13:30:28 UTC
Permalink
Post by Igor Stasenko
Here the the snippet to parse array literals.. based on existing parser..
| parser|
parser :=
(Parser new
init: '#(1 2 3 (ab bc de))' readStream notifying: nil failBlock: []
).
parser encoder initScopeAndLiteralTables.
parser primaryExpression.
parser parseNode key
Looks neat. Now, this of course still raises the question - shouldn't we
try to move further with our literal arrays?

As I mentioned, in Tirade I added support for Associations. So I can do:

{ 'name'->'Igor' }

...without adding full support for expressions. This was to "match"
JSON. It will still produce an Array of Associations, but then I can
easily change that to a Dictionary on the receiving end.

In Amber Nicolas has added this syntax for literal dictionaries:

#{ 'name' -> 'Igor'}

regards, G?ran
Stéphane Ducasse
2012-04-24 21:56:43 UTC
Permalink
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.
Post by Igor Stasenko
Here the the snippet to parse array literals.. based on existing parser..
| parser|
parser :=
(Parser new
init: '#(1 2 3 (ab bc de))' readStream notifying: nil failBlock: []
).
parser encoder initScopeAndLiteralTables.
parser primaryExpression.
parser parseNode key
Post by Stéphane Ducasse
goran could I extract the parser? and rename it in another package?
Stef
Post by Göran Krampe
Post by Göran Krampe
Post by Stéphane Ducasse
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.
Göran Krampe
2012-04-24 13:24:12 UTC
Permalink
Post by Stéphane Ducasse
goran could I extract the parser? and rename it in another package?
Yeah, sure, it is a "classic" recursive descent parser with a hereChar
ivar etc. Code is MIT, feel free to grab.

And feel free to ask any and all questions :)

regards, G?ran
Stéphane Ducasse
2012-04-24 09:45:06 UTC
Permalink
Post by Sven Van Caekenberghe
Yes, you are right, they are technically mostly equivalent. (JSON has simpler primitive types, clear escapes, lists/arrays and maps/dictionaries).
But the point is, there are so many formats out there, and everybody likes to make there own.
If you pick JSON, the discussion ends. It is an RFC standard.
If you pick something that looks suspiciously like some (for most people) weird programming language you will get discussions, always.
Dale said so: it is a pragmatic choice.
Now, given the fact that the domain here is Smalltalk anyway, there is something to say for using a Smalltalk based representation.
But then you need to write a clear spec and a non-compiler based parser.
Let us do it.
Post by Sven Van Caekenberghe
With the JSON meta data, you could envision other non-Smalltalk tools using it more easily.
Do you want to build our tools in Javascript or other languages?
Because we are talking about class definition and smalltalk meta data itself.
H. Hirzel
2012-04-24 10:50:42 UTC
Permalink
Post by Sven Van Caekenberghe
Post by Stéphane Ducasse
Post by Sven Van Caekenberghe
Post by Göran Krampe
And yet again I point to Tirade :)
http://goran.krampe.se/blog/Squeak/Tirade.rdoc
http://goran.krampe.se/blog/Squeak/Tirade2.rdoc
http://goran.krampe.se/blog/Squeak/Tirade3.rdoc
Especially Tirade2 above shows a bit about size (4 classes, 500 loc)
speed and portability. Tirade is basically a parser for Smalltalk
messages that only are allowed to use literals as arguments (although
arbitrarily nested literals).
Which is exactly what Stef describes + a bit more. :)
Yeah, I remember reading that a long time ago. It is indeed a cool idea,
G?ran. Reminds me of the Erlang related UBF
(http://www.sics.se/~joe/ubf/site/home.html).
I think the JSON choise is not bad: it is simple and universally accepted.
But you can express **EXACTLY** the same with
#(
)
So what is the point?
Stef
Yes, you are right, they are technically mostly equivalent. (JSON has
simpler primitive types, clear escapes, lists/arrays and maps/dictionaries).
But the point is, there are so many formats out there, and everybody likes
to make there own.
If you pick JSON, the discussion ends. It is an RFC standard.
+1
Post by Sven Van Caekenberghe
If you pick something that looks suspiciously like some (for most people)
weird programming language you will get discussions, always.
Dale said so: it is a pragmatic choice.
+1
Post by Sven Van Caekenberghe
Now, given the fact that the domain here is Smalltalk anyway, there is
something to say for using a Smalltalk based representation.
But then you need to write a clear spec and a non-compiler based parser.
With the JSON meta data, you could envision other non-Smalltalk tools using it more easily.
+1
Post by Sven Van Caekenberghe
Sven
--
Sven Van Caekenberghe
http://stfx.eu
Smalltalk is the Red Pill
Igor Stasenko
2012-04-24 10:58:42 UTC
Permalink
Post by Sven Van Caekenberghe
Post by Stéphane Ducasse
Post by Sven Van Caekenberghe
Post by Göran Krampe
And yet again I point to Tirade :)
http://goran.krampe.se/blog/Squeak/Tirade.rdoc
http://goran.krampe.se/blog/Squeak/Tirade2.rdoc
http://goran.krampe.se/blog/Squeak/Tirade3.rdoc
Especially Tirade2 above shows a bit about size (4 classes, 500 loc)
speed and portability. Tirade is basically a parser for Smalltalk
messages that only are allowed to use literals as arguments (although
arbitrarily nested literals).
Which is exactly what Stef describes + a bit more. :)
Yeah, I remember reading that a long time ago. It is indeed a cool idea,
G?ran. Reminds me of the Erlang related UBF
(http://www.sics.se/~joe/ubf/site/home.html).
I think the JSON choise is not bad: it is simple and universally accepted.
But you can express **EXACTLY** the same with
? ? ?#(
? ? ? ? ? ? ?)
So what is the point?
Stef
Yes, you are right, they are technically mostly equivalent. (JSON has
simpler primitive types, clear escapes, lists/arrays and maps/dictionaries).
But the point is, there are so many formats out there, and everybody likes
to make there own.
If you pick JSON, the discussion ends. It is an RFC standard.
If you pick smalltalk , it is ansi standard.. so.. what the point?
+1
Post by Sven Van Caekenberghe
If you pick something that looks suspiciously like some (for most people)
weird programming language you will get discussions, always.
Dale said so: it is a pragmatic choice.
+1
Post by Sven Van Caekenberghe
Now, given the fact that the domain here is Smalltalk anyway, there is
something to say for using a Smalltalk based representation.
But then you need to write a clear spec and a non-compiler based parser.
With the JSON meta data, you could envision other non-Smalltalk tools using
it more easily.
+1
this is killer argument ;)

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?


Sorry, the only valid and understandable argument here to me, is that
it is purely pragmatic choice :)
--
Best regards,
Igor Stasenko.
H. Hirzel
2012-04-24 11:06:07 UTC
Permalink
Post by Igor Stasenko
Post by Sven Van Caekenberghe
Post by Stéphane Ducasse
Post by Sven Van Caekenberghe
Post by Göran Krampe
And yet again I point to Tirade :)
http://goran.krampe.se/blog/Squeak/Tirade.rdoc
http://goran.krampe.se/blog/Squeak/Tirade2.rdoc
http://goran.krampe.se/blog/Squeak/Tirade3.rdoc
Especially Tirade2 above shows a bit about size (4 classes, 500 loc)
speed and portability. Tirade is basically a parser for Smalltalk
messages that only are allowed to use literals as arguments (although
arbitrarily nested literals).
Which is exactly what Stef describes + a bit more. :)
Yeah, I remember reading that a long time ago. It is indeed a cool idea,
G?ran. Reminds me of the Erlang related UBF
(http://www.sics.se/~joe/ubf/site/home.html).
I think the JSON choise is not bad: it is simple and universally accepted.
But you can express **EXACTLY** the same with
#(
)
So what is the point?
Stef
Yes, you are right, they are technically mostly equivalent. (JSON has
simpler primitive types, clear escapes, lists/arrays and
maps/dictionaries).
But the point is, there are so many formats out there, and everybody likes
to make there own.
If you pick JSON, the discussion ends. It is an RFC standard.
If you pick smalltalk , it is ansi standard.. so.. what the point?
+1
There is already a documentation of the format. No additional work needed.
Post by Igor Stasenko
Post by Sven Van Caekenberghe
If you pick something that looks suspiciously like some (for most people)
weird programming language you will get discussions, always.
Dale said so: it is a pragmatic choice.
+1
Post by Sven Van Caekenberghe
Now, given the fact that the domain here is Smalltalk anyway, there is
something to say for using a Smalltalk based representation.
But then you need to write a clear spec and a non-compiler based parser.
With the JSON meta data, you could envision other non-Smalltalk tools using
it more easily.
+1
this is killer argument ;)
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.
Post by Igor Stasenko
Sorry, the only valid and understandable argument here to me, is that
it is purely pragmatic choice :)
And as Dale writes. It is already implemented in different dialects of
Smalltalk.

Thank you for asking

Hannes
Post by Igor Stasenko
--
Best regards,
Igor Stasenko.
Göran Krampe
2012-04-24 11:39:53 UTC
Permalink
Post by H. Hirzel
Post by Igor Stasenko
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
Stéphane Ducasse
2012-04-24 21:52:05 UTC
Permalink
Give us a break!

Stef
Post by H. Hirzel
Post by Igor Stasenko
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.
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
Göran Krampe
2012-04-25 00:00:15 UTC
Permalink
Post by Stéphane Ducasse
Give us a break!
I have all respect for you St?phane but you really have a way with words
sometimes.

regards, G?ran
Stéphane Ducasse
2012-04-25 06:51:57 UTC
Permalink
Yes! I agree with you.
Now let us make progress on that point.
Post by Stéphane Ducasse
Give us a break!
I have all respect for you St?phane but you really have a way with words sometimes.
regards, G?ran
Francisco Garau
2012-04-24 07:45:52 UTC
Permalink
Hi Stef - you know I like you and appreciate how much you are doing for
Pharo and the Smalltalk community.

But when I read comments like this... I think you are shooting yourself in
the foot!

The last sentence is the one I am talking about: you cannot say decision is
"stupid". I think you are showing your emotions there... and funny that you
previously said the JSON vs Literal discussion had been emotional.

You are our benevolent dictator.

Please, be a little bit more diplomatic in your emails!

- Francisco
Post by Stéphane Ducasse
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20120424/d1636dec/attachment.html>
Norbert Hartl
2012-04-24 07:58:18 UTC
Permalink
Hi Stef - you know I like you and appreciate how much you are doing for Pharo and the Smalltalk community.
But when I read comments like this... I think you are shooting yourself in the foot!
The last sentence is the one I am talking about: you cannot say decision is "stupid". I think you are showing your emotions there... and funny that you previously said the JSON vs Literal discussion had been emotional.
Well, he said it was emotional. He just didn't tell who was emotional :)
You are our benevolent dictator.
Please, be a little bit more diplomatic in your emails!
But he is french, he is supposed to say: NO! :)

Basically I think you are right. But then I think we shouldn't be too hard to ourselves. And I'm sure Dale is not offended by that. So where is the problem?

Norbert
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20120424/ea9949a9/attachment.html>
Esteban Lorenzano
2012-04-24 08:08:05 UTC
Permalink
oh, come on guys!

Infinite threads asking to be polite are even worst than the supposed "troll" emails... slow down, pleeeeeeease.
we are going to die intoxicated by susceptibility :)

Esteban
Post by Norbert Hartl
Hi Stef - you know I like you and appreciate how much you are doing for Pharo and the Smalltalk community.
But when I read comments like this... I think you are shooting yourself in the foot!
The last sentence is the one I am talking about: you cannot say decision is "stupid". I think you are showing your emotions there... and funny that you previously said the JSON vs Literal discussion had been emotional.
Well, he said it was emotional. He just didn't tell who was emotional :)
You are our benevolent dictator.
Please, be a little bit more diplomatic in your emails!
But he is french, he is supposed to say: NO! :)
Basically I think you are right. But then I think we shouldn't be too hard to ourselves. And I'm sure Dale is not offended by that. So where is the problem?
Norbert
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20120424/0c19395d/attachment.html>
phil
2012-04-24 08:36:57 UTC
Permalink
These discussions just sound like what I see happening at clients places
all the time... Unless someone keeps the thing straight, this is just
burning cash and time and getting nowhere.

Diplomacy and software do not work together. The computer doesn't care.

What works is software and marketing. That's different.

Phil

2012/4/24 Francisco Garau <francisco.garau at gmail.com>
Post by Francisco Garau
Hi Stef - you know I like you and appreciate how much you are doing for
Pharo and the Smalltalk community.
But when I read comments like this... I think you are shooting yourself in
the foot!
The last sentence is the one I am talking about: you cannot say decision
is "stupid". I think you are showing your emotions there... and funny that
you previously said the JSON vs Literal discussion had been emotional.
You are our benevolent dictator.
Please, be a little bit more diplomatic in your emails!
- Francisco
Post by Stéphane Ducasse
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
--
Philippe Back
"Helping you hit the top 3 outcomes you really want to achieve"

Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:
phil at highoctane.be| Web:
http://philippeback.eu | Blog:
http://philippeback.be

High Octane SPRL
rue cour Boisacq 101
1301 Bierges
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20120424/80e09cdf/attachment.html>
Stéphane Ducasse
2012-04-24 08:42:09 UTC
Permalink
Francisco

Sorry but you do not know. Read the mails I sent in the past in the metacello mailing-list.
We use literal arrays to represent Moose models since years and it works well.

So my mail is not emotional. I already mentioned facts in the metacello mailing-list.

Stef
Hi Stef - you know I like you and appreciate how much you are doing for Pharo and the Smalltalk community.
But when I read comments like this... I think you are shooting yourself in the foot!
The last sentence is the one I am talking about: you cannot say decision is "stupid". I think you are showing your emotions there... and funny that you previously said the JSON vs Literal discussion had been emotional.
You are our benevolent dictator.
Please, be a little bit more diplomatic in your emails!
- Francisco
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
Janko Mivšek
2012-04-24 09:59:04 UTC
Permalink
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. We will
be much closer to other words with Smalltalk that way and even more by
using GitHub for code repository.

Best regards
Janko
Post by Igor Stasenko
Post by Dale Henrichs
Igor,
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.
Post by Dale Henrichs
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" <siguctua at gmail.com>
| To: Pharo-project at lists.gforge.inria.fr
| 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?
|
| > 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.
| >
| >
| > 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" <bernhard at pieber.com>
| > | To: Pharo-project at lists.gforge.inria.fr
| > | 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
| > | 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.
| > |
| > | > Hi!
| > | >
| > | >>> 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
H. Hirzel
2012-04-24 10:46:18 UTC
Permalink
Post by Janko Mivšek
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
Post by Janko Mivšek
be much closer to other words with Smalltalk that way and even more by
using GitHub for code repository.
+1
Post by Janko Mivšek
Best regards
Janko
Post by Igor Stasenko
Post by Dale Henrichs
Igor,
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.
Post by Dale Henrichs
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" <siguctua at gmail.com>
| To: Pharo-project at lists.gforge.inria.fr
| 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?
|
| > 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.
| >
| >
| > 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" <bernhard at pieber.com>
| > | To: Pharo-project at lists.gforge.inria.fr
| > | 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
| > | 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.
| > |
| > | > Hi!
| > | >
| > | >>> 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
Stéphane Ducasse
2012-04-24 10:53:10 UTC
Permalink
Post by Janko Mivšek
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.
In a really really bad way. Because the tags are used in a non sense way.
You still have to parse method to get the selector :) So VW is far from
an example. And we are not talking about the method format, just method metadata.
Post by Janko Mivšek
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. We will
be much closer to other words with Smalltalk that way
Not at all. Do you really think that somebody will be interested by Smalltalk just because
metadata of methods are stored in JSON :)
Come on.
Post by Janko Mivšek
and even more by
using GitHub for code repository.
Igor Stasenko
2012-04-24 11:02:32 UTC
Permalink
Post by Stéphane Ducasse
Post by Janko Mivšek
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.
In a really really bad way. Because the tags are used in a non sense way.
You still have to parse method to get the selector :) So VW is far from
an example. And we are not talking about the method format, just method metadata.
Post by Janko Mivšek
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. We will
be much closer to other words with Smalltalk that way
Not at all. Do you really think that somebody will be interested by Smalltalk just because
metadata of methods are stored in JSON :)
Come on.
yeah. lets store our metadata in SQL syntax.. so we are closer to SQL
databases..
LOL :)
Post by Stéphane Ducasse
Post by Janko Mivšek
and even more by
using GitHub for code repository.
--
Best regards,
Igor Stasenko.
Igor Stasenko
2012-04-24 11:36:51 UTC
Permalink
you know, it is like C and their makefiles..
in C world they cannot express the project metadata using C syntax..
that's why they using this weird
makefiles (and many other .project formats) to glue things together..
But hey, we can express things in smalltalk. So, why adding extra tool
to the toolchain?

My point is not about whether it is better to use JSON over another
format. My point is that we can use smalltalk all the way down.
Because it means less dependencies and simpler tool chain (you need to
have only smalltalk parser to handle everything stored in your files,
and no extra stuff).
Because tomorrow, other guy could say: hey i love xml and i want to
store this in xml.. and provide same arguments:
it is used worldwide, and can be used for interoperability with other
languages... and so on, so on.
And he will be totally right, except from the fact that we don't need it.

My argument is purely pragmatic: it is better having just one parser
to parse all data than two or more.
More formats, more syntax(es) means more things to worry about, and maintain.
Post by Igor Stasenko
Post by Stéphane Ducasse
Post by Janko Mivšek
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.
In a really really bad way. Because the tags are used in a non sense way.
You still have to parse method to get the selector :) So VW is far from
an example. And we are not talking about the method format, just method metadata.
Post by Janko Mivšek
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. We will
be much closer to other words with Smalltalk that way
Not at all. Do you really think that somebody will be interested by Smalltalk just because
metadata of methods are stored in JSON :)
Come on.
yeah. lets store our metadata in SQL syntax.. so we are closer to SQL
databases..
LOL :)
Post by Stéphane Ducasse
Post by Janko Mivšek
and even more by
using GitHub for code repository.
--
Best regards,
Igor Stasenko.
--
Best regards,
Igor Stasenko.
H. Hirzel
2012-04-24 12:01:46 UTC
Permalink
In this sense I agree with you, Igor, and I actually had your
position in the discussion on the 11th and 12 April on the metacello
list (I made a small example as you, and I added XML as a third
option)

As I am not going to implement neither JSON, nor XML nor a Smalltalk
solution I have to say that anything is fine for me.

However the discussion is about Cypress and the project is moving on.
See
https://github.com/CampSmalltalk/Cypress/wiki

--Hannes


===========================================================
For ease of Reference here the full email of Dale from April 12th, 2012

See my emphasis with +++++++++++++++++
===========================================================



Guys, Guys, Guys... this is my last post on this topic ...

I have not read any of the overnight posts ...

I am not interested in talking about what format the property files should use.

I made the decision (weeks ago) and no amount of arguing on this list
will change the current implementation and the only thing that will
change a future implementation is CODE.

I have stated that whatever format you want to invent it should
include a "literal dictionary format", because the existing code is
expecting to work with Dictionaries.


+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
I have also stated that any code produced be portable to all of the
dialects participating in the project.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

If you meet these two requirements, it is likely that the project
maintainers will just fold it in ... if it takes too much work to use
your format, then you'll have to do it yourself.

1) FileTree/Cypress is using JSON

2) the current implementation is functioning just fine

3) FileTree/Cypress is designed to be flexible in terms of format, at
some future date, you will be free to fork the projects and introduce
your own favorite format and you are free to make the changes that are
necessary in the source code for all of the dialects or use your own
custom package structure on just your own projects.

We are all programmers.

We all understand that the data can be represented in an infinite
number of formats.

We all understand that it is just a small matter of writing code to
implement readers and writers for this infinite number of formats.

We all understand that the data is much more important than the disk format ....

We should all understand that there is no right answer to the format
question ... every conceivable format will work (with the appropriate
amount of supporting software) ...

We all have an opinion and I understand that each of you has your own
opinion about what the format should be and I understand that the
folks who are continuing to argue over this are not happy with my
decision...

That's just too bad.

If you are interested in being able to use git and github and are
excited at the prospect of being able to not only share code across
dialects, but to collaborate on cross dialect projects, then stop
worrying about the format of the file and put your energy into writing
code in support of this goal (see point 3 and read it 5 times in a
row).

If you are arguing on these points, you are showing that you have
passion ... I don't fault you for having strong opinions ... I just
ask you to channel your energy into writing code on this issue or
focussing on some of the harder problems that do exist...

I do not intend to read any responses to this mail as far as I am
concerned I am moving on to some of the much more important issues
that need attention ...

Dale
Post by Igor Stasenko
you know, it is like C and their makefiles..
in C world they cannot express the project metadata using C syntax..
that's why they using this weird
makefiles (and many other .project formats) to glue things together..
But hey, we can express things in smalltalk. So, why adding extra tool
to the toolchain?
My point is not about whether it is better to use JSON over another
format. My point is that we can use smalltalk all the way down.
Because it means less dependencies and simpler tool chain (you need to
have only smalltalk parser to handle everything stored in your files,
and no extra stuff).
Because tomorrow, other guy could say: hey i love xml and i want to
it is used worldwide, and can be used for interoperability with other
languages... and so on, so on.
And he will be totally right, except from the fact that we don't need it.
My argument is purely pragmatic: it is better having just one parser
to parse all data than two or more.
More formats, more syntax(es) means more things to worry about, and maintain.
Post by Igor Stasenko
Post by Stéphane Ducasse
Post by Janko Mivšek
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.
In a really really bad way. Because the tags are used in a non sense way.
You still have to parse method to get the selector :) So VW is far from
an example. And we are not talking about the method format, just method metadata.
Post by Janko Mivšek
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. We will
be much closer to other words with Smalltalk that way
Not at all. Do you really think that somebody will be interested by
Smalltalk just because
metadata of methods are stored in JSON :)
Come on.
yeah. lets store our metadata in SQL syntax.. so we are closer to SQL
databases..
LOL :)
Post by Stéphane Ducasse
Post by Janko Mivšek
and even more by
using GitHub for code repository.
--
Best regards,
Igor Stasenko.
--
Best regards,
Igor Stasenko.
Dale Henrichs
2012-04-24 00:17:33 UTC
Permalink
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.

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...

Dale

----- Original Message -----
| From: "Igor Stasenko" <siguctua at gmail.com>
| To: Pharo-project at lists.gforge.inria.fr
| 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 <dhenrich at vmware.com> 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" <siguctua at gmail.com>
| > | To: Pharo-project at lists.gforge.inria.fr
| > | 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 <dhenrich at vmware.com>
| > | 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" <bernhard at pieber.com>
| > | > | To: Pharo-project at lists.gforge.inria.fr
| > | > | 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.
|
|
Igor Stasenko
2012-04-24 00:21:57 UTC
Permalink
Post by Dale Henrichs
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? ;)
Post by Dale Henrichs
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
Post by Dale Henrichs
Dale
----- Original Message -----
| From: "Igor Stasenko" <siguctua at gmail.com>
| To: Pharo-project at lists.gforge.inria.fr
| 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]
|
| > Igor,
| >
| >
| > ?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" <siguctua at gmail.com>
| > | To: Pharo-project at lists.gforge.inria.fr
| > | 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 <dhenrich at vmware.com>
| > | > 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.
| > | >
| > | >
| > | > ?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" <bernhard at pieber.com>
| > | > | To: Pharo-project at lists.gforge.inria.fr
| > | > | 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
| > | > | 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.
| > | > |
| > | > | > Hi!
| > | > | >
| > | > | >>> 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.
Dale Henrichs
2012-04-24 00:32:42 UTC
Permalink
Igor,

GemStone's Smalltalk parser/compiler is implemented in C ... 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" <siguctua at gmail.com>
| To: Pharo-project at lists.gforge.inria.fr
| 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 <dhenrich at vmware.com> 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" <siguctua at gmail.com>
| > | To: Pharo-project at lists.gforge.inria.fr
| > | 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 <dhenrich at vmware.com>
| > | 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" <siguctua at gmail.com>
| > | > | To: Pharo-project at lists.gforge.inria.fr
| > | > | 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 <dhenrich at vmware.com>
| > | > | 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" <bernhard at pieber.com>
| > | > | > | To: Pharo-project at lists.gforge.inria.fr
| > | > | > | 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.
|
|
Stéphane Ducasse
2012-04-24 05:28:00 UTC
Permalink
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" <siguctua at gmail.com>
| To: Pharo-project at lists.gforge.inria.fr
| 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]
|
| > 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" <siguctua at gmail.com>
| > | To: Pharo-project at lists.gforge.inria.fr
| > | 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 <dhenrich at vmware.com>
| > | > Igor,
| > | >
| > | >
| > | > 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" <siguctua at gmail.com>
| > | > | To: Pharo-project at lists.gforge.inria.fr
| > | > | 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 <dhenrich at vmware.com>
| > | > | > 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.
| > | > | >
| > | > | >
| > | > | > 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" <bernhard at pieber.com>
| > | > | > | To: Pharo-project at lists.gforge.inria.fr
| > | > | > | 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
| > | > | > | 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.
| > | > | > |
| > | > | > | > Hi!
| > | > | > | >
| > | > | > | >>> 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.
|
|
Stéphane Ducasse
2012-04-24 05:31:23 UTC
Permalink
When I tried long time ago to load (and I could at then end)
all the versions of squeak into VW I faced the problems of the difference in format for floats.
So how do you plan to handle that? Storing just strings?

Stef
Post by Dale Henrichs
Igor,
GemStone's Smalltalk parser/compiler is implemented in C ... 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" <siguctua at gmail.com>
| To: Pharo-project at lists.gforge.inria.fr
| 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]
|
| > 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" <siguctua at gmail.com>
| > | To: Pharo-project at lists.gforge.inria.fr
| > | 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 <dhenrich at vmware.com>
| > | > Igor,
| > | >
| > | >
| > | > 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" <siguctua at gmail.com>
| > | > | To: Pharo-project at lists.gforge.inria.fr
| > | > | 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 <dhenrich at vmware.com>
| > | > | > 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.
| > | > | >
| > | > | >
| > | > | > 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" <bernhard at pieber.com>
| > | > | > | To: Pharo-project at lists.gforge.inria.fr
| > | > | > | 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
| > | > | > | 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.
| > | > | > |
| > | > | > | > Hi!
| > | > | > | >
| > | > | > | >>> 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.
|
|
Dale Henrichs
2012-04-24 09:30:05 UTC
Permalink
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" <stephane.ducasse at inria.fr>
| To: Pharo-project at lists.gforge.inria.fr
| 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" <siguctua at gmail.com>
| > | To: Pharo-project at lists.gforge.inria.fr
| > | 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 <dhenrich at vmware.com>
| > | 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" <siguctua at gmail.com>
| > | > | To: Pharo-project at lists.gforge.inria.fr
| > | > | 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 <dhenrich at vmware.com>
| > | > | 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" <siguctua at gmail.com>
| > | > | > | To: Pharo-project at lists.gforge.inria.fr
| > | > | > | 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
| > | > | > | <dhenrich at vmware.com>
| > | > | > | 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" <bernhard at pieber.com>
| > | > | > | > | To: Pharo-project at lists.gforge.inria.fr
| > | > | > | > | 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.
| > |
| > |
| >
|
|
|
Stéphane Ducasse
2012-04-24 09:41:24 UTC
Permalink
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?
so you cannot put the array in a file and call the parser (even if this is a primitive)?
I'm confused.
Dale
----- Original Message -----
| From: "St?phane Ducasse" <stephane.ducasse at inria.fr>
| To: Pharo-project at lists.gforge.inria.fr
| 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]
|
|
|
| > Igor,
| >
| > GemStone's Smalltalk parser/compiler is implemented in C ?
|
| 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" <siguctua at gmail.com>
| > | To: Pharo-project at lists.gforge.inria.fr
| > | 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 <dhenrich at vmware.com>
| > | > 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" <siguctua at gmail.com>
| > | > | To: Pharo-project at lists.gforge.inria.fr
| > | > | 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 <dhenrich at vmware.com>
| > | > | > Igor,
| > | > | >
| > | > | >
| > | > | > 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" <siguctua at gmail.com>
| > | > | > | To: Pharo-project at lists.gforge.inria.fr
| > | > | > | 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
| > | > | > | <dhenrich at vmware.com>
| > | > | > | > 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
| > | > | > | >
| > | > | > | > 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" <bernhard at pieber.com>
| > | > | > | > | To: Pharo-project at lists.gforge.inria.fr
| > | > | > | > | 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
| > | > | > | > | 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.
| > | > | > | > |
| > | > | > | > | > Hi!
| > | > | > | > | >
| > | > | > | > | >>> 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.
| > |
| > |
| >
|
|
|
Philippe Back
2012-04-24 09:36:35 UTC
Permalink
Where is the source? I like it and can use it in my current project.

Tx
Phil


Envoy? depuis un mobile Samsung
Post by Sven Van Caekenberghe
But then you need to write a clear spec and a non-compiler based parser.
Ok, perhaps you all understood this from my links etc, but Tirade *is* a
non-compiler based parser. It *is* safe. It only allows literals. It is
*much* faster than the Compiler. It is very small, code is simple and it
is trivial to port to ANY Smalltalk.

Now, for the other arguments - I agree, JSON is "good enough" for many
things and universally accepted in almost all camps these days. Just
don't want people to reinvent Tirade :)

regards, G?ran
Dale Henrichs
2012-04-24 09:54:17 UTC
Permalink
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.

... JSON is and was a pragmatic choice...

Dale

----- Original Message -----
| From: "St?phane Ducasse" <stephane.ducasse at inria.fr>
| To: Pharo-project at lists.gforge.inria.fr
| Sent: Tuesday, April 24, 2012 2:41:24 AM
| Subject: Re: [Pharo-project] About Cypress [Was: Re: [ANN] Styled Text Editor for Cuis 4.0 Smalltalk]
|
|
| On Apr 24, 2012, at 11:30 AM, Dale Henrichs wrote:
|
| > 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?
|
| so you cannot put the array in a file and call the parser (even if
| this is a primitive)?
| I'm confused.
|
|
| >
| > Dale
| >
| > ----- Original Message -----
| > | From: "St?phane Ducasse" <stephane.ducasse at inria.fr>
| > | To: Pharo-project at lists.gforge.inria.fr
| > | 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" <siguctua at gmail.com>
| > | > | To: Pharo-project at lists.gforge.inria.fr
| > | > | 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 <dhenrich at vmware.com>
| > | > | 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" <siguctua at gmail.com>
| > | > | > | To: Pharo-project at lists.gforge.inria.fr
| > | > | > | 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
| > | > | > | <dhenrich at vmware.com>
| > | > | > | 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" <siguctua at gmail.com>
| > | > | > | > | To: Pharo-project at lists.gforge.inria.fr
| > | > | > | > | 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
| > | > | > | > | <dhenrich at vmware.com>
| > | > | > | > | 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" <bernhard at pieber.com>
| > | > | > | > | > | To: Pharo-project at lists.gforge.inria.fr
| > | > | > | > | > | 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.
| > | > |
| > | > |
| > | >
| > |
| > |
| > |
| >
|
|
|
Igor Stasenko
2012-04-24 10:40:05 UTC
Permalink
Post by Dale Henrichs
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..
Post by Dale Henrichs
... JSON is and was a pragmatic choice...
well, i did not realized that GemStone have no own parser/compiler
written in smalltalk.
Post by Dale Henrichs
Dale
----- Original Message -----
| From: "St?phane Ducasse" <stephane.ducasse at inria.fr>
| To: Pharo-project at lists.gforge.inria.fr
| Sent: Tuesday, April 24, 2012 2:41:24 AM
| Subject: Re: [Pharo-project] About Cypress [Was: Re: [ANN] Styled ? ? Text ? ?Editor for Cuis 4.0 Smalltalk]
|
|
|
| > 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?
|
| so you cannot put the array in a file and call the parser (even if
| this is a primitive)?
| I'm confused.
|
|
| >
| > Dale
| >
| > ----- Original Message -----
| > | From: "St?phane Ducasse" <stephane.ducasse at inria.fr>
| > | To: Pharo-project at lists.gforge.inria.fr
| > | 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]
| > |
| > |
| > |
| > | > Igor,
| > | >
| > | > GemStone's Smalltalk parser/compiler is implemented in C ?
| > |
| > | ? 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" <siguctua at gmail.com>
| > | > | To: Pharo-project at lists.gforge.inria.fr
| > | > | 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 <dhenrich at vmware.com>
| > | > | > 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" <siguctua at gmail.com>
| > | > | > | To: Pharo-project at lists.gforge.inria.fr
| > | > | > | Sent: Monday, April 23, 2012 4:07:04 PM
| > | > | > | [ANN]
| > | > | > | Styled
| > | > | > | Text Editor for Cuis 4.0 Smalltalk]
| > | > | > |
| > | > | > | On 24 April 2012 01:54, Dale Henrichs
| > | > | > | <dhenrich at vmware.com>
| > | > | > | > Igor,
| > | > | > | >
| > | > | > | >
| > | > | > | > ?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" <siguctua at gmail.com>
| > | > | > | > | To: Pharo-project at lists.gforge.inria.fr
| > | > | > | > | Sent: Monday, April 23, 2012 2:34:54 PM
| > | > | > | > | [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
| > | > | > | > | <dhenrich at vmware.com>
| > | > | > | > | > 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
| > | > | > | > | >
| > | > | > | > | > ?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" <bernhard at pieber.com>
| > | > | > | > | > | To: Pharo-project at lists.gforge.inria.fr
| > | > | > | > | > | 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
| > | > | > | > | > | 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.
| > | > | > | > | > |
| > | > | > | > | > | > Hi!
| > | > | > | > | > | >
| > | > | > | > | > | >>> 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.
| > | > |
| > | > |
| > | >
| > |
| > |
| > |
| >
|
|
|
--
Best regards,
Igor Stasenko.
Herby Vojčík
2012-04-24 12:17:59 UTC
Permalink
Post by Igor Stasenko
Post by Dale Henrichs
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..
Post by Dale Henrichs
... 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.

Herby
Igor Stasenko
2012-04-24 12:22:34 UTC
Permalink
Post by Herby Vojčík
Post by Igor Stasenko
Post by Dale Henrichs
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..
Post by Dale Henrichs
... 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.
Post by Herby Vojčík
Herby
--
Best regards,
Igor Stasenko.
Igor Stasenko
2012-04-24 12:30:05 UTC
Permalink
yeah, lets put another canister of fuel into the flame:

hey, who needs that odd smalltalk syntax? who says that smalltalk
source code should have original syntax?
lets express it in JSON!!
Post by Igor Stasenko
Post by Herby Vojčík
Post by Igor Stasenko
Post by Dale Henrichs
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..
Post by Dale Henrichs
... 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.
Post by Herby Vojčík
Herby
--
Best regards,
Igor Stasenko.
--
Best regards,
Igor Stasenko.
H. Hirzel
2012-04-24 12:32:34 UTC
Permalink
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
Post by Igor Stasenko
Post by Herby Vojčík
Post by Igor Stasenko
Post by Dale Henrichs
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..
Post by Dale Henrichs
... 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.
Post by Herby Vojčík
Herby
--
Best regards,
Igor Stasenko.
Stéphane Ducasse
2012-04-24 21:50:51 UTC
Permalink
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
Post by H. Hirzel
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
Post by Igor Stasenko
Post by Herby Vojčík
Post by Igor Stasenko
Post by Dale Henrichs
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..
Post by Dale Henrichs
... 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.
Post by Herby Vojčík
Herby
--
Best regards,
Igor Stasenko.
Igor Stasenko
2012-04-24 22:26:58 UTC
Permalink
Post by 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, 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.
Post by Stéphane Ducasse
Stef
Post by H. Hirzel
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
Post by Igor Stasenko
Post by Herby Vojčík
Post by Igor Stasenko
Post by Dale Henrichs
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..
Post by Dale Henrichs
... 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.
Post by Herby Vojčík
Herby
--
Best regards,
Igor Stasenko.
--
Best regards,
Igor Stasenko.
Norbert Hartl
2012-04-25 06:58:06 UTC
Permalink
Post by Igor Stasenko
Post by 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, 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
Post by Igor Stasenko
Post by Stéphane Ducasse
Stef
Post by H. Hirzel
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
Post by Igor Stasenko
Post by Herby Vojčík
Post by Igor Stasenko
Post by Dale Henrichs
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..
Post by Dale Henrichs
... 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.
Post by Herby Vojčík
Herby
--
Best regards,
Igor Stasenko.
--
Best regards,
Igor Stasenko.
Norbert Hartl
2012-04-25 06:48:30 UTC
Permalink
Post by 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, 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
Post by Stéphane Ducasse
Post by H. Hirzel
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
Post by Igor Stasenko
Post by Herby Vojčík
Post by Igor Stasenko
Post by Dale Henrichs
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..
Post by Dale Henrichs
... 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.
Post by Herby Vojčík
Herby
--
Best regards,
Igor Stasenko.
Dale Henrichs
2012-04-24 21:58:44 UTC
Permalink
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" <stephane.ducasse at inria.fr>
| To: Pharo-project at lists.gforge.inria.fr
| 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<siguctua at gmail.com> 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
| >
|
|
|
Stéphane Ducasse
2012-04-24 22:26:06 UTC
Permalink
Post by Dale Henrichs
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.
Post by Dale Henrichs
Dale
----- Original Message -----
| From: "St?phane Ducasse" <stephane.ducasse at inria.fr>
| To: Pharo-project at lists.gforge.inria.fr
| Sent: Tuesday, April 24, 2012 2:52:05 PM
| Subject: Re: [Pharo-project] Tirade!
|
| Give us a break!
|
| Stef
|
|
| >>> 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
| >
| > 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
| >
|
|
|
Dale Henrichs
2012-04-24 22:01:50 UTC
Permalink
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.ducasse at inria.fr>
| To: Pharo-project at 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 <siguctua at gmail.com> wrote:
| >> On 24 April 2012 14:17, Herby Voj??k <herby at mailbox.sk> wrote:
| >>>
| >>>
| >>> Igor Stasenko wrote:
| >>>>
| >>>> On 24 April 2012 11:54, Dale Henrichs<dhenrich at 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.
| >>
| >>
| >
|
|
|
Continue reading on narkive:
Loading...