July 2009 - Pharo-dev - lists.pharo.org

[Pharo-project] Fwd: Issue 513 in pharo: UTF8 and file names

by StÃ©phane Ducasse

> can other people check so that we can close it. :) > Thanks marco. > > Stef > > Begin forwarded message: > >> From: codesite-noreply(a)google.com >> Date: July 3, 2009 10:33:34 AM CEDT >> To: stephane.ducasse(a)gmail.com >> Subject: Issue 513 in pharo: UTF8 and file names >> >> >> Comment #7 on issue 513 by MarcoTaugammaSchmidt: UTF8 and file names >> http://code.google.com/p/pharo/issues/detail?id=513 >> >> This bug should be closed? It works for me... >> >> >> -- >> You received this message because you are listed in the owner >> or CC fields of this issue, or because you starred this issue. >> You may adjust your issue notification preferences at: >> http://code.google.com/hosting/settings > > > >

July 3, 2009

Re: [Pharo-project] What will be the standard browser in Pharo?

by StÃ©phane Ducasse

yes yes yes! Stef On Jul 3, 2009, at 10:15 AM, Adrian Lienhard wrote: > Hi Bill, > > Performance is certainly important. Please don't stop bugging us to > make progress at this front too ;) > > What we should start with is to identify which features makes it slow. > > I recently posted basic benchmarks [1], but we need to identify single > features so that we know where to optimize or which features should > better be disabled. > > What would help is if you could tell us what exactly is slow (at the > moment I'm mainly working in the core image without freetype fonts and > speed feels ok on my MacBook Pro). > > Cheers, > Adrian > > [1] http://lists.gforge.inria.fr/pipermail/pharo-project/2009-June/009905.html > > > On Jul 3, 2009, at 00:29 , Schwab,Wilhelm K wrote: > >> Stef, >> >> Understood, but since you appear to be leaving open things that I >> consider to be drastic (removing traits), it only seems reasonable >> to try the faster browser on some slower machines to see what impact >> it makes. It would not take too much prodding for me to be able to >> give some guidance along the lines of "not enough impact to be of >> help" or "well worth adopting." _Something_ is eating up a lot of >> clock cycles at present. >> >> Bill >> >> >> ________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr >> ] On Behalf Of Mariano Martinez Peck >> Sent: Thursday, July 02, 2009 4:25 PM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] What will be the standard browser in >> Pharo? >> >> "Ideally we would love to have a fast browser with package >> support:..." >> >> Notice the "ideally" and the "would" haha >> >> On Thu, Jul 2, 2009 at 8:22 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu >> <mailto:bschwab@anest.ufl.edu>> wrote: >> Stef, >> >> Is there a way to get the fast browser, or an image with it loaded? >> >> Bill >> >> >> -----Original Message----- >> From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr >>> [mailto:pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr >>> ] On Behalf Of StÃ©phane Ducasse >> Sent: Thursday, July 02, 2009 3:30 PM >> To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr >>> >> Subject: Re: [Pharo-project] What will be the standard browser in >> Pharo? >> >> Hi oscar >> >> Ideally we would love to have a fast browser with package support: >> - dual browser >> - class extensions >> - traits >> - refactoring >> - icons >> >> Now apparently OBEnhancements was a bit dirty and this is not clear >> what colin will integrate or not. >> Lukas has a OB version which is fast but it does not have >> - dual browser >> - class extensions >> - traits >> - icons >> So david and lukas should talk a bit more and we could get the best >> of the worlds. >> Saturday we should have a discussion. Having a fast but powerful >> browser is important and right now if the browser does not support >> trait then we should remove traits from the image. >> Similarly we cannot work well without class extension support and >> other package related functionality. >> Stef >> >> >> >> On Jul 2, 2009, at 9:07 PM, Oscar Nierstrasz wrote: >> >>> >>> Hi Folks, >>> >>> I am trying to port Squeak by Example to Pharo by Example. I am a >>> bit >>> confused about what is suppose dto be the standard browser now. I >>> thought it was the OB Package Browser, but Damien Cassou just gave >>> me >>> a new image where the browser is an OB System Browser (Categories, >>> not >>> packages). I cannot even see any more how to switch between the >>> two. >>> >>> Can someone enlighten me? (Then I can explain it in the book.) >>> >>> - on >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr >>>> >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr >>> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr >>> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 3, 2009

