- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Issue 832

by Henrik Johansen

Sure. I'd wait applying it till others can confirm that simply saving after running an update does not fix their performance problems though, as outlined in my last mail. Cheers, Henry StÃ©phane Ducasse skrev: > can you send me the st for the reverting? > > Stef > > On May 28, 2009, at 10:08 AM, Henrik Johansen wrote: > > >> It's strange though, for me dragging is just as slow reverting the >> changes I made in a 319 image... >> And filing in the .st in a 309 image, I notice no slow downs. (309 >> upgraded to 319 I do). >> >> Are we sure nothing else causes this, perhaps changes related to >> events/polling frequency or something? >> >> Cheers, >> Henry >> >> Schwab,Wilhelm K skrev: >> >>> Henry, >>> >>> I for one appreciate your effort, and encourage you to keep going. >>> Speaking of slow machines, I have a small herd and would be willing >>> to >>> help you profile the problem. Give me about a month, and I will be >>> in >>> a position to press them into service to help with this. >>> >>> Bill >>> >>> >>> ------------------------------------------------------------------------ >>> *From:* pharo-project-bounces(a)lists.gforge.inria.fr >>> [mailto:pharo-project-bounces@lists.gforge.inria.fr] *On Behalf Of >>> *Henrik Sperre Johansen >>> *Sent:* Wednesday, May 27, 2009 5:07 PM >>> *To:* Pharo-project(a)lists.gforge.inria.fr >>> *Subject:* Re: [Pharo-project] Issue 832 >>> >>> Sorry, just back from the pub (YAY BARCELONA!) my initial reaction >>> was really: >>> I'd rather see the cause of such slowdowns while resizing >>> investigated >>> (and fixed), but considering the time needed to accomplish that, >>> rollbacking is probably a safer option at this time. >>> My mind absolutely boggles that a resizing performance decrease would >>> be the most visible effect of the changes made in that update... >>> Welcome to the wonderful world of Morphic! >>> >>> Cheers, >>> Henry >>> >>> On 27.05.2009 23:54, Henrik Sperre Johansen wrote: >>> >>>> Yes, rollbacking probably is the safest choice, >>>> As I implied in the mail, this was really meant as a experimental >>>> effort, to see if people on slower machines noticed the effects I >>>> was >>>> (pre)anticipating. >>>> I really don't see how an extra intersect: per Morph (containing >>>> submorphs) can make such a big difference... >>>> >>>> I'll definately post another update sometime in the future, I don't >>>> know when I'll have to look into it though. >>>> <rant> >>>> To me, the way it is right now seems unacceptable, there's really no >>>> reason to write a "smart" drawOn: routine for morphs that are likely >>>> to end up as a subMorph (saaaay, the TextMorph which I started >>>> investigating in the first place), as they have to redraw the entire >>>> area anyways. >>>> This leads to a bad cycle in morph development; >>>> "As long as at minimum the area we want to redraw is marked as, it's >>>> fine. There's no performance gain from reporting a more accurate >>>> area >>>> anyways". >>>> So you end up with "sloppy" damage rects for new morphs, which leads >>>> to more to fix if it IS changed, and slower performance for those >>>> whom redrawing the entire area rather than a subsection IS >>>> expensive. >>>> </rant> >>>> >>>> Cheers, >>>> Henry >>>> >>>> >>>> On 27.05.2009 19:44, StÃ©phane Ducasse wrote: >>>> >>>>> Thanks for reporting. >>>>> Henrik? >>>>> I could rollback the changes. >>>>> >>>>> Stef >>>>> >>>>> On May 27, 2009, at 6:25 PM, Gary Chambers wrote: >>>>> >>>>> >>>>> >>>>>> Performance of UI seems poor after 832 integration. >>>>>> >>>>>> http://code.google.com/p/pharo/issues/detail?id=832 >>>>>> >>>>>> Regards, Gary >>>>>> >>>>>> _______________________________________________ >>>>>> 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 > > > 'From Pharo0.1 of 16 May 2008 [Latest update: #10309] on 28 May 2009 at 11:39:22 am'! !Morph methodsFor: 'drawing' stamp: 'dgd 2/22/2003 14:31'! drawSubmorphsOn: aCanvas "Display submorphs back to front" | drawBlock | submorphs isEmpty ifTrue: [^self]. drawBlock := [:canvas | submorphs reverseDo: [:m | canvas fullDrawMorph: m]]. self clipSubmorphs ifTrue: [aCanvas clipBy: self clippingBounds during: drawBlock] ifFalse: [drawBlock value: aCanvas]! ! !LazyMorphListMorph methodsFor: 'as yet unclassified' stamp: 'gvc 5/3/2006 14:27'! drawSubmorphsOn: aCanvas "Display submorphs back to front" |drawBlock i| submorphs isEmpty ifTrue: [^self]. drawBlock := [:canvas | (self topVisibleRowForCanvas: aCanvas) to: (self bottomVisibleRowForCanvas: aCanvas) do: [ :row | i := self item: row. canvas fullDrawMorph: i]]. self clipSubmorphs ifTrue: [aCanvas clipBy: self clippingBounds during: drawBlock] ifFalse: [drawBlock value: aCanvas]! ! !PasteUpMorph methodsFor: 'painting' stamp: 'nk 7/4/2003 15:59'! drawSubmorphsOn: aCanvas "Display submorphs back to front, but skip my background sketch." | drawBlock | submorphs isEmpty ifTrue: [^self]. drawBlock := [:canvas | submorphs reverseDo: [:m | m ~~ backgroundMorph ifTrue: [ canvas fullDrawMorph: m ]]]. self clipSubmorphs ifTrue: [aCanvas clipBy: self clippingBounds during: drawBlock] ifFalse: [drawBlock value: aCanvas]! ! !TabSelectorMorph methodsFor: 'as yet unclassified' stamp: 'gvc 5/31/2007 14:11'! drawSubmorphsOn: aCanvas "Display submorphs back to front. Draw the focus here since we are using inset bounds for the focus rectangle." super drawSubmorphsOn: aCanvas. self hasKeyboardFocus ifTrue: [ self selectedTab ifNotNilDo: [:t | self clipSubmorphs ifTrue: [aCanvas clipBy: self clippingBounds during: [:c | t drawKeyboardFocusOn: c]] ifFalse: [t drawKeyboardFocusOn: aCanvas]]]! !

