- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [ANN] update to OCompletion

by Romain Robbes

Of course, I forgot to remind you how to install it. Just execute the following line in a workspace: Installer squeaksource project: 'OCompletion'; install: 'OCLoader'. Cheers, Romain On May 28, 2009, at 2:30 PM, Romain Robbes wrote: > new in this update: > > -OCompletion completes also class names! If the prefix starts with an > uppercase letter, OCompletion will propose recently changed classes. > Since it maintains its small list of classes, the speed problem Hernan > encountered is partially solved (it still slows downs while you scroll > in the extended list). Also, Henrik's concern about case sensitivity > is now solved for that case (I still think it should be case- > insensitive after the first letter, but we can discuss this). > -OCompletion uses the default font for menus, which is indeed > nicer ;-) > -OCompletion only proposes matches strictly longer than what was > actually typed. > -Various small bug fixes (thanks Simon!). > > I'm looking forward to your feedback as usual, > 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 -- Romain Robbes http://www.inf.unisi.ch/phd/robbes

May 28, 2009

[Pharo-project] [ANN] update to OCompletion

by Romain Robbes

new in this update: -OCompletion completes also class names! If the prefix starts with an uppercase letter, OCompletion will propose recently changed classes. Since it maintains its small list of classes, the speed problem Hernan encountered is partially solved (it still slows downs while you scroll in the extended list). Also, Henrik's concern about case sensitivity is now solved for that case (I still think it should be case- insensitive after the first letter, but we can discuss this). -OCompletion uses the default font for menus, which is indeed nicer ;-) -OCompletion only proposes matches strictly longer than what was actually typed. -Various small bug fixes (thanks Simon!). I'm looking forward to your feedback as usual, Romain -- Romain Robbes http://www.inf.unisi.ch/phd/robbes

May 28, 2009

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

by Romain Robbes

maybe just as that? do: aBlock ^ self valuesDo: aBlock at least if it is deprecated it should not change the behavior. Romain On May 28, 2009, at 2:02 PM, Adrian Lienhard wrote: > I deprecated this method because it was not clean and there were no > senders in the core. > > If this method is used, we should re-implement it. > > You cannot just use the super implementation. Method dictionaries > internally include nil key/values just like Dictionaries do but > MethodDictionary is implemented differently than Dictionary (its a > variable subclass and the array contains values whereas the indexable > part contains the keys). > > Adrian > > On May 28, 2009, at 12:30 , StÃ©phane Ducasse wrote: > >> I really do not know from where this method is coming from. >> Scary. We will have to improve our tracability >> >> Stef >> >> On May 28, 2009, at 11:25 AM, 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 >>> >> >> >> _______________________________________________ >> 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] MethodDictionary >> #do: deprecated

by Simon Denier

On 28 mai 09, at 14:02, Adrian Lienhard wrote: > I deprecated this method because it was not clean and there were no > senders in the core. > > If this method is used, we should re-implement it. It is used by Fame/Moose/OCompletion, perhaps some others... So yes, should be re-implemented > > > You cannot just use the super implementation. Method dictionaries > internally include nil key/values just like Dictionaries do but > MethodDictionary is implemented differently than Dictionary (its a > variable subclass and the array contains values whereas the indexable > part contains the keys). > > Adrian > > On May 28, 2009, at 12:30 , StÃ©phane Ducasse wrote: > >> I really do not know from where this method is coming from. >> Scary. We will have to improve our tracability >> >> Stef >> >> On May 28, 2009, at 11:25 AM, 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 >>> >> >> >> _______________________________________________ >> 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 > -- Simon

May 28, 2009

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

by Alain Plantec

