November 2008 - Pharo-dev - lists.pharo.org

[Pharo-project] [update] #10142

by Marcus Denker

Issue 317: lessMethodSendsInFontUsage Issue 301: UIManager enhacements -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Nov. 9, 2008

[Pharo-project] [ANN] Part of Etoy removal updates

by StÃ©phane Ducasse

update10137 simple etoy cleaning from gary list. ------------------------------------------------------ update10138 HaloMorphEtoyCleaning ------------------------------------------------------ update10139 EtoyUnsentMessageRemoval ------------------------------------------------------ update10140 Object etoy cleaning (treated so far) assured beViewed belongToUniClass browseOwnClassSubProtocol categoriesForViewer: categoriesForVocabulary: aVocabulary limitClass: aLimitClass chooseNewNameForReference defaultLimitClassForVocabulary: eToyStreamedRepresentationNotifying: infoFor: anElement inViewer: aViewer Object (to fix later so far) presenter currentVocabulary defaultNameStemForInstances

Nov. 8, 2008

Re: [Pharo-project] Monticelle renaming (was I would like to clean the inbox! Please read)

by Keith Hodges

For package renaming, in the past I have temporarily borrowed the #copyAll function in order that all packages and their history are renamed as they are transferred from one repository to another. Keith

Nov. 8, 2008

[Pharo-project] About etoy cleaning

by StÃ©phane Ducasse

Hi guys I just wanted to let you know that I'm working on etoy cleaning from Object, Morph and friends. And I will probably do some mistakes (because this is complex). I'm trying to do that concentrated but still this is serious beast. Now I'm keeping a list of my progress at this page http://code.google.com/p/pharo/w/edit/CurrentlyWorkingOn so that you can follow my progression and that I'm not lost either. I'm using gary etoy removal and going over his list and checking senders of senders .... and verifying when I have doubts. and I'm finding missed points from time to time and this is normal when we see the complexity of etoy and morphic together. So gary may be at the end I would appreciate that you have a look at the stuff I'm removing. May be by doing a "changes" comparison. Right now I'm cleaning object and I will keep a list of the difficult methods I did not fixed yet. May be these ones will be easier to treat when etoy will be removed. Stef

Nov. 8, 2008

[Pharo-project] [update] #10136

by Marcus Denker

Issue 305: TODO: garbage collection parameters Issue 312: Typo in PasteUpMorph>>keyboardNavigationHandler Issue 309: Color>hex: should be brought back Issue 306: file stream not closed after drag and drop of CS in postscript: (Preferences preferenceAt: #allowEtoyUserCustomEvents) changeInformee: nil changeSelector: nil. -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Nov. 8, 2008

Re: [Pharo-project] Monticelle renaming (was I would like to clean the inbox! Please read)

by Lukas Renggli

On 11/8/08, Noury Bouraqadi <bouraqadi(a)ensm-douai.fr> wrote: > Thanks Lukas for the feedback. Now I have some questions: > > -For fuctionality 1 : Because of the dependency with the > RefactoringBrowser, which obviously shouldn't be in the core image. > Does it make sense to have it in an external package ? It's handy to > avoid using multiple tools when renaming a Monticello Package and the > corresponding class prefixes. But, may be should I reimplement without > reusing the RefactoringBrowser ? Renaming all classes of a package doesn't really make sense without fixing all references automatically. It is certainly a pain to do without the refactoring tools. But, as I said, this functionality is already part of the OB refactoring tools. > -Is fuctionality 2 useful for other people than me ? It is definitely useful. For the Seaside 2.9 repackaging effort we had to rename sevaral packages manually. A solid tool would be a huge advantage. Cheers, Lukas Fixing the issues > you identified wouldn't be a big challenge. > > Noury > On 7 nov. 08, at 22:26, Lukas Renggli wrote: > >> The package MonticelloPackageRenaming-Noury.1 introduces 2 new menu >> items into the Monticello Browser, by overriding and extending several >> methods in Monticello. If this code is included with Pharo, it should >> become part of Monticello itself. There are 4 test cases included. >> >> Below I review the two new functionalities independently: >> >> 1. Replace Classes Prefix: This functionality is useful, however the >> implementation depends on the presence of the Refactoring Browser. >> Furthermore this functionality is already present in the Refactoring >> Browser (OB-Regex) in a more generic fashion. Open | Rewrite Class >> allows one to batch rename, batch copy and batch create a set of >> classes using regular expressions. >> >> 2. Rename Package: This functionality renames class categories and >> method protocols to match the new package name. The code also takes >> care of the dependencies and removing traces of the old package in the >> Monticello Browser. It does not depend on external functionality. >> There are however 3 major problems with the implementation: (1) Class >> extensions extinct if they do not match the package names in a >> case-sensitive way. PackageInfo treats class categories >> case-sensitive, but protocols are handled case-insensitive. (2) >> Packages that share the same prefix are wrongly renamed, even if >> PackageInfo does not consider them to be from the same package (for >> example Morphic and MorphicExtras). (3) The ancestry of the renamed >> package is not preserved, what makes merging packages across renaming >> impossible. Though, I don't know if such a functionality would be >> possible with Monticello at all? >> >> Given the number of problems I don't suggest to include these >> extensions for now. >> >> Cheers, >> 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 >> > > Noury Bouraqadi > ------------------------------------------------------------------ > Dr. Noury Bouraqadi - Enseignant/Chercheur > Responsable de l'enseignement de l'informatique > ARMINES - Ecole des Mines de Douai - Dept. I.A. > http://vst.ensm-douai.fr/noury > > European Smalltalk Users Group Board > http://www.esug.org > ------------------------------------------------------------------ > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch

Nov. 8, 2008

Re: [Pharo-project] adrian .... help :)