May 28, 2009

Re: [Pharo-project] MethodDictionary >> #do: deprecated

by Simon Denier

Well, the previous implementation of MethodDictionary#do: (non- licence clean) looks like an optimization with some nil check. So far I didnt have any problem running with replacement code, and the super implementation in Dictionary should work fine too. Does someone know when/why nil values could be stored in a method dictionary? On 28 mai 09, at 11:25, Romain Robbes wrote: > in Pharo 10318 > > On May 28, 2009, at 11:12 AM, StÃ©phane Ducasse wrote: > >> in which image? >> >> Stef >> >> On May 28, 2009, at 10:48 AM, Romain Robbes wrote: >> >>> Each time methodDictionary >> #do: is invoked, I get a warning. >>> Worse, if warnings are disabled, it will not do anything, which >>> sounds >>> error-prone. >>> >>> Why not just removing the method and use the implementation in >>> Dictionary? >>> >>> Romain >>> >>> -- >>> Romain Robbes >>> http://www.inf.unisi.ch/phd/robbes >>> >>> >>> _______________________________________________ >>> 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 > > -- > Romain Robbes > http://www.inf.unisi.ch/phd/robbes > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Simon

May 28, 2009

Re: [Pharo-project] Issue 832

by Henrik Johansen

To clarify after some more mucking about: After updating 309 to 319, there's noticeable . Save that image though, and the slowdown goes away... With 309 and 318 dev images side by side, I really can't notice any performance difference. Henrik Johansen skrev: > It's strange though, for me dragging is just as slow reverting the > changes I made in a 319 image... > And filing in the .st in a 309 image, I notice no slow downs. (309 > upgraded to 319 I do). > > Are we sure nothing else causes this, perhaps changes related to > events/polling frequency or something? > > Cheers, > Henry > > Schwab,Wilhelm K skrev: > >> Henry, >> >> I for one appreciate your effort, and encourage you to keep going. >> Speaking of slow machines, I have a small herd and would be willing to >> help you profile the problem. Give me about a month, and I will be in >> a position to press them into service to help with this. >> >> Bill >> >> >> ------------------------------------------------------------------------ >> *From:* pharo-project-bounces(a)lists.gforge.inria.fr >> [mailto:pharo-project-bounces@lists.gforge.inria.fr] *On Behalf Of >> *Henrik Sperre Johansen >> *Sent:* Wednesday, May 27, 2009 5:07 PM >> *To:* Pharo-project(a)lists.gforge.inria.fr >> *Subject:* Re: [Pharo-project] Issue 832 >> >> Sorry, just back from the pub (YAY BARCELONA!) my initial reaction >> was really: >> I'd rather see the cause of such slowdowns while resizing investigated >> (and fixed), but considering the time needed to accomplish that, >> rollbacking is probably a safer option at this time. >> My mind absolutely boggles that a resizing performance decrease would >> be the most visible effect of the changes made in that update... >> Welcome to the wonderful world of Morphic! >> >> Cheers, >> Henry >> >> On 27.05.2009 23:54, Henrik Sperre Johansen wrote: >> >>> Yes, rollbacking probably is the safest choice, >>> As I implied in the mail, this was really meant as a experimental >>> effort, to see if people on slower machines noticed the effects I was >>> (pre)anticipating. >>> I really don't see how an extra intersect: per Morph (containing >>> submorphs) can make such a big difference... >>> >>> I'll definately post another update sometime in the future, I don't >>> know when I'll have to look into it though. >>> <rant> >>> To me, the way it is right now seems unacceptable, there's really no >>> reason to write a "smart" drawOn: routine for morphs that are likely >>> to end up as a subMorph (saaaay, the TextMorph which I started >>> investigating in the first place), as they have to redraw the entire >>> area anyways. >>> This leads to a bad cycle in morph development; >>> "As long as at minimum the area we want to redraw is marked as, it's >>> fine. There's no performance gain from reporting a more accurate area >>> anyways". >>> So you end up with "sloppy" damage rects for new morphs, which leads >>> to more to fix if it IS changed, and slower performance for those >>> whom redrawing the entire area rather than a subsection IS expensive. >>> </rant> >>> >>> Cheers, >>> Henry >>> >>> >>> On 27.05.2009 19:44, StÃ©phane Ducasse wrote: >>> >>>> Thanks for reporting. >>>> Henrik? >>>> I could rollback the changes. >>>> >>>> Stef >>>> >>>> On May 27, 2009, at 6:25 PM, Gary Chambers wrote: >>>> >>>> >>>> >>>>> Performance of UI seems poor after 832 integration. >>>>> >>>>> http://code.google.com/p/pharo/issues/detail?id=832 >>>>> >>>>> Regards, Gary >>>>> >>>>> _______________________________________________ >>>>> 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 > > >