Alexandre Bergel a Ã©crit : > Before removing the preference class, maybe you could rename it simply > at the beginning. Hi Alexandre, yes, we will do it with care. Anyway we are far from being ready to remove it :(. Before we remove it, we have to make sure that all client classes from pharo are re-factored such that they don't need it anymore. Cheers Alain > > Alexandre > > > On 28 May 2009, at 03:08, Alain Plantec wrote: > >> Hi all, >> >> We have to make important decisions about squeak/pharo compatibility >> regarding the new setting package. >> The problem is that some packages (as Polymorph but also OB, >> ecompletion and certainly a lot of others) are >> included in pharo (aka pharo-dev) but are also used by squeak and the >> compatibility is now an issue because we plan >> to remove the Preferences class from Pharo. >> So, I'm looking for advices about that... >> Any feedback ? >> >> Cheers >> Alain >> >> From: Alain Plantec <alain.plantec(a)univ-brest.fr> >> Date: 27 May 2009 13:21:25 GMT-04:00 >> To: Gary Chambers <gazzaguru2(a)btinternet.com> >> Subject: Re: preferences refactoring >> Reply-To: alain.plantec(a)univ-brest.fr >> >> >> Gary Chambers a Ã©crit : >>> Hi Alain. >>> >>> I guess I may have to fork the Pharo/Squeak specific areas. Not an >>> easy job! >> yes, not really cool. >> >> what about the following: >> I make the assumption that DiffMorph is using the >> browseWithPrettyPrint preference. >> For pharo, you can create a new package with a PolymorphSettings class: >> >> ---------------------- >> PolymorphSettings class>>browseWithPrettyPrint >> <setting> >> ^ BrowseWithPrettyPrint ifNil: [ BrowseWithPrettyPrint := >> (SettingManager newSetting: 'bla bla') ... ] >> >> PolymorphSettings class>>initialize >> self browseWithPrettyPrint whenChangedSend: #prettyPrinting: to: >> DiffMorph >> ---------------------- >> >> For squeak you can also create a new package with a >> PolymorphPreferences class: >> >> ---------------------- >> PolymorphPreferences class>>initialize >> (Preferences preferenceAt: #browseWithPrettyPrint) ifNil:[ >> Preferences >> addPreference: #browseWithPrettyPrint >> categories: #(browsing) >> default: true >> balloonHelp: 'Enable, or ...'. >> (Preferences preferenceAt: browseWithPrettyPrint) >> changeInformee: self >> changeSelector: #browseWithPrettyPrintChanged. >> self browseWithPrettyPrintChanged]. >> PolymorphPreferences class>>browseWithPrettyPrintChanged >> DiffMorph prettyPrinting: Preferences browseWithPrettyPrint >> >> ---------------------- >> >> and as you pointed out, DiffMorph has also its own class variable for >> the preference. >> >> DiffMorph class>>prettyPrinting: aBoolean >> PrettyPrinting := aBoolean >> >> DiffMorph class>>prettyPrinting >> ^ PrettyPrinting >> >> >> Thus, in Pharo PolymorphSettings is loaded and the DiffMorph class >> variable changes are handled via the setting. >> In Squeak, PolymorphPreferences is loaded and the DiffMorph class >> variable updating relies on the changeInformee hook. >> >> a little bit ugly but I guess this is the price to pay for >> compatibility. >> >> what do you think ? >> >> Cheers >> Alain >>> >>> To start I'll refactor Polymorph to use class side accessors for any >>> use of preferences. That way Squeak can delegate to Preferences >>> whilst Pharo can use the pragma based settings. >>> >>> E.g. >>> DiffMorph>>setText can do >>> >>> self class colorWhenPrettyPrinting value >>> >>> In Squeak: >>> >>> DiffMorph class>>colorWhenPrettyPrinting >>> ^Preferences colorWhenPrettyPrinting >>> >>> In Pharo: >>> >>> DiffMorph class>>colorWhenPrettyPrinting >>> ^ColorWhenPrettyPrinting ifNil: [ >>> ColorWhenPrettyPrinting := (SettingManager newSetting: 'Color >>> pretty print') default: false] >>> >>> Regards, Gary >>> >>> ----- Original Message ----- From: "Alain Plantec" >>> <alain.plantec(a)univ-brest.fr> >>> To: "Gary Chambers" <gazzaguru2(a)btinternet.com> >>> Sent: Friday, May 22, 2009 3:56 PM >>> Subject: preferences refactoring >>> >>> >>>> Hi Gary, >>>> During the migration from old preferences to the new setting >>>> framework, >>>> some methods I'm changing can be from Polymorph packages. >>>> I just like to know if I have to send to you polymorph specific >>>> parts ? >>>> or what is the rule ? >>>> As an example, DiffMorph>>setText will be touched by the removal of >>>> the #colorWhenPrettyPrinting >>>> preference. Do I have to send to you a Polymorph specific part ? >>>> Thanks >>>> Alain >>> >>> >>> >> >> >> >> >> >> >> _______________________________________________ >> 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 Adrian Lienhard

I deprecated this method because it was not clean and there were no senders in the core. If this method is used, we should re-implement it. You cannot just use the super implementation. Method dictionaries internally include nil key/values just like Dictionaries do but MethodDictionary is implemented differently than Dictionary (its a variable subclass and the array contains values whereas the indexable part contains the keys). Adrian On May 28, 2009, at 12:30 , StÃ©phane Ducasse wrote: > I really do not know from where this method is coming from. > Scary. We will have to improve our tracability > > Stef > > On May 28, 2009, at 11:25 AM, 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 >> > > > _______________________________________________ > 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] [Fwd: Re: preferences refactoring]

by Alexandre Bergel

