May 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] How to find if a method has a version in a package

by Goubier Thierry

Le 23/05/2013 11:29, stephane ducasse a Ã©crit : > Normally RPackage knows it. The problem is that two use cases for an extension or an override with the AltBrowser is: extension: 1 - create a new method x in Class A belonging to package B 2 - drag and drop method x to package C (to make it an extension in C) override: 1 - modify method x in Class A belonging to package B 2 - drag and drop method x to package C (to make it an override in C) What I think that RPackage will do is that, at step 2, it will answer that method x belong to package B (in both cases). What I would like is, at 2, being able to tell whether x is new in B or has been stored as part of package B (before any changes). Will RPackage be able distinguish between the two ? > Now we are really thinking how to go the next level with PackageInfo and the rest. > > Stef > > On May 23, 2013, at 9:32 AM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > >> Hi, >> >> as the question says: how can I determine if a selector of a class is already listed as belonging to an existing version of a MC package ? >> >> What I want to do is to determine, when I drag a method from a class to a package, whether this method should go as an extension or an override. At the moment, in the AltBrowser, if you drag a method from a class to the extension tag of a package, it will move the method in the right extension protocol, creating it if needed. Now, what I'd like is, if you do that to a method which has a version in an existing package (not just in the current changes), it can give you the choice to list that method as an override instead of an extension. And for that, I need to query the MCPackage, no? >> >> Thierry >> -- >> Thierry Goubier >> CEA list >> Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s >> 91191 Gif sur Yvette Cedex >> France >> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >> > > > > -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

May 23, 2013

[update 3.0] #30161

by Esteban Lorenzano

30161 ----- 10720 Morphic-Base classes have extension methods of Morphic https://pharo.fogbugz.com/f/cases/10720 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Morphic-Base-EstebanLorenzano…

May 23, 2013

Opening Settings browser is really slow

by StÃ©phane Ducasse

Hi in the latest 30 opening the setting browser is slow. I could not find if it was already reported. Any idea why? Stef

May 23, 2013

Re: [Pharo-dev] Messy Configurations

by stephane ducasse

>>> > > well this is only a convention, without proper tools everything will become messy > anyway :P agreed > > Here is used example of the new configuration: > > Gofer new > smalltalkhubUser: 'Pharo' project: 'ci'; > configurationOf: 'CI'; > load. > > #ConfigurationOfCI asClass browse Yes this is good!.

May 23, 2013

Re: [Pharo-dev] FileSystem inconsistency

by Camillo Bruni

On 2013-05-23, at 11:27, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > So we should sit together and do a pass on all the mails and sent and address what should be addressed. > Wednesday morning? that's fine.

May 23, 2013

Re: [Pharo-dev] Messy Configurations

by Camillo Bruni

On 2013-05-23, at 11:27, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > > On May 23, 2013, at 10:17 AM, roberto.minelli(a)usi.ch wrote: > >> +1000 Camillo!! I'd really appreciate a "better" MC configuration mechanism! well this is only a convention, without proper tools everything will become messy anyway :P Here is used example of the new configuration: Gofer new smalltalkhubUser: 'Pharo' project: 'ci'; configurationOf: 'CI'; load. #ConfigurationOfCI asClass browse

May 23, 2013

Re: [Pharo-dev] How to find if a method has a version in a package

by stephane ducasse

Normally RPackage knows it. Now we are really thinking how to go the next level with PackageInfo and the rest. Stef On May 23, 2013, at 9:32 AM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > Hi, > > as the question says: how can I determine if a selector of a class is already listed as belonging to an existing version of a MC package ? > > What I want to do is to determine, when I drag a method from a class to a package, whether this method should go as an extension or an override. At the moment, in the AltBrowser, if you drag a method from a class to the extension tag of a package, it will move the method in the right extension protocol, creating it if needed. Now, what I'd like is, if you do that to a method which has a version in an existing package (not just in the current changes), it can give you the choice to list that method as an override instead of an extension. And for that, I need to query the MCPackage, no? > > Thierry > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >

May 23, 2013

Re: [Pharo-dev] FileSystem inconsistency

by stephane ducasse

So we should sit together and do a pass on all the mails and sent and address what should be addressed. Wednesday morning? On May 23, 2013, at 9:50 AM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > On 2013-05-23, at 07:41, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > >> We should talk when I'm back but my point is that >> deleting an nonexisting file should raise an error, if deleting an non existig folder does. > > yes FilePluginPrims >> #deleteFile: should raise a warning if the file does not exist. > otherwise it is quite inconsistent :/

May 23, 2013

Re: [Pharo-dev] Messy Configurations

by stephane ducasse

On May 23, 2013, at 10:17 AM, roberto.minelli(a)usi.ch wrote: > +1000 Camillo!! I'd really appreciate a "better" MC configuration mechanism! us too. Now we have to deal with the fact that latest version of metacello could not work in Pharo anymore Stef > On May 22, 2013, at 5:53 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > >> I recently spent some time to revise how to write Metacello Configurations. >> >> Observation: >> ============ >> - many configurations are quite a mess >> - many configurations duplicate code internally >> - many configurations have archived development versions >> >> >> For Pharo 3.0 I made a new Configuration template which improves and documents >> these observed points in quite some detail. Simply load a new 3.0 image and >> create a new configuration from the monticello working copy browser. >> >> Solution: >> ========= >> - specify external projects in separate, reusable methods >> - only have ONE development version you regularly update >> - do not use version numbers for the development version >> - only make a version number when you release something stable AKA not #development >> - name the baseline after the first version that introduces it >> >> >> >> What do you think? > >

May 23, 2013

Re: [Pharo-dev] TxText new version 0.8

by stephane ducasse

I understand your point. Now I would like a tool to help and that the tool or rule encode decision. We are all overloaded with information that we should keep in mind. Tools are done for that to help us getting free to think on the important point. Stef On May 23, 2013, at 8:35 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > > Am 23.05.2013 um 02:35 schrieb Igor Stasenko <siguctua(a)gmail.com>: > >> ProjectName-Core >> ProjectName-Extras >> ProjectName-Tests > > That approach has a limited scope. Because we match by prefix you have to do -Core and not just ProjectName. In a decent amount of projects -Core and -Extras will grow and you will have tests for -Core and -Extras and you don't want to combine them into a single -Tests package. > But what do you do? > > ProjectName-Core-Core > ProjectName-Core-Tests > > ?? Surely not. From this perspective one can look the way seaside does it. It is > > ProjectName-Core > ProjectName-Extras > ProjectName-Tests-Core > ProjectName-Tests-Extras > > So there are multiple possibilities how to achieve it. I always start my projects by keeping tests inside the same package as the rest of the code. Well, I have the habit to mostly create a -Core package at the beginning. Later of the module grows I put -Tests in an extra package. And in one big project I did the seaside approach by putting the -Tests after the ProjectName. This way you don't have too much problems until you introduce platform dependent packages. > > Norbert

May 23, 2013