May 28, 2009

Re: [Pharo-project] MethodDictionary >> #do: deprecated

by Romain Robbes

in Pharo 10318 On May 28, 2009, at 11:12 AM, StÃ©phane Ducasse wrote: > in which image? > > Stef > > On May 28, 2009, at 10:48 AM, Romain Robbes wrote: > >> Each time methodDictionary >> #do: is invoked, I get a warning. >> Worse, if warnings are disabled, it will not do anything, which >> sounds >> error-prone. >> >> Why not just removing the method and use the implementation in >> Dictionary? >> >> Romain >> >> -- >> Romain Robbes >> http://www.inf.unisi.ch/phd/robbes >> >> >> _______________________________________________ >> 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 -- Romain Robbes http://www.inf.unisi.ch/phd/robbes

May 28, 2009

Re: [Pharo-project] Issue 832

by StÃ©phane Ducasse

can you send me the st for the reverting? Stef On May 28, 2009, at 10:08 AM, Henrik Johansen wrote: > It's strange though, for me dragging is just as slow reverting the > changes I made in a 319 image... > And filing in the .st in a 309 image, I notice no slow downs. (309 > upgraded to 319 I do). > > Are we sure nothing else causes this, perhaps changes related to > events/polling frequency or something? > > Cheers, > Henry > > Schwab,Wilhelm K skrev: >> Henry, >> >> I for one appreciate your effort, and encourage you to keep going. >> Speaking of slow machines, I have a small herd and would be willing >> to >> help you profile the problem. Give me about a month, and I will be >> in >> a position to press them into service to help with this. >> >> Bill >> >> >> ------------------------------------------------------------------------ >> *From:* pharo-project-bounces(a)lists.gforge.inria.fr >> [mailto:pharo-project-bounces@lists.gforge.inria.fr] *On Behalf Of >> *Henrik Sperre Johansen >> *Sent:* Wednesday, May 27, 2009 5:07 PM >> *To:* Pharo-project(a)lists.gforge.inria.fr >> *Subject:* Re: [Pharo-project] Issue 832 >> >> Sorry, just back from the pub (YAY BARCELONA!) my initial reaction >> was really: >> I'd rather see the cause of such slowdowns while resizing >> investigated >> (and fixed), but considering the time needed to accomplish that, >> rollbacking is probably a safer option at this time. >> My mind absolutely boggles that a resizing performance decrease would >> be the most visible effect of the changes made in that update... >> Welcome to the wonderful world of Morphic! >> >> Cheers, >> Henry >> >> On 27.05.2009 23:54, Henrik Sperre Johansen wrote: >>> Yes, rollbacking probably is the safest choice, >>> As I implied in the mail, this was really meant as a experimental >>> effort, to see if people on slower machines noticed the effects I >>> was >>> (pre)anticipating. >>> I really don't see how an extra intersect: per Morph (containing >>> submorphs) can make such a big difference... >>> >>> I'll definately post another update sometime in the future, I don't >>> know when I'll have to look into it though. >>> <rant> >>> To me, the way it is right now seems unacceptable, there's really no >>> reason to write a "smart" drawOn: routine for morphs that are likely >>> to end up as a subMorph (saaaay, the TextMorph which I started >>> investigating in the first place), as they have to redraw the entire >>> area anyways. >>> This leads to a bad cycle in morph development; >>> "As long as at minimum the area we want to redraw is marked as, it's >>> fine. There's no performance gain from reporting a more accurate >>> area >>> anyways". >>> So you end up with "sloppy" damage rects for new morphs, which leads >>> to more to fix if it IS changed, and slower performance for those >>> whom redrawing the entire area rather than a subsection IS >>> expensive. >>> </rant> >>> >>> Cheers, >>> Henry >>> >>> >>> On 27.05.2009 19:44, StÃ©phane Ducasse wrote: >>>> Thanks for reporting. >>>> Henrik? >>>> I could rollback the changes. >>>> >>>> Stef >>>> >>>> On May 27, 2009, at 6:25 PM, Gary Chambers wrote: >>>> >>>> >>>>> Performance of UI seems poor after 832 integration. >>>>> >>>>> http://code.google.com/p/pharo/issues/detail?id=832 >>>>> >>>>> Regards, Gary >>>>> >>>>> _______________________________________________ >>>>> 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 >

