Hi Igor,

It is pretty clear that JSON is slowly replacing even XML elsewhere and
if I for instance have to chose between XML and JSON, I'd certainly
choose later. Our chunk format is, well, ours only. VW is using XML,
others are using anything else. Something as neutral and as simple as
JSON-based format can therefore become a bridge even between us.

JSON is now becoming defacto standard for any interoperability scenario
in cloud world, so IMO Dale did a right decision to choose it. We will
be much closer to other words with Smalltalk that way and even more by
using GitHub for code repository.

Best regards
Janko


Dne 24. 04. 2012 01:07, piše Igor Stasenko:
> 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.
>> |
>> |
>>
> 
> 
> 

-- 
Janko Mivšek
Aida/Web
Smalltalk Web Application Server
http://www.aidaweb.si

Reply via email to