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

Re: [Pharo-project] Tirade!

by StÃ©phane Ducasse

Where is the code? Do you have tests? Can we extract a parser for literal array? Stef > On 04/24/2012 11:25 AM, Sven Van Caekenberghe wrote: >> But then you need to write a clear spec and a non-compiler based parser. > > Ok, perhaps you all understood this from my links etc, but Tirade *is* a non-compiler based parser. It *is* safe. It only allows literals. It is *much* faster than the Compiler. It is very small, code is simple and it is trivial to port to ANY Smalltalk. > > Now, for the other arguments - I agree, JSON is "good enough" for many things and universally accepted in almost all camps these days. Just don't want people to reinvent Tirade :) > > regards, GÃ¶ran >

April 24, 2012

Re: [Pharo-project] Tirade! (was: Re: About Cypress [Was: Re: [ANN] Styled Text Editor for Cuis 4.0 Smalltalk])

by StÃ©phane Ducasse

> > 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. Let us do it. > With the JSON meta data, you could envision other non-Smalltalk tools using it more easily. Do you want to build our tools in Javascript or other languages? Because we are talking about class definition and smalltalk meta data itself.

April 24, 2012

Re: [Pharo-project] new icon set

by Norbert Hartl

Am 24.04.2012 um 11:35 schrieb Geert Claes: > > Norbert Hartl wrote >> >> Of course, if there is an ugly replacment that can be used if the system >> is minimised. Having two icon sets introduces the possibility to make the >> ugly one consume even less memory, e.g. make it black and white. >> > > I have no idea what you just tried to say :) When you say ugly replacement, > are you talking about the current ugly icons or do you find Esteban's > suggested icons not appealing enough? > It is just an addition to my first statement. If we call the current icon set medium in the sense of medium cutiness and medium memory consumption than there is a new situation with the new nice icons. Igor is right, if the vector world is coming to pharo then it is easy to make really good looking icons in the image. But the memory consumption and CPU intensity will be raised. That contradicts to usage of pharo in a server environment. So what I was saying is that I think that the new icons are great. But then there should be a replacement for it when the image is shrinked. The same happens with the fonts if you shrink. And if the icons are replaced they could even be replaced by something really basic that saves additional memory. On a server with VNC or the like the icons aren't that important and maybe can be removed completely. More clear now? Norbert

April 24, 2012

Re: [Pharo-project] Tirade! (was: Re: About Cypress [Was: Re: [ANN] Styled Text Editor for Cuis 4.0 Smalltalk])

by StÃ©phane Ducasse

>> > The two points are still the same, Stef. The lesser important point was the absence of a cross platform parser for that format. Here I understand Dale. He spawns of project after project that depend on each other. I think he is not willing to yet postpone this project only to create such a parser when there is a usable alternativ. Others might create it and convince him afterwards which isn't very difficult if I take my experience until now. That would be the easier part. > The harder part is security. The security standpoints always divide between white lists and black lists. Meaning a white list forbids everything and allows things on a white list. Or vice versa you allow everything and put things you don't like on a black list. Having a Smalltalk format means I have two options: "Read and parse it" or "Read and evaluate it". As far as I understand Dale he sees a big problem if people just evaluate configurations which contain bogus code. It is just so easy to introduce code that borkes your system. > While I really can understand the security concerns I personally think that having two options is better. The standard tools should just take parse route. I will develop a literal parser and this is solved. No security hole no JSON. Easy.

April 24, 2012

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

by StÃ©phane Ducasse

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" <stephane.ducasse(a)inria.fr> > | To: Pharo-project(a)lists.gforge.inria.fr > | 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" <siguctua(a)gmail.com> > | > | To: Pharo-project(a)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 <dhenrich(a)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" <siguctua(a)gmail.com> > | > | > | To: Pharo-project(a)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 <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. > | > | > | > | > | > | > | > | > > | > | > | > | > | > | > | > | -- > | > | Best regards, > | > | Igor Stasenko. > | > | > | > | > | > > | > | > | >

April 24, 2012

[Pharo-project] SimpleLiteralArrayParser

by stephane ducasse

Hi guys We should develop a simple Literal Array parser that is dialect independant so that we can avoid using JSON for meta data. So I will start to develop. I will start to write some tests and do it test first. Gofer new repository: 'http://ss3.gemstone.com/ss/SimpleLiteralArrayParser'; package: 'SimpleLiteralArrayParser'; load Now I still wonder what do we do about floats. May be the situation changed but Squeak and VW floats were not the same. Stef

April 24, 2012

[Pharo-project] RE : Re: Tirade!

by Philippe Back

Where is the source? I like it and can use it in my current project. Tx Phil EnvoyÃ© depuis un mobile Samsung GÃ¶ran Krampe <goran(a)krampe.se> a Ã©critÂ : On 04/24/2012 11:25 AM, Sven Van Caekenberghe wrote: > But then you need to write a clear spec and a non-compiler based parser. Ok, perhaps you all understood this from my links etc, but Tirade *is* a non-compiler based parser. It *is* safe. It only allows literals. It is *much* faster than the Compiler. It is very small, code is simple and it is trivial to port to ANY Smalltalk. Now, for the other arguments - I agree, JSON is "good enough" for many things and universally accepted in almost all camps these days. Just don't want people to reinvent Tirade :) regards, GÃ¶ran

April 24, 2012

Re: [Pharo-project] new icon set

by Geert Claes

Norbert Hartl wrote > > Of course, if there is an ugly replacment that can be used if the system > is minimised. Having two icon sets introduces the possibility to make the > ugly one consume even less memory, e.g. make it black and white. > I have no idea what you just tried to say :) When you say ugly replacement, are you talking about the current ugly icons or do you find Esteban's suggested icons not appealing enough? -- View this message in context: http://forum.world.st/new-icon-set-tp4580408p4582867.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 24, 2012

Re: [Pharo-project] Tirade!

by GÃ¶ran Krampe

On 04/24/2012 11:25 AM, Sven Van Caekenberghe wrote: > But then you need to write a clear spec and a non-compiler based parser. Ok, perhaps you all understood this from my links etc, but Tirade *is* a non-compiler based parser. It *is* safe. It only allows literals. It is *much* faster than the Compiler. It is very small, code is simple and it is trivial to port to ANY Smalltalk. Now, for the other arguments - I agree, JSON is "good enough" for many things and universally accepted in almost all camps these days. Just don't want people to reinvent Tirade :) regards, GÃ¶ran

April 24, 2012

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

by Dale Henrichs

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... Dale ----- Original Message ----- | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> | To: Pharo-project(a)lists.gforge.inria.fr | 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" <siguctua(a)gmail.com> | > | To: Pharo-project(a)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 <dhenrich(a)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" <siguctua(a)gmail.com> | > | > | To: Pharo-project(a)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 <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. | > | > | | > | > | | > | > | > | | > | | > | | > | -- | > | Best regards, | > | Igor Stasenko. | > | | > | | > | | |

April 24, 2012