March 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Issue 3835 in pharo: Finder and RecentSubmissions new versions

by pharo＠googlecode.com

Updates: Status: Closed Comment #2 on issue 3835 by stephane...(a)gmail.com: Finder and RecentSubmissions new versions http://code.google.com/p/pharo/issues/detail?id=3835 tx in 13098

March 20, 2011

Re: [Pharo-project] Issue 3835 in pharo: Finder and RecentSubmissions new versions

by pharo＠googlecode.com

Comment #1 on issue 3835 by stephane...(a)gmail.com: Finder and RecentSubmissions new versions http://code.google.com/p/pharo/issues/detail?id=3835 indicate the packages and repo: it will help us.

March 20, 2011

Re: [Pharo-project] Issue 3836 in pharo: superfluous packageInfo respondsTo: #overriddenMethods

by pharo＠googlecode.com

Updates: Status: Closed Comment #1 on issue 3836 by stephane...(a)gmail.com: superfluous packageInfo respondsTo: #overriddenMethods http://code.google.com/p/pharo/issues/detail?id=3836 (No comment was entered for this change.)

March 20, 2011

Re: [Pharo-project] Refactoring Browser Enhancements

by StÃ©phane Ducasse

On Mar 20, 2011, at 9:59 AM, Lukas Renggli wrote: > Yes, I looked at it and I gave detailed feedback in my previous mails. > > No, I won't include it for the reasons given in my previous mails. > Your changes subtly break assumptions made by any user of > BrowserEnvironment (in addition to unnecessarily changing the API), > but I am not going to repeat that and how to solve it differently a > fourth time :-( Too bad that you are stubborn. I'm too. The changes we are proposing to not break the default use of the system. ***All the queries that a normal user will do will share the same default environment *** and only when we will need to browse/query another systemDictionary we will have to make sure that the environment points to the right systemDictionary and that the queries access this root (which they do). Show me how this is wrong. We need it. So if you do not want to help I cannot do too much and I will fork because all our efforts to make the system parameterized will not be blocked just because you do not want to take 5 min to listen carefully what we are saying. Stef > > Lukas > > On 20 March 2011 09:43, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> So lukas >> - did you check what we did? >> - will you include in rb packages? >> I need to know. >> >> Stef >> >> On Mar 19, 2011, at 7:55 AM, StÃ©phane Ducasse wrote: >> >>> Let us be more productive :) >>> >>> A BrowserEnvironment >>> has an environment input= a systemDictionary (may be we should call it origin) >>> a selectedEnviroment = a composite based on the BrowserEnvironment hierarchy >>> >>> The precondition is that it does not make sense to mix apple and orange so >>> selectedEnvironment inside a composite to be meaningfull should sahre the same origin. >>> >>> Now it does not mean that we cannot have different composite over the same origin (ie we have >>> multiple queries over Smalltalk globals) or that we cannot have different and separate composite >>> working on different origin (ie I have a selection on Pharo1.2 and one on Pharo1.3 or a remote one). >>> >>> >>> On Mar 18, 2011, at 10:09 PM, Lukas Renggli wrote: >>> >>>> - BrowserEnvironment>>#copyEmpty >>> >>> copyEmpty >>> ^ self class new on: SystemDictionary new; yourself. >>> >>>> - BrowserEnvironment>>#& >>> >>> & anEnvironment >>> "If we or anEnvironment includes everything, then just include the other environment (optimization)" >>> >>> self isSystem ifTrue: [^anEnvironment]. >>> anEnvironment isSystem ifTrue: [^self]. >>> ^AndEnvironment onEnvironment: self and: anEnvironment >>> >>> does not change >>> >>> >>>> - BrowserEnvironment>>#I >>> >>> | anEnvironment >>> "If we or anEnvironment includes everything, then return it instead of creating >>> an or that will include everything." >>> >>> self isSystem ifTrue: [^self]. >>> anEnvironment isSystem ifTrue: [^anEnvironment]. >>> ^ OrEnvironment onEnvironment: self or: anEnvironment >>> >>>> - BrowserEnvironment>>#not >>> not >>> self isSystem ifTrue: [^SelectorEnvironment new]. >>> ^NotEnvironment onEnvironment: self >>> >>> >>> >>>> - BrowserEnvironment>>#isSystem >>> isSystem >>> ^true >>> >>> No problem (this could be renamed isOriginalInput but we keep it for compatibiity >>> >>>> - ClassEnvironment>>#classesDo: >>> >>> classesDo: aBlock >>> classes do: [ :each | >>> | class | >>> class := Smalltalk globals at: each ifAbsent: [ nil ]. >>> (class notNil and: [ environment includesClass: class ]) >>> ifTrue: [ aBlock value: class ] ]. >>> metaClasses do: [ :each | >>> | class | >>> class := Smalltalk globals at: each ifAbsent: [ nil ]. >>> (class notNil and: [ environment includesClass: class class ]) >>> ifTrue: [ aBlock value: class class ] ] >>> We already fixed it. >>> >>> classesDo: aBlock >>> classes do: [ :each | >>> | class | >>> class := self environment at: each ifAbsent: [ nil ]. >>> (class notNil and: [ selectedEnvironment includesClass: class ]) >>> ifTrue: [ aBlock value: class ] ]. >>> metaClasses do: [ :each | >>> | class | >>> class := self environment at: each ifAbsent: [ nil ]. >>> (class notNil and: [ selectedEnvironment includesClass: class class ]) >>> ifTrue: [ aBlock value: class class ] ] >>> >>>> - SelectorEnvironment>>#classesDo: >>> >>> classesDo: aBlock >>> classSelectors keysDo: [ :each | >>> | class | >>> class := Smalltalk globals at: each ifAbsent: [ nil ]. >>> (class notNil and: [ environment includesClass: class ]) >>> ifTrue: [ aBlock value: class ] ]. >>> metaClassSelectors keysDo: [ :each | >>> | class | >>> class := Smalltalk globals at: each ifAbsent: [ nil ]. >>> (class notNil and: [ environment includesClass: class class ]) >>> ifTrue: [ aBlock value: class class ] ] >>> >>> again we already fixed it. >>> >>> classesDo: aBlock >>> classes do: [ :each | >>> | class | >>> class := self environment at: each ifAbsent: [ nil ]. >>> (class notNil and: [ selectedEnvironment includesClass: class ]) >>> ifTrue: [ aBlock value: class ] ]. >>> metaClasses do: [ :each | >>> | class | >>> class := self environment at: each ifAbsent: [ nil ]. >>> (class notNil and: [ selectedEnvironment includesClass: class class ]) >>> ifTrue: [ aBlock value: class class ] ] >>> >>> >>> So does it make sense? >>> I think so. >>> We just have a common input for a given composite. >>> >>> Stef >> >> >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch >

