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 5:19 PM, Gary Chambers wrote: > As far as I can tell, the history/changes still shows the differences > between the selected versions and not the image. I'm not sure in fact :) > > Regards, Gary > > ----- Original Message ----- > From: "Lukas Renggli" <renggli(a)gmail.com> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Tuesday, September 08, 2009 1:38 PM > Subject: Re: [Pharo-project] request for the new merge tool :) > > >>> 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. >> >>> 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 > > > _______________________________________________ > 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 Michael Roberts

All this documentation appearing on the list is very useful. It seems that trying to merge from squeak trunk has stretched the merge model I don't know. It would be a shame if you had to be a mc expert before doing such a task since merging per se is not difficult. I felt really constrained in what I could do per change. It looks like we are in a period where this will become a more common use case since there is good code going into squeak trunk but pharo in some packages is ahead and you don't want the merge tool to discard changes. I'm definitely up for helping. I will try the old merge tool just to use the other features described. Of course it could just be user error.. Cheers mike On Tuesday, September 8, 2009, Gary Chambers <gazzaguru2(a)btinternet.com> wrote: > 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 > > > _______________________________________________ > 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 Gary Chambers

Perhaps an opportunity to build-in a deployment feature? 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

Sept. 8, 2009

Re: [Pharo-project] Halos

by Damien Cassou

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

Sept. 8, 2009

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

by Damien

Sent to you by Damien via Google Reader: Slice-MCDependenciesDialogPlagueFixed-ab.1.mcz via PharoInbox on 9/8/09 This fix stops MC from asking for a log message for every dependent of the package that you are saving. Instead, it re-uses the log message from the parent. Is it necessary to offer a checkbox in the parent's save dialogue to ask if this is the desired behaviour? Things you can do from here: - Subscribe to PharoInbox using Google Reader - Get started using Google Reader to easily keep up with all your favorite sites

Sept. 8, 2009

[Pharo-project] Halos

by Gary Chambers

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... Regards, Gary

Sept. 8, 2009

[Pharo-project] Morph extension

by Gary Chambers

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. I thought Marcus has mentioned this some time ago, but no progress? 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

Sept. 8, 2009

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

by Gary Chambers

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

Sept. 8, 2009

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

by Gary Chambers

We always turn off the Projectlauncher start up in order to get (some) sanity on command-line options (still need an extra "-" to bypass though). Regards, Gary ----- Original Message ----- From: "John M McIntosh" <johnmci(a)smalltalkconsulting.com> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Tuesday, September 08, 2009 2:40 PM Subject: Re: [Pharo-project] Author reset at each image startup issue 1134 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 Gary Chambers

As far as I can tell, the history/changes still shows the differences between the selected versions and not the image. Regards, Gary ----- Original Message ----- From: "Lukas Renggli" <renggli(a)gmail.com> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Tuesday, September 08, 2009 1:38 PM Subject: Re: [Pharo-project] request for the new merge tool :) >> 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. > >> 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