Re: [Pharo-project] adding nil to sets

by StÃ©phane Ducasse

Thanks ralph. I think that this is not a so good idea to have nil as element. BTW: just to make sure. Our is not to hijack people from the squeak community (because when I scanned some emails there I thought that we were considered as evil and bad guys - people have a short memory). Our goal is to build an agile Smalltalk with faster, better.... code. And to make sure that people can reinvent the future because they can use cool abstractions. Stef On Jul 3, 2009, at 8:53 AM, Ralph Boland wrote: > Please note the change of topic; adding the ability to add nil to > sets > won't make sets faster and may well make them slower so has nothing > to to with the FasterSets package. > > Since I am here allow me to state my opinion on the matter. > We should not add the ability to add nil to Sets. While I admit I > don't > know for sure, I believe the number of instances where we need to add > nil to a set is rare. For the rare cases in which it is needed we > should > create a class SetSupportingNils which has two instance variables: > containsNil: a boolean set to true iff the SetSupportingNils > instance contains nil. > > set: an instance of Set or one of its subclasses and used to > store any object added to the SetSupportingNils instance except > of course nil. > > This means that SetSupportingNils would need to recognize > any message that Sets or its subclasses can understand. > Any message not understood by SetSupportingNils would be > forwarded to its set instance variable. > My proposal is not very efficient when adding nil to a set is > needed but it requires no modifications to Set or any of its > subclasses. > That a rarely used class is somewhat inefficient is acceptable. > > Issue: > I suppose we need a BagSupportingNils class too. > Are there any other classes we need? > Can they be combined into one class? > > Regards, > > Ralph Boland > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 3, 2009

Re: [Pharo-project] FasterSets improvements

by StÃ©phane Ducasse

Thanks > IIRC, the behavior of adding nil to a Set is undefined as per ANSI. > In > VW, adding nil is a no-op. In that case I would not let nil to be a possible element and avoid incompatibility. But this is strange since I remember having problem to port code from VW to Squeak Stef

July 3, 2009

[Pharo-project] [ANN] 10351

by StÃ©phane Ducasse

De : StÃ©phane Ducasse [mailto:stephane.ducasse@inria.fr] EnvoyÃ© : jeudi 2 juillet 2009 23:48 Ã : Emmanuelle Pham Objet : Fwd: [ANN] 10351 Hi all here are some other updates - issue 67: better end of line guessing - issue 879: Float ANSI Thanks norbert and nicolas Stef

July 3, 2009

Re: [Pharo-project] What will be the standard browser in Pharo?

by Lukas Renggli

> Lukas, how did you put a syntax highlight for this script? > Can't beleive Google supports smalltalk syntax highlighting :) That's done automatically. I guess it uses Javascript highlighting, it is certainly not quite correct. AFAIK there is no way to disable or change it. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

July 3, 2009

Re: [Pharo-project] What will be the standard browser in Pharo?

by Igor Stasenko

