April 2012 - Pharo-dev - lists.pharo.org

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

by Igor Stasenko

On 24 April 2012 01:54, Dale Henrichs <dhenrich(a)vmware.com> wrote: > Igor, > > The short answer is: > > Â We could have used literal arrays, but it would have taken more work up > Â front than using the existing (portable) Seaside JSON parser. > umm.. what more work? Use if existing Smalltalk parser is more work? IMO, binding to JSON format and introducing dependency is more like a problem to me.. but anyways, since i late on party.. i don't wanna put sticks into already rotating wheel.. you made a decision, if it works for you, fine. P.S. I dealt with JSON when playing with SCouchDB project.. i wouldn't say that i adore this format. but it ok.. yeah.. everyone using it. Still s-expressions is IMO far more elegant. > Â At this point we have working implementations in 5 different Smalltalk dialects > Â written to use JSON for properties files. > > Â Cypress is designed to be flexible. FileTree the original Cypress implementation > Â reads 3 different disk-based package. We're going to stick with the current > Â implementation for the foreseeable future while we expend our effort on > Â problems for which we don't have ready-made solutions. > > Hannes has the correct link for the latter discussion, but the original discussion took place at the beginning of Feb[1]. > > Dale > > [1] http://forum.world.st/feedback-on-using-JSON-to-specify-baselines-for-git-r… > > > ----- Original Message ----- > | From: "Igor Stasenko" <siguctua(a)gmail.com> > | To: Pharo-project(a)lists.gforge.inria.fr > | Sent: Monday, April 23, 2012 2:34:54 PM > | Subject: [Pharo-project] About Cypress [Was: Re: [ANN] Styled Text Editor for Cuis 4.0 Smalltalk] > | > | Hi, Dale > | > | it is great to see an effort in such direction. > | I just wonder what .js files doing there? > | > | According to what i see, it is just a meta data which holding > | additional properties per entity.. > | > | { > | "category" : "Cypress-Tests", > | "classinstvars" : [ > | ], > | "classtraitcomposition" : "{}", > | "classvars" : [ > | ], > | "commentStamp" : "", > | "instvars" : [ > | ], > | "name" : "CypressPatchTest", > | "pools" : [ > | ], > | "super" : "CypressAbstractTest", > | "traitcomposition" : "{}", > | "type" : "normal" } > | > | why you cannot use a regular smalltalk literal syntax for this data? > | What/why there is need to store this data in json format? > | > | On 23 April 2012 23:57, Dale Henrichs <dhenrich(a)vmware.com> wrote: > | > Bernhard, > | > > | > With regards to sharing code between dialects, I'd like to > | > recommend that you look into porting Cypress to Cuis (I'm willing > | > to help as much as I can). > | > > | > The Cypress project is aimed from the get go to enable sharing of > | > packages between Smalltalk dialects with a recognition that > | > possibly the most important aspect is a shared VCS (git/github). > | > > | > If you look at the current code base in Cypress, you will see a > | > reference implementation written against Pharo. The reference > | > implementation is a work in progress and the initial > | > implementation was done for Amber[2]. > | > > | > Cypress has Monticello-like packages, but other than taking a few > | > ideas from Monticello (definitions, packages and snapshots ... > | > more than a few:)) the code base is independent of Monticello. The > | > fact that Cypress runs on top of Amber (sans file system access) > | > speaks volumes for it's portability. > | > > | > To paraphrase a point from my STIC talk[3] on this subject: > | > > | > Â Cypress is not intended to be the primary version control > | > Â system for any dialect, however, if you want to share code > | > Â between dialects you should allow your developers to import > | > Â and export code using the Cypress package format. > | > > | > If you are interested, there are bits and pieces of code in a few > | > other projects that I would want to pull into the Cypress project > | > and couple other things that I'd like to move out of the Cypress > | > project before tackling another port ... > | > > | > We can correspond via private email if you'd like to take me up on > | > the offer of help:) > | > > | > Dale > | > > | > [1] https://github.com/CampSmalltalk/Cypress > | > [2] https://github.com/CampSmalltalk/amber-cypress > | > [3] > | > http://portal.sliderocket.com/vmware/STIC-2012-Practical-Git-for-Smalltalk > | > > | > ----- Original Message ----- > | > | From: "Bernhard Pieber" <bernhard(a)pieber.com> > | > | To: Pharo-project(a)lists.gforge.inria.fr > | > | Sent: Monday, April 23, 2012 9:53:35 AM > | > | Subject: Re: [Pharo-project] [ANN] Styled Text Editor for Cuis > | > | 4.0 Smalltalk > | > | > | > | Hi GÃ¶ran, > | > | > | > | Thanks for your question! I have posted the announcement of the > | > | Styled Text Editor to the Pharo list as well because I still have > | > | not given up on the idea to port it to Squeak and Pharo. It is > | > | not > | > | straightforward but I consider it possible. > | > | > | > | Currently the Styled Text Editor is an external package which is > | > | loaded on top of Cuis 4.0. The API it uses is quite specific to > | > | Cuis > | > | so to port it alone is probably too much effort. What I think can > | > | be > | > | done is the following: > | > | Split Cuis into three parts, > | > | a) the parts which are not needed for Styled Text Editor, like > | > | the > | > | Cuis tools > | > | b) the parts of Cuis Morphic the Styled Text Editor depends on â > | > | this > | > | is in my opinion the most valuable part of Cuis because Juan > | > | spent > | > | years cleaning it > | > | c) the Smalltalk kernel below > | > | > | > | The idea is to port only part b) and the Styled Text Editor. And > | > | it > | > | has to be done automatically by a tool which creates packages for > | > | Squeak and Pharo, always from the latest code base. In addition > | > | you > | > | will probably need small Cuis portability packages done manually, > | > | one for Squeak and one for Pharo. > | > | > | > | Being able to always load the latest code base of Styled Text > | > | Editor > | > | and Cuis Morphic as an external package in Pharo is a > | > | prerequisite > | > | to look into possibilities of sharing more of the code. > | > | > | > | I plan to write a more detailed proposal and then to approach > | > | ESUG > | > | and ask for support for the funding. Any ideas for other sources > | > | of > | > | funding are highly welcome and could speed things up > | > | considerably, > | > | of course! ;-) > | > | > | > | I for one have not given up on the idea that it might be possible > | > | to > | > | develop substantial components as you called it â thank you for > | > | that > | > | as well â in a more Squeak-dialect-independent way. ;-) > | > | > | > | Finally, I would like to take the opportunity and kindly ask > | > | everyone > | > | who has not done so yet: Please check out Cuis 4.0 and the Styled > | > | Text Editor and give us feedback, even if it does not (yet) run > | > | on > | > | your favourite Squeak dialect! Thank you! > | > | > | > | Peace, > | > | Bernhard > | > | > | > | P.S. Thanks to GÃ¶ran and Janko for trying to establish different > | > | threads for the rather off-topic discussions that my announcement > | > | posting has caused. > | > | > | > | Am 23.04.2012 um 16:04 schrieb GÃ¶ran Krampe: > | > | > Hi! > | > | > > | > | > On 04/23/2012 03:40 PM, StÃ©phane Ducasse wrote: > | > | >>> Just cloning it off into Pharo and forking seems... less > | > | >>> optimal. > | > | >>> Any ideas or thoughts? > | > | >> > | > | >> I do not get what you mean. I just want to work on our roadmap > | > | >> and > | > | >> make it getting real. > | > | >> It is hard enough to get some momentum and to deliver for > | > | >> real. > | > | >> So can you help us to get focused? > | > | >> People can do what they want. I wrote a vision document. We > | > | >> have a > | > | >> roadmap > | > | >> and we will do it. > | > | > > | > | > Ok, let me clarify. I was just wondering how the Pharo > | > | > community > | > | > wants to handle a case where a substantial component (in this > | > | > case, this new editor) is not *primarily* developed in Pharo > | > | > (in > | > | > this case Cuis). > | > | > > | > | > The simple route is to just copy and fork. But IMHO this > | > | > doesn't > | > | > leverage the team already around this editor, right? We (Pharo) > | > | > can't just go around and forking everything and maintaining > | > | > everything for ourselves, right? > | > | > > | > | > I just got interested in that problem - now, later replies > | > | > indicated that it would still need a substantial rewrite for > | > | > Pharo, so perhaps the situation I am describing is not really > | > | > applicable in this case. > | > | > > | > | > regards, GÃ¶ran > | > | > > | > | > | > | > | > | > | > > | > | > | > | -- > | Best regards, > | Igor Stasenko. > | > | > -- Best regards, Igor Stasenko.

