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

Re: [Pharo-project] [ANN] PharoLauncher for Mac users

by Peter Hugosson-Miller

Bookmarking this for when I get Lion on my personal MBP. It's still stuck on Snow Leopard for now :-( But this looks _really_ interesting, great job! /Peter On Tue, Apr 24, 2012 at 12:29 PM, HwaJong Oh <daliot.oh(a)gmail.com> wrote: > Simple. > > I want to use Autolayout feature, which requires Lion(Mac OS X 10.7). :-) > It is such a magic. Morphic may be great with it. > > HwaJong Oh > > -- > View this message in context: > http://forum.world.st/ANN-PharoLauncher-for-Mac-users-tp4580756p4582996.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.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, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 24 April 2012 12:50, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: >> 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. >> > > If you pick smalltalk , it is ansi standard.. so.. what the point? > >> +1 There is already a documentation of the format. No additional work needed. >> >>> 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 > > this is killer argument ;) > > can you name just one which can be useful in this context??? > what tools, except written in smalltalk and used by smalltalkers you > are expecting to use > with smalltalk source code stored in source code repositories? JavaScript :-) in connection with Amber. And couchDB. > > Sorry, the only valid and understandable argument here to me, is that > it is purely pragmatic choice :) And as Dale writes. It is already implemented in different dialects of Smalltalk. Thank you for asking Hannes > -- > Best regards, > Igor Stasenko. > >

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 12:53, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> 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. > > 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. yeah. lets store our metadata in SQL syntax.. so we are closer to SQL databases.. LOL :) > >> and even more by >> using GitHub for code repository. > > > -- Best regards, Igor Stasenko.

April 24, 2012

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

by Igor Stasenko

On 24 April 2012 12:50, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: > 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. > If you pick smalltalk , it is ansi standard.. so.. what the point? > +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 this is killer argument ;) can you name just one which can be useful in this context??? what tools, except written in smalltalk and used by smalltalkers you are expecting to use with smalltalk source code stored in source code repositories? Sorry, the only valid and understandable argument here to me, is that it is purely pragmatic choice :) -- Best regards, Igor Stasenko.

April 24, 2012

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