March 20, 2011

Re: [Pharo-project] need your attention: Package

by StÃ©phane Ducasse

Thanks doru. I will digest that. I have the impression that I understand your approach but would not it be error prone to select the Rpackages you want to map to MCPackage? Stef >>> Hi Stef, >>> >>> Thanks a lot for all this effort. >>> >>> I will reiterate again the original idea, which I still believe would work best. >>> >>> RPackage is meant to become the organization entity in the image. MCPackage will still be needed for versioning. Furthermore, for a while, categories will still remain in the system for a while as an implementation detail. RPackages mirror each category. >>> >>> The first step would be to keep loading from Monticello exactly like it is now: it will create Categories, and this will mirror in RPackages. >> >> this sentence is not clear doru. >> Do you mean that a RPackage should contain classes that are contained in matching PackageInfo package? >> I mean >> RFoo >> contains RFoo and RFoo-zork categories classes? > > No. I meant we have a 1-1 mapping to categories. So, you will get multiple RPackages in the system: RFoo, RFoo-zork ... > >>> The next step is to provide a tool that provides only a 1-1 mapping between MC and RPackages that we can use for publishing. >> >> The problem is not publishing the problem is assigning classes to packages. > > I think that if we split loading and publishing logic as a transition phase it would solve the problem, and I actually believe that you are talking about a similar thing (see below). > >>> In this way, we would be able to: >>> - load existing MC without problems >>> - publish new MCPackages that will be compatible with other dialects >> >> let us see >> imagine the following scenaro >> >> PI-Foo contains >> Foo >> Foo-Zork >> >> => >> We get >> RFoo >> and RFoo-Zork >> >> we can save and people can load >> now >> >> I add a category Foo-Two >> in pharo I get an extra package >> we should modify metacelloConfig >> ok people can load it too >> >> in other system it will be in Foo >> ok we can load it >> >> >> Now if we should preserve the current loading semantics **package creation** >> >> when PI-Foo contains >> Foo >> Foo-Zork >> >> if we should create only one RFoo containing all the FooCat >> then we arrive to the point where this is not clear that >> when I add a new cat it will not be in. > > The solution I proposed was a new publishing interface for MC that works with the 1-1 mapping between RPackage and PackageInfo. Like this, for saving we would be force to save the new package. > > So, in your case, when you would open the NewMC, you would see in the list: > > Foo > Foo-Zork > Foo-Cat* > > The +Package button would disappear altogether. You would be provided with the possible things to commit, and then you would not have to think about the mapping at all. All you have to do is select each of the RPackages that you want to commit, and if there does not exist a correspondent Monticello package for it, you would be asked to provide the repo and then the creation would happen transparently. > >> So we could always load and create a RPackage for each Category. This would be simpler. > > In your solution, you would again split the mapping logic of load from that of publishing but you would change the loading mapping such that when you load you create only one category per PI. Perhaps that is indeed simpler, but you would lose the extra info of categories. > > > Were my explanations clearer now? > > > Cheers, > Doru > > > >> >>> Indeed, Metacello configurations will need modifications, but we have a smooth path to it. The Metacello configurations are still typically used only for loading and that will still continue to work just like they do now. With the Metacello Browser things will change, but then again we can change that tool, too. >>> >>> The only problem is how to define class extensions. I believe the * magic mapping is in MC. That will create problems, but for a while, I think we can still rely on this mapping. >> >> yes >> >>> >>> Cheers, >>> Doru >>> >>> >>> >>> On 19 Mar 2011, at 22:20, StÃ©phane Ducasse wrote: >>> >>>> >>>> On Mar 19, 2011, at 7:17 PM, Guillermo Polito wrote: >>>> >>>>> BTW, for smooth transition, why not just replace usages of PackageInfo by RPackage keeping everything working as today? And after that, we can improve the way we use it. >>>>> >>>>> In two words, why not replace only infrastructure instead of infrastructure and behavior at the same time? Doing both together is kind of complex and easy to make mistakes... >>>> >>>> yes this is what cyrille started to do. On top of RPackage so may be cleaning that is the way to go. >>>> but the matching semantics is not good. >>>> >>>>> But maybe it's easier (or nicer) to replace everything together... :P >>>>> >>>>> Guille >>>>> >>>>> On Sat, Mar 19, 2011 at 1:35 PM, Dale Henrichs <dhenrich(a)vmware.com> wrote: >>>>> Stef, >>>>> >>>>> I would say that trying to diverge from category-based packaging for MC1 would pretty much be a disaster. the big problem is not what happens within Pharo (which is a tough enough problem to solve), but what happens to other folks (Squeak or GemStone or even VW in this case) trying to use mcz files created in Pharo that no longer align with the class and method categories? It will not be pretty. >>>>> >>>>> On the other hand, MC2 has been designed from the beginning to allow for alternate package definition schemes ... category-based packaging has always been a hack.... >>>>> >>>>> Perhaps this is time to start a push towards MC2 and perhaps RPackage-based packaging could become part of MC2 or at least one of the packaging schemes ... >>>>> >>>>> For transition, MC1 would continue to use category-based packages and those projects that wanted to preserve MC1 compatibility would simply continue to name the categories to make MC1 happy and use RPackage for MC2 packages with a different rule set ... >>>>> >>>>> One of the problems with MC2 has been the lack of a compelling reason to make the transition to a new system ... RPackage and the associated tools could be the compelling reason to move to MC2... >>>>> >>>>> Dale >>>>> >>>>> On Mar 18, 2011, at 1:56 PM, StÃ©phane Ducasse wrote: >>>>> >>>>>> Hi guys >>>>>> >>>>>> we need to think about package: >>>>>> >>>>>> right now we have a new implementation that is fast, robust and supports well a new generation of tools (glamour, nautilus...). >>>>>> We are capturing all system events and we would be more or less ready to remove systemNotifier and use Announcement >>>>>> instead. >>>>>> RPackage can live also on the side of PackageInfo for a while but it would be better to have the shortest possible period of co-existence. >>>>>> >>>>>> Now one of the problem I see is that we may not have a smooth transition because: >>>>>> - Rpackage does not rely on category tagging matching. >>>>>> - It is simpler to have a mapping from current categories to packages >>>>>> - Now it means that we could load a package in the system and it would be turned into several RPackages >>>>>> so this means that configuration would have to be adapted. >>>>>> >>>>>> - marcus was suggesting me to create a package with the same contents as the one of loaded by MC. >>>>>> and to have tags to only represent categories. >>>>>> >>>>>> Now my time is short so I will >>>>>> - probably not implement tags >>>>>> - check again the implementation of RPackage and in particular the necessary compatibility layer, because I saw some strange >>>>>> code. >>>>>> - check the MC dependency on method category conventions, because some logic is not defined in the right place >>>>>> like overrides in the MC tools and not in the PackageInfo >>>>>> - check how a package gets created when loaded: the key question is that there is a problem to rely on categories to >>>>>> associate classes to packages because we can end up with overlapping (normally the IDE captures the category renames >>>>>> and change the packages accordingly). >>>>>> - we should not rely on most-specific-category kind of pattern matching. >>>>>> >>>>>> So if you have suggestion please talk now. >>>>>> >>>>>> >>>>>> Stef >>>>> >>>>> >>>>> >>>> >>>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "When people care, great things can happen." >>> >>> >>> >>> >> >> > > -- > www.tudorgirba.com > > "Every now and then stop and ask yourself if the war you're fighting is the right one." > > > >

