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

Re: [Pharo-project] Issue 832

by StÃ©phane Ducasse

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

May 28, 2009

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

by StÃ©phane Ducasse

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

May 28, 2009

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

by Torsten Bergmann

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

May 28, 2009

[Pharo-project] OCompletion feedback

by Torsten Bergmann

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

May 28, 2009

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

by Torsten Bergmann

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

May 28, 2009

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

by Romain Robbes

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

May 28, 2009

Re: [Pharo-project] OCompletion feedback

by Romain Robbes

Hi Henrik, Thanks for the feedback, I really appreciate it, and I will look in the issues you mentioned. Indeed inserting selectors from the extended list is a way to update the cache. The most important one however is that all the selectors contained in a method are added to the cache when it is compiled. For the case sensitivity, I was thinking the preference in ecompletion itself was enough (I myself prefer not to have it). This is also related to the non-handling of class names at the moment, which I intend to fix. Cheers, Romain On May 27, 2009, at 5:23 PM, Henrik Johansen wrote: > First let me say, I love OCompletion, first time I've found > completion > in Smalltalk actually helpful! > Here's a few things I found a bit of though: > - Font for OCompletion inherits ECompletion's behaviour of being > hardcoded (O(X)MenuMorph class >>messageFont/titleFont), would it be > possible to change them to one of the settable font-preferences? > (Balloon-help font f.ex.) > - Suggestions do not seem to be case-sensitive, even if you use > uppercase in your writing. (writing f.ex. Ope lists open) > - Words you've fully written are still included in suggestion list. > (f.ex. open) > - If a new character excludes items in the suggestion list, they are > removed, but entries not in the OCompletion cache (but in the extended > list) are not added to suggestions. - Type in enough characters to > make > the cached suggetions empty, and the extended list becomes > unavailiable... > - If I select to write out the entire message name (say > openMenuFor: ), > then hit space, the entry is not added to top of OCompletion > suggestions > for "open". > - Two above aren't very annoying, but as far as I can tell, combined > they mean the only way to add new items to the OCompletion cache is if > you select it from the extended list. > > Cheers, > Henry > > > _______________________________________________ > 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] New Pharo based on core 10318 with antialiased fonts

by Romain Robbes

It does fix the problem, but I handled it on my side. What I did is to test for it when OCompletion is installed so that I can install ECompletionOmniBrowser as needed. Hence you should not need to update the script. I also removed the questionable way I was checking for OB before. Cheers, Romain On May 27, 2009, at 5:59 PM, Damien Cassou wrote: > On Wed, May 27, 2009 at 3:37 PM, Simon Denier > <Simon.Denier(a)inria.fr> wrote: >> Yes, installing ECompletionOmniBrowser before OCompletion should do >> the trick. > > Could you please check Romain and tell me so that I can update the > script? > > -- > 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 -- Romain Robbes http://www.inf.unisi.ch/phd/robbes

May 28, 2009

Re: [Pharo-project] Issue 832

by Henrik Johansen

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

May 28, 2009

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

by StÃ©phane Ducasse

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. Stef > 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: May 27, 2009 7:21:25 PM CEDT > To: Gary Chambers <gazzaguru2(a)btinternet.com> > Subject: Re: preferences refactoring > Reply-To: alain.plantec(a)univ-brest.fr > > > Gary Chambers a Ã©crit : >> Hi Alain. >> >> I guess I may have to fork the Pharo/Squeak specific areas. Not an >> easy job! > yes, not really cool. > > what about the following: > I make the assumption that DiffMorph is using the > browseWithPrettyPrint preference. > For pharo, you can create a new package with a PolymorphSettings > class: > > ---------------------- > PolymorphSettings class>>browseWithPrettyPrint > <setting> > ^ BrowseWithPrettyPrint ifNil: [ BrowseWithPrettyPrint := > (SettingManager newSetting: 'bla bla') ... ] > > PolymorphSettings class>>initialize > self browseWithPrettyPrint whenChangedSend: #prettyPrinting: to: > DiffMorph > ---------------------- > > For squeak you can also create a new package with a > PolymorphPreferences class: > > ---------------------- > PolymorphPreferences class>>initialize > (Preferences preferenceAt: #browseWithPrettyPrint) ifNil:[ > Preferences > addPreference: #browseWithPrettyPrint > categories: #(browsing) > default: true > balloonHelp: 'Enable, or ...'. > (Preferences preferenceAt: browseWithPrettyPrint) > changeInformee: self > changeSelector: #browseWithPrettyPrintChanged. > self browseWithPrettyPrintChanged]. > PolymorphPreferences class>>browseWithPrettyPrintChanged > DiffMorph prettyPrinting: Preferences browseWithPrettyPrint > > ---------------------- > > and as you pointed out, DiffMorph has also its own class variable > for the preference. > > DiffMorph class>>prettyPrinting: aBoolean > PrettyPrinting := aBoolean > > DiffMorph class>>prettyPrinting > ^ PrettyPrinting > > > Thus, in Pharo PolymorphSettings is loaded and the DiffMorph class > variable changes are handled via the setting. > In Squeak, PolymorphPreferences is loaded and the DiffMorph class > variable updating relies on the changeInformee hook. > > a little bit ugly but I guess this is the price to pay for > compatibility. > > what do you think ? > > Cheers > Alain >> >> To start I'll refactor Polymorph to use class side accessors for >> any use of preferences. That way Squeak can delegate to Preferences >> whilst Pharo can use the pragma based settings. >> >> E.g. >> DiffMorph>>setText can do >> >> self class colorWhenPrettyPrinting value >> >> In Squeak: >> >> DiffMorph class>>colorWhenPrettyPrinting >> ^Preferences colorWhenPrettyPrinting >> >> In Pharo: >> >> DiffMorph class>>colorWhenPrettyPrinting >> ^ColorWhenPrettyPrinting ifNil: [ >> ColorWhenPrettyPrinting := (SettingManager newSetting: 'Color >> pretty print') default: false] >> >> Regards, Gary >> >> ----- Original Message ----- From: "Alain Plantec" <alain.plantec(a)univ-brest.fr >> > >> To: "Gary Chambers" <gazzaguru2(a)btinternet.com> >> Sent: Friday, May 22, 2009 3:56 PM >> Subject: preferences refactoring >> >> >>> Hi Gary, >>> During the migration from old preferences to the new setting >>> framework, >>> some methods I'm changing can be from Polymorph packages. >>> I just like to know if I have to send to you polymorph specific >>> parts ? >>> or what is the rule ? >>> As an example, DiffMorph>>setText will be touched by the removal >>> of the #colorWhenPrettyPrinting >>> preference. Do I have to send to you a Polymorph specific part ? >>> Thanks >>> Alain >> >> >> > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 28, 2009