2009/7/3 Lukas Renggli <renggli(a)gmail.com>: >> Is there a way to get the fast browser, or an image with it loaded? > > You use a Pharo-Core image and the script published here (you might > want to comments the parts you don't need, e.g. Seaside, Magirtte, > Pier): > > Â Â http://code.google.com/p/pharo/wiki/ImageBuildScripts > Lukas, how did you put a syntax highlight for this script? Can't beleive Google supports smalltalk syntax highlighting :) > Lukas > > 2009/7/2 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: >> Stef, >> >> Is there a way to get the fast browser, or an image with it loaded? >> >> Bill >> >> >> -----Original Message----- >> From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse >> Sent: Thursday, July 02, 2009 3:30 PM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] What will be the standard browser in Pharo? >> >> Hi oscar >> >> Ideally we would love to have a fast browser with package support: >> Â Â Â Â - dual browser >> Â Â Â Â - class extensions >> Â Â Â Â - traits >> Â Â Â Â - refactoring >> Â Â Â Â - icons >> >> Now apparently OBEnhancements was a bit dirty and this is not clear what colin will integrate or not. >> Lukas has a OB version which is fast but it does not have >> Â Â Â Â - dual browser >> Â Â Â Â - class extensions >> Â Â Â Â - traits >> Â Â Â Â - icons >> So david and lukas should talk a bit more and we could get the best of the worlds. >> Saturday we should have a discussion. Having a fast but powerful browser is important and right now if the browser does not support trait then we should remove traits from the image. >> Similarly we cannot work well without class extension support and other package related functionality. >> Stef >> >> >> >> On Jul 2, 2009, at 9:07 PM, Oscar Nierstrasz wrote: >> >>> >>> Hi Folks, >>> >>> I am trying to port Squeak by Example to Pharo by Example. Â I am a bit >>> confused about what is suppose dto be the standard browser now. Â I >>> thought it was the OB Package Browser, but Damien Cassou just gave me >>> a new image where the browser is an OB System Browser (Categories, not >>> packages). Â I cannot even see any more how to switch between the two. >>> >>> Can someone enlighten me? Â (Then I can explain it in the book.) >>> >>> - on >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

July 3, 2009

Re: [Pharo-project] What will be the standard browser in Pharo?

by Adrian Lienhard

Hi Bill, Performance is certainly important. Please don't stop bugging us to make progress at this front too ;) What we should start with is to identify which features makes it slow. I recently posted basic benchmarks [1], but we need to identify single features so that we know where to optimize or which features should better be disabled. What would help is if you could tell us what exactly is slow (at the moment I'm mainly working in the core image without freetype fonts and speed feels ok on my MacBook Pro). Cheers, Adrian [1] http://lists.gforge.inria.fr/pipermail/pharo-project/2009-June/009905.html On Jul 3, 2009, at 00:29 , Schwab,Wilhelm K wrote: > Stef, > > Understood, but since you appear to be leaving open things that I > consider to be drastic (removing traits), it only seems reasonable > to try the faster browser on some slower machines to see what impact > it makes. It would not take too much prodding for me to be able to > give some guidance along the lines of "not enough impact to be of > help" or "well worth adopting." _Something_ is eating up a lot of > clock cycles at present. > > Bill > > > ________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr > ] On Behalf Of Mariano Martinez Peck > Sent: Thursday, July 02, 2009 4:25 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] What will be the standard browser in > Pharo? > > "Ideally we would love to have a fast browser with package > support:..." > > Notice the "ideally" and the "would" haha > > On Thu, Jul 2, 2009 at 8:22 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu > <mailto:bschwab@anest.ufl.edu>> wrote: > Stef, > > Is there a way to get the fast browser, or an image with it loaded? > > Bill > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr > > [mailto:pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr > >] On Behalf Of StÃ©phane Ducasse > Sent: Thursday, July 02, 2009 3:30 PM > To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr > > > Subject: Re: [Pharo-project] What will be the standard browser in > Pharo? > > Hi oscar > > Ideally we would love to have a fast browser with package support: > - dual browser > - class extensions > - traits > - refactoring > - icons > > Now apparently OBEnhancements was a bit dirty and this is not clear > what colin will integrate or not. > Lukas has a OB version which is fast but it does not have > - dual browser > - class extensions > - traits > - icons > So david and lukas should talk a bit more and we could get the best > of the worlds. > Saturday we should have a discussion. Having a fast but powerful > browser is important and right now if the browser does not support > trait then we should remove traits from the image. > Similarly we cannot work well without class extension support and > other package related functionality. > Stef > > > > On Jul 2, 2009, at 9:07 PM, Oscar Nierstrasz wrote: > >> >> Hi Folks, >> >> I am trying to port Squeak by Example to Pharo by Example. I am a >> bit >> confused about what is suppose dto be the standard browser now. I >> thought it was the OB Package Browser, but Damien Cassou just gave me >> a new image where the browser is an OB System Browser (Categories, >> not >> packages). I cannot even see any more how to switch between the two. >> >> Can someone enlighten me? (Then I can explain it in the book.) >> >> - on >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr >> > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 3, 2009

