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

Re: [Pharo-project] request for the new merge tool :)

by StÃ©phane Ducasse

On Sep 8, 2009, at 6:53 PM, Gary Chambers wrote: > Install code? No install menu :) Gary in the old merge tool you can select a change and install it bringing the menu on the item This is important since we can chose what we want to install or not. So the behavior is there since it is working with the old one. Stef > > Just pointing out that we should all-together decide how we want MC to > interact with the user then decide you to get MC to support that... > maybe > MC1.0/1.5/2.0 who knows. > > There are clearly different needs fo all of us. Just trying to get > things > pinned down (somewhat) before moving things along. > > Regards, Gary > > ----- Original Message ----- > From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Tuesday, September 08, 2009 5:47 PM > Subject: Re: [Pharo-project] request for the new merge tool :) > > > Gary having the install code is really important. > > >> Would be great to decide on the UI we want then make MC play ball... >> >> Regards, Gary >> >> ----- Original Message ----- >> From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> >> To: <Pharo-project(a)lists.gforge.inria.fr> >> Sent: Tuesday, September 08, 2009 3:28 PM >> Subject: Re: [Pharo-project] request for the new merge tool :) >> >> >>> would be great. >>> Send code :) >>> >>> On Sep 8, 2009, at 4:24 PM, rkrock(a)locksleycreeksoftware.com wrote: >>> >>>>>>> Yes, this is what the History button is supposed to do, display >>>>>>> the >>>>>>> diff between two arbitrary versions. >>>>>> >>>>>> What about backport? >>>>>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2004-September/08209… >>>>> >>>>> That works in the wrong direction for me. I prefer to load changes >>>>> into my working copy instead of having to load the other code and >>>>> "backporting" my changes into their code. >>>>> >>>>> Lukas >>>>> >>>> >>>> What about an option for go forward or backward. It really on which >>>> fork >>>> of the code is considered the 'root' and that is often in the eyes >>>> of the >>>> beholder. >>>> >>>>> -- >>>>> 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 >>>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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

Sept. 8, 2009

[Pharo-project] Spring in November, Argentina

by Alexandre Bergel

Dear List, I added a section in the Sprint wiki page: http://code.google.com/p/pharo/wiki/PharoSprints?ts=1252433348&updated=Phar… People should add their name. I will send a remainder a few days before the event. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 8, 2009

Re: [Pharo-project] Morph extension

by Henrik Johansen

StÃ©phane Ducasse skrev: > On Sep 8, 2009, at 5:32 PM, Gary Chambers wrote: > > >> After some experimenting I can get over 10% perfromance improvement >> with >> window operations when fillStyle; borderStyle; hResizing; vResizing >> are >> made as instance variables of Morph, rather than going through >> extension. >> > > this is a lot. > You really mean Morph or we could get them in subclasses too. > > Inspect this in an image with some windows open, it will give you the percentage of morphs with otherProperties containing any given property: |propBag noMorphs| propBag := Bag new: 50. noMorphs := 0. Morph allSubInstances do: [:each | each otherProperties ifNotNil: [:props | propBag addAll: props keys. noMorphs := noMorphs +1]] . noMorphs := noMorphs asFloat. propBag sortedCounts collect: [:each | each key: each key / noMorphs; yourself] otherProperties is heavily abused. with respectively 98 and 125 senders of valueOfProperty: / valueOfProperty:ifAbsent:... In my case there were _57_ different distinct otherProperties in use, an average of three, a maximum of 15, and four of them present in over a quarter of morphs defining any (80% for the most common one)... If moving directly to Morph is a bit extreme, at least _some_ of these qualify for promotion to direct access in MorphExtension imho, it seems to have some "free" instvars anyways after the removal of players. In the interest of seeing which would benefit the most from moving, I did a small profile: - Dragging a window and switching some between different ones with 2 browsers, a monticello browser, a workspace and a Method search open. I had the following access numbers: 105586->#clipSubmorphs (about 4.5 per millisecond) 66029->#layoutProperties 62783->#layoutPolicy 55556->#theme 41312->#hasDropShadow 41310->#hasRolloverBorder 36817->#fillStyle 19241->#cornerStyle 13239->#highlightedForDrop 13239->#highlightedForMouseDown 11945->#roundedCorners 11911->#borderStyle 10644->#edgeToAdhereTo 9020->#paneColor 8885->#lastPaneColor [rest below 5000 accesses] Cheers, Henry