April 23, 2012

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

by Igor Stasenko

On 24 April 2012 01:57, Igor Stasenko <siguctua(a)gmail.com> wrote: > Oh, i'm not subscribed to that list. > > Anyways.. > since i late on the party.. just wanna put my 2 cents here: > > you don't need a literal dictionary syntax to be able to (de)serialize > dictionaries. > > Just a simple example: > > we start from: > > #( propertyName value ) > > ok, some values can be arrays: > > #( propertyName ( array of values) ) > > and some values can be dictionaries: > > #( propertyName #dict ( key1 value1 key2 value2 ... ) ) > > and to avoid ambugility, you can just put #symbol, to indicate that > next element is symbol: > > #( propertyName #symbol #dict) > > so it won't try to construct a dictionary, but just use #dict as a > symbol value for propery, > same for #symbol itself: > > #(propertyName #symbol #symbol) > > ... and of course there can be numerous other ways for doing that. > > and sure.. you're free to introduce any other keywords to meet your needs... i.e. #( top #point (10 20)) will produce: { #top. 10@20 }. -- Best regards, Igor Stasenko.

April 23, 2012

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

by Igor Stasenko

Oh, i'm not subscribed to that list. Anyways.. since i late on the party.. just wanna put my 2 cents here: you don't need a literal dictionary syntax to be able to (de)serialize dictionaries. Just a simple example: we start from: #( propertyName value ) ok, some values can be arrays: #( propertyName ( array of values) ) and some values can be dictionaries: #( propertyName #dict ( key1 value1 key2 value2 ... ) ) and to avoid ambugility, you can just put #symbol, to indicate that next element is symbol: #( propertyName #symbol #dict) so it won't try to construct a dictionary, but just use #dict as a symbol value for propery, same for #symbol itself: #(propertyName #symbol #symbol) ... and of course there can be numerous other ways for doing that. On 24 April 2012 01:19, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: > You are right. It is hidden in another thread > > http://forum.world.st/FileTree-and-Cypress-status-td4543773.html > 'FileTree and Cypress status' > > The basic outcome was that it is a matter of taste and that Dale does > not want to be bothered. In addition other Smalltalkers support it. > See signatures on photo at the bottom of > https://github.com/CampSmalltalk/Cypress/wiki > > --Hannes > > > > On 4/24/12, Igor Stasenko <siguctua(a)gmail.com> wrote: >> On 24 April 2012 00:56, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: >>> Hello Igor >>> >>> This has been discussed on the Metacello mailing list on the 11 and >>> 12th of this month. >> >> can you please give me a direct link to thread? >> too much mails.. too much mails. >> :) >> >>> >>> Regards >>> Hannes >>> >>> On 4/23/12, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>> Hi, Dale >>>> >>>> it is great to see an effort in such direction. >>>> I just wonder what .js files doing there? >>>> >>>> According to what i see, it is just a meta data which holding >>>> additional properties per entity.. >>>> >>>> { >>>> "category" : "Cypress-Tests", >>>> "classinstvars" : [ >>>> ], >>>> "classtraitcomposition" : "{}", >>>> "classvars" : [ >>>> ], >>>> "commentStamp" : "", >>>> "instvars" : [ >>>> ], >>>> "name" : "CypressPatchTest", >>>> "pools" : [ >>>> ], >>>> "super" : "CypressAbstractTest", >>>> "traitcomposition" : "{}", >>>> "type" : "normal" } >>>> >>>> why you cannot use a regular smalltalk literal syntax for this data? >>>> What/why there is need to store this data in json format? >>>> >>>> On 23 April 2012 23:57, Dale Henrichs <dhenrich(a)vmware.com> wrote: >>>>> Bernhard, >>>>> >>>>> With regards to sharing code between dialects, I'd like to recommend >>>>> that >>>>> you look into porting Cypress to Cuis (I'm willing to help as much as I >>>>> can). >>>>> >>>>> The Cypress project is aimed from the get go to enable sharing of >>>>> packages >>>>> between Smalltalk dialects with a recognition that possibly the most >>>>> important aspect is a shared VCS (git/github). >>>>> >>>>> If you look at the current code base in Cypress, you will see a >>>>> reference >>>>> implementation written against Pharo. The reference implementation is a >>>>> work in progress and the initial implementation was done for Amber[2]. >>>>> >>>>> Cypress has Monticello-like packages, but other than taking a few ideas >>>>> from Monticello (definitions, packages and snapshots ... more than a >>>>> few:)) the code base is independent of Monticello. The fact that Cypress >>>>> runs on top of Amber (sans file system access) speaks volumes for it's >>>>> portability. >>>>> >>>>> To paraphrase a point from my STIC talk[3] on this subject: >>>>> >>>>> Â Cypress is not intended to be the primary version control >>>>> Â system for any dialect, however, if you want to share code >>>>> Â between dialects you should allow your developers to import >>>>> Â and export code using the Cypress package format. >>>>> >>>>> If you are interested, there are bits and pieces of code in a few other >>>>> projects that I would want to pull into the Cypress project and couple >>>>> other things that I'd like to move out of the Cypress project before >>>>> tackling another port ... >>>>> >>>>> We can correspond via private email if you'd like to take me up on the >>>>> offer of help:) >>>>> >>>>> Dale >>>>> >>>>> [1] https://github.com/CampSmalltalk/Cypress >>>>> [2] https://github.com/CampSmalltalk/amber-cypress >>>>> [3] >>>>> http://portal.sliderocket.com/vmware/STIC-2012-Practical-Git-for-Smalltalk >>>>> >>>>> ----- Original Message ----- >>>>> | From: "Bernhard Pieber" <bernhard(a)pieber.com> >>>>> | To: Pharo-project(a)lists.gforge.inria.fr >>>>> | Sent: Monday, April 23, 2012 9:53:35 AM >>>>> | Subject: Re: [Pharo-project] [ANN] Styled Text Editor for Cuis 4.0 >>>>> Smalltalk >>>>> | >>>>> | Hi GÃ¶ran, >>>>> | >>>>> | Thanks for your question! I have posted the announcement of the >>>>> | Styled Text Editor to the Pharo list as well because I still have >>>>> | not given up on the idea to port it to Squeak and Pharo. It is not >>>>> | straightforward but I consider it possible. >>>>> | >>>>> | Currently the Styled Text Editor is an external package which is >>>>> | loaded on top of Cuis 4.0. The API it uses is quite specific to Cuis >>>>> | so to port it alone is probably too much effort. What I think can be >>>>> | done is the following: >>>>> | Split Cuis into three parts, >>>>> | a) the parts which are not needed for Styled Text Editor, like the >>>>> | Cuis tools >>>>> | b) the parts of Cuis Morphic the Styled Text Editor depends on â this >>>>> | is in my opinion the most valuable part of Cuis because Juan spent >>>>> | years cleaning it >>>>> | c) the Smalltalk kernel below >>>>> | >>>>> | The idea is to port only part b) and the Styled Text Editor. And it >>>>> | has to be done automatically by a tool which creates packages for >>>>> | Squeak and Pharo, always from the latest code base. In addition you >>>>> | will probably need small Cuis portability packages done manually, >>>>> | one for Squeak and one for Pharo. >>>>> | >>>>> | Being able to always load the latest code base of Styled Text Editor >>>>> | and Cuis Morphic as an external package in Pharo is a prerequisite >>>>> | to look into possibilities of sharing more of the code. >>>>> | >>>>> | I plan to write a more detailed proposal and then to approach ESUG >>>>> | and ask for support for the funding. Any ideas for other sources of >>>>> | funding are highly welcome and could speed things up considerably, >>>>> | of course! ;-) >>>>> | >>>>> | I for one have not given up on the idea that it might be possible to >>>>> | develop substantial components as you called it â thank you for that >>>>> | as well â in a more Squeak-dialect-independent way. ;-) >>>>> | >>>>> | Finally, I would like to take the opportunity and kindly ask everyone >>>>> | who has not done so yet: Please check out Cuis 4.0 and the Styled >>>>> | Text Editor and give us feedback, even if it does not (yet) run on >>>>> | your favourite Squeak dialect! Thank you! >>>>> | >>>>> | Peace, >>>>> | Bernhard >>>>> | >>>>> | P.S. Thanks to GÃ¶ran and Janko for trying to establish different >>>>> | threads for the rather off-topic discussions that my announcement >>>>> | posting has caused. >>>>> | >>>>> | Am 23.04.2012 um 16:04 schrieb GÃ¶ran Krampe: >>>>> | > Hi! >>>>> | > >>>>> | > On 04/23/2012 03:40 PM, StÃ©phane Ducasse wrote: >>>>> | >>> Just cloning it off into Pharo and forking seems... less optimal. >>>>> | >>> Any ideas or thoughts? >>>>> | >> >>>>> | >> I do not get what you mean. I just want to work on our roadmap and >>>>> | >> make it getting real. >>>>> | >> It is hard enough to get some momentum and to deliver for real. >>>>> | >> So can you help us to get focused? >>>>> | >> People can do what they want. I wrote a vision document. We have a >>>>> | >> roadmap >>>>> | >> and we will do it. >>>>> | > >>>>> | > Ok, let me clarify. I was just wondering how the Pharo community >>>>> | > wants to handle a case where a substantial component (in this >>>>> | > case, this new editor) is not *primarily* developed in Pharo (in >>>>> | > this case Cuis). >>>>> | > >>>>> | > The simple route is to just copy and fork. But IMHO this doesn't >>>>> | > leverage the team already around this editor, right? We (Pharo) >>>>> | > can't just go around and forking everything and maintaining >>>>> | > everything for ourselves, right? >>>>> | > >>>>> | > I just got interested in that problem - now, later replies >>>>> | > indicated that it would still need a substantial rewrite for >>>>> | > Pharo, so perhaps the situation I am describing is not really >>>>> | > applicable in this case. >>>>> | > >>>>> | > regards, GÃ¶ran >>>>> | > >>>>> | >>>>> | >>>>> | >>>>> >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>>> >>>> >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> >> > -- Best regards, Igor Stasenko.

