[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@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@pieber.com> | To: Pharo-project@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.
Hello Igor This has been discussed on the Metacello mailing list on the 11 and 12th of this month. Regards Hannes On 4/23/12, Igor Stasenko <siguctua@gmail.com> wrote:
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@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@pieber.com> | To: Pharo-project@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.
On 24 April 2012 00:56, H. Hirzel <hannes.hirzel@gmail.com> wrote:
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. :)
Regards Hannes
On 4/23/12, Igor Stasenko <siguctua@gmail.com> wrote:
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@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@pieber.com> | To: Pharo-project@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.
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 On 4/24/12, Igor Stasenko <siguctua@gmail.com> wrote:
On 24 April 2012 00:56, H. Hirzel <hannes.hirzel@gmail.com> wrote:
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. :)
Regards Hannes
On 4/23/12, Igor Stasenko <siguctua@gmail.com> wrote:
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@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@pieber.com> | To: Pharo-project@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.
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. On 24 April 2012 01:19, H. Hirzel <hannes.hirzel@gmail.com> wrote:
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
On 4/24/12, Igor Stasenko <siguctua@gmail.com> wrote:
On 24 April 2012 00:56, H. Hirzel <hannes.hirzel@gmail.com> wrote:
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. :)
Regards Hannes
On 4/23/12, Igor Stasenko <siguctua@gmail.com> wrote:
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@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@pieber.com> | To: Pharo-project@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.
On 24 April 2012 01:57, Igor Stasenko <siguctua@gmail.com> wrote:
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.
and sure.. you're free to introduce any other keywords to meet your needs... i.e. #( top #point (10 20)) will produce: { #top. 10@20 }. -- Best regards, Igor Stasenko.
Yes, this was part of the discussion there. --Hannes On 4/24/12, Igor Stasenko <siguctua@gmail.com> wrote:
On 24 April 2012 01:57, Igor Stasenko <siguctua@gmail.com> wrote:
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.
and sure.. you're free to introduce any other keywords to meet your needs... i.e.
#( top #point (10 20)) will produce:
{ #top. 10@20 }.
-- Best regards, Igor Stasenko.
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-re... ----- Original Message ----- | From: "Igor Stasenko" <siguctua@gmail.com> | To: Pharo-project@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@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@pieber.com> | > | To: Pharo-project@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. | |
On 24 April 2012 01:54, Dale Henrichs <dhenrich@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-re...
----- Original Message ----- | From: "Igor Stasenko" <siguctua@gmail.com> | To: Pharo-project@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@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@pieber.com> | > | To: Pharo-project@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, 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@gmail.com> | To: Pharo-project@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@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-re... | > | > | > ----- Original Message ----- | > | From: "Igor Stasenko" <siguctua@gmail.com> | > | To: Pharo-project@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@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@pieber.com> | > | > | To: Pharo-project@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. | |
On 24 April 2012 03:17, Dale Henrichs <dhenrich@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@gmail.com> | To: Pharo-project@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@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-re... | > | > | > ----- Original Message ----- | > | From: "Igor Stasenko" <siguctua@gmail.com> | > | To: Pharo-project@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@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@pieber.com> | > | > | To: Pharo-project@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, 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@gmail.com> | To: Pharo-project@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@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@gmail.com> | > | To: Pharo-project@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@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-re... | > | > | > | > | > | > ----- Original Message ----- | > | > | From: "Igor Stasenko" <siguctua@gmail.com> | > | > | To: Pharo-project@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@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@pieber.com> | > | > | > | To: Pharo-project@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. | |
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@gmail.com> | To: Pharo-project@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@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@gmail.com> | > | To: Pharo-project@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@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-re... | > | > | > | > | > | > ----- Original Message ----- | > | > | From: "Igor Stasenko" <siguctua@gmail.com> | > | > | To: Pharo-project@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@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@pieber.com> | > | > | > | To: Pharo-project@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. | |
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@inria.fr> | To: Pharo-project@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@gmail.com> | > | To: Pharo-project@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@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@gmail.com> | > | > | To: Pharo-project@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@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-re... | > | > | > | > | > | > | > | > | > ----- Original Message ----- | > | > | > | From: "Igor Stasenko" <siguctua@gmail.com> | > | > | > | To: Pharo-project@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@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@pieber.com> | > | > | > | > | To: Pharo-project@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. | > | | > | | > | | |
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@inria.fr> | To: Pharo-project@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@gmail.com> | > | To: Pharo-project@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@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@gmail.com> | > | > | To: Pharo-project@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@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-re... | > | > | > | > | > | > | > | > | > ----- Original Message ----- | > | > | > | From: "Igor Stasenko" <siguctua@gmail.com> | > | > | > | To: Pharo-project@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@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@pieber.com> | > | > | > | > | To: Pharo-project@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. | > | | > | | > | | |
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@inria.fr> | To: Pharo-project@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@inria.fr> | > | To: Pharo-project@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@gmail.com> | > | > | To: Pharo-project@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@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@gmail.com> | > | > | > | To: Pharo-project@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@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-re... | > | > | > | > | > | > | > | > | > | > | > | > ----- Original Message ----- | > | > | > | > | From: "Igor Stasenko" <siguctua@gmail.com> | > | > | > | > | To: Pharo-project@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@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@pieber.com> | > | > | > | > | > | To: Pharo-project@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. | > | > | | > | > | | > | > | > | | > | | > | | > | | |
On 24 April 2012 11:54, Dale Henrichs <dhenrich@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.
Dale
----- Original Message ----- | From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> | To: Pharo-project@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@inria.fr> | > | To: Pharo-project@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@gmail.com> | > | > | To: Pharo-project@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@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@gmail.com> | > | > | > | To: Pharo-project@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@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-re... | > | > | > | > | > | > | > | > | > | > | > | > ----- Original Message ----- | > | > | > | > | From: "Igor Stasenko" <siguctua@gmail.com> | > | > | > | > | To: Pharo-project@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@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@pieber.com> | > | > | > | > | > | To: Pharo-project@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. | > | > | | > | > | | > | > | > | | > | | > | | > | | |
-- Best regards, Igor Stasenko.
Igor Stasenko wrote:
On 24 April 2012 11:54, Dale Henrichs<dhenrich@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. Herby
On 24 April 2012 14:17, Herby VojÄÃk <herby@mailbox.sk> wrote:
Igor Stasenko wrote:
On 24 April 2012 11:54, Dale Henrichs<dhenrich@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.
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!! On 24 April 2012 14:22, Igor Stasenko <siguctua@gmail.com> wrote:
On 24 April 2012 14:17, Herby VojÄÃk <herby@mailbox.sk> wrote:
Igor Stasenko wrote:
On 24 April 2012 11:54, Dale Henrichs<dhenrich@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.
-- Best regards, Igor Stasenko.
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@gmail.com> wrote:
On 24 April 2012 14:17, Herby VojÄÃk <herby@mailbox.sk> wrote:
Igor Stasenko wrote:
On 24 April 2012 11:54, Dale Henrichs<dhenrich@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.
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@gmail.com> wrote:
On 24 April 2012 14:17, Herby VojÄÃk <herby@mailbox.sk> wrote:
Igor Stasenko wrote:
On 24 April 2012 11:54, Dale Henrichs<dhenrich@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.
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@inria.fr> | To: Pharo-project@lists.gforge.inria.fr | Sent: Tuesday, April 24, 2012 2:50:51 PM | Subject: Re: [Pharo-project] About Cypress [Was: Re: [ANN] Styled Text Editor for Cuis 4.0 Smalltalk] | | We will write a parser because we do not want a JSON syntax. | I started and I will continue. | | Hannes I think that igor did a lot for us and that he knows probably | more | than you what is to work for the community. Because Igor could be | working for Google | right now without any problem. So let us appreciate to have guys like | him in our community. | | Stef | | > Igor, | > | > Let me rephrase the context. It is that you started this thread | > yesterday Monday Apr 23, 2012 at 11:34 .You said that you are not | > pleased with storing Smalltalk meta data in JSON format. | > | > You gave the example | > | > { | > "category" : "Cypress-Tests", | > "classinstvars" : [ | > ], | > "classtraitcomposition" : "{}", | > "classvars" : [ | > ], | > "commentStamp" : "", | > "instvars" : [ | > ], | > "name" : "CypressPatchTest", | > "pools" : [ | > ], | > "super" : "CypressAbstractTest", | > "traitcomposition" : "{}", | > "type" : "normal" } | > | > The cypress project URL is | > | > https://github.com/CampSmalltalk/Cypress | > | > This is Dale Henrichs' work. | > | > Cypress uses JSON for storing the meta data. | > | > There is a button called 'Fork' on the git hub project. | > | > Dale is willing to take arguments if they are based on code. | > For many people JSON is fine. | > | > HTH :-) | > | > Hannes | > | > On 4/24/12, Igor Stasenko <siguctua@gmail.com> wrote: | >> On 24 April 2012 14:17, Herby VojÄÃk <herby@mailbox.sk> wrote: | >>> | >>> | >>> Igor Stasenko wrote: | >>>> | >>>> On 24 April 2012 11:54, Dale Henrichs<dhenrich@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. | >> | >> | > | | |
On 24 April 2012 23:50, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
We will write a parser because we do not want a JSON syntax. I started and I will continue.
Hannes I think that igor did a lot for us and that he knows probably more than you what is to work for the community. Because Igor could be working for Google right now without any problem. So let us appreciate to have guys like him in our community.
Stef, i see nothing disrespectful in Hannes reply. Also, i'd prefer to be not put in a role of high authority. If i could work on Google, it doesn't makes any of my arguments stronger or weaker.
Stef
Igor,
Let me rephrase the context. It is that you started this thread yesterday Monday Apr 23, 2012 at 11:34 .You said that you are not pleased with storing Smalltalk meta data in JSON format.
You gave the example
{ "category" : "Cypress-Tests", "classinstvars" : [ ], "classtraitcomposition" : "{}", "classvars" : [ ], "commentStamp" : "", "instvars" : [ ], "name" : "CypressPatchTest", "pools" : [ ], "super" : "CypressAbstractTest", "traitcomposition" : "{}", "type" : "normal" }
The cypress project URL is
https://github.com/CampSmalltalk/Cypress
This is Dale Henrichs' work.
Cypress uses JSON for storing the meta data.
There is a button called 'Fork' on the git hub project.
Dale is willing to take arguments if they are based on code. For many people JSON is fine.
HTH :-)
Hannes
On 4/24/12, Igor Stasenko <siguctua@gmail.com> wrote:
On 24 April 2012 14:17, Herby VojÄÃk <herby@mailbox.sk> wrote:
Igor Stasenko wrote:
On 24 April 2012 11:54, Dale Henrichs<dhenrich@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.
-- Best regards, Igor Stasenko.
Am 25.04.2012 um 00:26 schrieb Igor Stasenko <siguctua@gmail.com>:
On 24 April 2012 23:50, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
We will write a parser because we do not want a JSON syntax. I started and I will continue.
Hannes I think that igor did a lot for us and that he knows probably more than you what is to work for the community. Because Igor could be working for Google right now without any problem. So let us appreciate to have guys like him in our community.
Stef, i see nothing disrespectful in Hannes reply. Also, i'd prefer to be not put in a role of high authority. If i could work on Google, it doesn't makes any of my arguments stronger or weaker.
Exactly. And google is no indicator of quality. Sure it is said that they hire the best ones. But first you need a certain degree in information science otherwise they won't employ you. It is that easy. To be honest the most clever guys I met in my life had no degree at all ;) Norbert
Stef
Igor,
Let me rephrase the context. It is that you started this thread yesterday Monday Apr 23, 2012 at 11:34 .You said that you are not pleased with storing Smalltalk meta data in JSON format.
You gave the example
{ "category" : "Cypress-Tests", "classinstvars" : [ ], "classtraitcomposition" : "{}", "classvars" : [ ], "commentStamp" : "", "instvars" : [ ], "name" : "CypressPatchTest", "pools" : [ ], "super" : "CypressAbstractTest", "traitcomposition" : "{}", "type" : "normal" }
The cypress project URL is
https://github.com/CampSmalltalk/Cypress
This is Dale Henrichs' work.
Cypress uses JSON for storing the meta data.
There is a button called 'Fork' on the git hub project.
Dale is willing to take arguments if they are based on code. For many people JSON is fine.
HTH :-)
Hannes
On 4/24/12, Igor Stasenko <siguctua@gmail.com> wrote:
On 24 April 2012 14:17, Herby VojÄÃk <herby@mailbox.sk> wrote:
Igor Stasenko wrote:
On 24 April 2012 11:54, Dale Henrichs<dhenrich@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.
-- Best regards, Igor Stasenko.
Am 24.04.2012 um 23:50 schrieb Stéphane Ducasse <stephane.ducasse@inria.fr>:
We will write a parser because we do not want a JSON syntax. I started and I will continue.
Hannes I think that igor did a lot for us and that he knows probably more than you what is to work for the community. Because Igor could be working for Google right now without any problem. So let us appreciate to have guys like him in our community.
Stef, the last paragraph has an unfortunate ratio. The last sentence is fine but the first two are not. You have the right to be stubborn but I don't think you have the right to be so arrogant and unfair. Norbert
Igor,
Let me rephrase the context. It is that you started this thread yesterday Monday Apr 23, 2012 at 11:34 .You said that you are not pleased with storing Smalltalk meta data in JSON format.
You gave the example
{ "category" : "Cypress-Tests", "classinstvars" : [ ], "classtraitcomposition" : "{}", "classvars" : [ ], "commentStamp" : "", "instvars" : [ ], "name" : "CypressPatchTest", "pools" : [ ], "super" : "CypressAbstractTest", "traitcomposition" : "{}", "type" : "normal" }
The cypress project URL is
https://github.com/CampSmalltalk/Cypress
This is Dale Henrichs' work.
Cypress uses JSON for storing the meta data.
There is a button called 'Fork' on the git hub project.
Dale is willing to take arguments if they are based on code. For many people JSON is fine.
HTH :-)
Hannes
On 4/24/12, Igor Stasenko <siguctua@gmail.com> wrote:
On 24 April 2012 14:17, Herby VojÄÃk <herby@mailbox.sk> wrote:
Igor Stasenko wrote:
On 24 April 2012 11:54, Dale Henrichs<dhenrich@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.
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 On Apr 24, 2012, at 2:32 AM, Dale Henrichs wrote:
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@gmail.com> | To: Pharo-project@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@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@gmail.com> | > | To: Pharo-project@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@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-re... | > | > | > | > | > | > ----- Original Message ----- | > | > | From: "Igor Stasenko" <siguctua@gmail.com> | > | > | To: Pharo-project@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@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@pieber.com> | > | > | > | To: Pharo-project@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 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 On Apr 24, 2012, at 1:07 AM, Igor Stasenko wrote:
On 24 April 2012 01:54, Dale Henrichs <dhenrich@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-re...
----- Original Message ----- | From: "Igor Stasenko" <siguctua@gmail.com> | To: Pharo-project@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@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@pieber.com> | > | To: Pharo-project@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.
On 04/24/2012 07:25 AM, Stéphane Ducasse wrote:
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
On 24 Apr 2012, at 08:58, Göran Krampe wrote:
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
On 04/24/2012 10:04 AM, Sven Van Caekenberghe wrote:
On 24 Apr 2012, at 08:58, Göran Krampe wrote:
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
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
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
Am 24.04.2012 um 11:10 schrieb Stéphane Ducasse:
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
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.
On 24 Apr 2012, at 11:10, Stéphane Ducasse wrote:
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
On 04/24/2012 11:25 AM, Sven Van Caekenberghe wrote:
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
Where is the code? Do you have tests? Can we extract a parser for literal array? Stef
On 04/24/2012 11:25 AM, Sven Van Caekenberghe wrote:
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
On 04/24/2012 11:46 AM, Stéphane Ducasse wrote:
Where is the code?
On SS. But it seems... down? Project is called "Tirade".
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?
Can we extract a parser for literal array?
Yes, should be trivial.
Stef
regards, Göran
On 04/24/2012 11:51 AM, Göran Krampe wrote:
On 04/24/2012 11:46 AM, Stéphane Ducasse wrote:
Where is the code?
On SS. But it seems... down? Project is called "Tirade".
http://www.squeaksource.com/Tirade.html regards, Göran
On 04/24/2012 11:52 AM, Göran Krampe wrote:
On 04/24/2012 11:51 AM, Göran Krampe wrote:
On 04/24/2012 11:46 AM, Stéphane Ducasse wrote:
Where is the code?
On SS. But it seems... down? Project is called "Tirade".
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
Ok I will have a look. Because it would solve our problem. Stef
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
On 04/24/2012 12:57 PM, Stéphane Ducasse wrote:
Ok I will have a look. Because it would solve our problem.
I just added first stab at supporting literal arrays, the following works: (TiradeParser parse: 'keyword: #(1 3.4 ''asd'' #jupp 2).') last value first print it => #(1 3.4 'asd' #jupp 2) The "last value first" is just because the result from TiradeParser contains Associations between the keyword and an array of arguments. It could in fact return instances of Message, that might be nice :) ...but nesting needs a bit more thought since one can ommit the # when nesting literal arrays inside literal arrays. regards, Göran
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
Thanks. I saw that #(tire ) is interpreted as true so I will check and improve that. tef On Apr 24, 2012, at 3:18 PM, Göran Krampe wrote:
Ok, I spent some time adding support for literal arrays to Tirade. It probably has bugs and I haven't written tests for them but it does parse this correctly:
(TiradeParser parse: 'keyword: #(1 -2 3.4 -4.5 ''asd'' (2 nil true false 3) #jupp jupp jupp:tup: #''ju li'' jup:tu 2).') last value first
...produces this:
#(1 -2 3.4 -4.5 'asd' #(2 nil true false 3) #jupp #jupp #jupp:tup: #'ju li' #'jup:tu' 2)
So it handles integers, floats, nil, true, false, nested literal arrays and symbols. In fact it does handle some more than a true literal array does since Tirade supports { bla . bla } arrays also (but only of literals) and also treats key -> value as a literal syntax.
Thus for example these work too:
(TiradeParser parse: 'keyword: #(1->2 3->#ad).') last value first
(TiradeParser parse: 'keyword: #({2 . 4}).') last value first
regards, Göran
I saw and I started to extract parts that I need and writing some texts. Stef
On 04/24/2012 12:57 PM, Stéphane Ducasse wrote:
Ok I will have a look. Because it would solve our problem.
I just added first stab at supporting literal arrays, the following works:
(TiradeParser parse: 'keyword: #(1 3.4 ''asd'' #jupp 2).') last value first print it =>
#(1 3.4 'asd' #jupp 2)
The "last value first" is just because the result from TiradeParser contains Associations between the keyword and an array of arguments. It could in fact return instances of Message, that might be nice :)
...but nesting needs a bit more thought since one can ommit the # when nesting literal arrays inside literal arrays.
regards, Göran
goran could I extract the parser? and rename it in another package? Stef On Apr 24, 2012, at 12:00 PM, Göran Krampe wrote:
On 04/24/2012 11:52 AM, Göran Krampe wrote:
On 04/24/2012 11:51 AM, Göran Krampe wrote:
On 04/24/2012 11:46 AM, Stéphane Ducasse wrote:
Where is the code?
On SS. But it seems... down? Project is called "Tirade".
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
Here the the snippet to parse array literals.. based on existing parser.. i only had to add a #parseNode accessor to Parser to make it work: | parser| parser := (Parser new init: '#(1 2 3 (ab bc de))' readStream notifying: nil failBlock: [] ). parser encoder initScopeAndLiteralTables. parser primaryExpression. parser parseNode key On 24 April 2012 15:19, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
goran could I extract the parser? and rename it in another package?
Stef
On Apr 24, 2012, at 12:00 PM, Göran Krampe wrote:
On 04/24/2012 11:52 AM, Göran Krampe wrote:
On 04/24/2012 11:51 AM, Göran Krampe wrote:
On 04/24/2012 11:46 AM, Stéphane Ducasse wrote:
Where is the code?
On SS. But it seems... down? Project is called "Tirade".
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.
On 04/24/2012 03:23 PM, Igor Stasenko wrote:
Here the the snippet to parse array literals.. based on existing parser.. i only had to add a #parseNode accessor to Parser to make it work:
| parser| parser := (Parser new init: '#(1 2 3 (ab bc de))' readStream notifying: nil failBlock: [] ).
parser encoder initScopeAndLiteralTables. parser primaryExpression. parser parseNode key
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
I do not think it works for gemstone because apparently they cannot access the parser or at least wants to make sure that you cannot write code that can break the server scenario: you are mean that you write a strange meta data that is executed on the server so I will take tirade parser and make sure that we get one that only parse literal arrays. On Apr 24, 2012, at 3:23 PM, Igor Stasenko wrote:
Here the the snippet to parse array literals.. based on existing parser.. i only had to add a #parseNode accessor to Parser to make it work:
| parser| parser := (Parser new init: '#(1 2 3 (ab bc de))' readStream notifying: nil failBlock: [] ).
parser encoder initScopeAndLiteralTables. parser primaryExpression. parser parseNode key
On 24 April 2012 15:19, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
goran could I extract the parser? and rename it in another package?
Stef
On Apr 24, 2012, at 12:00 PM, Göran Krampe wrote:
On 04/24/2012 11:52 AM, Göran Krampe wrote:
On 04/24/2012 11:51 AM, Göran Krampe wrote:
On 04/24/2012 11:46 AM, Stéphane Ducasse wrote:
Where is the code?
On SS. But it seems... down? Project is called "Tirade".
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.
On 04/24/2012 03:19 PM, Stéphane Ducasse wrote:
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
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.
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.
On 4/24/12, Sven Van Caekenberghe <sven@beta9.be> wrote:
On 24 Apr 2012, at 11:10, Stéphane Ducasse wrote:
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
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
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
Sven
-- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
On 24 April 2012 12:50, H. Hirzel <hannes.hirzel@gmail.com> wrote:
On 4/24/12, Sven Van Caekenberghe <sven@beta9.be> wrote:
On 24 Apr 2012, at 11:10, Stéphane Ducasse wrote:
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
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
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.
On 4/24/12, Igor Stasenko <siguctua@gmail.com> wrote:
On 24 April 2012 12:50, H. Hirzel <hannes.hirzel@gmail.com> wrote:
On 4/24/12, Sven Van Caekenberghe <sven@beta9.be> wrote:
On 24 Apr 2012, at 11:10, Stéphane Ducasse wrote:
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.
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
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.
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
-- Best regards, Igor Stasenko.
On 04/24/2012 01:06 PM, H. Hirzel wrote:
On 4/24/12, Igor Stasenko<siguctua@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
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@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
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@inria.fr> | To: Pharo-project@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@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 | > | | |
On Apr 24, 2012, at 11:58 PM, Dale Henrichs wrote:
Stef,
It is starting to look like STON will be a good option ... it has the advantage of having an existing implementation and provides much more functionality than a simple literal array parser ... Oh and it looks a lot like Smalltalk ...
BTW, I am still interested in seeing how Tirade would provide the same functionality as STON...
I suggest that you take a deep breath and relax a bit:)
I see the advantage of ston to be able to specify class as in the Bitmap [ ] example Now it means that we will have the parser of ston loaded to load code⦠:( Ston can be a format for objects exchange but I still do not see why VW like literal arrays do not work.
Dale
----- Original Message ----- | From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> | To: Pharo-project@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@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 | > | | |
Yes! I agree with you. Now let us make progress on that point. On Apr 25, 2012, at 2:00 AM, Göran Krampe wrote:
On 04/24/2012 11:52 PM, Stéphane Ducasse wrote:
Give us a break!
I have all respect for you Stéphane but you really have a way with words sometimes.
regards, Göran
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 On 24 April 2012 06:25, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
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
Am 24.04.2012 um 09:45 schrieb 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.
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
On 24 April 2012 06:25, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote: 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
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 On Apr 24, 2012, at 9:58 AM, Norbert Hartl wrote:
Am 24.04.2012 um 09:45 schrieb 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.
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
On 24 April 2012 06:25, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote: 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
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@gmail.com>
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
On 24 April 2012 06:25, Stéphane Ducasse <stephane.ducasse@inria.fr>wrote:
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@highoctane.be| Web: http://philippeback.eu | Blog: http://philippeback.be High Octane SPRL rue cour Boisacq 101 1301 Bierges
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 On Apr 24, 2012, at 9:45 AM, Francisco Garau wrote:
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
On 24 April 2012 06:25, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote: 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
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 Dne 24. 04. 2012 01:07, piše Igor Stasenko:
On 24 April 2012 01:54, Dale Henrichs <dhenrich@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-re...
----- Original Message ----- | From: "Igor Stasenko" <siguctua@gmail.com> | To: Pharo-project@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@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@pieber.com> | > | To: Pharo-project@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. | |
-- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si
On 4/24/12, Janko Mivšek <janko.mivsek@eranova.si> wrote:
Hi Igor,
It is pretty clear that JSON is slowly replacing even XML elsewhere and if I for instance have to chose between XML and JSON, I'd certainly choose later. Our chunk format is, well, ours only. VW is using XML, others are using anything else. Something as neutral and as simple as JSON-based format can therefore become a bridge even between us.
JSON is now becoming defacto standard for any interoperability scenario in cloud world, so IMO Dale did a right decision to choose it. +1 We will be much closer to other words with Smalltalk that way and even more by using GitHub for code repository. +1
Best regards Janko
Dne 24. 04. 2012 01:07, piše Igor Stasenko:
On 24 April 2012 01:54, Dale Henrichs <dhenrich@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-re...
----- Original Message ----- | From: "Igor Stasenko" <siguctua@gmail.com> | To: Pharo-project@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@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@pieber.com> | > | To: Pharo-project@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. | |
-- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si
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.
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.
and even more by using GitHub for code repository.
On 24 April 2012 12:53, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Hi Igor,
It is pretty clear that JSON is slowly replacing even XML elsewhere and if I for instance have to chose between XML and JSON, I'd certainly choose later. Our chunk format is, well, ours only. VW is using XML, others are using anything else.
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.
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 :)
and even more by using GitHub for code repository.
-- Best regards, 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 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. On 24 April 2012 13:02, Igor Stasenko <siguctua@gmail.com> wrote:
On 24 April 2012 12:53, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Hi Igor,
It is pretty clear that JSON is slowly replacing even XML elsewhere and if I for instance have to chose between XML and JSON, I'd certainly choose later. Our chunk format is, well, ours only. VW is using XML, others are using anything else.
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.
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 :)
and even more by using GitHub for code repository.
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
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 On 4/24/12, Igor Stasenko <siguctua@gmail.com> wrote:
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.
On 24 April 2012 13:02, Igor Stasenko <siguctua@gmail.com> wrote:
On 24 April 2012 12:53, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Hi Igor,
It is pretty clear that JSON is slowly replacing even XML elsewhere and if I for instance have to chose between XML and JSON, I'd certainly choose later. Our chunk format is, well, ours only. VW is using XML, others are using anything else.
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.
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 :)
and even more by using GitHub for code repository.
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
participants (13)
-
Dale Henrichs -
Esteban Lorenzano -
Francisco Garau -
Göran Krampe -
H. Hirzel -
Herby VojÄÃk -
Igor Stasenko -
Janko Mivšek -
Norbert Hartl -
phil＠highoctane.be -
Stéphane Ducasse -
Sven Van Caekenberghe -
Tobias Pape