January 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] What we should do with the Dev image? Re: question about O2 vs OB

by Schwab,Wilhelm K

Slogans aside, there are tools that are simply not very good. To assume that what I find least offensive is least offensive to other users, or vice versa, is asking for trouble. 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: Wednesday, January 20, 2010 1:12 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] What we should do with the Dev image? Re: question about O2 vs OB On Wed, Jan 20, 2010 at 2:38 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote: I am very much in favor or providing ready choice in the browsers and tools. It would also help to have the browswers somehow brand themselves. Conversation here centers on things like O2 vs. OB, but there are at least two O2 browswers (package and system). This is exactly why having both browser is confusing a newcomer. If you cannot choose, you don't confuse :) I am probably most concerned about keeping the standard tool set which does away with the new inspector and might have other favorable side effects. 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 Miguel Enrique CobÃ¡ Martinez Sent: Wednesday, January 20, 2010 12:20 PM To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> Subject: Re: [Pharo-project] What we should do with the Dev image? Re: question about O2 vs OB El miÃ©, 20-01-2010 a las 17:44 +0100, Mariano Martinez Peck escribiÃ³: > > That's the reason of having OB and O2. While both now work > together in the same image > without inferring each other, this indeed increases the number > of classes in the image > quite a lot as they duplicate a whole bunch of code. So I > strongly suggest to either use > OB or O2, even though you can have both. But I do not see a > reason why people want to > switch between the two dynamically in the same image. > > > > We have two things to choose: which browser is default and which ones > are installed. Both ? only one ? The solution I like most, is in > these options: > > 1) Install both: OB and O2. Let OB as default. > > 2) Install only OB, of course, as default, and those who wants can > install O2 in that dev image. They way to install O2 now is very easy. > > 3) Install only OB, of course, as default, but create a group in > ConfigurationOfPharo like "StandardDevImageWithO2" so that those > people who want a dev image with O2 can just evaluate that in a core > image and wala! > > With 1 the image will be smaller but won't have O2 preinstalled. With > 2) and 3) you will have also O2 but bigger image. > > I think I will coose 2) AND 3). Those who want to install O2 directly > in a dev image, use the ConfigurationOfO2 and those who wants to > create a dev image over the core, they use ConfigurationOfPharo with > the new group I can create. I think that group are the way to go. A group for pharo dev with OB (and only OB) a group with O2 (and only O2) a group with both (and this could be the default because most new users won't have a preference). Also, this avoid give any package preference over the other. Of course, the documentation for creating a dev image, should state clearly the three options to build an image. my 2 cents > > What do you think ? > > Mariano > > > > _______________________________________________ > 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 -- Miguel CobÃ¡ http://miguel.leugim.com.mx _______________________________________________ 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

Jan. 20, 2010

Re: [Pharo-project] New profiler for Pharo: tester wanted!

by Alexandre Bergel

The millisecond grain information is obtained from MessageTally. How do I access this microsecond clock? Something like "Time class>>#microsecondClock" ? Cheers, Alexandre On 20 Jan 2010, at 16:24, John M McIntosh wrote: > You know I"m trying to integrate a microsecond clock into the VM. It > might be interesting if you > run on a macintosh to try a test V5 VM I can supply to see what > happens if you change your > time collecting from the millisecond clock to the microsecond clock. > > > On 2010-01-20, at 11:20 AM, Alexandre Bergel wrote: > >> Each implementor of #ensureMetacello is different. Even the one of >> ConfigurationOfMetacello is different from the one of the website :-) >> >> I update ConfigurationOfSpy. It loads now without any problem. >> >> Cheers, >> Alexandre > > -- > = > = > = > = > = > ====================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: > squeaker68882 > Corporate Smalltalk Consulting Ltd. http:// > www.smalltalkconsulting.com > = > = > = > = > = > ====================================================================== > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 20, 2010

Re: [Pharo-project] [update 1.1] #11167

by Alexandre Bergel