April 23, 2012

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

by Dale Henrichs

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-r… ----- Original Message ----- | From: "Igor Stasenko" <siguctua(a)gmail.com> | To: Pharo-project(a)lists.gforge.inria.fr | Sent: Monday, April 23, 2012 2:34:54 PM | Subject: [Pharo-project] About Cypress [Was: Re: [ANN] Styled Text Editor for Cuis 4.0 Smalltalk] | | Hi, Dale | | it is great to see an effort in such direction. | I just wonder what .js files doing there? | | According to what i see, it is just a meta data which holding | additional properties per entity.. | | { | "category" : "Cypress-Tests", | "classinstvars" : [ | ], | "classtraitcomposition" : "{}", | "classvars" : [ | ], | "commentStamp" : "", | "instvars" : [ | ], | "name" : "CypressPatchTest", | "pools" : [ | ], | "super" : "CypressAbstractTest", | "traitcomposition" : "{}", | "type" : "normal" } | | why you cannot use a regular smalltalk literal syntax for this data? | What/why there is need to store this data in json format? | | On 23 April 2012 23:57, Dale Henrichs <dhenrich(a)vmware.com> wrote: | > Bernhard, | > | > With regards to sharing code between dialects, I'd like to | > recommend that you look into porting Cypress to Cuis (I'm willing | > to help as much as I can). | > | > The Cypress project is aimed from the get go to enable sharing of | > packages between Smalltalk dialects with a recognition that | > possibly the most important aspect is a shared VCS (git/github). | > | > If you look at the current code base in Cypress, you will see a | > reference implementation written against Pharo. The reference | > implementation is a work in progress and the initial | > implementation was done for Amber[2]. | > | > Cypress has Monticello-like packages, but other than taking a few | > ideas from Monticello (definitions, packages and snapshots ... | > more than a few:)) the code base is independent of Monticello. The | > fact that Cypress runs on top of Amber (sans file system access) | > speaks volumes for it's portability. | > | > To paraphrase a point from my STIC talk[3] on this subject: | > | > Â Cypress is not intended to be the primary version control | > Â system for any dialect, however, if you want to share code | > Â between dialects you should allow your developers to import | > Â and export code using the Cypress package format. | > | > If you are interested, there are bits and pieces of code in a few | > other projects that I would want to pull into the Cypress project | > and couple other things that I'd like to move out of the Cypress | > project before tackling another port ... | > | > We can correspond via private email if you'd like to take me up on | > the offer of help:) | > | > Dale | > | > [1] https://github.com/CampSmalltalk/Cypress | > [2] https://github.com/CampSmalltalk/amber-cypress | > [3] | > http://portal.sliderocket.com/vmware/STIC-2012-Practical-Git-for-Smalltalk | > | > ----- Original Message ----- | > | From: "Bernhard Pieber" <bernhard(a)pieber.com> | > | To: Pharo-project(a)lists.gforge.inria.fr | > | Sent: Monday, April 23, 2012 9:53:35 AM | > | Subject: Re: [Pharo-project] [ANN] Styled Text Editor for Cuis | > | 4.0 Smalltalk | > | | > | Hi GÃ¶ran, | > | | > | Thanks for your question! I have posted the announcement of the | > | Styled Text Editor to the Pharo list as well because I still have | > | not given up on the idea to port it to Squeak and Pharo. It is | > | not | > | straightforward but I consider it possible. | > | | > | Currently the Styled Text Editor is an external package which is | > | loaded on top of Cuis 4.0. The API it uses is quite specific to | > | Cuis | > | so to port it alone is probably too much effort. What I think can | > | be | > | done is the following: | > | Split Cuis into three parts, | > | a) the parts which are not needed for Styled Text Editor, like | > | the | > | Cuis tools | > | b) the parts of Cuis Morphic the Styled Text Editor depends on â | > | this | > | is in my opinion the most valuable part of Cuis because Juan | > | spent | > | years cleaning it | > | c) the Smalltalk kernel below | > | | > | The idea is to port only part b) and the Styled Text Editor. And | > | it | > | has to be done automatically by a tool which creates packages for | > | Squeak and Pharo, always from the latest code base. In addition | > | you | > | will probably need small Cuis portability packages done manually, | > | one for Squeak and one for Pharo. | > | | > | Being able to always load the latest code base of Styled Text | > | Editor | > | and Cuis Morphic as an external package in Pharo is a | > | prerequisite | > | to look into possibilities of sharing more of the code. | > | | > | I plan to write a more detailed proposal and then to approach | > | ESUG | > | and ask for support for the funding. Any ideas for other sources | > | of | > | funding are highly welcome and could speed things up | > | considerably, | > | of course! ;-) | > | | > | I for one have not given up on the idea that it might be possible | > | to | > | develop substantial components as you called it â thank you for | > | that | > | as well â in a more Squeak-dialect-independent way. ;-) | > | | > | Finally, I would like to take the opportunity and kindly ask | > | everyone | > | who has not done so yet: Please check out Cuis 4.0 and the Styled | > | Text Editor and give us feedback, even if it does not (yet) run | > | on | > | your favourite Squeak dialect! Thank you! | > | | > | Peace, | > | Bernhard | > | | > | P.S. Thanks to GÃ¶ran and Janko for trying to establish different | > | threads for the rather off-topic discussions that my announcement | > | posting has caused. | > | | > | Am 23.04.2012 um 16:04 schrieb GÃ¶ran Krampe: | > | > Hi! | > | > | > | > On 04/23/2012 03:40 PM, StÃ©phane Ducasse wrote: | > | >>> Just cloning it off into Pharo and forking seems... less | > | >>> optimal. | > | >>> Any ideas or thoughts? | > | >> | > | >> I do not get what you mean. I just want to work on our roadmap | > | >> and | > | >> make it getting real. | > | >> It is hard enough to get some momentum and to deliver for | > | >> real. | > | >> So can you help us to get focused? | > | >> People can do what they want. I wrote a vision document. We | > | >> have a | > | >> roadmap | > | >> and we will do it. | > | > | > | > Ok, let me clarify. I was just wondering how the Pharo | > | > community | > | > wants to handle a case where a substantial component (in this | > | > case, this new editor) is not *primarily* developed in Pharo | > | > (in | > | > this case Cuis). | > | > | > | > The simple route is to just copy and fork. But IMHO this | > | > doesn't | > | > leverage the team already around this editor, right? We (Pharo) | > | > can't just go around and forking everything and maintaining | > | > everything for ourselves, right? | > | > | > | > I just got interested in that problem - now, later replies | > | > indicated that it would still need a substantial rewrite for | > | > Pharo, so perhaps the situation I am describing is not really | > | > applicable in this case. | > | > | > | > regards, GÃ¶ran | > | > | > | | > | | > | | > | | | | -- | Best regards, | Igor Stasenko. | |