March 20, 2011

[Pharo-project] Issue 3836 in pharo: superfluous packageInfo respondsTo: #overriddenMethods

by pharo＠googlecode.com

Status: FixProposed Owner: stephane...(a)gmail.com Labels: Milestone-1.3 New issue 3836 by stephane...(a)gmail.com: superfluous packageInfo respondsTo: #overriddenMethods http://code.google.com/p/pharo/issues/detail?id=3836 MCPackage>>snapshot | packageInfo definitions categories | packageInfo := self packageInfo. definitions := OrderedCollection new. categories := packageInfo systemCategories. categories isEmpty ifFalse: [ definitions add: (MCOrganizationDefinition categories: categories) ]. packageInfo methods do: [:ea | definitions add: ea asMethodDefinition] displayingProgress: 'Snapshotting methods...'. (packageInfo respondsTo: #overriddenMethods) ifTrue: [packageInfo overriddenMethods do: [:ea | definitions add: (packageInfo changeRecordForOverriddenMethod: ea) asMethodDefinition] displayingProgress: 'Searching for overrides...']. packageInfo classes do: [:ea | definitions addAll: ea classDefinitions] displayingProgress: 'Snapshotting classes...'. (packageInfo respondsTo: #hasPreamble) ifTrue: [ packageInfo hasPreamble ifTrue: [definitions add: (MCPreambleDefinition from: packageInfo)]. packageInfo hasPostscript ifTrue: [definitions add: (MCPostscriptDefinition from: packageInfo)]. packageInfo hasPreambleOfRemoval ifTrue: [definitions add: (MCRemovalPreambleDefinition from: packageInfo)]. packageInfo hasPostscriptOfRemoval ifTrue: [definitions add: (MCRemovalPostscriptDefinition from: packageInfo)]]. ^ MCSnapshot fromDefinitions: definitions MCPackage>>snapshot | packageInfo definitions categories | packageInfo := self packageInfo. definitions := OrderedCollection new. categories := packageInfo systemCategories. categories isEmpty ifFalse: [ definitions add: (MCOrganizationDefinition categories: categories) ]. packageInfo methods do: [:ea | definitions add: ea asMethodDefinition] displayingProgress: 'Snapshotting methods...'. packageInfo overriddenMethods do: [:ea | definitions add: (packageInfo changeRecordForOverriddenMethod: ea) asMethodDefinition] displayingProgress: 'Searching for overrides...'. packageInfo classes do: [:ea | definitions addAll: ea classDefinitions] displayingProgress: 'Snapshotting classes...'. (packageInfo respondsTo: #hasPreamble) ifTrue: [ packageInfo hasPreamble ifTrue: [definitions add: (MCPreambleDefinition from: packageInfo)]. packageInfo hasPostscript ifTrue: [definitions add: (MCPostscriptDefinition from: packageInfo)]. packageInfo hasPreambleOfRemoval ifTrue: [definitions add: (MCRemovalPreambleDefinition from: packageInfo)]. packageInfo hasPostscriptOfRemoval ifTrue: [definitions add: (MCRemovalPostscriptDefinition from: packageInfo)]]. ^ MCSnapshot fromDefinitions: definitions