May 28, 2009

Re: [Pharo-project] MethodDictionary >> #do: deprecated

by StÃ©phane Ducasse

in which image? Stef On May 28, 2009, at 10:48 AM, Romain Robbes wrote: > Each time methodDictionary >> #do: is invoked, I get a warning. > Worse, if warnings are disabled, it will not do anything, which sounds > error-prone. > > Why not just removing the method and use the implementation in > Dictionary? > > Romain > > -- > Romain Robbes > http://www.inf.unisi.ch/phd/robbes > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 28, 2009

[Pharo-project] [Fwd: Re: preferences refactoring]

by Torsten Bergmann

Stephane wrote: >Ideally I would like to have pharo and squeak versions separated (may >be the packages should have a OB-Squeak and OB-Pharo). >else we will never make real progress. Dear Santa, I would also like to see an own http://www.pharosource.org/.com MC repository server, otherwise confusion will grow in both worlds the more progress happens. There we could host all "pharo-working" packages. Maybe this image can run on the same hardware but should be accessible from another URL. Thx Torsten -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss fÃ¼r nur 17,95 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02

May 28, 2009

[Pharo-project] OCompletion feedback

by Torsten Bergmann

>This is also related to the non-handling of class names at the moment, >which I intend to fix. Yes please! Thx T. -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss fÃ¼r nur 17,95 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02

May 28, 2009

[Pharo-project] LoadOrder Test for gemstone AND pharo - Seaside Issue 385

by Torsten Bergmann

Hi all, see http://code.google.com/p/seaside/issues/detail?id=385 for details and code is in "LoadOrderTests-tbn.21.mcz" on squeaksource/Seaside29 This is necessary since we want to allow easy testing of latest seaside code in pharo just by evaluating "ScriptLoader loadSeaside29" from within a pharo image. I hope this is OK for gemstone too since for non-pharo it keeps the old comanche packages. Anyone able to confirm this? Thanks Torsten -------- Original-Nachricht -------- > Datum: Wed, 27 May 2009 20:42:41 +0200 > Von: Lukas Renggli <renggli(a)iam.unibe.ch> > An: Torsten Bergmann <astares(a)gmx.de> > CC: renggli(a)gmail.com, damien.cassou(a)gmail.com > Betreff: Re: Seaside29 repository access to fix issue 385 > Hi Torsten, > ... > > > Looks like "LoadOrderTest" is currently more Squeak oriented, but > > with this patch it should easily work also in pharo. > > Keep in mind that this is a script written by the GemStone guys for > testing dependencies between packages and their respective tests. I am > not sure if it is supposed to be used to load Seaside into Squeak/Pharo. > > Cheers, > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss fÃ¼r nur 17,95 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02

May 28, 2009

[Pharo-project] MethodDictionary >> #do: deprecated

by Romain Robbes

Each time methodDictionary >> #do: is invoked, I get a warning. Worse, if warnings are disabled, it will not do anything, which sounds error-prone. Why not just removing the method and use the implementation in Dictionary? Romain -- Romain Robbes http://www.inf.unisi.ch/phd/robbes

May 28, 2009