[Pharo-project] adding nil to sets

by Ralph Boland

Please note the change of topic; adding the ability to add nil to sets won't make sets faster and may well make them slower so has nothing to to with the FasterSets package. Since I am here allow me to state my opinion on the matter. We should not add the ability to add nil to Sets. While I admit I don't know for sure, I believe the number of instances where we need to add nil to a set is rare. For the rare cases in which it is needed we should create a class SetSupportingNils which has two instance variables: containsNil: a boolean set to true iff the SetSupportingNils instance contains nil. set: an instance of Set or one of its subclasses and used to store any object added to the SetSupportingNils instance except of course nil. This means that SetSupportingNils would need to recognize any message that Sets or its subclasses can understand. Any message not understood by SetSupportingNils would be forwarded to its set instance variable. My proposal is not very efficient when adding nil to a set is needed but it requires no modifications to Set or any of its subclasses. That a rarely used class is somewhat inefficient is acceptable. Issue: I suppose we need a BagSupportingNils class too. Are there any other classes we need? Can they be combined into one class? Regards, Ralph Boland

July 3, 2009

Re: [Pharo-project] FasterSets improvements

by Igor Stasenko

2009/7/3 Andres Valloud <avalloud(a)smalltalk.comcastbiz.net>: > Why does #like: have to be disabled? Â Why can't you provide an > implementation for it? > > Every add: has an additional nil check. Â I'd bet that in 99.9999% of the > cases, the nil check is effectively overhead. Â In efficient > implementations of hashed collections, you can tell when you add a few > message sends because it costs about 10% (as I measured for > findElementOrNil: in VW's IdentitySet). > you forgot that #add: in Set has an additional nil check already :) > Besides the additional complexity, is do: actually correct? Â How can a > set includeNil but have a tally of 0? Â I am suspicious that add: should > increase the tally when you add nil (more complexity). > again, 'tally' is an internal state. Not something you can see or meaningfully use outside. > Every removal has an additional nil check. Â I also note that the tally > is not updated either... > well, you can test it, if you think it wrongly implemented. > So. Â I wanted to point out that these 8 refined methods give you: > > * Inflexible implementation. Â If Set changes, then you have to change > GenericSet too. > can't accept such argument. Should i implement it from scratch by subclassing from Object? > * Additional code complexity that people have to deal with. > where? and what you mean by 'deal with'? Did i extended a Set protocol, or something like that? > * But you can add nil to a Set. > > Let's say you write code with GenericSet and use the fact that you can > add nils. Â In the vast majority of Smalltalks (all?), you can't add nil > to a set. Â So, if you want to port code, you have to port GenericSet > (and apply the necessary refinements N times). Â You can't use the > everyday Set that IIRC is specified in the ANSI standard. > I can say similar about situations where you need to use sets where it meaningfully can contain nils. Each time, in every such place, you have to write a workarounds to count nil separately. Now compare this with a class, which provides you this in a simple and usual manner. > Again, is it worth the effort? > > Finally, of course you compare GenericSet to e.g.: HPS, and there's no > complexity at all. Â Nevertheless, I've come to think that "I can do it" > generally doesn't mean "I should do it". > Sure thing. But you will recall my words each time when you will need to deal with nil, as with useful and valuable object, which you can treat in same way as others. > Andres. > > -- Best regards, Igor Stasenko AKA sig.

July 3, 2009