Before removing the preference class, maybe you could rename it simply at the beginning. Alexandre On 28 May 2009, at 03:08, Alain Plantec wrote: > Hi all, > > We have to make important decisions about squeak/pharo compatibility > regarding the new setting package. > The problem is that some packages (as Polymorph but also OB, > ecompletion and certainly a lot of others) are > included in pharo (aka pharo-dev) but are also used by squeak and > the compatibility is now an issue because we plan > to remove the Preferences class from Pharo. > So, I'm looking for advices about that... > Any feedback ? > > Cheers > Alain > > From: Alain Plantec <alain.plantec(a)univ-brest.fr> > Date: 27 May 2009 13:21:25 GMT-04:00 > To: Gary Chambers <gazzaguru2(a)btinternet.com> > Subject: Re: preferences refactoring > Reply-To: alain.plantec(a)univ-brest.fr > > > Gary Chambers a Ã©crit : >> Hi Alain. >> >> I guess I may have to fork the Pharo/Squeak specific areas. Not an >> easy job! > yes, not really cool. > > what about the following: > I make the assumption that DiffMorph is using the > browseWithPrettyPrint preference. > For pharo, you can create a new package with a PolymorphSettings > class: > > ---------------------- > PolymorphSettings class>>browseWithPrettyPrint > <setting> > ^ BrowseWithPrettyPrint ifNil: [ BrowseWithPrettyPrint := > (SettingManager newSetting: 'bla bla') ... ] > > PolymorphSettings class>>initialize > self browseWithPrettyPrint whenChangedSend: #prettyPrinting: to: > DiffMorph > ---------------------- > > For squeak you can also create a new package with a > PolymorphPreferences class: > > ---------------------- > PolymorphPreferences class>>initialize > (Preferences preferenceAt: #browseWithPrettyPrint) ifNil:[ > Preferences > addPreference: #browseWithPrettyPrint > categories: #(browsing) > default: true > balloonHelp: 'Enable, or ...'. > (Preferences preferenceAt: browseWithPrettyPrint) > changeInformee: self > changeSelector: #browseWithPrettyPrintChanged. > self browseWithPrettyPrintChanged]. > PolymorphPreferences class>>browseWithPrettyPrintChanged > DiffMorph prettyPrinting: Preferences browseWithPrettyPrint > > ---------------------- > > and as you pointed out, DiffMorph has also its own class variable > for the preference. > > DiffMorph class>>prettyPrinting: aBoolean > PrettyPrinting := aBoolean > > DiffMorph class>>prettyPrinting > ^ PrettyPrinting > > > Thus, in Pharo PolymorphSettings is loaded and the DiffMorph class > variable changes are handled via the setting. > In Squeak, PolymorphPreferences is loaded and the DiffMorph class > variable updating relies on the changeInformee hook. > > a little bit ugly but I guess this is the price to pay for > compatibility. > > what do you think ? > > Cheers > Alain >> >> To start I'll refactor Polymorph to use class side accessors for >> any use of preferences. That way Squeak can delegate to Preferences >> whilst Pharo can use the pragma based settings. >> >> E.g. >> DiffMorph>>setText can do >> >> self class colorWhenPrettyPrinting value >> >> In Squeak: >> >> DiffMorph class>>colorWhenPrettyPrinting >> ^Preferences colorWhenPrettyPrinting >> >> In Pharo: >> >> DiffMorph class>>colorWhenPrettyPrinting >> ^ColorWhenPrettyPrinting ifNil: [ >> ColorWhenPrettyPrinting := (SettingManager newSetting: 'Color >> pretty print') default: false] >> >> Regards, Gary >> >> ----- Original Message ----- From: "Alain Plantec" <alain.plantec(a)univ-brest.fr >> > >> To: "Gary Chambers" <gazzaguru2(a)btinternet.com> >> Sent: Friday, May 22, 2009 3:56 PM >> Subject: preferences refactoring >> >> >>> Hi Gary, >>> During the migration from old preferences to the new setting >>> framework, >>> some methods I'm changing can be from Polymorph packages. >>> I just like to know if I have to send to you polymorph specific >>> parts ? >>> or what is the rule ? >>> As an example, DiffMorph>>setText will be touched by the removal >>> of the #colorWhenPrettyPrinting >>> preference. Do I have to send to you a Polymorph specific part ? >>> Thanks >>> Alain >> >> >> > > > > > > > _______________________________________________ > 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 28, 2009

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

by StÃ©phane Ducasse

I really do not know from where this method is coming from. Scary. We will have to improve our tracability Stef On May 28, 2009, at 11:25 AM, 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 >

May 28, 2009

Re: [Pharo-project] Issue 832

by StÃ©phane Ducasse

Yes thanks for checking. I would really like that we understand the problem On my machine I noticed no slowdown. Stef On May 28, 2009, at 11:46 AM, Henrik Johansen wrote: > 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]]]! ! > > > _______________________________________________ > 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

On May 28, 2009, at 11:37 AM, Simon Denier wrote: > > 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? > Maybe as a side effect of removing a method from the system? Romain > 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 > > > > > _______________________________________________ > 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