- Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] Minor test runner bug?

by StÃ©phane Ducasse

damien I prefer that we try to confirm this first because after it can take time to close. On May 28, 2009, at 9:00 AM, Damien Cassou wrote: > 2009/5/27 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> Is this a bug ? If someone confirm it I will create a ticket. > > Please create a ticket in all cases. We will close it if it's not a > bug. > > -- > 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] How To build exupery?

by Giuseppe Luigi Punzi

I asked, because it won't run. I get the same problems I posted some days on squeak-dev. Trying to run it, I get this: check that /usr/local/lib/squeak/3.10-3/vm-display-X11.so exists, or And I have /usr/local/lib/squeak/3.10-4.... I solved this for squeak, building for sources and make install, and I suppose, I need to do this for exupery. El miÃ©, 27-05-2009 a las 22:09 +0100, Bryce Kampjes escribiÃ³: > On Wed, 2009-05-27 at 20:39 +0200, Giuseppe Luigi Punzi Ruiz wrote: > > I downloaded but I suppose a make install or something like this is > > needed, to put all files and plugins in the rigth place. > > What are you trying to do? The VM's include a pre-built squeak > executable, just execute that. > > There's also some source tarballs but they aren't recommended because > most people should either build from VMMaker (real source) or use a > pre-compiled VM. I supply the source packages because they were asked > for and there are a few legitimate uses for them. > > Bryce > > > > _______________________________________________ > 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 Alain Plantec

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

May 28, 2009

Re: [Pharo-project] New Pharo based on core 10318 with antialiased fonts

by Damien Cassou

On Wed, May 27, 2009 at 10:32 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > Upload where? source.wiresong.ca/ob is world-writeable -- 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] Bug with debugger ?

by Damien Cassou

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. -- 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] Minor test runner bug?

by Damien Cassou

2009/5/27 Mariano Martinez Peck <marianopeck(a)gmail.com>: > Is this a bug ? If someone confirm it I will create a ticket. Please create a ticket in all cases. We will close it if it's not a bug. -- 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