April 23, 2012

Re: [Pharo-project] monticello repos speedup

by Dale Henrichs

April 23, 2012

Re: [Pharo-project] new icon set

by Martin Sandiford

How about "cake" from the silk set? :) More seriously, what about "rosette"? I'm guessing that this is the set used: http://www.famfamfam.com/lab/icons/silk/previews/index_abc.png The bullets look kind of familiar from OmniBrowser test cases. Cheers, Martin On Mon, Apr 23, 2012 at 11:02 PM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > I like them.Â Except for the test runner one :P.Â Isn't there any other > nicer?

April 23, 2012

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

by H. Hirzel

You are right. It is hidden in another thread http://forum.world.st/FileTree-and-Cypress-status-td4543773.html 'FileTree and Cypress status' The basic outcome was that it is a matter of taste and that Dale does not want to be bothered. In addition other Smalltalkers support it. See signatures on photo at the bottom of https://github.com/CampSmalltalk/Cypress/wiki --Hannes On 4/24/12, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 24 April 2012 00:56, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: >> Hello Igor >> >> This has been discussed on the Metacello mailing list on the 11 and >> 12th of this month. > > can you please give me a direct link to thread? > too much mails.. too much mails. > :) > >> >> Regards >> Hannes >> >> On 4/23/12, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> Hi, Dale >>> >>> it is great to see an effort in such direction. >>> I just wonder what .js files doing there? >>> >>> According to what i see, it is just a meta data which holding >>> additional properties per entity.. >>> >>> { >>> "category" : "Cypress-Tests", >>> "classinstvars" : [ >>> ], >>> "classtraitcomposition" : "{}", >>> "classvars" : [ >>> ], >>> "commentStamp" : "", >>> "instvars" : [ >>> ], >>> "name" : "CypressPatchTest", >>> "pools" : [ >>> ], >>> "super" : "CypressAbstractTest", >>> "traitcomposition" : "{}", >>> "type" : "normal" } >>> >>> why you cannot use a regular smalltalk literal syntax for this data? >>> What/why there is need to store this data in json format? >>> >>> On 23 April 2012 23:57, Dale Henrichs <dhenrich(a)vmware.com> wrote: >>>> Bernhard, >>>> >>>> With regards to sharing code between dialects, I'd like to recommend >>>> that >>>> you look into porting Cypress to Cuis (I'm willing to help as much as I >>>> can). >>>> >>>> The Cypress project is aimed from the get go to enable sharing of >>>> packages >>>> between Smalltalk dialects with a recognition that possibly the most >>>> important aspect is a shared VCS (git/github). >>>> >>>> If you look at the current code base in Cypress, you will see a >>>> reference >>>> implementation written against Pharo. The reference implementation is a >>>> work in progress and the initial implementation was done for Amber[2]. >>>> >>>> Cypress has Monticello-like packages, but other than taking a few ideas >>>> from Monticello (definitions, packages and snapshots ... more than a >>>> few:)) the code base is independent of Monticello. The fact that Cypress >>>> runs on top of Amber (sans file system access) speaks volumes for it's >>>> portability. >>>> >>>> To paraphrase a point from my STIC talk[3] on this subject: >>>> >>>> Â Cypress is not intended to be the primary version control >>>> Â system for any dialect, however, if you want to share code >>>> Â between dialects you should allow your developers to import >>>> Â and export code using the Cypress package format. >>>> >>>> If you are interested, there are bits and pieces of code in a few other >>>> projects that I would want to pull into the Cypress project and couple >>>> other things that I'd like to move out of the Cypress project before >>>> tackling another port ... >>>> >>>> We can correspond via private email if you'd like to take me up on the >>>> offer of help:) >>>> >>>> Dale >>>> >>>> [1] https://github.com/CampSmalltalk/Cypress >>>> [2] https://github.com/CampSmalltalk/amber-cypress >>>> [3] >>>> http://portal.sliderocket.com/vmware/STIC-2012-Practical-Git-for-Smalltalk >>>> >>>> ----- Original Message ----- >>>> | From: "Bernhard Pieber" <bernhard(a)pieber.com> >>>> | To: Pharo-project(a)lists.gforge.inria.fr >>>> | Sent: Monday, April 23, 2012 9:53:35 AM >>>> | Subject: Re: [Pharo-project] [ANN] Styled Text Editor for Cuis 4.0 >>>> Smalltalk >>>> | >>>> | Hi GÃ¶ran, >>>> | >>>> | Thanks for your question! I have posted the announcement of the >>>> | Styled Text Editor to the Pharo list as well because I still have >>>> | not given up on the idea to port it to Squeak and Pharo. It is not >>>> | straightforward but I consider it possible. >>>> | >>>> | Currently the Styled Text Editor is an external package which is >>>> | loaded on top of Cuis 4.0. The API it uses is quite specific to Cuis >>>> | so to port it alone is probably too much effort. What I think can be >>>> | done is the following: >>>> | Split Cuis into three parts, >>>> | a) the parts which are not needed for Styled Text Editor, like the >>>> | Cuis tools >>>> | b) the parts of Cuis Morphic the Styled Text Editor depends on â this >>>> | is in my opinion the most valuable part of Cuis because Juan spent >>>> | years cleaning it >>>> | c) the Smalltalk kernel below >>>> | >>>> | The idea is to port only part b) and the Styled Text Editor. And it >>>> | has to be done automatically by a tool which creates packages for >>>> | Squeak and Pharo, always from the latest code base. In addition you >>>> | will probably need small Cuis portability packages done manually, >>>> | one for Squeak and one for Pharo. >>>> | >>>> | Being able to always load the latest code base of Styled Text Editor >>>> | and Cuis Morphic as an external package in Pharo is a prerequisite >>>> | to look into possibilities of sharing more of the code. >>>> | >>>> | I plan to write a more detailed proposal and then to approach ESUG >>>> | and ask for support for the funding. Any ideas for other sources of >>>> | funding are highly welcome and could speed things up considerably, >>>> | of course! ;-) >>>> | >>>> | I for one have not given up on the idea that it might be possible to >>>> | develop substantial components as you called it â thank you for that >>>> | as well â in a more Squeak-dialect-independent way. ;-) >>>> | >>>> | Finally, I would like to take the opportunity and kindly ask everyone >>>> | who has not done so yet: Please check out Cuis 4.0 and the Styled >>>> | Text Editor and give us feedback, even if it does not (yet) run on >>>> | your favourite Squeak dialect! Thank you! >>>> | >>>> | Peace, >>>> | Bernhard >>>> | >>>> | P.S. Thanks to GÃ¶ran and Janko for trying to establish different >>>> | threads for the rather off-topic discussions that my announcement >>>> | posting has caused. >>>> | >>>> | Am 23.04.2012 um 16:04 schrieb GÃ¶ran Krampe: >>>> | > Hi! >>>> | > >>>> | > On 04/23/2012 03:40 PM, StÃ©phane Ducasse wrote: >>>> | >>> Just cloning it off into Pharo and forking seems... less optimal. >>>> | >>> Any ideas or thoughts? >>>> | >> >>>> | >> I do not get what you mean. I just want to work on our roadmap and >>>> | >> make it getting real. >>>> | >> It is hard enough to get some momentum and to deliver for real. >>>> | >> So can you help us to get focused? >>>> | >> People can do what they want. I wrote a vision document. We have a >>>> | >> roadmap >>>> | >> and we will do it. >>>> | > >>>> | > Ok, let me clarify. I was just wondering how the Pharo community >>>> | > wants to handle a case where a substantial component (in this >>>> | > case, this new editor) is not *primarily* developed in Pharo (in >>>> | > this case Cuis). >>>> | > >>>> | > The simple route is to just copy and fork. But IMHO this doesn't >>>> | > leverage the team already around this editor, right? We (Pharo) >>>> | > can't just go around and forking everything and maintaining >>>> | > everything for ourselves, right? >>>> | > >>>> | > I just got interested in that problem - now, later replies >>>> | > indicated that it would still need a substantial rewrite for >>>> | > Pharo, so perhaps the situation I am describing is not really >>>> | > applicable in this case. >>>> | > >>>> | > regards, GÃ¶ran >>>> | > >>>> | >>>> | >>>> | >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >>> >> > > > > -- > Best regards, > Igor Stasenko. > >