On 19 Jan 2010, at 17:55, Mariano Martinez Peck wrote: > Gofer new > squeaksource: 'MetacelloRepository'; > package: 'ConfigurationOfPharo'; > load. > > ((Smalltalk at: #ConfigurationOfPharo) project version: '1.0- > rc2.10505.2') load. > > Gofer new > squeaksource: 'ImageForDevelopers'; > package: 'ImageForDevelopers-pharo'; > load. I tried, and it ends up with an error: Could not access http://www.squeaksource.com/PrStef I think the name has been renamed into ProfStef. Let me know when you fix this, I will be happy to give another shoot. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 20, 2010

[Pharo-project] Bug in ThreadSafeTranscript

by Stefan Marr

Hi: ThreadSafeTranscript crShow: is not thread-safe, but definitely need to be thread-safe. The problem is, it is using a mutex currently. (I guess thats the reason why there is no accessSemaphore critical: [...]. in crShow) Replacing it by a reentrant/recursive Monitor would probably allow to avoid code duplication. Best Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 3956 Fax: +32 2 629 3525

Jan. 20, 2010

Re: [Pharo-project] A dog-slow browser

by StÃ©phane Ducasse

color | flags aColor | true ifTrue: [ ^ Color transparent ]. flags := 0. self isThisAnOverride ifTrue: [ flags := flags bitOr: 4 ]. currentCompiledMethod sendsToSuper ifTrue: [ flags := flags bitOr: 2 ]. self isThereAnOverride ifTrue: [ flags := flags bitOr: 1 ]. aColor := { Color transparent. Color tan lighter. Color green muchLighter. Color blue muchLighter. Color red muchLighter. "has super but doesn't call it" (Color r: 0.94 g: 0.823 b: 0.673). "has sub; has super but doesn't call it" Color green muchLighter. Color blue muchLighter. } at: flags + 1. ^aColor! ! BTW why do we create all the time this array? On Jan 20, 2010, at 6:56 PM, Adrian Lienhard wrote: > Ok, in the class Morph it is not really smooth, also on my MacBook Pro. > > I quickly did some profiling and came up with the following speedups (i.e., experimental hacks): > > <BrowserSpeedup.1.cs> > > Is it better now? > > Cheers, > Adrian > > BTW, not GC makes it slow but often recomputing the method list. Also, button colors are computed expensively, even though they are not used. > > > On Jan 20, 2010, at 17:56 , Levente Uzonyi wrote: > >> On Wed, 20 Jan 2010, Mariano Martinez Peck wrote: >> >>> On Wed, Jan 20, 2010 at 5:44 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: >>> >>>> Smalltalk garbageCollect >>>> >>> >>> hahahaha sorry. As you said "a full GC" I imagined that there was another >> >> There is: incremental gc. You can trigger it with Smalltalk >> garbageCollectMost. >> >> >> Levente >> >>> kind of GC (like gemstine) that I was not aware of :) >>> >>> >>>> >>>> On Jan 20, 2010, at 17:37 , Mariano Martinez Peck wrote: >>>> >>>>> On Wed, Jan 20, 2010 at 5:33 PM, Adrian Lienhard <adi(a)netstyle.ch> >>>> wrote: >>>>> >>>>>> just a wild guess: maybe its a GC edge case? >>>>>> >>>>>> When it happens, trigger a full GC and see if it is still slow... >>>>>> >>>>>> >>>>> how do you do that Adrian ? >>>>> >>>>> >>>>>> Adrian >>>>>> >>>>>> On Jan 20, 2010, at 17:26 , Gary Chambers wrote: >>>>>> >>>>>>> A good few months back I noticed similarly inexplicable slowness (that >>>> I >>>>>>> mistakenly ascribed to some changes...). Went away after image >>>>>>> save/restart... maybe that kind of thing has happened. >>>>>>> >>>>>>> Regards, Gary >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>> From: "Igor Stasenko" <siguctua(a)gmail.com> >>>>>>> To: <Pharo-project(a)lists.gforge.inria.fr> >>>>>>> Sent: Wednesday, January 20, 2010 4:16 PM >>>>>>> Subject: Re: [Pharo-project] A dog-slow browser >>>>>>> >>>>>>> >>>>>>>> 2010/1/20 Gary Chambers <gazzaguru2(a)btinternet.com>: >>>>>>>>> Super quick here... (1.1 latest updates, admittedly a quad-core, only >>>>>> one >>>>>>>>> used though...) >>>>>>>> >>>>>>>> I have to take my words back. >>>>>>>> Strange, very strange.. its now magically started working quite fast.. >>>>>>>> As i said, first time i run it, it was flickering the hourglass mouse >>>>>>>> cursor each time i switching between methods in browser. >>>>>>>> What was it? And why it disappears? Any suggestions? >>>>>>>> >>>>>>>>> >>>>>>>>> Regards, Gary >>>>>>>>> >>>>>>>>> ----- Original Message ----- >>>>>>>>> From: "Marcus Denker" <marcus.denker(a)inria.fr> >>>>>>>>> To: <Pharo-project(a)lists.gforge.inria.fr> >>>>>>>>> Sent: Wednesday, January 20, 2010 3:47 PM >>>>>>>>> Subject: Re: [Pharo-project] A dog-slow browser >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Jan 20, 2010, at 4:35 PM, Igor Stasenko wrote: >>>>>>>>>> >>>>>>>>>>> 2010/1/20 Marcus Denker <marcus.denker(a)inria.fr>: >>>>>>>>>>>> >>>>>>>>>>>> On Jan 20, 2010, at 4:28 PM, Igor Stasenko wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Please, don't take it as a offense, but as a constructive critics >>>>>> :) >>>>>>>>>>>>> >>>>>>>>>>>>> Pharo-core browser is awfully slooow! >>>>>>>>>>>>> >>>>>>>>>>>> Pharo core? Or Pharo dev? >>>>>>>>>>>> >>>>>>>>>>> core >>>>>>>>>> >>>>>>>>>> It should not... it uses the fast fonts, no syntax highligting... >>>>>>>>>> In essense, it should be the same performance than Squeak 3.9. >>>>>>>>>> >>>>>>>>>> Is it slower than that? I can not see any problem (the curse of a >>>> fast >>>>>>>>>> machine?) >>>>>>>>>> >>>>>>>>>> Marcus >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Marcus Denker -- http://www.marcusdenker.de >>>>>>>>>> INRIA Lille -- Nord Europe. Team RMoD. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> 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 >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Best regards, >>>>>>>> Igor Stasenko AKA sig. >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>> >>>>> _______________________________________________ >>>>> 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 20, 2010

Re: [Pharo-project] What we should do with the Dev image? Re: question about O2 vs OB

by csrabak＠bol.com.br

I think that as Pharo evolves as a proposition of a better implementation of Smalltalk, the Pharo community will have to choose one browser as the preferred (not only default) to be supported in the broad sense: documentation, preference to bug fixes, mentioning in the books, videos and other training material, etc. Among other things we shall have reduce the space of choices to avoid the "paradox of choice" http://en.wikipedia.org/wiki/Decision_theory#Paradox_of_choice problem. my 0.019999... -- Cesar Rabak Em 20/01/2010 14:44, Mariano Martinez Peck <marianopeck(a)gmail.com> escreveu: That's the reason of having OB and O2. While both now work together in the same image without inferring each other, this indeed increases the number of classes in the image quite a lot as they duplicate a whole bunch of code. So I strongly suggest to either use OB or O2, even though you can have both. But I do not see a reason why people want to switch between the two dynamically in the same image. We have two things to choose: which browser is default and which ones are installed. Both ? only one ?Â The solution I like most, is in these options: 1) Install both: OB and O2. Let OB as default. 2) Install only OB, of course, as default, and those who wants can install O2 in that dev image. They way to install O2 now is very easy. 3) Install only OB, of course, as default, but create a group in ConfigurationOfPharo like "StandardDevImageWithO2" so that those people who want a dev image with O2 can just evaluate that in a core image and wala! With 1 the image will be smaller but won't have O2 preinstalled. With 2) and 3)Â you will have also O2 but bigger image. I think I will coose 2) AND 3). Those who want to install O2 directly in a dev image, use the ConfigurationOfO2 and those who wants to create a dev image over the core, they use ConfigurationOfPharo with the new group I can create. What do you think ? Mariano

Jan. 20, 2010

Re: [Pharo-project] ocompletion bug fix

by StÃ©phane Ducasse

yeahhhhhhh me too. Good to hear that it was killed! Stef On Jan 20, 2010, at 6:59 PM, Sean Allen wrote: > I just fixed a bug that has been driving me crazy for a while in the > Ocompletion package. > > When you select an area of text and delete, if you are deleting all of > it, it throws a subscript out of bounds error. > > What is the proper process for getting this change integrated? > I'm not really sure who this small fix should be sent to. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 20, 2010

Re: [Pharo-project] FileStream speed up

by StÃ©phane Ducasse

thanks I will have a look and follow your advice. > >> Hi levente >> >> can you have a look at the attached cs? >> > > I had a quick look and found that the changes for MultiByteFileStream are still missing. Those are the first that you should apply. Why? Because some methods (#upToEnd IIRC) use the collection instance variable for no reason. If you keep that method and apply the changes to StandardFileStream, (as I pointed out earlier) the system may break. > Also the fix from Files-ul.67 is missing (StandardFileStream >> #upTo:). > > I suggest you to make 3 steps to integrate the changes: > 1. Integrate the changes to MultiByteFileStream > 2. Integrate the changes to StandardFileStream > 3. Evaluate: > StandardFileStream allSubInstancesDo: [ :each | > each closed ifFalse: [ each enableReadBuffering ] ] > Then save the image, run tests, reopen the image, run tests. Every test should pass which passed before. > > > Levente_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 20, 2010

Re: [Pharo-project] What we should do with the Dev image? Re: question about O2 vs OB

by laurent laffont

May be this is off topic, but when I was working in embedded linux development I have used a cool tool to customize its own linux image before downloading it. It's narcissus from angstrom distribution: http://www.angstrom-distribution.org/narcissus/ For me, a Pharo image and a linux distribution are quite similar when talking about packages. With Metacello, Loader and Seaside, may be such a tool to configure your image to download is not a big deal ? So everybody can easily choose between OB, O2 or both, WorkingSet / Algernon, AidaWeb / Seaside, .... Laurent On Wed, Jan 20, 2010 at 8:19 PM, Tudor Girba <tudor.girba(a)gmail.com> wrote: > I agree with this solution. > > As much as it pains me to work with OB (and I forced myself to do it > for 2 weeks :)), it is stable and this issue prevails at this moment > for 1.0. > > Cheers, > Doru > > > On 20 Jan 2010, at 19:10, Mariano Martinez Peck wrote: > > > > > > > On Wed, Jan 20, 2010 at 3:03 PM, Adrian Lienhard <adi(a)netstyle.ch> > > wrote: > > Hi Mariano, > > > > > 2) Install only OB > > > > is a reasonable choice. We are very close to a 1.0 release and > > including OB again at this point does not make sense. The risk for > > unknown bugs that we needed to fix in maintenance releases of 1.0 is > > too high in my opinion. > > > > > > > > Thanks Adrian. I didn't want to say it, but yes. I think like you. > > WE NEED TO RELEASE 1.0 NOW!!!! and as much as stable possible. > > > > For new comers, I think it is even easier to have only one browser. > > Having two, bring to confussion, insecurity, etc. Once the newcomer > > stop to be newcomer, he will be able to install O2 by himself and > > take his own opinion on both browsers. > > > > And come on...that's the idea of Metacello!! that each people can > > load whatever they want. > > > > so.... +1 (ouch...I have already voted!) > > > > However, when we start building images for 1.1 we should consider to > > add it again. > > > > Cheers, > > Adrian > > > > On Jan 20, 2010, at 17:44 , Mariano Martinez Peck wrote: > > > > >> That's the reason of having OB and O2. While both now work > > together in the > > >> same image > > >> without inferring each other, this indeed increases the number of > > classes > > >> in the image > > >> quite a lot as they duplicate a whole bunch of code. So I > > strongly suggest > > >> to either use > > >> OB or O2, even though you can have both. But I do not see a > > reason why > > >> people want to > > >> switch between the two dynamically in the same image. > > >> > > >> > > > > > > We have two things to choose: which browser is default and which > > ones are > > > installed. Both ? only one ? The solution I like most, is in > > these options: > > > > > > 1) Install both: OB and O2. Let OB as default. > > > > > > 2) Install only OB, of course, as default, and those who wants can > > install > > > O2 in that dev image. They way to install O2 now is very easy. > > > > > > 3) Install only OB, of course, as default, but create a group in > > > ConfigurationOfPharo like "StandardDevImageWithO2" so that those > > people who > > > want a dev image with O2 can just evaluate that in a core image > > and wala! > > > > > > With 1 the image will be smaller but won't have O2 preinstalled. > > With 2) and > > > 3) you will have also O2 but bigger image. > > > > > > I think I will coose 2) AND 3). Those who want to install O2 > > directly in a > > > dev image, use the ConfigurationOfO2 and those who wants to create > > a dev > > > image over the core, they use ConfigurationOfPharo with the new > > group I can > > > create. > > > > > > What do you think ? > > > > > > Mariano > > > _______________________________________________ > > > 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 > > -- > www.tudorgirba.com > > "Reasonable is what we are accustomed with." > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 20, 2010

Re: [Pharo-project] A dog-slow browser

by Henrik Sperre Johansen

On 20.01.2010 18:56, Adrian Lienhard wrote: > Ok, in the class Morph it is not really smooth, also on my MacBook Pro. > > I quickly did some profiling and came up with the following speedups (i.e., experimental hacks): > > > > > > > Is it better now? > > Cheers, > Adrian > > BTW, not GC makes it slow but often recomputing the method list. Also, button colors are computed expensively, even though they are not used. > Yes, my only "gripe" with the Polymorph themes is they tend to recompute/replace morph properties rather than retain the current if it has not changed. This also makes any kind of caching impossible (say, f.ex. in Color for heavily accessed derived colors like twiceDarker/Lighter, or an appropiately sized Form for AlphaInfiniteForms). Changing it would be a major overhaul of how it currently works though, and would be much easier if themed in the way Igor proposed. Cheers, Henry

Jan. 20, 2010