Igor,

A lot of your questions/assertions were addressed in the two existing threads 
...

Smalltalk parsers are not available in all Smalltalk dialects, so again, JSON 
is and was a pragmatic choice, pure and simple. 

The entire disk-based package structure has a number of warts of varying sizes 
and qualities, but the one thing that is true is that we have 5 Smalltalk 
dialects (with more coming) sharing the same package structure and the same 
version control system ... something that has never been true before and _that_ 
is the most important thing right now...

Dale

----- Original Message -----
| From: "Igor Stasenko" <[email protected]>
| To: [email protected]
| 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 <[email protected]> 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" <[email protected]>
| > | To: [email protected]
| > | 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 <[email protected]>
| > | 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" <[email protected]>
| > | > | To: [email protected]
| > | > | Sent: Monday, April 23, 2012 9:53:35 AM
| > | > | Subject: Re: [Pharo-project] [ANN] Styled Text Editor for
| > | > | Cuis
| > | > | 4.0 Smalltalk
| > | > |
| > | > | Hi Göran,
| > | > |
| > | > | Thanks for your question! I have posted the announcement of
| > | > | the
| > | > | Styled Text Editor to the Pharo list as well because I still
| > | > | have
| > | > | not given up on the idea to port it to Squeak and Pharo. It
| > | > | is
| > | > | not
| > | > | straightforward but I consider it possible.
| > | > |
| > | > | Currently the Styled Text Editor is an external package which
| > | > | is
| > | > | loaded on top of Cuis 4.0. The API it uses is quite specific
| > | > | to
| > | > | Cuis
| > | > | so to port it alone is probably too much effort. What I think
| > | > | can
| > | > | be
| > | > | done is the following:
| > | > | Split Cuis into three parts,
| > | > | a) the parts which are not needed for Styled Text Editor,
| > | > | like
| > | > | the
| > | > | Cuis tools
| > | > | b) the parts of Cuis Morphic the Styled Text Editor depends
| > | > | on –
| > | > | this
| > | > | is in my opinion the most valuable part of Cuis because Juan
| > | > | spent
| > | > | years cleaning it
| > | > | c) the Smalltalk kernel below
| > | > |
| > | > | The idea is to port only part b) and the Styled Text Editor.
| > | > | And
| > | > | it
| > | > | has to be done automatically by a tool which creates packages
| > | > | for
| > | > | Squeak and Pharo, always from the latest code base. In
| > | > | addition
| > | > | you
| > | > | will probably need small Cuis portability packages done
| > | > | manually,
| > | > | one for Squeak and one for Pharo.
| > | > |
| > | > | Being able to always load the latest code base of Styled Text
| > | > | Editor
| > | > | and Cuis Morphic as an external package in Pharo is a
| > | > | prerequisite
| > | > | to look into possibilities of sharing more of the code.
| > | > |
| > | > | I plan to write a more detailed proposal and then to approach
| > | > | ESUG
| > | > | and ask for support for the funding. Any ideas for other
| > | > | sources
| > | > | of
| > | > | funding are highly welcome and could speed things up
| > | > | considerably,
| > | > | of course! ;-)
| > | > |
| > | > | I for one have not given up on the idea that it might be
| > | > | possible
| > | > | to
| > | > | develop substantial components as you called it – thank you
| > | > | for
| > | > | that
| > | > | as well – in a more Squeak-dialect-independent way. ;-)
| > | > |
| > | > | Finally, I would like to take the opportunity and kindly ask
| > | > | everyone
| > | > | who has not done so yet: Please check out Cuis 4.0 and the
| > | > | Styled
| > | > | Text Editor and give us feedback, even if it does not (yet)
| > | > | run
| > | > | on
| > | > | your favourite Squeak dialect! Thank you!
| > | > |
| > | > | Peace,
| > | > | Bernhard
| > | > |
| > | > | P.S. Thanks to Göran and Janko for trying to establish
| > | > | different
| > | > | threads for the rather off-topic discussions that my
| > | > | announcement
| > | > | posting has caused.
| > | > |
| > | > | Am 23.04.2012 um 16:04 schrieb Göran Krampe:
| > | > | > Hi!
| > | > | >
| > | > | > On 04/23/2012 03:40 PM, Stéphane Ducasse wrote:
| > | > | >>> Just cloning it off into Pharo and forking seems... less
| > | > | >>> optimal.
| > | > | >>> Any ideas or thoughts?
| > | > | >>
| > | > | >> I do not get what you mean. I just want to work on our
| > | > | >> roadmap
| > | > | >> and
| > | > | >> make it getting real.
| > | > | >> It is hard enough to get some momentum and to deliver for
| > | > | >> real.
| > | > | >> So can you help us to get focused?
| > | > | >> People can do what they want. I wrote a vision document.
| > | > | >> We
| > | > | >> have a
| > | > | >> roadmap
| > | > | >> and we will do it.
| > | > | >
| > | > | > Ok, let me clarify. I was just wondering how the Pharo
| > | > | > community
| > | > | > wants to handle a case where a substantial component (in
| > | > | > this
| > | > | > case, this new editor) is not *primarily* developed in
| > | > | > Pharo
| > | > | > (in
| > | > | > this case Cuis).
| > | > | >
| > | > | > The simple route is to just copy and fork. But IMHO this
| > | > | > doesn't
| > | > | > leverage the team already around this editor, right? We
| > | > | > (Pharo)
| > | > | > can't just go around and forking everything and maintaining
| > | > | > everything for ourselves, right?
| > | > | >
| > | > | > I just got interested in that problem - now, later replies
| > | > | > indicated that it would still need a substantial rewrite
| > | > | > for
| > | > | > Pharo, so perhaps the situation I am describing is not
| > | > | > really
| > | > | > applicable in this case.
| > | > | >
| > | > | > regards, Göran
| > | > | >
| > | > |
| > | > |
| > | > |
| > | >
| > |
| > |
| > |
| > | --
| > | Best regards,
| > | Igor Stasenko.
| > |
| > |
| >
| 
| 
| 
| --
| Best regards,
| Igor Stasenko.
| 
| 

Reply via email to