by StÃ©phane Ducasse

Adrian I fixed some glitches in prepare... and commited. I will work a bit on etoy removal now. Stef On Nov 8, 2008, at 8:12 AM, StÃ©phane Ducasse wrote: > Ok I see thanks > > > On Nov 7, 2008, at 11:13 PM, Adrian Lienhard wrote: > >> Hi Stef >> >> Yesterday evening I did another update and it worked fine... >> >> It looks like the counter was increased twice in your case. This >> can happen if the image is not fresh (the counter was set already) >> or the #prepareNewUpdate is executed twice. To prevent this in the >> future I changed how the counter is computed (now it does not >> lazily increase it anymore but it looks at the latest updateXXX >> number). The previous implementation of updateXXX number + 1 does >> not work anymore because the new process supports to get back to >> apply changes another time after the verification step and hence >> you do not know if the updateXXX method was already created or not. >> >> I did a small update (10135) to check and it worked. So I'm curious >> if it works reliably for you too now. >> >> Adrian >> >> >> On Nov 7, 2008, at 16:12 , StÃ©phane Ducasse wrote: >> >>> adrian >>> >>> could you have a look at the scriptloader because it gets >>> desynchronised (I had to change the number by hand this morning >>> again and I followed exactly the process). May be my image counter >>> was not correct. I think that this counter is >>> brittle. I would just do what we did before taking the lastest >>> updateXXX number + 1 >>> >>> Stef >>> >>> _______________________________________________ >>> 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 >

Nov. 8, 2008

Re: [Pharo-project] I would like to clean the inbox! Please read

by StÃ©phane Ducasse

by the way damien can you reply for the network and networktest? did you check what was done? Stef On Nov 8, 2008, at 11:08 AM, Damien Cassou wrote: > On Fri, Nov 7, 2008 at 5:29 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> I will move the rest to treated. >> Except I you shout and tell me that your code is ready for >> integration. > > Does it mean you will ignore everything but these 3 fixes? I don't > understand why. If you don't have time, just don't harvest them. > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Nov. 8, 2008

Re: [Pharo-project] Monticelle renaming (was I would like to clean the inbox! Please read)

by StÃ©phane Ducasse

> Thanks Lukas for the feedback. Now I have some questions: > > -For fuctionality 1 : Because of the dependency with the > RefactoringBrowser, which obviously shouldn't be in the core image. > Does it make sense to have it in an external package ? It's handy to > avoid using multiple tools when renaming a Monticello Package and > the corresponding class prefixes. But, may be should I reimplement > without reusing the RefactoringBrowser ? My feeling is that the RBengine should be in the system (not core) at the same time the browsers are in. Because renaming a class in the refactoring way is just the way to go since 10 years or more. > -Is fuctionality 2 useful for other people than me ? Fixing the > issues you identified wouldn't be a big challenge. Yes renaming a package would be cool. > > > Noury > On 7 nov. 08, at 22:26, Lukas Renggli wrote: > >> The package MonticelloPackageRenaming-Noury.1 introduces 2 new menu >> items into the Monticello Browser, by overriding and extending >> several >> methods in Monticello. If this code is included with Pharo, it should >> become part of Monticello itself. There are 4 test cases included. >> >> Below I review the two new functionalities independently: >> >> 1. Replace Classes Prefix: This functionality is useful, however the >> implementation depends on the presence of the Refactoring Browser. >> Furthermore this functionality is already present in the Refactoring >> Browser (OB-Regex) in a more generic fashion. Open | Rewrite Class >> allows one to batch rename, batch copy and batch create a set of >> classes using regular expressions. >> >> 2. Rename Package: This functionality renames class categories and >> method protocols to match the new package name. The code also takes >> care of the dependencies and removing traces of the old package in >> the >> Monticello Browser. It does not depend on external functionality. >> There are however 3 major problems with the implementation: (1) Class >> extensions extinct if they do not match the package names in a >> case-sensitive way. PackageInfo treats class categories >> case-sensitive, but protocols are handled case-insensitive. (2) >> Packages that share the same prefix are wrongly renamed, even if >> PackageInfo does not consider them to be from the same package (for >> example Morphic and MorphicExtras). (3) The ancestry of the renamed >> package is not preserved, what makes merging packages across renaming >> impossible. Though, I don't know if such a functionality would be >> possible with Monticello at all? >> >> Given the number of problems I don't suggest to include these >> extensions for now. >> >> Cheers, >> 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 >> > > Noury Bouraqadi > ------------------------------------------------------------------ > Dr. Noury Bouraqadi - Enseignant/Chercheur > Responsable de l'enseignement de l'informatique > ARMINES - Ecole des Mines de Douai - Dept. I.A. > http://vst.ensm-douai.fr/noury > > European Smalltalk Users Group Board > http://www.esug.org > ------------------------------------------------------------------ > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Nov. 8, 2008

Re: [Pharo-project] I would like to clean the inbox! Please read

by StÃ©phane Ducasse

No totally I just clean what I could. For example, I asked you if you could redo your embedded world. because with the changes lukas did we got a lot of noise. Again I repeat it, when we open the pharoinbox this is difficult for us (even if the merging of MC helps a lot) to know what is the slice for, its importance, impact... >> Except I you shout and tell me that your code is ready for >> integration. > > Does it mean you will ignore everything but these 3 fixes? I don't > understand why. No I'm cleaning. There were old submissions hanging around. > If you don't have time, just don't harvest them. this is not the point. > > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Nov. 8, 2008