- Pharo-dev - lists.pharo.org

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

by Cameron Sanders

I'm loving OCompletion! Thanks. That's my only feedback at this time. Happy Coding, Cam On May 28, 2009, at 8:30 AM, 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

May 28, 2009

Re: [Pharo-project] SLICE-RelicensingPart1

by Nicolas Cellier

2009/5/28 Gabriel Cotelli <g.cotelli(a)gmail.com>: > 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. > Yes, that is exactly what I tried to explain :) Nicolas > 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 > > > _______________________________________________ > 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] allObjectsDo: broken

by Nicolas Cellier

There is also http://bugs.squeak.org/view.php?id=7313 to capitalize these changes across forks. >From what I remember, Lukas' fix > Keithy's workaround. Nicolas 2009/5/27 Lukas Renggli <renggli(a)gmail.com>: > I played a bit with it. I came up with the following quick fix, but > probably Eliot has a better solution. I find that code quite fragile > anyway, if you instantiate an object in your enumeration block your > lost (that was already the case before) ... > > allObjectsDo: aBlock > Â Â Â Â "Evaluate the argument, aBlock, for each object in the system > Â Â Â Â excluding SmallIntegers." > Â Â Â Â | object | > Â Â Â Â object := self someObject. > Â Â Â Â [0 == object] > Â Â Â Â Â Â Â Â whileFalse: [ > Â Â Â Â Â Â Â Â Â Â Â Â (object class == MethodContext and: [ object closure == aBlock ]) > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifFalse: [ aBlock value: object ]. > Â Â Â Â Â Â Â Â Â Â Â Â object := object nextObject] > > On Wed, May 27, 2009 at 10:53 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: >> SystemNavigation default allObjectsDo: [ :e Â ] >> >> ...never terminates. At least since this is broken since #10268cl. >> Version #10263 was still working. >> >> The suspect are new closures (I guess, creating new context instances >> while iterating over all objects)... >> >> http://code.google.com/p/pharo/issues/detail?id=851 >> >> Adrian >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 28, 2009

Re: [Pharo-project] Issue 832

by Schwab,Wilhelm K

BTW, Just a hunch, I suspect the sensor fixes might be the thing that helps in the updated image. Not only is typing slow pre-rollback, but the older image seems to be losing keystrokes. Does that make sense? Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Schwab,Wilhelm K Sent: Thursday, May 28, 2009 8:35 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Issue 832 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 _______________________________________________ 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 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