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

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

by StÃ©phane Ducasse

mariano did you use MC2? > I think when Pharo has its own code repository should be using new > monticello 2 and sourcetalk

May 28, 2009

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

by Mariano Martinez Peck

On Thu, May 28, 2009 at 8:00 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > Stephane wrote: > >Ideally I would like to have pharo and squeak versions separated (may > >be the packages should have a OB-Squeak and OB-Pharo). > >else we will never make real progress. > > Dear Santa, > > I would also like to see an own http://www.pharosource.org/.com MC > repository server, otherwise confusion will grow in both worlds > the more progress happens. There we could host all "pharo-working" > packages. I think when Pharo has its own code repository should be using new monticello 2 and sourcetalk > > > Maybe this image can run on the same hardware but should be > accessible from another URL. > > Thx > Torsten > -- > Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + > Telefonanschluss fÃ¼r nur 17,95 Euro/mtl.!* > http://portal.gmx.net/de/go/dsl02 > > _______________________________________________ > 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 Adrian Lienhard

no: http://code.google.com/p/pharo/issues/detail?id=849 Needs fixing in OB. Adrian On May 28, 2009, at 16:47 , Alexandre Bergel wrote: > Thanks Romain. > I try to press the Esc key to remove the completion pane, and I > obtained a DNU: OBTextSelection>>isClassNode > Am I the only one? > > Alexandre > > On 28 May 2009, at 08:30, 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 >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > 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 Alexandre Bergel

Thanks Romain. I try to press the Esc key to remove the completion pane, and I obtained a DNU: OBTextSelection>>isClassNode Am I the only one? Alexandre On 28 May 2009, at 08:30, 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 > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 28, 2009

Re: [Pharo-project] SLICE-RelicensingPart1

by Alexandre Bergel

I agree Character class>>value: accepts values above 256, we were talking about codePoint: however. Maybe codePoint is obsolete and should be removed. There is sender in a last Pharo + Mondrian + Moose + other stuffs. Side node. This is very strange, using a DejaVu font, I can printIt "Character value: 300". But printint-It "Character value: 257" takes forever. I am the only one? If not, then I open a ticket. > The <0 assertion must be done. An error saying that character values cannot be negative would be helpful. > 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... Looks good to me. > Thanks for the help, Glad it helped Alexandre > > 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 -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 28, 2009

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

by Nicolas Cellier

Isn't there any possibility to include a compatibility layer ? Nicolas 2009/5/28 Alain Plantec <alain.plantec(a)free.fr>: > 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 >> > > > _______________________________________________ > 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 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