April 23, 2012

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

by Igor Stasenko

On 24 April 2012 00:56, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: > Hello Igor > > This has been discussed on the Metacello mailing list on the 11 and > 12th of this month. can you please give me a direct link to thread? too much mails.. too much mails. :) > > Regards > Hannes > > On 4/23/12, Igor Stasenko <siguctua(a)gmail.com> wrote: >> Hi, Dale >> >> it is great to see an effort in such direction. >> I just wonder what .js files doing there? >> >> According to what i see, it is just a meta data which holding >> additional properties per entity.. >> >> { >> "category" : "Cypress-Tests", >> "classinstvars" : [ >> ], >> "classtraitcomposition" : "{}", >> "classvars" : [ >> ], >> "commentStamp" : "", >> "instvars" : [ >> ], >> "name" : "CypressPatchTest", >> "pools" : [ >> ], >> "super" : "CypressAbstractTest", >> "traitcomposition" : "{}", >> "type" : "normal" } >> >> why you cannot use a regular smalltalk literal syntax for this data? >> What/why there is need to store this data in json format? >> >> On 23 April 2012 23:57, Dale Henrichs <dhenrich(a)vmware.com> wrote: >>> Bernhard, >>> >>> With regards to sharing code between dialects, I'd like to recommend that >>> you look into porting Cypress to Cuis (I'm willing to help as much as I >>> can). >>> >>> The Cypress project is aimed from the get go to enable sharing of packages >>> between Smalltalk dialects with a recognition that possibly the most >>> important aspect is a shared VCS (git/github). >>> >>> If you look at the current code base in Cypress, you will see a reference >>> implementation written against Pharo. The reference implementation is a >>> work in progress and the initial implementation was done for Amber[2]. >>> >>> Cypress has Monticello-like packages, but other than taking a few ideas >>> from Monticello (definitions, packages and snapshots ... more than a >>> few:)) the code base is independent of Monticello. The fact that Cypress >>> runs on top of Amber (sans file system access) speaks volumes for it's >>> portability. >>> >>> To paraphrase a point from my STIC talk[3] on this subject: >>> >>> Â Cypress is not intended to be the primary version control >>> Â system for any dialect, however, if you want to share code >>> Â between dialects you should allow your developers to import >>> Â and export code using the Cypress package format. >>> >>> If you are interested, there are bits and pieces of code in a few other >>> projects that I would want to pull into the Cypress project and couple >>> other things that I'd like to move out of the Cypress project before >>> tackling another port ... >>> >>> We can correspond via private email if you'd like to take me up on the >>> offer of help:) >>> >>> Dale >>> >>> [1] https://github.com/CampSmalltalk/Cypress >>> [2] https://github.com/CampSmalltalk/amber-cypress >>> [3] >>> http://portal.sliderocket.com/vmware/STIC-2012-Practical-Git-for-Smalltalk >>> >>> ----- Original Message ----- >>> | From: "Bernhard Pieber" <bernhard(a)pieber.com> >>> | To: Pharo-project(a)lists.gforge.inria.fr >>> | Sent: Monday, April 23, 2012 9:53:35 AM >>> | Subject: Re: [Pharo-project] [ANN] Styled Text Editor for Cuis 4.0 >>> Smalltalk >>> | >>> | Hi GÃ¶ran, >>> | >>> | Thanks for your question! I have posted the announcement of the >>> | Styled Text Editor to the Pharo list as well because I still have >>> | not given up on the idea to port it to Squeak and Pharo. It is not >>> | straightforward but I consider it possible. >>> | >>> | Currently the Styled Text Editor is an external package which is >>> | loaded on top of Cuis 4.0. The API it uses is quite specific to Cuis >>> | so to port it alone is probably too much effort. What I think can be >>> | done is the following: >>> | Split Cuis into three parts, >>> | a) the parts which are not needed for Styled Text Editor, like the >>> | Cuis tools >>> | b) the parts of Cuis Morphic the Styled Text Editor depends on â this >>> | is in my opinion the most valuable part of Cuis because Juan spent >>> | years cleaning it >>> | c) the Smalltalk kernel below >>> | >>> | The idea is to port only part b) and the Styled Text Editor. And it >>> | has to be done automatically by a tool which creates packages for >>> | Squeak and Pharo, always from the latest code base. In addition you >>> | will probably need small Cuis portability packages done manually, >>> | one for Squeak and one for Pharo. >>> | >>> | Being able to always load the latest code base of Styled Text Editor >>> | and Cuis Morphic as an external package in Pharo is a prerequisite >>> | to look into possibilities of sharing more of the code. >>> | >>> | I plan to write a more detailed proposal and then to approach ESUG >>> | and ask for support for the funding. Any ideas for other sources of >>> | funding are highly welcome and could speed things up considerably, >>> | of course! ;-) >>> | >>> | I for one have not given up on the idea that it might be possible to >>> | develop substantial components as you called it â thank you for that >>> | as well â in a more Squeak-dialect-independent way. ;-) >>> | >>> | Finally, I would like to take the opportunity and kindly ask everyone >>> | who has not done so yet: Please check out Cuis 4.0 and the Styled >>> | Text Editor and give us feedback, even if it does not (yet) run on >>> | your favourite Squeak dialect! Thank you! >>> | >>> | Peace, >>> | Bernhard >>> | >>> | P.S. Thanks to GÃ¶ran and Janko for trying to establish different >>> | threads for the rather off-topic discussions that my announcement >>> | posting has caused. >>> | >>> | Am 23.04.2012 um 16:04 schrieb GÃ¶ran Krampe: >>> | > Hi! >>> | > >>> | > On 04/23/2012 03:40 PM, StÃ©phane Ducasse wrote: >>> | >>> Just cloning it off into Pharo and forking seems... less optimal. >>> | >>> Any ideas or thoughts? >>> | >> >>> | >> I do not get what you mean. I just want to work on our roadmap and >>> | >> make it getting real. >>> | >> It is hard enough to get some momentum and to deliver for real. >>> | >> So can you help us to get focused? >>> | >> People can do what they want. I wrote a vision document. We have a >>> | >> roadmap >>> | >> and we will do it. >>> | > >>> | > Ok, let me clarify. I was just wondering how the Pharo community >>> | > wants to handle a case where a substantial component (in this >>> | > case, this new editor) is not *primarily* developed in Pharo (in >>> | > this case Cuis). >>> | > >>> | > The simple route is to just copy and fork. But IMHO this doesn't >>> | > leverage the team already around this editor, right? We (Pharo) >>> | > can't just go around and forking everything and maintaining >>> | > everything for ourselves, right? >>> | > >>> | > I just got interested in that problem - now, later replies >>> | > indicated that it would still need a substantial rewrite for >>> | > Pharo, so perhaps the situation I am describing is not really >>> | > applicable in this case. >>> | > >>> | > regards, GÃ¶ran >>> | > >>> | >>> | >>> | >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> >> > -- Best regards, Igor Stasenko.

