- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Tirade!

by StÃ©phane Ducasse

Ok I will have a look. Because it would solve our problem. Stef >> http://www.squeaksource.com/Tirade.html > > Eh, oops. I just realized that TiradeParser uses dynamic arrays { } and does not have current support for literal Arrays. Duh. Sorry about that, but feel free to use the code anyways, adding #parseLiteralArray should not be hard. > > regards, GÃ¶ran >

April 24, 2012

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

by StÃ©phane Ducasse

> 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. In a really really bad way. Because the tags are used in a non sense way. You still have to parse method to get the selector :) So VW is far from an example. And we are not talking about the method format, just method metadata. > 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 Not at all. Do you really think that somebody will be interested by Smalltalk just because metadata of methods are stored in JSON :) Come on. > and even more by > using GitHub for code repository.

April 24, 2012

Re: [Pharo-project] SimpleLiteralArrayParser

by Mariano Martinez Peck

On Tue, Apr 24, 2012 at 12:43 PM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > > 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. > > > > I don't get it. You define your own float format, and then each dialect > parses it and converts it to their correspondant format... Now, I do not > know the format > > differences so I do not know which one take :). > > It can work for simple scenario but if you save a float with e120 and save > it and you get e70 > then you are in trouble. > You are not in trouble. And if you are, then you are exactlty the same as if you were using a literal parser. You have a specification. You say that floats are written in THIS XXX text representation. Nobody cares how your floats are represented inside your Smalltalk. For JSON you write floats in a particular way, explained by the JSON specification. Then, when you code the parser, you will need to crate an instance of Float from the string. Each dialect will know how to do that. So, again, where is the problem? And how the literal parser would solve it? because I think it will happen the same. Cheers, > > Stef > -- Mariano http://marianopeck.wordpress.com

April 24, 2012

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

by H. Hirzel

On 4/24/12, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > > On 24 Apr 2012, at 11:10, StÃ©phane Ducasse 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. >> >> But you can express **EXACTLY** the same with >> #( >> >> >> ) >> >> So what is the point? >> >> Stef > > 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. +1 > 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. +1 > 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. > > With the JSON meta data, you could envision other non-Smalltalk tools using > it more easily. +1 > Sven > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > > >

April 24, 2012

Re: [Pharo-project] new icon set

by Igor Stasenko

On 24 April 2012 11:44, Norbert Hartl <norbert(a)hartl.name> wrote: > > 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 > > did i miss something? since when memory consumption for vector graphics takes more space? look at the size of .svg files and compare them with size of .png files for same icons. Vector data are much more compact. So, actually if you really want to shrink things down, you need to operate with vectors :) More CPU for rendering vector graphics? Perhaps. It is of course more expensive than just copying memory from one bitmap to another. But desktop environment requires a lot more complex operations that just copying bits from one form over another one. And also consider the cases where you need to use 5 different operations to simulate just one. (look at famous corner rounder hack). -- Best regards, Igor Stasenko.

April 24, 2012

Re: [Pharo-project] new icon set

by StÃ©phane Ducasse

yes and we will have to also distribute icons into class resources. > total memory consumption on old icons: 27258 > total memory consumption on new icons: 67234 > > so... is 40k more... I think we can live with that :) > > anyway, if you want to save memory, you can strip that and have no icons at all (just remove *IconContents methods and reset icons class var). > > Esteban > > On Apr 24, 2012, at 11:44 AM, Norbert Hartl wrote: > >> >> 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] About Cypress [Was: Re: [ANN] Styled Text Editor for Cuis 4.0 Smalltalk]

by H. Hirzel

On 4/24/12, Janko MivÅ¡ek <janko.mivsek(a)eranova.si> wrote: > 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. +1 We will > be much closer to other words with Smalltalk that way and even more by > using GitHub for code repository. +1 > Best regards > Janko > > > Dne 24. 04. 2012 01:07, piÅ¡e Igor Stasenko: >> 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. >>> | >>> | >>> >> >> >> > > -- > Janko MivÅ¡ek > Aida/Web > Smalltalk Web Application Server > http://www.aidaweb.si > >

April 24, 2012

Re: [Pharo-project] SimpleLiteralArrayParser

by StÃ©phane 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. > > I don't get it. You define your own float format, and then each dialect parses it and converts it to their correspondant format... Now, I do not know the format > differences so I do not know which one take :). It can work for simple scenario but if you save a float with e120 and save it and you get e70 then you are in trouble. Stef

April 24, 2012

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

by Igor Stasenko

On 24 April 2012 11:54, Dale Henrichs <dhenrich(a)vmware.com> wrote: > Stef, > > There is no Parser class and there is no Compiler class. There is a primitive call that takes method source, class, methodDictionary, etc. and produces a method installed in the methodDictionary. > so you can take 1st literal from such method and you done. or you cannot access method's literals? it of course not as simple as parsing the source, but if you cannot avoid compilation.. > ... JSON is and was a pragmatic choice... > well, i did not realized that GemStone have no own parser/compiler written in smalltalk. > Dale > > ----- Original Message ----- > | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > | To: Pharo-project(a)lists.gforge.inria.fr > | 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" <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. > | > | > | > | > | > | > | > | > > | > | > | > | > | > | > | > > | > | > | > -- Best regards, Igor Stasenko.

April 24, 2012

Re: [Pharo-project] SimpleLiteralArrayParser

by Mariano Martinez Peck

On Tue, Apr 24, 2012 at 12:31 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > On Tue, Apr 24, 2012 at 12:15 PM, Sven Van Caekenberghe <sven(a)beta9.be>wrote: > >> >> On 24 Apr 2012, at 11:40, stephane ducasse wrote: >> >> > 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 >> >> Good idea! >> >> I was already thinking about doing that ;-) >> >> But shouldn't there be a specification first ? >> > >> For primitives, have a look at JSON, don't make it more complicated than >> that. >> >> > Taking your last two sentences I would conclude that then we are yet > reinventing the wheele again? > I think noone has still say which is the big problem of using JSON. The > answer "we need a parser" is not enough. You will need a parser for the > literal array also. > Dale said the parser for JSON was decoupled from Seaside and quite small. > So...can someone tell me the real problem with numbers and facts please? > > BTW...wasn't Sven working in a kind of JSON for Smalltalk ? > -- Mariano http://marianopeck.wordpress.com

April 24, 2012