Sept. 8, 2009

Re: [Pharo-project] Halos

by Gary Chambers

Indeed. I have also noticed, with our stuff, that the interrupt seldom wqorks in runaway cases... Regards, Gary ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Tuesday, September 08, 2009 5:52 PM Subject: Re: [Pharo-project] Halos >> Perhaps an opportunity to build-in a deployment feature? > > yes > Trapping interrupts too. > > > >> Regards, Gary >> >> ----- Original Message ----- >> From: "Damien Cassou" <damien.cassou(a)gmail.com> >> To: <Pharo-project(a)lists.gforge.inria.fr> >> Sent: Tuesday, September 08, 2009 5:21 PM >> Subject: Re: [Pharo-project] Halos >> >> >>> 2009/9/8 Gary Chambers <gazzaguru2(a)btinternet.com>: >>>> Since the #halosEnabled preference has been removed it is now more >>>> difficult >>>> to lock an image down for deployment as halos are now always >>>> available >>>> via >>>> shift-blue-button... >>> >>> We knew that when we did the change. The deployment mode will have to >>> be rethought completely to make that kind of things simpler. >>> System-Settings may help. >>> >>> -- >>> 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 >> >> >> _______________________________________________ >> 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

Sept. 8, 2009

Re: [Pharo-project] Morph extension

by Gary Chambers

Affects the performance of all Morph (and subclass) instances. Regards, Gary ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Tuesday, September 08, 2009 5:49 PM Subject: Re: [Pharo-project] Morph extension > > On Sep 8, 2009, at 5:32 PM, Gary Chambers wrote: > >> After some experimenting I can get over 10% perfromance improvement >> with >> window operations when fillStyle; borderStyle; hResizing; vResizing >> are >> made as instance variables of Morph, rather than going through >> extension. > > this is a lot. > You really mean Morph or we could get them in subclasses too. > >> I thought Marcus has mentioned this some time ago, but no progress? > > No progress just playing with it at esug last year. > >> There is obviously an issue with name collision/shadowing but not >> many methods in core need changing to accomodate. > > > > >> >> Whilst on the subject I am wondering on everyone's opinion on >> merging the behaviour of color/borderColor/borderWidth with that of >> fillStyle... sure to be some gains there! >> >> 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

Sept. 8, 2009

Re: [Pharo-project] Slice-MCDependenciesDialogPlagueFixed-ab.1.mcz

by Henrik Johansen

Damien skrev: > > > > > Sent to you by Damien via Google Reader: > > > > > > Slice-MCDependenciesDialogPlagueFixed-ab.1.mcz > <http://www.squeaksource.com/PharoInbox.html> > > via PharoInbox <http://www.squeaksource.com/> on 9/8/09 > > > Is it necessary to offer a checkbox in the parent's save dialogue to > ask if this is the desired behaviour? With the current behaviour, I'd say no. If you try to cancel the extra dialogs, it leads to an error and unloadable slices... Better then with an atomic operation that is either done or not, and having the comment behaviour forced. Ideally, I think it'd be nice to have an "apply to all" checkbox, and if not checked, change it so comments are all set before anything is stored. (using the comment for the "top" package as default) Cheers, Henry

Sept. 8, 2009

Re: [Pharo-project] request for the new merge tool :)

by Gary Chambers

