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

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

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

Igor Stasenko
Hi, Dale

it is great to see an effort in such direction.
I just wonder what .js files doing there?

According to what i see, it is just a meta data which holding
additional properties per entity..

{
"category" : "Cypress-Tests",
"classinstvars" : [
],
"classtraitcomposition" : "{}",
"classvars" : [
],
"commentStamp" : "",
"instvars" : [
],
"name" : "CypressPatchTest",
"pools" : [
],
"super" : "CypressAbstractTest",
"traitcomposition" : "{}",
"type" : "normal" }

why you cannot use a regular smalltalk literal syntax for this data?
What/why there is need to store this data in json format?

On 23 April 2012 23:57, Dale Henrichs <[hidden email]> 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" <[hidden email]>
> | To: [hidden email]
> | 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.

Reply | Threaded
Open this post in threaded view
|

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

Hannes Hirzel
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 <[hidden email]> 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 <[hidden email]> 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" <[hidden email]>
>> | To: [hidden email]
>> | 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.
>
>

Reply | Threaded
Open this post in threaded view
|

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

Igor Stasenko
On 24 April 2012 00:56, H. Hirzel <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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" <[hidden email]>
>>> | To: [hidden email]
>>> | 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.

Reply | Threaded
Open this post in threaded view
|

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

Hannes Hirzel
You are right. It is hidden in another thread

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

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

--Hannes



On 4/24/12, Igor Stasenko <[hidden email]> wrote:

> On 24 April 2012 00:56, H. Hirzel <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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" <[hidden email]>
>>>> | To: [hidden email]
>>>> | 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.
>
>

Reply | Threaded
Open this post in threaded view
|

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

Dale Henrichs
In reply to this post by 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-repository-td4356301.html


----- Original Message -----
| From: "Igor Stasenko" <[hidden email]>
| To: [hidden email]
| 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 <[hidden email]> 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" <[hidden email]>
| > | To: [hidden email]
| > | 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.
|
|

Reply | Threaded
Open this post in threaded view
|

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

Igor Stasenko
In reply to this post by Hannes Hirzel
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 <[hidden email]> 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 <[hidden email]> wrote:
>> On 24 April 2012 00:56, H. Hirzel <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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" <[hidden email]>
>>>>> | To: [hidden email]
>>>>> | 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.

Reply | Threaded
Open this post in threaded view
|

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

Igor Stasenko
On 24 April 2012 01:57, Igor Stasenko <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

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

Igor Stasenko
In reply to this post by Dale Henrichs
On 24 April 2012 01:54, Dale Henrichs <[hidden email]> wrote:
> Igor,
>
> The short answer is:
>
>  We could have used literal arrays, but it would have taken more work up
>  front than using the existing (portable) Seaside JSON parser.
>
umm.. what more work? Use if existing Smalltalk parser is more work?

IMO, binding to JSON format and introducing dependency is more like a
problem to me..

but anyways, since i late on party.. i don't wanna put sticks into
already rotating wheel..

you made a decision, if it works for you, fine.

P.S. I dealt with JSON when playing with SCouchDB project.. i wouldn't
say that i adore this format.
but it ok.. yeah.. everyone using it. Still s-expressions is IMO far
more elegant.


>  At this point we have working implementations in 5 different Smalltalk dialects
>  written to use JSON for properties files.
>
>  Cypress is designed to be flexible. FileTree the original Cypress implementation
>  reads 3 different disk-based package. We're going to stick with the current
>  implementation for the foreseeable future while we expend our effort on
>  problems for which we don't have ready-made solutions.
>
> Hannes has the correct link for the latter discussion, but the original discussion took place at the beginning of Feb[1].
>
> Dale
>
> [1] http://forum.world.st/feedback-on-using-JSON-to-specify-baselines-for-git-repository-td4356301.html
>
>
> ----- Original Message -----
> | From: "Igor Stasenko" <[hidden email]>
> | To: [hidden email]
> | 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 <[hidden email]> 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" <[hidden email]>
> | > | To: [hidden email]
> | > | 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.

Reply | Threaded
Open this post in threaded view
|

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

Hannes Hirzel
In reply to this post by Igor Stasenko
Yes, this was part of the discussion there.

--Hannes

On 4/24/12, Igor Stasenko <[hidden email]> wrote:

> On 24 April 2012 01:57, Igor Stasenko <[hidden email]> 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.
>
>

Reply | Threaded
Open this post in threaded view
|

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