March 20, 2011

Re: [Pharo-project] Refactoring Browser Enhancements

by Lukas Renggli

Yes, I looked at it and I gave detailed feedback in my previous mails. No, I won't include it for the reasons given in my previous mails. Your changes subtly break assumptions made by any user of BrowserEnvironment (in addition to unnecessarily changing the API), but I am not going to repeat that and how to solve it differently a fourth time :-( Lukas On 20 March 2011 09:43, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > So lukas > Â Â Â Â - did you check what we did? > Â Â Â Â - will you include in rb packages? > I need to know. > > Stef > > On Mar 19, 2011, at 7:55 AM, StÃ©phane Ducasse wrote: > >> Let us be more productive :) >> >> A BrowserEnvironment >> Â Â Â has an environment input= a systemDictionary (may be we should call it origin) >> Â Â Â a selectedEnviroment = a composite based on the BrowserEnvironment hierarchy >> >> The precondition is that it does not make sense to mix apple and orange so >> selectedEnvironment inside a composite to be meaningfull should sahre the same origin. >> >> Now it does not mean that we cannot have different composite over the same origin (ie we have >> multiple queries over Smalltalk globals) or that we cannot have different and separate composite >> working on different origin (ie I have a selection on Pharo1.2 and one on Pharo1.3 or a remote one). >> >> >> On Mar 18, 2011, at 10:09 PM, Lukas Renggli wrote: >> >>> - BrowserEnvironment>>#copyEmpty >> >> copyEmpty >> Â Â Â ^ self class new on: SystemDictionary new; yourself. >> >>> - BrowserEnvironment>>#& >> >> & anEnvironment >> Â Â Â "If we or anEnvironment includes everything, then just include the other environment (optimization)" >> >> Â Â Â self isSystem ifTrue: [^anEnvironment]. >> Â Â Â anEnvironment isSystem ifTrue: [^self]. >> Â Â Â ^AndEnvironment onEnvironment: self and: anEnvironment >> >> does not change >> >> >>> - BrowserEnvironment>>#I >> >> | anEnvironment >> Â Â Â "If we or anEnvironment includes everything, then return it instead of creating >> Â Â Â an or that will include everything." >> >> Â Â Â self isSystem ifTrue: [^self]. >> Â Â Â anEnvironment isSystem ifTrue: [^anEnvironment]. >> Â Â Â ^ OrEnvironment onEnvironment: self or: anEnvironment >> >>> - BrowserEnvironment>>#not >> not >> Â Â Â self isSystem ifTrue: [^SelectorEnvironment new]. >> Â Â Â ^NotEnvironment onEnvironment: self >> >> >> >>> - BrowserEnvironment>>#isSystem >> isSystem >> Â Â Â ^true >> >> No problem (this could be renamed isOriginalInput but we keep it for compatibiity >> >>> - ClassEnvironment>>#classesDo: >> >> classesDo: aBlock >> Â Â Â classes do: [ :each | >> Â Â Â Â Â Â Â | class | >> Â Â Â Â Â Â Â class := Smalltalk globals at: each ifAbsent: [ nil ]. >> Â Â Â Â Â Â Â (class notNil and: [ environment includesClass: class ]) >> Â Â Â Â Â Â Â Â Â Â Â ifTrue: [ aBlock value: class ] ]. >> Â Â Â metaClasses do: [ :each | >> Â Â Â Â Â Â Â | class | >> Â Â Â Â Â Â Â class := Smalltalk globals at: each ifAbsent: [ nil ]. >> Â Â Â Â Â Â Â (class notNil and: [ environment includesClass: class class ]) >> Â Â Â Â Â Â Â Â Â Â Â ifTrue: [ aBlock value: class class ] ] >> We already fixed it. >> >> classesDo: aBlock >> Â Â Â classes do: [ :each | >> Â Â Â Â Â Â Â | class | >> Â Â Â Â Â Â Â class := self environment at: each ifAbsent: [ nil ]. >> Â Â Â Â Â Â Â (class notNil and: [ selectedEnvironment includesClass: class ]) >> Â Â Â Â Â Â Â Â Â Â Â ifTrue: [ aBlock value: class ] ]. >> Â Â Â metaClasses do: [ :each | >> Â Â Â Â Â Â Â | class | >> Â Â Â Â Â Â Â class := self environment at: each ifAbsent: [ nil ]. >> Â Â Â Â Â Â Â (class notNil and: [ selectedEnvironment includesClass: class class ]) >> Â Â Â Â Â Â Â Â Â Â Â ifTrue: [ aBlock value: class class ] ] >> >>> - SelectorEnvironment>>#classesDo: >> >> classesDo: aBlock >> Â Â Â classSelectors keysDo: [ :each | >> Â Â Â Â Â Â Â | class | >> Â Â Â Â Â Â Â class := Smalltalk globals at: each ifAbsent: [ nil ]. >> Â Â Â Â Â Â Â (class notNil and: [ environment includesClass: class ]) >> Â Â Â Â Â Â Â Â Â Â Â ifTrue: [ aBlock value: class ] ]. >> Â Â Â metaClassSelectors keysDo: [ :each | >> Â Â Â Â Â Â Â | class | >> Â Â Â Â Â Â Â class := Smalltalk globals at: each ifAbsent: [ nil ]. >> Â Â Â Â Â Â Â (class notNil and: [ environment includesClass: class class ]) >> Â Â Â Â Â Â Â Â Â Â Â ifTrue: [ aBlock value: class class ] ] >> >> again we already fixed it. >> >> classesDo: aBlock >> Â Â Â classes do: [ :each | >> Â Â Â Â Â Â Â | class | >> Â Â Â Â Â Â Â class := self environment at: each ifAbsent: [ nil ]. >> Â Â Â Â Â Â Â (class notNil and: [ selectedEnvironment includesClass: class ]) >> Â Â Â Â Â Â Â Â Â Â Â ifTrue: [ aBlock value: class ] ]. >> Â Â Â metaClasses do: [ :each | >> Â Â Â Â Â Â Â | class | >> Â Â Â Â Â Â Â class := self environment at: each ifAbsent: [ nil ]. >> Â Â Â Â Â Â Â (class notNil and: [ selectedEnvironment includesClass: class class ]) >> Â Â Â Â Â Â Â Â Â Â Â ifTrue: [ aBlock value: class class ] ] >> >> >> So does it make sense? >> I think so. >> We just have a common input for a given composite. >> >> Stef > > > -- Lukas Renggli www.lukas-renggli.ch

