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

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

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

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

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

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

>
> Dale
>
> ----- Original Message -----
> | From: "Stéphane Ducasse" <[hidden email]>
> | To: [hidden email]
> | Sent: Monday, April 23, 2012 10:28:00 PM
> | Subject: Re: [Pharo-project] About Cypress [Was: Re: [ANN] Styled Text Editor for Cuis 4.0 Smalltalk]
> |
> |
> | On Apr 24, 2012, at 2:32 AM, Dale Henrichs wrote:
> |
> | > Igor,
> | >
> | > GemStone's Smalltalk parser/compiler is implemented in C …
> |
> | This puzzled me a lot:
> | so you cannot invoke it from Smalltalk?
> |
> | Then how do you compile code in Gemstome? Via the command line?
> |
> | As I said if this is only that we can write a parser for literal
> | array.
> | But yo should not say that you need a literal array syntax that
> | support dictionaries
> | because syntax and semantics are two different things.
> | (x 33)
> | (z 24)
> | can be binding for dictionary.
> |
> | Stef
> |
> |
> | > I told you that JSON is and was a pragmatic choice ...
> | >
> | > The seaside JSON parser is 27 methods and runs without change in
> | > GemStone ... this is all covered in the other two threads, so
> | > maybe you should spend some time reading up on the issues that
> | > have already been hashed over twice so far... Oh wait, now there
> | > are now three threads that are covering the "why JSON" question:)
> | >
> | > Dale
> | >
> | > ----- Original Message -----
> | > | From: "Igor Stasenko" <[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.
> | > |
> | > |
> | >
> |
> |
> |
>

>
> Yes, you are right, they are technically mostly equivalent. (JSON has simpler primitive types, clear escapes, lists/arrays and maps/dictionaries).
>
> But the point is, there are so many formats out there, and everybody likes to make there own.
>
> If you pick JSON, the discussion ends. It is an RFC standard.
> If you pick something that looks suspiciously like some (for most people) weird programming language you will get discussions, always.
>
> Dale said so: it is a pragmatic choice.
>
> Now, given the fact that the domain here is Smalltalk anyway, there is something to say for using a Smalltalk based representation.
>
> But then you need to write a clear spec and a non-compiler based parser.

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

> Dale
>
> ----- Original Message -----
> | From: "Stéphane Ducasse" <[hidden email]>
> | To: [hidden email]
> | Sent: Tuesday, April 24, 2012 2:41:24 AM
> | Subject: Re: [Pharo-project] About Cypress [Was: Re: [ANN] Styled     Text    Editor for Cuis 4.0 Smalltalk]
> |
> |
> | On Apr 24, 2012, at 11:30 AM, Dale Henrichs wrote:
> |
> | > Stef,
> | >
> | > ... JSON is and was a pragmatic choice... GemStone produces methods
> | > from source via a primitive call... it is what it is ... JSON is
> | > and was a pragmatic choice…
> |
> | so you cannot put the array in a file and call the parser (even if
> | this is a primitive)?
> | I'm confused.
> |
> |
> | >
> | > Dale
> | >
> | > ----- Original Message -----
> | > | From: "Stéphane Ducasse" <[hidden email]>
> | > | To: [hidden email]
> | > | Sent: Monday, April 23, 2012 10:28:00 PM
> | > | Subject: Re: [Pharo-project] About Cypress [Was: Re: [ANN] Styled
> | > | Text      Editor for Cuis 4.0 Smalltalk]
> | > |
> | > |
> | > | On Apr 24, 2012, at 2:32 AM, Dale Henrichs wrote:
> | > |
> | > | > Igor,
> | > | >
> | > | > GemStone's Smalltalk parser/compiler is implemented in C …
> | > |
> | > | This puzzled me a lot:
> | > |   so you cannot invoke it from Smalltalk?
> | > |
> | > | Then how do you compile code in Gemstome? Via the command line?
> | > |
> | > | As I said if this is only that we can write a parser for literal
> | > | array.
> | > | But yo should not say that you need a literal array syntax that
> | > | support dictionaries
> | > | because syntax and semantics are two different things.
> | > |           (x 33)
> | > |           (z 24)
> | > | can be binding for dictionary.
> | > |
> | > | Stef
> | > |
> | > |
> | > | > I told you that JSON is and was a pragmatic choice ...
> | > | >
> | > | > The seaside JSON parser is 27 methods and runs without change
> | > | > in
> | > | > GemStone ... this is all covered in the other two threads, so
> | > | > maybe you should spend some time reading up on the issues that
> | > | > have already been hashed over twice so far... Oh wait, now
> | > | > there
> | > | > are now three threads that are covering the "why JSON"
> | > | > question:)
> | > | >
> | > | > Dale
> | > | >
> | > | > ----- Original Message -----
> | > | > | From: "Igor Stasenko" <[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.
> | > | > |
> | > | > |
> | > | >
> | > |
> | > |
> | > |
> | >
> |
> |
> |
>