Dale Henrichs
In reply to this post by 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" <[hidden email]>
| To: [hidden email]
| 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 <[hidden email]> wrote:
| > Igor,
| >
| > The short answer is:
| >
| >  We could have used literal arrays, but it would have taken more
| >  work up
| >  front than using the existing (portable) Seaside JSON parser.
| >
| umm.. what more work? Use if existing Smalltalk parser is more work?
|
| IMO, binding to JSON format and introducing dependency is more like a
| problem to me..
|
| but anyways, since i late on party.. i don't wanna put sticks into
| already rotating wheel..
|
| you made a decision, if it works for you, fine.
|
| P.S. I dealt with JSON when playing with SCouchDB project.. i
| wouldn't
| say that i adore this format.
| but it ok.. yeah.. everyone using it. Still s-expressions is IMO far
| more elegant.
|
|
| >  At this point we have working implementations in 5 different
| >  Smalltalk dialects
| >  written to use JSON for properties files.
| >
| >  Cypress is designed to be flexible. FileTree the original Cypress
| >  implementation
| >  reads 3 different disk-based package. We're going to stick with
| >  the current
| >  implementation for the foreseeable future while we expend our
| >  effort on
| >  problems for which we don't have ready-made solutions.
| >
| > Hannes has the correct link for the latter discussion, but the
| > original discussion took place at the beginning of Feb[1].
| >
| > Dale
| >
| > [1]
| > http://forum.world.st/feedback-on-using-JSON-to-specify-baselines-for-git-repository-td4356301.html
| >
| >
| > ----- Original Message -----
| > | From: "Igor Stasenko" <[hidden email]>
| > | To: [hidden email]
| > | 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 <[hidden email]>
| > | 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" <[hidden email]>
| > | > | To: [hidden email]
| > | > | 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.
|
|

Reply | Threaded
Open this post in threaded view
|

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

Igor Stasenko
On 24 April 2012 03:17, Dale Henrichs <[hidden email]> 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" <[hidden email]>
> | To: [hidden email]
> | 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 <[hidden email]> wrote:
> | > Igor,
> | >
> | > The short answer is:
> | >
> | >  We could have used literal arrays, but it would have taken more
> | >  work up
> | >  front than using the existing (portable) Seaside JSON parser.
> | >
> | umm.. what more work? Use if existing Smalltalk parser is more work?
> |
> | IMO, binding to JSON format and introducing dependency is more like a
> | problem to me..
> |
> | but anyways, since i late on party.. i don't wanna put sticks into
> | already rotating wheel..
> |
> | you made a decision, if it works for you, fine.
> |
> | P.S. I dealt with JSON when playing with SCouchDB project.. i
> | wouldn't
> | say that i adore this format.
> | but it ok.. yeah.. everyone using it. Still s-expressions is IMO far
> | more elegant.
> |
> |
> | >  At this point we have working implementations in 5 different
> | >  Smalltalk dialects
> | >  written to use JSON for properties files.
> | >
> | >  Cypress is designed to be flexible. FileTree the original Cypress
> | >  implementation
> | >  reads 3 different disk-based package. We're going to stick with
> | >  the current
> | >  implementation for the foreseeable future while we expend our
> | >  effort on
> | >  problems for which we don't have ready-made solutions.
> | >
> | > Hannes has the correct link for the latter discussion, but the
> | > original discussion took place at the beginning of Feb[1].
> | >
> | > Dale
> | >
> | > [1]
> | > http://forum.world.st/feedback-on-using-JSON-to-specify-baselines-for-git-repository-td4356301.html
> | >
> | >
> | > ----- Original Message -----
> | > | From: "Igor Stasenko" <[hidden email]>
> | > | To: [hidden email]
> | > | 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 <[hidden email]>
> | > | 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" <[hidden email]>
> | > | > | To: [hidden email]
> | > | > | 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.

Reply | Threaded
Open this post in threaded view
|

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

Dale Henrichs
Igor,

GemStone's Smalltalk parser/compiler is implemented in C ...  I told you that JSON is and was a pragmatic choice ...

The seaside JSON parser is 27 methods and runs without change in GemStone ... this is all covered in the other two threads, so maybe you should spend some time reading up on the issues that have already been hashed over twice so far... Oh wait, now there are now three threads that are covering the "why JSON" question:)

Dale

