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" <siguc...@gmail.com>
> | To: Pharo-project@lists.gforge.inria.fr
> | Sent: Monday, April 23, 2012 5:21:57 PM
> | Subject: Re: [Pharo-project] About Cypress [Was: Re: [ANN] Styled Text
> Editor for Cuis 4.0 Smalltalk]
> |
> | On 24 April 2012 03:17, Dale Henrichs <dhenr...@vmware.com> wrote:
> | > Igor,
> | >
> | > A lot of your questions/assertions were addressed in the two
> | > existing threads ...
> | >
> | > Smalltalk parsers are not available in all Smalltalk dialects, so
> | > again, JSON is and was a pragmatic choice, pure and simple.
> | >
> | what? how is that? smalltalk which cannot parse smalltalk? but can
> | parse JSON? ;)
> |
> | > The entire disk-based package structure has a number of warts of
> | > varying sizes and qualities, but the one thing that is true is
> | > that we have 5 Smalltalk dialects (with more coming) sharing the
> | > same package structure and the same version control system ...
> | > something that has never been true before and _that_ is the most
> | > important thing right now...
> | >
> | that's out of the question
> |
> | > Dale
> | >
> | > ----- Original Message -----
> | > | From: "Igor Stasenko" <siguc...@gmail.com>
> | > | To: Pharo-project@lists.gforge.inria.fr
> | > | Sent: Monday, April 23, 2012 4:07:04 PM
> | > | Subject: Re: [Pharo-project] About Cypress [Was: Re: [ANN] Styled
> | > | Text Editor for Cuis 4.0 Smalltalk]
> | > |
> | > | On 24 April 2012 01:54, Dale Henrichs <dhenr...@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-repository-td4356301.html
> | > | >
> | > | >
> | > | > ----- Original Message -----
> | > | > | From: "Igor Stasenko" <siguc...@gmail.com>
> | > | > | To: Pharo-project@lists.gforge.inria.fr
> | > | > | Sent: Monday, April 23, 2012 2:34:54 PM
> | > | > | Subject: [Pharo-project] About Cypress [Was: Re: [ANN] Styled
> | > | > | Text Editor for Cuis 4.0 Smalltalk]
> | > | > |
> | > | > | Hi, Dale
> | > | > |
> | > | > | it is great to see an effort in such direction.
> | > | > | I just wonder what .js files doing there?
> | > | > |
> | > | > | According to what i see, it is just a meta data which holding
> | > | > | additional properties per entity..
> | > | > |
> | > | > | {
> | > | > | "category" : "Cypress-Tests",
> | > | > | "classinstvars" : [
> | > | > | ],
> | > | > | "classtraitcomposition" : "{}",
> | > | > | "classvars" : [
> | > | > | ],
> | > | > | "commentStamp" : "",
> | > | > | "instvars" : [
> | > | > | ],
> | > | > | "name" : "CypressPatchTest",
> | > | > | "pools" : [
> | > | > | ],
> | > | > | "super" : "CypressAbstractTest",
> | > | > | "traitcomposition" : "{}",
> | > | > | "type" : "normal" }
> | > | > |
> | > | > | why you cannot use a regular smalltalk literal syntax for
> | > | > | this
> | > | > | data?
> | > | > | What/why there is need to store this data in json format?
> | > | > |
> | > | > | On 23 April 2012 23:57, Dale Henrichs <dhenr...@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" <bernh...@pieber.com>
> | > | > | > | To: Pharo-project@lists.gforge.inria.fr
> | > | > | > | Sent: Monday, April 23, 2012 9:53:35 AM
> | > | > | > | Subject: Re: [Pharo-project] [ANN] Styled Text Editor for
> | > | > | > | Cuis
> | > | > | > | 4.0 Smalltalk
> | > | > | > |
> | > | > | > | Hi Göran,
> | > | > | > |
> | > | > | > | Thanks for your question! I have posted the announcement
> | > | > | > | of
> | > | > | > | the
> | > | > | > | Styled Text Editor to the Pharo list as well because I
> | > | > | > | still
> | > | > | > | have
> | > | > | > | not given up on the idea to port it to Squeak and Pharo.
> | > | > | > | It
> | > | > | > | is
> | > | > | > | not
> | > | > | > | straightforward but I consider it possible.
> | > | > | > |
> | > | > | > | Currently the Styled Text Editor is an external package
> | > | > | > | which
> | > | > | > | is
> | > | > | > | loaded on top of Cuis 4.0. The API it uses is quite
> | > | > | > | specific
> | > | > | > | to
> | > | > | > | Cuis
> | > | > | > | so to port it alone is probably too much effort. What I
> | > | > | > | think
> | > | > | > | can
> | > | > | > | be
> | > | > | > | done is the following:
> | > | > | > | Split Cuis into three parts,
> | > | > | > | a) the parts which are not needed for Styled Text Editor,
> | > | > | > | like
> | > | > | > | the
> | > | > | > | Cuis tools
> | > | > | > | b) the parts of Cuis Morphic the Styled Text Editor
> | > | > | > | depends
> | > | > | > | on –
> | > | > | > | this
> | > | > | > | is in my opinion the most valuable part of Cuis because
> | > | > | > | Juan
> | > | > | > | spent
> | > | > | > | years cleaning it
> | > | > | > | c) the Smalltalk kernel below
> | > | > | > |
> | > | > | > | The idea is to port only part b) and the Styled Text
> | > | > | > | Editor.
> | > | > | > | And
> | > | > | > | it
> | > | > | > | has to be done automatically by a tool which creates
> | > | > | > | packages
> | > | > | > | for
> | > | > | > | Squeak and Pharo, always from the latest code base. In
> | > | > | > | addition
> | > | > | > | you
> | > | > | > | will probably need small Cuis portability packages done
> | > | > | > | manually,
> | > | > | > | one for Squeak and one for Pharo.
> | > | > | > |
> | > | > | > | Being able to always load the latest code base of Styled
> | > | > | > | Text
> | > | > | > | Editor
> | > | > | > | and Cuis Morphic as an external package in Pharo is a
> | > | > | > | prerequisite
> | > | > | > | to look into possibilities of sharing more of the code.
> | > | > | > |
> | > | > | > | I plan to write a more detailed proposal and then to
> | > | > | > | approach
> | > | > | > | ESUG
> | > | > | > | and ask for support for the funding. Any ideas for other
> | > | > | > | sources
> | > | > | > | of
> | > | > | > | funding are highly welcome and could speed things up
> | > | > | > | considerably,
> | > | > | > | of course! ;-)
> | > | > | > |
> | > | > | > | I for one have not given up on the idea that it might be
> | > | > | > | possible
> | > | > | > | to
> | > | > | > | develop substantial components as you called it – thank
> | > | > | > | you
> | > | > | > | for
> | > | > | > | that
> | > | > | > | as well – in a more Squeak-dialect-independent way. ;-)
> | > | > | > |
> | > | > | > | Finally, I would like to take the opportunity and kindly
> | > | > | > | ask
> | > | > | > | everyone
> | > | > | > | who has not done so yet: Please check out Cuis 4.0 and
> | > | > | > | the
> | > | > | > | Styled
> | > | > | > | Text Editor and give us feedback, even if it does not
> | > | > | > | (yet)
> | > | > | > | run
> | > | > | > | on
> | > | > | > | your favourite Squeak dialect! Thank you!
> | > | > | > |
> | > | > | > | Peace,
> | > | > | > | Bernhard
> | > | > | > |
> | > | > | > | P.S. Thanks to Göran and Janko for trying to establish
> | > | > | > | different
> | > | > | > | threads for the rather off-topic discussions that my
> | > | > | > | announcement
> | > | > | > | posting has caused.
> | > | > | > |
> | > | > | > | Am 23.04.2012 um 16:04 schrieb Göran Krampe:
> | > | > | > | > Hi!
> | > | > | > | >
> | > | > | > | > On 04/23/2012 03:40 PM, Stéphane Ducasse wrote:
> | > | > | > | >>> Just cloning it off into Pharo and forking seems...
> | > | > | > | >>> less
> | > | > | > | >>> optimal.
> | > | > | > | >>> Any ideas or thoughts?
> | > | > | > | >>
> | > | > | > | >> I do not get what you mean. I just want to work on our
> | > | > | > | >> roadmap
> | > | > | > | >> and
> | > | > | > | >> make it getting real.
> | > | > | > | >> It is hard enough to get some momentum and to deliver
> | > | > | > | >> for
> | > | > | > | >> real.
> | > | > | > | >> So can you help us to get focused?
> | > | > | > | >> People can do what they want. I wrote a vision
> | > | > | > | >> document.
> | > | > | > | >> We
> | > | > | > | >> have a
> | > | > | > | >> roadmap
> | > | > | > | >> and we will do it.
> | > | > | > | >
> | > | > | > | > Ok, let me clarify. I was just wondering how the Pharo
> | > | > | > | > community
> | > | > | > | > wants to handle a case where a substantial component
> | > | > | > | > (in
> | > | > | > | > this
> | > | > | > | > case, this new editor) is not *primarily* developed in
> | > | > | > | > Pharo
> | > | > | > | > (in
> | > | > | > | > this case Cuis).
> | > | > | > | >
> | > | > | > | > The simple route is to just copy and fork. But IMHO
> | > | > | > | > this
> | > | > | > | > doesn't
> | > | > | > | > leverage the team already around this editor, right? We
> | > | > | > | > (Pharo)
> | > | > | > | > can't just go around and forking everything and
> | > | > | > | > maintaining
> | > | > | > | > everything for ourselves, right?
> | > | > | > | >
> | > | > | > | > I just got interested in that problem - now, later
> | > | > | > | > replies
> | > | > | > | > indicated that it would still need a substantial
> | > | > | > | > rewrite
> | > | > | > | > for
> | > | > | > | > Pharo, so perhaps the situation I am describing is not
> | > | > | > | > really
> | > | > | > | > applicable in this case.
> | > | > | > | >
> | > | > | > | > regards, Göran
> | > | > | > | >
> | > | > | > |
> | > | > | > |
> | > | > | > |
> | > | > | >
> | > | > |
> | > | > |
> | > | > |
> | > | > | --
> | > | > | Best regards,
> | > | > | Igor Stasenko.
> | > | > |
> | > | > |
> | > | >
> | > |
> | > |
> | > |
> | > | --
> | > | Best regards,
> | > | Igor Stasenko.
> | > |
> | > |
> | >
> |
> |
> |
> | --
> | Best regards,
> | Igor Stasenko.
> |
> |
>