April 23, 2012

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

by H. 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 <siguctua(a)gmail.com> wrote: > Hi, Dale > > it is great to see an effort in such direction. > I just wonder what .js files doing there? > > According to what i see, it is just a meta data which holding > additional properties per entity.. > > { > "category" : "Cypress-Tests", > "classinstvars" : [ > ], > "classtraitcomposition" : "{}", > "classvars" : [ > ], > "commentStamp" : "", > "instvars" : [ > ], > "name" : "CypressPatchTest", > "pools" : [ > ], > "super" : "CypressAbstractTest", > "traitcomposition" : "{}", > "type" : "normal" } > > why you cannot use a regular smalltalk literal syntax for this data? > What/why there is need to store this data in json format? > > On 23 April 2012 23:57, Dale Henrichs <dhenrich(a)vmware.com> wrote: >> Bernhard, >> >> With regards to sharing code between dialects, I'd like to recommend that >> you look into porting Cypress to Cuis (I'm willing to help as much as I >> can). >> >> The Cypress project is aimed from the get go to enable sharing of packages >> between Smalltalk dialects with a recognition that possibly the most >> important aspect is a shared VCS (git/github). >> >> If you look at the current code base in Cypress, you will see a reference >> implementation written against Pharo. The reference implementation is a >> work in progress and the initial implementation was done for Amber[2]. >> >> Cypress has Monticello-like packages, but other than taking a few ideas >> from Monticello (definitions, packages and snapshots ... more than a >> few:)) the code base is independent of Monticello. The fact that Cypress >> runs on top of Amber (sans file system access) speaks volumes for it's >> portability. >> >> To paraphrase a point from my STIC talk[3] on this subject: >> >> Â Cypress is not intended to be the primary version control >> Â system for any dialect, however, if you want to share code >> Â between dialects you should allow your developers to import >> Â and export code using the Cypress package format. >> >> If you are interested, there are bits and pieces of code in a few other >> projects that I would want to pull into the Cypress project and couple >> other things that I'd like to move out of the Cypress project before >> tackling another port ... >> >> We can correspond via private email if you'd like to take me up on the >> offer of help:) >> >> Dale >> >> [1] https://github.com/CampSmalltalk/Cypress >> [2] https://github.com/CampSmalltalk/amber-cypress >> [3] >> http://portal.sliderocket.com/vmware/STIC-2012-Practical-Git-for-Smalltalk >> >> ----- Original Message ----- >> | From: "Bernhard Pieber" <bernhard(a)pieber.com> >> | To: Pharo-project(a)lists.gforge.inria.fr >> | Sent: Monday, April 23, 2012 9:53:35 AM >> | Subject: Re: [Pharo-project] [ANN] Styled Text Editor for Cuis 4.0 >> Smalltalk >> | >> | Hi GÃ¶ran, >> | >> | Thanks for your question! I have posted the announcement of the >> | Styled Text Editor to the Pharo list as well because I still have >> | not given up on the idea to port it to Squeak and Pharo. It is not >> | straightforward but I consider it possible. >> | >> | Currently the Styled Text Editor is an external package which is >> | loaded on top of Cuis 4.0. The API it uses is quite specific to Cuis >> | so to port it alone is probably too much effort. What I think can be >> | done is the following: >> | Split Cuis into three parts, >> | a) the parts which are not needed for Styled Text Editor, like the >> | Cuis tools >> | b) the parts of Cuis Morphic the Styled Text Editor depends on â this >> | is in my opinion the most valuable part of Cuis because Juan spent >> | years cleaning it >> | c) the Smalltalk kernel below >> | >> | The idea is to port only part b) and the Styled Text Editor. And it >> | has to be done automatically by a tool which creates packages for >> | Squeak and Pharo, always from the latest code base. In addition you >> | will probably need small Cuis portability packages done manually, >> | one for Squeak and one for Pharo. >> | >> | Being able to always load the latest code base of Styled Text Editor >> | and Cuis Morphic as an external package in Pharo is a prerequisite >> | to look into possibilities of sharing more of the code. >> | >> | I plan to write a more detailed proposal and then to approach ESUG >> | and ask for support for the funding. Any ideas for other sources of >> | funding are highly welcome and could speed things up considerably, >> | of course! ;-) >> | >> | I for one have not given up on the idea that it might be possible to >> | develop substantial components as you called it â thank you for that >> | as well â in a more Squeak-dialect-independent way. ;-) >> | >> | Finally, I would like to take the opportunity and kindly ask everyone >> | who has not done so yet: Please check out Cuis 4.0 and the Styled >> | Text Editor and give us feedback, even if it does not (yet) run on >> | your favourite Squeak dialect! Thank you! >> | >> | Peace, >> | Bernhard >> | >> | P.S. Thanks to GÃ¶ran and Janko for trying to establish different >> | threads for the rather off-topic discussions that my announcement >> | posting has caused. >> | >> | Am 23.04.2012 um 16:04 schrieb GÃ¶ran Krampe: >> | > Hi! >> | > >> | > On 04/23/2012 03:40 PM, StÃ©phane Ducasse wrote: >> | >>> Just cloning it off into Pharo and forking seems... less optimal. >> | >>> Any ideas or thoughts? >> | >> >> | >> I do not get what you mean. I just want to work on our roadmap and >> | >> make it getting real. >> | >> It is hard enough to get some momentum and to deliver for real. >> | >> So can you help us to get focused? >> | >> People can do what they want. I wrote a vision document. We have a >> | >> roadmap >> | >> and we will do it. >> | > >> | > Ok, let me clarify. I was just wondering how the Pharo community >> | > wants to handle a case where a substantial component (in this >> | > case, this new editor) is not *primarily* developed in Pharo (in >> | > this case Cuis). >> | > >> | > The simple route is to just copy and fork. But IMHO this doesn't >> | > leverage the team already around this editor, right? We (Pharo) >> | > can't just go around and forking everything and maintaining >> | > everything for ourselves, right? >> | > >> | > I just got interested in that problem - now, later replies >> | > indicated that it would still need a substantial rewrite for >> | > Pharo, so perhaps the situation I am describing is not really >> | > applicable in this case. >> | > >> | > regards, GÃ¶ran >> | > >> | >> | >> | >> > > > > -- > Best regards, > Igor Stasenko. > >