Install code? Just pointing out that we should all-together decide how we want MC to interact with the user then decide you to get MC to support that... maybe MC1.0/1.5/2.0 who knows. There are clearly different needs fo all of us. Just trying to get things pinned down (somewhat) before moving things along. Regards, Gary ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Tuesday, September 08, 2009 5:47 PM Subject: Re: [Pharo-project] request for the new merge tool :) Gary having the install code is really important. > Would be great to decide on the UI we want then make MC play ball... > > Regards, Gary > > ----- Original Message ----- > From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Tuesday, September 08, 2009 3:28 PM > Subject: Re: [Pharo-project] request for the new merge tool :) > > >> would be great. >> Send code :) >> >> On Sep 8, 2009, at 4:24 PM, rkrock(a)locksleycreeksoftware.com wrote: >> >>>>>> Yes, this is what the History button is supposed to do, display >>>>>> the >>>>>> diff between two arbitrary versions. >>>>> >>>>> What about backport? >>>>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2004-September/08209… >>>> >>>> That works in the wrong direction for me. I prefer to load changes >>>> into my working copy instead of having to load the other code and >>>> "backporting" my changes into their code. >>>> >>>> Lukas >>>> >>> >>> What about an option for go forward or backward. It really on which >>> fork >>> of the code is considered the 'root' and that is often in the eyes >>> of the >>> beholder. >>> >>>> -- >>>> 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 >>>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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

Sept. 8, 2009

Re: [Pharo-project] Halos

by StÃ©phane Ducasse

> Perhaps an opportunity to build-in a deployment feature? yes Trapping interrupts too. > Regards, Gary > > ----- Original Message ----- > From: "Damien Cassou" <damien.cassou(a)gmail.com> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Tuesday, September 08, 2009 5:21 PM > Subject: Re: [Pharo-project] Halos > > >> 2009/9/8 Gary Chambers <gazzaguru2(a)btinternet.com>: >>> Since the #halosEnabled preference has been removed it is now more >>> difficult >>> to lock an image down for deployment as halos are now always >>> available >>> via >>> shift-blue-button... >> >> We knew that when we did the change. The deployment mode will have to >> be rethought completely to make that kind of things simpler. >> System-Settings may help. >> >> -- >> 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 8, 2009

Re: [Pharo-project] Morph extension

by StÃ©phane Ducasse

On Sep 8, 2009, at 5:32 PM, Gary Chambers wrote: > After some experimenting I can get over 10% perfromance improvement > with > window operations when fillStyle; borderStyle; hResizing; vResizing > are > made as instance variables of Morph, rather than going through > extension. this is a lot. You really mean Morph or we could get them in subclasses too. > I thought Marcus has mentioned this some time ago, but no progress? No progress just playing with it at esug last year. > There is obviously an issue with name collision/shadowing but not > many methods in core need changing to accomodate. > > Whilst on the subject I am wondering on everyone's opinion on > merging the behaviour of color/borderColor/borderWidth with that of > fillStyle... sure to be some gains there! > > Regards, Gary > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 8, 2009

Re: [Pharo-project] request for the new merge tool :)

by StÃ©phane Ducasse

Gary having the install code is really important. > Would be great to decide on the UI we want then make MC play ball... > > Regards, Gary > > ----- Original Message ----- > From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Tuesday, September 08, 2009 3:28 PM > Subject: Re: [Pharo-project] request for the new merge tool :) > > >> would be great. >> Send code :) >> >> On Sep 8, 2009, at 4:24 PM, rkrock(a)locksleycreeksoftware.com wrote: >> >>>>>> Yes, this is what the History button is supposed to do, display >>>>>> the >>>>>> diff between two arbitrary versions. >>>>> >>>>> What about backport? >>>>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2004-September/08209… >>>> >>>> That works in the wrong direction for me. I prefer to load changes >>>> into my working copy instead of having to load the other code and >>>> "backporting" my changes into their code. >>>> >>>> Lukas >>>> >>> >>> What about an option for go forward or backward. It really on which >>> fork >>> of the code is considered the 'root' and that is often in the eyes >>> of the >>> beholder. >>> >>>> -- >>>> 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 >>>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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

Sept. 8, 2009