March 20, 2011

Re: [Pharo-project] need your attention: Package

by Tudor Girba

On 20 Mar 2011, at 09:18, StÃ©phane Ducasse wrote: > > On Mar 19, 2011, at 10:55 PM, Tudor Girba wrote: > >> Hi Stef, >> >> Thanks a lot for all this effort. >> >> I will reiterate again the original idea, which I still believe would work best. >> >> RPackage is meant to become the organization entity in the image. MCPackage will still be needed for versioning. Furthermore, for a while, categories will still remain in the system for a while as an implementation detail. RPackages mirror each category. >> >> The first step would be to keep loading from Monticello exactly like it is now: it will create Categories, and this will mirror in RPackages. > > this sentence is not clear doru. > Do you mean that a RPackage should contain classes that are contained in matching PackageInfo package? > I mean > RFoo > contains RFoo and RFoo-zork categories classes? No. I meant we have a 1-1 mapping to categories. So, you will get multiple RPackages in the system: RFoo, RFoo-zork ... >> The next step is to provide a tool that provides only a 1-1 mapping between MC and RPackages that we can use for publishing. > > The problem is not publishing the problem is assigning classes to packages. I think that if we split loading and publishing logic as a transition phase it would solve the problem, and I actually believe that you are talking about a similar thing (see below). >> In this way, we would be able to: >> - load existing MC without problems >> - publish new MCPackages that will be compatible with other dialects > > let us see > imagine the following scenaro > > PI-Foo contains > Foo > Foo-Zork > > => > We get > RFoo > and RFoo-Zork > > we can save and people can load > now > > I add a category Foo-Two > in pharo I get an extra package > we should modify metacelloConfig > ok people can load it too > > in other system it will be in Foo > ok we can load it > > > Now if we should preserve the current loading semantics **package creation** > > when PI-Foo contains > Foo > Foo-Zork > > if we should create only one RFoo containing all the FooCat > then we arrive to the point where this is not clear that > when I add a new cat it will not be in. The solution I proposed was a new publishing interface for MC that works with the 1-1 mapping between RPackage and PackageInfo. Like this, for saving we would be force to save the new package. So, in your case, when you would open the NewMC, you would see in the list: Foo Foo-Zork Foo-Cat* The +Package button would disappear altogether. You would be provided with the possible things to commit, and then you would not have to think about the mapping at all. All you have to do is select each of the RPackages that you want to commit, and if there does not exist a correspondent Monticello package for it, you would be asked to provide the repo and then the creation would happen transparently. > So we could always load and create a RPackage for each Category. This would be simpler. In your solution, you would again split the mapping logic of load from that of publishing but you would change the loading mapping such that when you load you create only one category per PI. Perhaps that is indeed simpler, but you would lose the extra info of categories. Were my explanations clearer now? Cheers, Doru > >> Indeed, Metacello configurations will need modifications, but we have a smooth path to it. The Metacello configurations are still typically used only for loading and that will still continue to work just like they do now. With the Metacello Browser things will change, but then again we can change that tool, too. >> >> The only problem is how to define class extensions. I believe the * magic mapping is in MC. That will create problems, but for a while, I think we can still rely on this mapping. > > yes > >> >> Cheers, >> Doru >> >> >> >> On 19 Mar 2011, at 22:20, StÃ©phane Ducasse wrote: >> >>> >>> On Mar 19, 2011, at 7:17 PM, Guillermo Polito wrote: >>> >>>> BTW, for smooth transition, why not just replace usages of PackageInfo by RPackage keeping everything working as today? And after that, we can improve the way we use it. >>>> >>>> In two words, why not replace only infrastructure instead of infrastructure and behavior at the same time? Doing both together is kind of complex and easy to make mistakes... >>> >>> yes this is what cyrille started to do. On top of RPackage so may be cleaning that is the way to go. >>> but the matching semantics is not good. >>> >>>> But maybe it's easier (or nicer) to replace everything together... :P >>>> >>>> Guille >>>> >>>> On Sat, Mar 19, 2011 at 1:35 PM, Dale Henrichs <dhenrich(a)vmware.com> wrote: >>>> Stef, >>>> >>>> I would say that trying to diverge from category-based packaging for MC1 would pretty much be a disaster. the big problem is not what happens within Pharo (which is a tough enough problem to solve), but what happens to other folks (Squeak or GemStone or even VW in this case) trying to use mcz files created in Pharo that no longer align with the class and method categories? It will not be pretty. >>>> >>>> On the other hand, MC2 has been designed from the beginning to allow for alternate package definition schemes ... category-based packaging has always been a hack.... >>>> >>>> Perhaps this is time to start a push towards MC2 and perhaps RPackage-based packaging could become part of MC2 or at least one of the packaging schemes ... >>>> >>>> For transition, MC1 would continue to use category-based packages and those projects that wanted to preserve MC1 compatibility would simply continue to name the categories to make MC1 happy and use RPackage for MC2 packages with a different rule set ... >>>> >>>> One of the problems with MC2 has been the lack of a compelling reason to make the transition to a new system ... RPackage and the associated tools could be the compelling reason to move to MC2... >>>> >>>> Dale >>>> >>>> On Mar 18, 2011, at 1:56 PM, StÃ©phane Ducasse wrote: >>>> >>>>> Hi guys >>>>> >>>>> we need to think about package: >>>>> >>>>> right now we have a new implementation that is fast, robust and supports well a new generation of tools (glamour, nautilus...). >>>>> We are capturing all system events and we would be more or less ready to remove systemNotifier and use Announcement >>>>> instead. >>>>> RPackage can live also on the side of PackageInfo for a while but it would be better to have the shortest possible period of co-existence. >>>>> >>>>> Now one of the problem I see is that we may not have a smooth transition because: >>>>> - Rpackage does not rely on category tagging matching. >>>>> - It is simpler to have a mapping from current categories to packages >>>>> - Now it means that we could load a package in the system and it would be turned into several RPackages >>>>> so this means that configuration would have to be adapted. >>>>> >>>>> - marcus was suggesting me to create a package with the same contents as the one of loaded by MC. >>>>> and to have tags to only represent categories. >>>>> >>>>> Now my time is short so I will >>>>> - probably not implement tags >>>>> - check again the implementation of RPackage and in particular the necessary compatibility layer, because I saw some strange >>>>> code. >>>>> - check the MC dependency on method category conventions, because some logic is not defined in the right place >>>>> like overrides in the MC tools and not in the PackageInfo >>>>> - check how a package gets created when loaded: the key question is that there is a problem to rely on categories to >>>>> associate classes to packages because we can end up with overlapping (normally the IDE captures the category renames >>>>> and change the packages accordingly). >>>>> - we should not rely on most-specific-category kind of pattern matching. >>>>> >>>>> So if you have suggestion please talk now. >>>>> >>>>> >>>>> Stef >>>> >>>> >>>> >>> >>> >> >> -- >> www.tudorgirba.com >> >> "When people care, great things can happen." >> >> >> >> > > -- www.tudorgirba.com "Every now and then stop and ask yourself if the war you're fighting is the right one."

