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

Re: [Pharo-project] MorphTreeMorph

by Gary Chambers

Or "Experimental" perhaps (like Polymorph...) 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 1:05 PM Subject: Re: [Pharo-project] MorphTreeMorph Alain could not you do a Beta-WidgetsWillBeReadyInNextVersion package :) Stef On Sep 8, 2009, at 11:32 AM, Tudor Girba wrote: > Aha, thanks for the clarification. In this case, I will just work with > it by loading it from Monticello :). > > Cheers, > Doru > > > On 8 Sep 2009, at 08:48, Alain Plantec wrote: > >> Hil all, >> >> MorphTreeMorph and related are still not mature enough to be >> considered >> as part of standard widgets. This is why it is private to the >> settings >> package. >> For 1.0, I think it is better to not integrate it >> Cheers >> Alain >> >> Marcus Denker a Ã©crit : >>> On 07.09.2009, at 20:10, Tudor Girba wrote: >>> >>> >>>> Hi, >>>> >>>> It looks like in the latest Pharo images (both core and dev) the >>>> MorphTreeMorph class is missing. In fact, it looks like the whole >>>> System-Settings package is missing. >>>> >>>> Is there a reason for this? >>>> >>>> >>> >>> Hello, >>> >>> The settings were not used and the next version seemingly will >>> change >>> form an >>> API perspective. >>> >>> Of course, I did not know that the package contained widgets that >>> are >>> used by >>> others... >>> >>> Maybe we can move the MorphTreeMorph class into the package that >>> contains the >>> widgets? >>> >>> Marcus >>> >>> >>> >>> >>> -- >>> Marcus Denker - http://marcusdenker.de >>> PLEIAD Lab - Computer Science Department (DCC) - University of Chile >>> >>> >>> _______________________________________________ >>> 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 >> > > -- > www.tudorgirba.com > > "Beauty is where we see it." > > > > > _______________________________________________ > 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] Merge tool bug?

by Gary Chambers

Unfortunately that doesn't appear to be an option with the way Monticello works. The megre tool, like the original, only deals with conflicts in that manner, not additions or removals. I'm happy to work with anyone that would like to improve MC here, though clearly difficult given the varieties of MC out there... Regards, Gary ----- Original Message ----- From: "Michael Robers" <mike(a)mjr104.co.uk> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Tuesday, September 08, 2009 12:55 PM Subject: Re: [Pharo-project] Merge tool bug? > Ok but I can't selectively take it or leave it? I seem to have no > choice. > > Thanks > Mike > > On 8 Sep 2009, at 10:38, "Gary Chambers" <gazzaguru2(a)btinternet.com> > wrote: > >> The left-hand pane shows the version of the method in the image only >> if it >> currently belongs to the package being merged... hence the "tick" >> showing an >> new addition (cross is removal from package, right-hand pane will be >> blank). >> >> I guess that in your image that method is in another package. >> >> Regards, Gary >> >> ----- Original Message ----- >> From: "Michael Roberts" <mike(a)mjr104.co.uk> >> To: "Pharo-project" <pharo-project(a)lists.gforge.inria.fr> >> Sent: Monday, September 07, 2009 11:31 PM >> Subject: Re: [Pharo-project] Merge tool bug? >> >> >>> sorry.... >>> >>> >>> I thought the left hand pane was always what was in the image and the >>> right was incoming? >>> >>> My method appears identical in both. >>> >>> thanks, >>> Mike >>> >> >> >> --- >> --- >> --- >> --- >> -------------------------------------------------------------------- >> >> >>> _______________________________________________ >>> 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] dnu - isScarySelector not found

by Lukas Renggli

> Did he remove that from his OB version? I think so. As far as I can tell he merged all my changes. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Sept. 8, 2009

Re: [Pharo-project] Cleanup of Deprecation

by Miguel Enrique CobÃ¡ Martinez