April 23, 2012

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

by Igor Stasenko

Hi, Dale it is great to see an effort in such direction. I just wonder what .js files doing there? According to what i see, it is just a meta data which holding additional properties per entity.. { "category" : "Cypress-Tests", "classinstvars" : [ ], "classtraitcomposition" : "{}", "classvars" : [ ], "commentStamp" : "", "instvars" : [ ], "name" : "CypressPatchTest", "pools" : [ ], "super" : "CypressAbstractTest", "traitcomposition" : "{}", "type" : "normal" } why you cannot use a regular smalltalk literal syntax for this data? What/why there is need to store this data in json format? On 23 April 2012 23:57, Dale Henrichs <dhenrich(a)vmware.com> wrote: > Bernhard, > > With regards to sharing code between dialects, I'd like to recommend that you look into porting Cypress to Cuis (I'm willing to help as much as I can). > > The Cypress project is aimed from the get go to enable sharing of packages between Smalltalk dialects with a recognition that possibly the most important aspect is a shared VCS (git/github). > > If you look at the current code base in Cypress, you will see a reference implementation written against Pharo. The reference implementation is a work in progress and the initial implementation was done for Amber[2]. > > Cypress has Monticello-like packages, but other than taking a few ideas from Monticello (definitions, packages and snapshots ... more than a few:)) the code base is independent of Monticello. The fact that Cypress runs on top of Amber (sans file system access) speaks volumes for it's portability. > > To paraphrase a point from my STIC talk[3] on this subject: > > Â Cypress is not intended to be the primary version control > Â system for any dialect, however, if you want to share code > Â between dialects you should allow your developers to import > Â and export code using the Cypress package format. > > If you are interested, there are bits and pieces of code in a few other projects that I would want to pull into the Cypress project and couple other things that I'd like to move out of the Cypress project before tackling another port ... > > We can correspond via private email if you'd like to take me up on the offer of help:) > > Dale > > [1] https://github.com/CampSmalltalk/Cypress > [2] https://github.com/CampSmalltalk/amber-cypress > [3] http://portal.sliderocket.com/vmware/STIC-2012-Practical-Git-for-Smalltalk > > ----- Original Message ----- > | From: "Bernhard Pieber" <bernhard(a)pieber.com> > | To: Pharo-project(a)lists.gforge.inria.fr > | Sent: Monday, April 23, 2012 9:53:35 AM > | Subject: Re: [Pharo-project] [ANN] Styled Text Editor for Cuis 4.0 Smalltalk > | > | Hi GÃ¶ran, > | > | Thanks for your question! I have posted the announcement of the > | Styled Text Editor to the Pharo list as well because I still have > | not given up on the idea to port it to Squeak and Pharo. It is not > | straightforward but I consider it possible. > | > | Currently the Styled Text Editor is an external package which is > | loaded on top of Cuis 4.0. The API it uses is quite specific to Cuis > | so to port it alone is probably too much effort. What I think can be > | done is the following: > | Split Cuis into three parts, > | a) the parts which are not needed for Styled Text Editor, like the > | Cuis tools > | b) the parts of Cuis Morphic the Styled Text Editor depends on â this > | is in my opinion the most valuable part of Cuis because Juan spent > | years cleaning it > | c) the Smalltalk kernel below > | > | The idea is to port only part b) and the Styled Text Editor. And it > | has to be done automatically by a tool which creates packages for > | Squeak and Pharo, always from the latest code base. In addition you > | will probably need small Cuis portability packages done manually, > | one for Squeak and one for Pharo. > | > | Being able to always load the latest code base of Styled Text Editor > | and Cuis Morphic as an external package in Pharo is a prerequisite > | to look into possibilities of sharing more of the code. > | > | I plan to write a more detailed proposal and then to approach ESUG > | and ask for support for the funding. Any ideas for other sources of > | funding are highly welcome and could speed things up considerably, > | of course! ;-) > | > | I for one have not given up on the idea that it might be possible to > | develop substantial components as you called it â thank you for that > | as well â in a more Squeak-dialect-independent way. ;-) > | > | Finally, I would like to take the opportunity and kindly ask everyone > | who has not done so yet: Please check out Cuis 4.0 and the Styled > | Text Editor and give us feedback, even if it does not (yet) run on > | your favourite Squeak dialect! Thank you! > | > | Peace, > | Bernhard > | > | P.S. Thanks to GÃ¶ran and Janko for trying to establish different > | threads for the rather off-topic discussions that my announcement > | posting has caused. > | > | Am 23.04.2012 um 16:04 schrieb GÃ¶ran Krampe: > | > Hi! > | > > | > On 04/23/2012 03:40 PM, StÃ©phane Ducasse wrote: > | >>> Just cloning it off into Pharo and forking seems... less optimal. > | >>> Any ideas or thoughts? > | >> > | >> I do not get what you mean. I just want to work on our roadmap and > | >> make it getting real. > | >> It is hard enough to get some momentum and to deliver for real. > | >> So can you help us to get focused? > | >> People can do what they want. I wrote a vision document. We have a > | >> roadmap > | >> and we will do it. > | > > | > Ok, let me clarify. I was just wondering how the Pharo community > | > wants to handle a case where a substantial component (in this > | > case, this new editor) is not *primarily* developed in Pharo (in > | > this case Cuis). > | > > | > The simple route is to just copy and fork. But IMHO this doesn't > | > leverage the team already around this editor, right? We (Pharo) > | > can't just go around and forking everything and maintaining > | > everything for ourselves, right? > | > > | > I just got interested in that problem - now, later replies > | > indicated that it would still need a substantial rewrite for > | > Pharo, so perhaps the situation I am describing is not really > | > applicable in this case. > | > > | > regards, GÃ¶ran > | > > | > | > | > -- Best regards, Igor Stasenko.

April 23, 2012