----- Original Message -----
| From: "Igor Stasenko" <[hidden email]>
| To: [hidden email]
| 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 <[hidden email]> 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" <[hidden email]>
| > | To: [hidden email]
| > | 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 <[hidden email]>
| > | wrote:
| > | > Igor,
| > | >
| > | > The short answer is:
| > | >
| > | >  We could have used literal arrays, but it would have taken
| > | >  more
| > | >  work up
| > | >  front than using the existing (portable) Seaside JSON parser.
| > | >
| > | umm.. what more work? Use if existing Smalltalk parser is more
| > | work?
| > |
| > | IMO, binding to JSON format and introducing dependency is more
| > | like a
| > | problem to me..
| > |
| > | but anyways, since i late on party.. i don't wanna put sticks
| > | into
| > | already rotating wheel..
| > |
| > | you made a decision, if it works for you, fine.
| > |
| > | P.S. I dealt with JSON when playing with SCouchDB project.. i
| > | wouldn't
| > | say that i adore this format.
| > | but it ok.. yeah.. everyone using it. Still s-expressions is IMO
| > | far
| > | more elegant.
| > |
| > |
| > | >  At this point we have working implementations in 5 different
| > | >  Smalltalk dialects
| > | >  written to use JSON for properties files.
| > | >
| > | >  Cypress is designed to be flexible. FileTree the original
| > | >  Cypress
| > | >  implementation
| > | >  reads 3 different disk-based package. We're going to stick
| > | >  with
| > | >  the current
| > | >  implementation for the foreseeable future while we expend our
| > | >  effort on
| > | >  problems for which we don't have ready-made solutions.
| > | >
| > | > Hannes has the correct link for the latter discussion, but the
| > | > original discussion took place at the beginning of Feb[1].
| > | >
| > | > Dale
| > | >
| > | > [1]
| > | > http://forum.world.st/feedback-on-using-JSON-to-specify-baselines-for-git-repository-td4356301.html
| > | >
| > | >
| > | > ----- Original Message -----
| > | > | From: "Igor Stasenko" <[hidden email]>
| > | > | To: [hidden email]
| > | > | 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 <[hidden email]>
| > | > | 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" <[hidden email]>
| > | > | > | To: [hidden email]
| > | > | > | 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.
|
|

Reply | Threaded
Open this post in threaded view
|

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

Stéphane Ducasse
In reply to this post by 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 <[hidden email]> wrote:
>> Igor,
>>
>> The short answer is:
>>
>>  We could have used literal arrays, but it would have taken more work up
>>  front than using the existing (portable) Seaside JSON parser.
>>
> umm.. what more work? Use if existing Smalltalk parser is more work?
>
> IMO, binding to JSON format and introducing dependency is more like a
> problem to me..
>
> but anyways, since i late on party.. i don't wanna put sticks into
> already rotating wheel..
>
> you made a decision, if it works for you, fine.
>
> P.S. I dealt with JSON when playing with SCouchDB project.. i wouldn't
> say that i adore this format.
> but it ok.. yeah.. everyone using it. Still s-expressions is IMO far
> more elegant.
>
>
>>  At this point we have working implementations in 5 different Smalltalk dialects
>>  written to use JSON for properties files.
>>
>>  Cypress is designed to be flexible. FileTree the original Cypress implementation
>>  reads 3 different disk-based package. We're going to stick with the current
>>  implementation for the foreseeable future while we expend our effort on
>>  problems for which we don't have ready-made solutions.
>>
>> Hannes has the correct link for the latter discussion, but the original discussion took place at the beginning of Feb[1].
>>
>> Dale
>>
>> [1] http://forum.world.st/feedback-on-using-JSON-to-specify-baselines-for-git-repository-td4356301.html
>>
>>
>> ----- Original Message -----
>> | From: "Igor Stasenko" <[hidden email]>
>> | To: [hidden email]
>> | 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 <[hidden email]> 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" <[hidden email]>
>> | > | To: [hidden email]
>> | > | 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.
>


Reply | Threaded
Open this post in threaded view
|

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

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

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" <[hidden email]>
> | To: [hidden email]
> | 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 <[hidden email]> 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" <[hidden email]>
> | > | To: [hidden email]
> | > | 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 <[hidden email]>
> | > | wrote:
> | > | > Igor,
> | > | >
> | > | > The short answer is:
> | > | >
> | > | >  We could have used literal arrays, but it would have taken
> | > | >  more
> | > | >  work up
> | > | >  front than using the existing (portable) Seaside JSON parser.
> | > | >
> | > | umm.. what more work? Use if existing Smalltalk parser is more
> | > | work?
> | > |
> | > | IMO, binding to JSON format and introducing dependency is more
> | > | like a
> | > | problem to me..
> | > |
> | > | but anyways, since i late on party.. i don't wanna put sticks
> | > | into
> | > | already rotating wheel..
> | > |
> | > | you made a decision, if it works for you, fine.
> | > |
> | > | P.S. I dealt with JSON when playing with SCouchDB project.. i
> | > | wouldn't
> | > | say that i adore this format.
> | > | but it ok.. yeah.. everyone using it. Still s-expressions is IMO
> | > | far
> | > | more elegant.
> | > |
> | > |
> | > | >  At this point we have working implementations in 5 different
> | > | >  Smalltalk dialects
> | > | >  written to use JSON for properties files.
> | > | >
> | > | >  Cypress is designed to be flexible. FileTree the original
> | > | >  Cypress
> | > | >  implementation
> | > | >  reads 3 different disk-based package. We're going to stick
> | > | >  with
> | > | >  the current
> | > | >  implementation for the foreseeable future while we expend our
> | > | >  effort on
> | > | >  problems for which we don't have ready-made solutions.
> | > | >
> | > | > Hannes has the correct link for the latter discussion, but the
> | > | > original discussion took place at the beginning of Feb[1].
> | > | >
> | > | > Dale
> | > | >
> | > | > [1]
> | > | > http://forum.world.st/feedback-on-using-JSON-to-specify-baselines-for-git-repository-td4356301.html
> | > | >
> | > | >
> | > | > ----- Original Message -----
> | > | > | From: "Igor Stasenko" <[hidden email]>
> | > | > | To: [hidden email]
> | > | > | 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 <[hidden email]>
> | > | > | 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" <[hidden email]>
> | > | > | > | To: [hidden email]
> | > | > | > | 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.
> |
> |
>