El mar, 08-09-2009 a las 07:20 -0700, Andrew P. Black escribiÃ³: > I just committed (with much help from StÃ©phane) my first contribution > to Pharo! Thanks. > > Cleanup of Deprecation > Status: > Fixed > Owner: > ---- > Milestone-1.0 > > Submitted a bunch of small fixes that make the use of deprecation > uniform across Pharo. The > changes are mostly to the wording of the deprecation message. They > also restore the previous > behavior of the exception handler so that the notifier says that > something has been deprecated. > > The package is Slice-CleaningDeprecation-AndrewBlack.1 > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Sept. 8, 2009

Re: [Pharo-project] Author reset at each image startup issue 1134

by StÃ©phane Ducasse

john is not not that calss that load .st from the command line? I have to check. Stef On Sep 8, 2009, at 3:40 PM, John M McIntosh wrote: > Frankly we should consider if the ProjectLauncher stuff should run at > all at startup > Go look at what it does then consider > AutoStart deinstall. > and decide if Pharo users/developers need all that to run everytime > they start the image. > > If you do, then why you should manually configure it, a perference > perhaps, because > likely you are the 1% that has special needs. > > > On 8-Sep-09, at 2:32 PM, Miguel Enrique CobÃ¡ Martinez wrote: > >> Issue 1134: Repeated Author Initials Inquiry >> >> Confirmed. >> >> Tracked down to >> >> ProjectLauncher>>startUp >> World ifNotNil: [World install]. >> Author fullName: ''. >> ^self startUpAfterLogin. >> >> That is invoked on image startUp by >> >> AutoStart>>startUp: resuming >> >> that itself uses the class var InstalledLaunchers that contains: >> >> ProjectLauncher. >> >> So at each image startup the fullName is reset to ''. >> >> What should we do. What is the purpouse of ProjectLauncher startUp. >> >> The versions windows of ProjectLauncher>>startUp shows: >> >> markus.denker 8/18/2008 21:35 ProjectLauncher startUp {running} >> >> Should the line: >> >> Author fullName: ''. >> >> be deleted from ProjectLauncher startUp >> >> or should ProjectLauncher be deleted from InstalledLaunchers on >> AutoStart? >> -- >> Miguel CobÃ¡ >> http://miguel.leugim.com.mx >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > = > = > = > = > = > ====================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: > squeaker68882 > Corporate Smalltalk Consulting Ltd. http:// > www.smalltalkconsulting.com > = > = > = > = > = > ====================================================================== > > > > > > _______________________________________________ > 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

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

Sept. 8, 2009

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

by StÃ©phane Ducasse

On Sep 8, 2009, at 2:38 PM, Lukas Renggli wrote: >> may be the first step would be to add back the install menu items. > > These are definitely crucial for being able to cherry pick changes > from different versions. yessssss so may be we should add it :) > >> Now for browsing the changes in the squeak trunk we should find a way >> to select >> only change between two versions and even using the history button I >> could not exactly get what >> I wanted. Lukas did you succeed to do this kind of operation? > > Yes, this is what the History button is supposed to do, display the > diff between two arbitrary versions. > > The Changes button displays the diff between the image and the > selected version. > > Lukas > > -- > 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

Sept. 8, 2009

Re: [Pharo-project] dnu - isScarySelector not found

by StÃ©phane Ducasse

oops strange then. Did he remove that from his OB version? Stef On Sep 8, 2009, at 2:35 PM, Lukas Renggli wrote: > I am using the code of Colin and there are no senders to > #isScarySelector, so I don't understand why there is a problem? > > Lukas

Sept. 8, 2009

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

by rkrock＠locksleycreeksoftware.com

>>> 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 >

Sept. 8, 2009

[Pharo-project] Cleanup of Deprecation

by Andrew P. Black

I just committed (with much help from StÃ©phane) my first contribution to Pharo! Cleanup of Deprecation Status: Fixed Owner: ---- Milestone-1.0 Submitted a bunch of small fixes that make the use of deprecation uniform across Pharo. The changes are mostly to the wording of the deprecation message. They also restore the previous behavior of the exception handler so that the notifier says that something has been deprecated. The package is Slice-CleaningDeprecation-AndrewBlack.1

Sept. 8, 2009