March 20, 2011

Re: [Pharo-project] allOverriddenMethods is confusing

by StÃ©phane Ducasse

So allOverriddenMethods returns all the methods of the complete system and it may be correct but strange to have it on the instance side. Now my hypothesis is that > overriddenMethodsDo: aBlock "Enumerates the methods the receiver contains which have been overridden by other packages" ^ self allOverriddenMethodsDo: [:ea | (self isOverrideOfYourMethod: ea) ifTrue: [aBlock value: ea]] check the complete system for every package snapshot and since we have a lot of override because of polymorph we pay the price. I will fold the overrides first and try to understand mc Stef

March 20, 2011

Re: [Pharo-project] Refactoring Browser Enhancements

by StÃ©phane Ducasse

So lukas - did you check what we did? - will you include in rb packages? I need to know. Stef On Mar 19, 2011, at 7:55 AM, StÃ©phane Ducasse wrote: > Let us be more productive :) > > A BrowserEnvironment > has an environment input= a systemDictionary (may be we should call it origin) > a selectedEnviroment = a composite based on the BrowserEnvironment hierarchy > > The precondition is that it does not make sense to mix apple and orange so > selectedEnvironment inside a composite to be meaningfull should sahre the same origin. > > Now it does not mean that we cannot have different composite over the same origin (ie we have > multiple queries over Smalltalk globals) or that we cannot have different and separate composite > working on different origin (ie I have a selection on Pharo1.2 and one on Pharo1.3 or a remote one). > > > On Mar 18, 2011, at 10:09 PM, Lukas Renggli wrote: > >> - BrowserEnvironment>>#copyEmpty > > copyEmpty > ^ self class new on: SystemDictionary new; yourself. > >> - BrowserEnvironment>>#& > > & anEnvironment > "If we or anEnvironment includes everything, then just include the other environment (optimization)" > > self isSystem ifTrue: [^anEnvironment]. > anEnvironment isSystem ifTrue: [^self]. > ^AndEnvironment onEnvironment: self and: anEnvironment > > does not change > > >> - BrowserEnvironment>>#I > > | anEnvironment > "If we or anEnvironment includes everything, then return it instead of creating > an or that will include everything." > > self isSystem ifTrue: [^self]. > anEnvironment isSystem ifTrue: [^anEnvironment]. > ^ OrEnvironment onEnvironment: self or: anEnvironment > >> - BrowserEnvironment>>#not > not > self isSystem ifTrue: [^SelectorEnvironment new]. > ^NotEnvironment onEnvironment: self > > > >> - BrowserEnvironment>>#isSystem > isSystem > ^true > > No problem (this could be renamed isOriginalInput but we keep it for compatibiity > >> - ClassEnvironment>>#classesDo: > > classesDo: aBlock > classes do: [ :each | > | class | > class := Smalltalk globals at: each ifAbsent: [ nil ]. > (class notNil and: [ environment includesClass: class ]) > ifTrue: [ aBlock value: class ] ]. > metaClasses do: [ :each | > | class | > class := Smalltalk globals at: each ifAbsent: [ nil ]. > (class notNil and: [ environment includesClass: class class ]) > ifTrue: [ aBlock value: class class ] ] > We already fixed it. > > classesDo: aBlock > classes do: [ :each | > | class | > class := self environment at: each ifAbsent: [ nil ]. > (class notNil and: [ selectedEnvironment includesClass: class ]) > ifTrue: [ aBlock value: class ] ]. > metaClasses do: [ :each | > | class | > class := self environment at: each ifAbsent: [ nil ]. > (class notNil and: [ selectedEnvironment includesClass: class class ]) > ifTrue: [ aBlock value: class class ] ] > >> - SelectorEnvironment>>#classesDo: > > classesDo: aBlock > classSelectors keysDo: [ :each | > | class | > class := Smalltalk globals at: each ifAbsent: [ nil ]. > (class notNil and: [ environment includesClass: class ]) > ifTrue: [ aBlock value: class ] ]. > metaClassSelectors keysDo: [ :each | > | class | > class := Smalltalk globals at: each ifAbsent: [ nil ]. > (class notNil and: [ environment includesClass: class class ]) > ifTrue: [ aBlock value: class class ] ] > > again we already fixed it. > > classesDo: aBlock > classes do: [ :each | > | class | > class := self environment at: each ifAbsent: [ nil ]. > (class notNil and: [ selectedEnvironment includesClass: class ]) > ifTrue: [ aBlock value: class ] ]. > metaClasses do: [ :each | > | class | > class := self environment at: each ifAbsent: [ nil ]. > (class notNil and: [ selectedEnvironment includesClass: class class ]) > ifTrue: [ aBlock value: class class ] ] > > > So does it make sense? > I think so. > We just have a common input for a given composite. > > Stef

March 20, 2011