Reply | Threaded
Open this post in threaded view
|

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

Stéphane Ducasse
In reply to this post by Dale Henrichs
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" <[hidden email]>
> | To: [hidden email]
> | 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 <[hidden email]> 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" <[hidden email]>
> | > | To: [hidden email]
> | > | 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 <[hidden email]>
> | > | wrote:
> | > | > Igor,
> | > | >
> | > | > The short answer is:
> | > | >
> | > | >  We could have used literal arrays, but it would have taken
> | > | >  more
> | > | >  work up
> | > | >  front than using the existing (portable) Seaside JSON parser.
> | > | >
> | > | umm.. what more work? Use if existing Smalltalk parser is more
> | > | work?
> | > |
> | > | IMO, binding to JSON format and introducing dependency is more
> | > | like a
> | > | problem to me..
> | > |
> | > | but anyways, since i late on party.. i don't wanna put sticks
> | > | into
> | > | already rotating wheel..
> | > |
> | > | you made a decision, if it works for you, fine.
> | > |
> | > | P.S. I dealt with JSON when playing with SCouchDB project.. i
> | > | wouldn't
> | > | say that i adore this format.
> | > | but it ok.. yeah.. everyone using it. Still s-expressions is IMO
> | > | far
> | > | more elegant.
> | > |
> | > |
> | > | >  At this point we have working implementations in 5 different
> | > | >  Smalltalk dialects
> | > | >  written to use JSON for properties files.
> | > | >
> | > | >  Cypress is designed to be flexible. FileTree the original
> | > | >  Cypress
> | > | >  implementation
> | > | >  reads 3 different disk-based package. We're going to stick
> | > | >  with
> | > | >  the current
> | > | >  implementation for the foreseeable future while we expend our
> | > | >  effort on
> | > | >  problems for which we don't have ready-made solutions.
> | > | >
> | > | > Hannes has the correct link for the latter discussion, but the
> | > | > original discussion took place at the beginning of Feb[1].
> | > | >
> | > | > Dale
> | > | >
> | > | > [1]
> | > | > http://forum.world.st/feedback-on-using-JSON-to-specify-baselines-for-git-repository-td4356301.html
> | > | >
> | > | >
> | > | > ----- Original Message -----
> | > | > | From: "Igor Stasenko" <[hidden email]>
> | > | > | To: [hidden email]
> | > | > | 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 <[hidden email]>
> | > | > | 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" <[hidden email]>
> | > | > | > | To: [hidden email]
> | > | > | > | 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.
> |
> |
>


Reply | Threaded
Open this post in threaded view
|

Tirade! (was: Re: About Cypress [Was: Re: [ANN] Styled Text Editor for Cuis 4.0 Smalltalk])

Göran Krampe
In reply to this post by Stéphane Ducasse
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

Reply | Threaded
Open this post in threaded view
|

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

Francisco Garau-2
In reply to this post by Stéphane Ducasse
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 <[hidden email]> 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

 
Reply | Threaded
Open this post in threaded view
|

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

NorbertHartl

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 <[hidden email]> 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

 

Reply | Threaded
Open this post in threaded view
|

Re: Tirade! (was: Re: About Cypress [Was: Re: [ANN] Styled Text Editor for Cuis 4.0 Smalltalk])

Sven Van Caekenberghe
In reply to this post by Göran Krampe

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
Reply | Threaded
Open this post in threaded view
|

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

EstebanLM
In reply to this post by NorbertHartl
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 <[hidden email]> 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

 


1234