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

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

by Damien Cassou

On Thu, May 28, 2009 at 2:30 PM, Romain Robbes <romain.robbes(a)lu.unisi.ch> wrote: > I'm looking forward to your feedback as usual, Thank you very much. It will be part of the next Pharo that will arrive in a week. -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

May 28, 2009

Re: [Pharo-project] Issue 832

by Schwab,Wilhelm K

Having tried it both ways, the rollback is "a must." There is probably an argument that the updated image dos a little better with it than does my 10303 image, but both benefit when the rollback is applied. As I said early, give me about a month, and I will happily wire up something slow to help test this. 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, May 28, 2009 4:56 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Issue 832 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-proje >>>>>> ct >>>>>> >>>>>> >>>>>> >>>>>> >>>>> ------------------------------------------------------------------ >>>>> ------ >>>>> >>>>> _______________________________________________ >>>>> 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 _______________________________________________ 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] SystemDictionary>>recreateSpecialObjectsArray (TranslatedMethod is Undeclared)

by Alain Plantec

Hi all, I've opened an issue for it: http://code.google.com/p/pharo/issues/detail?id=854 Alain

May 28, 2009

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

by Adrian Lienhard

On May 28, 2009, at 14:13 , Romain Robbes wrote: > maybe just as that? > > do: aBlock > ^ self valuesDo: aBlock yes, looks good. > at least if it is deprecated it should not change the behavior. Yes, you are right. The deprecation I did was wrong. Adrian > > > 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 > > > _______________________________________________ > 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] Bug with debugger ?

by Mariano Martinez Peck

On Thu, May 28, 2009 at 6:01 AM, Damien Cassou <damien.cassou(a)gmail.com>wrote: > 2009/5/27 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > Hi folks! I think there is a little (but a bit annoying) bug with the > > debugger. To reproduce it: > > Please open a ticket on the tracker and tell us what image you chose. > The image is pharo0.1-10318dev09.05.4. Done: http://code.google.com/p/pharo/issues/detail?id=853 > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry > > _______________________________________________ > 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] SLICE-RelicensingPart1

by Gabriel Cotelli

Hi Alexandre, I agree that it's better to get the exact error. So I think the negative check is necessary, however Character class>>value: works in my image for values greater than 255 (Character value: 257) = $? ... I don't known if there's un upper limit to this or if depends on the character set... Character class>>value: already checks for > 255 and in that case don't use the table.... The <0 assertion must be done. So if it's ok I want to do this: Retain Character class>>codePoint: anInteger ^self value: anInteger And change Character class>>value: anInteger to perform the negative check and raise a better error in that case... the >255 case don't raises an error (at least not always) so I open to suggestions... Any comments are welcome. Thanks for the help, Gabriel On Wed, May 27, 2009 at 6:33 PM, Alexandre Bergel <alexandre(a)bergel.eu>wrote: > I agree with what has been previously said. However, I think there is > a fundamental difference between getting en error: 'Character code > point ranges between 1 and 256 only' and 'subscript is out of bound'. > Currently, CharacterTable has 256 slots. Maybe an initialization has > to be done or something, but if you provide a value > 255, then you > will get an error. > > Alexandre > > > On 27 May 2009, at 17:26, Gabriel Cotelli wrote: > > > Yes, but if "value:" cannot lookup in the table uses some extended > > character set... > > > > I think the negative check mut be done... about the > 255 I'm not > > sure... > > > > On Wed, May 27, 2009 at 3:42 PM, Alexandre Bergel > > <alexandre(a)bergel.eu> wrote: > > > Please remove the upper limit, I think this was a > > > pre-internationalization method which should have been updated but > > was > > > not because not used. > > > > But CharacterTable is an array of 256 characters long. > > > > Alexandre > > > > > > > > > > > 2009/5/27 Alexandre Bergel <alexandre(a)bergel.eu>: > > >> Yes, with a negative argument. > > >> Adding the check: > > >> (0 > integer or: [255 < integer]) > > >> ifTrue: [self error: 'parameter out of range 0..255']. > > >> is probably enough. > > >> Alexandre > > >> > > >> > > >> On 27 May 2009, at 08:27, Gabriel Cotelli wrote: > > >> > > >> The ANSI Specification doesn't mention anything about that the > > >> integer must > > >> be in some range... the only thing that expects is that (Character > > >> codePoint: x) codePoint = x .... > > >> > > >> anyway... I can add the verification... but that's not specified in > > >> the > > >> ANSI... anybody knowns some senders of this? I checked Pharo-Dev > > >> and found > > >> none.. maybe in the Web Image? > > >> > > >> Alexandre, how you obtain an error using value: ? given a negative > > >> argument? > > >> I tried with values greater than 255 and works in my image... > > >> > > >> Tonight I check that > > >> > > >> 2009/5/27 Alexandre Bergel <Alexandre.Bergel(a)inria.fr> > > >> I went through all the changes proposed by this slice. I am not > > >> sure how > > >> should I review the code, but here is my try: > > >> - the new version of Character class>>codePoint: anInteger seems to > > >> have a > > >> different behavior: > > >> The old (current) code is > > >> codePoint: integer > > >> "Return a character whose encoding value is integer." > > >> #Fundmntl. > > >> (0 > integer or: [255 < integer]) > > >> ifTrue: [self error: 'parameter out of range 0..255']. > > >> ^ CharacterTable at: integer + 1 > > >> The new one is: > > >> codePoint: anInteger > > >> "Just for ANSI Compliance" > > >> ^self value: anInteger > > >> value: anInteger > > >> "Answer the Character whose value is anInteger." > > >> anInteger > 255 ifTrue: [^self basicNew setValue: anInteger]. > > >> ^ CharacterTable at: anInteger + 1. > > >> At the end an error is raised, but this is not the same. > > >> Was this review useful? > > >> Cheers, > > >> Alexandre > > >> -- > > >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > >> Alexandre Bergel http://www.bergel.eu > > >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > >> > > >> > > >> > > >> > > >> > > >> _______________________________________________ > > >> 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 > > >> > > >> -- > > >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > >> Alexandre Bergel http://www.bergel.eu > > >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > >> > > >> > > >> > > >> > > >> > > >> _______________________________________________ > > >> 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 > > > > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > > > _______________________________________________ > > 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 > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > 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] [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