August 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] About the migration from PackageInfo to RPackage

by StÃ©phane Ducasse

On Aug 5, 2012, at 2:27 PM, Guillermo Polito wrote: > What Mariano means is that you can have MCPackage(X) containing categories X-A, X-B, X-C. When that package is loaded today, three RPackages are created: X-A, X-B, X-C. So RPackages are more mapped from categories that from MCPackages. we decided that it will be one package with classes having corresponding tags. But we should do it. Again nothing should be mapped from MCPackages (MCPackages should not be used it is an internal class of MC). > > PackageInfo has a large APi that is often not used. > > So I would suggest that we reduce the PackageInfo API first because it will lower the stress on RPackage to be offer a > > compatible interface. > > All the methods in the compatibility should somehow disappear or only serve as purpose to help temporary > > backwards compat. > > > > > > I agree. But if you want to remove in the future PackageInfo, then RPackage HAS to provide a way to get the classes/extension methods of a MCPackage. That's why I need #allDefinedClasses and #allDefinedExtensionMethods > > Mariano if RPackage represents a MCPackage then RPackage offers all the correct queries to get the classes extended, method extensions and so > let me know if you do not see it because I payed extreme attention to that. > > RPackage>>defineMethodsForClass: > definedSelectorForClass: > extendedClassames > extendedClasses > extensionMethods > extensionMethodsForClass: > extensionSelectors > extensionSelectorsForClass: > methodsForClass: > selectorsForClass: > > Let me repeat it. We do not need the compatibility layer. > Now it may be that (since rpackage was pushed fast in the image) that the importer from PackageInfo to Rpackage did not cover all the cases > but this is clearly another issue. > > Stef > > > > > > > > > > > > > What do you think? > > > > Stef > > > > > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > >

Aug. 5, 2012

Re: [Pharo-project] About the migration from PackageInfo to RPackage

by StÃ©phane Ducasse

I do not get why do you use MCPackage There is ring for that and MCPackage one day will disappear. MCPAckage is just an internal abstraction of Monticello to represent a bunch a classes. You confused me. Fuel should be concerned about RPackage not MCPackage. MC should deal and build its MCPackage based on RPackage (now it is using PackageInfo) Fuel should not be based on Monticello abstractions. Stef > > > And do what? > you said in the issue tracker: "I believe that for tanker you should specify the exact package names..." > > Well, of course, I can do it myself (in my own code) but if every person that needs to map MCPackages to RPackage does it in their own.... > > I don't care if you provide #allDefinedClasses and #allDefinedExtensionMethods. What I think is a must if you want to remove PackageInfo is to provide a map between MCPackage and RPackage. I other words, say I have the MCPackage 'Fuel', how do I get the list of classes and extension methods? > > > > > > > What do you think? > > Stef > > > > -- > Mariano > http://marianopeck.wordpress.com > > > > > > -- > Mariano > http://marianopeck.wordpress.com >

Aug. 5, 2012

Re: [Pharo-project] About the migration from PackageInfo to RPackage

by StÃ©phane Ducasse

> Hi Stef, > > what would be the suggested API then ? All RPackage methods without the compatibility layer. > And in announcements, would that change the returned type of some events (MCWorkingCopyCreated / MCWorkingCopyDeleted) ? > > For Alt-Browser to navigate through the packages, I use MCWorkingCopy and PackageInfo. Is this the way it should be done ? Should I use RPackage instead ? yes. We will remove PackageInfo. The first step will be to keep inside PackageInfo only the methods used. Then make sure that we can have the same behavior with RPackage. MCWorkingCopy is just the repository for MC world. > Thierry > ________________________________________ > De : pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] de la part de StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] > Date d'envoi : dimanche 5 aoÃ»t 2012 13:28 > Ã : Pharo-project(a)lists.gforge.inria.fr Development > Objet : [Pharo-project] About the migration from PackageInfo to RPackage > > Hi guys > > PackageInfo has a large APi that is often not used. > So I would suggest that we reduce the PackageInfo API first because it will lower the stress on RPackage to be offer a > compatible interface. > All the methods in the compatibility should somehow disappear or only serve as purpose to help temporary > backwards compat. > > What do you think? > > Stef >

Aug. 5, 2012

Re: [Pharo-project] About the migration from PackageInfo to RPackage

by Guillermo Polito

What Mariano means is that you can have MCPackage(X) containing categories X-A, X-B, X-C. When that package is loaded today, three RPackages are created: X-A, X-B, X-C. So RPackages are more mapped from categories that from MCPackages. On Sun, Aug 5, 2012 at 2:24 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > > > > On Sun, Aug 5, 2012 at 1:28 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > > Hi guys > > > > PackageInfo has a large APi that is often not used. > > So I would suggest that we reduce the PackageInfo API first because it > will lower the stress on RPackage to be offer a > > compatible interface. > > All the methods in the compatibility should somehow disappear or only > serve as purpose to help temporary > > backwards compat. > > > > > > I agree. But if you want to remove in the future PackageInfo, then > RPackage HAS to provide a way to get the classes/extension methods of a > MCPackage. That's why I need #allDefinedClasses and > #allDefinedExtensionMethods > > Mariano if RPackage represents a MCPackage then RPackage offers all the > correct queries to get the classes extended, method extensions and so > let me know if you do not see it because I payed extreme attention to that. > > RPackage>>defineMethodsForClass: > definedSelectorForClass: > extendedClassames > extendedClasses > extensionMethods > extensionMethodsForClass: > extensionSelectors > extensionSelectorsForClass: > methodsForClass: > selectorsForClass: > > Let me repeat it. We do not need the compatibility layer. > Now it may be that (since rpackage was pushed fast in the image) that the > importer from PackageInfo to Rpackage did not cover all the cases > but this is clearly another issue. > > Stef > > > > > > > > > > > > > What do you think? > > > > Stef > > > > > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > >

Aug. 5, 2012

Re: [Pharo-project] About the migration from PackageInfo to RPackage

by StÃ©phane Ducasse

> > On Sun, Aug 5, 2012 at 1:28 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi guys > > PackageInfo has a large APi that is often not used. > So I would suggest that we reduce the PackageInfo API first because it will lower the stress on RPackage to be offer a > compatible interface. > All the methods in the compatibility should somehow disappear or only serve as purpose to help temporary > backwards compat. > > > I agree. But if you want to remove in the future PackageInfo, then RPackage HAS to provide a way to get the classes/extension methods of a MCPackage. That's why I need #allDefinedClasses and #allDefinedExtensionMethods Mariano if RPackage represents a MCPackage then RPackage offers all the correct queries to get the classes extended, method extensions and so let me know if you do not see it because I payed extreme attention to that. RPackage>>defineMethodsForClass: definedSelectorForClass: extendedClassames extendedClasses extensionMethods extensionMethodsForClass: extensionSelectors extensionSelectorsForClass: methodsForClass: selectorsForClass: Let me repeat it. We do not need the compatibility layer. Now it may be that (since rpackage was pushed fast in the image) that the importer from PackageInfo to Rpackage did not cover all the cases but this is clearly another issue. Stef > > > > > > What do you think? > > Stef > > > > -- > Mariano > http://marianopeck.wordpress.com >

Aug. 5, 2012

Re: [Pharo-project] About the migration from PackageInfo to RPackage

by Mariano Martinez Peck

On Sun, Aug 5, 2012 at 1:48 PM, Guillermo Polito <guillermopolito(a)gmail.com>wrote: > > On Sun, Aug 5, 2012 at 1:41 PM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> >> >> On Sun, Aug 5, 2012 at 1:28 PM, StÃ©phane Ducasse < >> stephane.ducasse(a)inria.fr> wrote: >> >>> Hi guys >>> >>> PackageInfo has a large APi that is often not used. >>> So I would suggest that we reduce the PackageInfo API first because it >>> will lower the stress on RPackage to be offer a >>> compatible interface. >>> All the methods in the compatibility should somehow disappear or only >>> serve as purpose to help temporary >>> backwards compat. >>> >>> >> I agree. But if you want to remove in the future PackageInfo, then >> RPackage HAS to provide a way to get the classes/extension methods of a >> MCPackage. That's why I need #allDefinedClasses and >> #allDefinedExtensionMethods >> >> > Unless we attack MCPackage at the same time > > And do what? you said in the issue tracker: "I believe that for tanker you should specify the exact package names..." Well, of course, I can do it myself (in my own code) but if every person that needs to map MCPackages to RPackage does it in their own.... I don't care if you provide #allDefinedClasses and #allDefinedExtensionMethods. What I think is a must if you want to remove PackageInfo is to provide a map between MCPackage and RPackage. I other words, say I have the MCPackage 'Fuel', how do I get the list of classes and extension methods? > >> >> >> >> >>> What do you think? >>> >>> Stef >>> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> > -- Mariano http://marianopeck.wordpress.com

Aug. 5, 2012

Re: [Pharo-project] [ENH]: FileReference subclasses

by Guillermo Polito

On Sat, Aug 4, 2012 at 9:56 PM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > Thoughts? Comments? Opinions? > Hmm, I do not like the idea of having subclasses of references for different kind of files... I believe that things like fileIn for example, or extract zip should be external to the file library... > Issue 6525: [ENH]: FileReference subclasses > http://code.google.com/p/pharo/issues/detail?id=6525 > > Different types of files have different behaviors. Currently, we need to > add > all those behaviors (e.g. #fileIn) to FileReference, even though they only > make sense with a fraction of instances. > > I propose that we match the filename against FileReference subclasses. The > following is a conversation starter. It works with strings... > > Usage: > '/Users/sean/start.st' asFileReference. "anStFileReference" > '/Users/sean/start.unknown' asFileReference. "aFileReference" > 'file:///Users/me.st' asUrl asFileReference "not handled by current > implementation, will default to aFileReference" > > For example, I can create a custom .st file subclass, with: > StFileReference>>isClassFor: aResolvable > (aResolvable isKindOf: String) ifFalse: [ ^ false ]. "just a hack > to avoid > DNU" > ^ aResolvable endsWith: '.st'. > > Enhancing the following method will catch aString asFileReference, but not > e.g. aFileUrl asFileReference: > FileSystem>>referenceTo: aResolvable > "Answer a reference to the argument from the context of the > receiver > filesystem. > Example: FSFilesystem disk referenceTo: 'plonk.taz'" > > | referenceClass | > referenceClass := FileReference allSubclasses > detect: [ :e | e isClassFor: aResolvable ] > ifNone: [ FileReference ]. > > ^ referenceClass > fileSystem: self > path: (self pathFromObject: aResolvable). > > > > -- > View this message in context: > http://forum.world.st/ENH-FileReference-subclasses-tp4643116.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >

Aug. 5, 2012

Re: [Pharo-project] About the migration from PackageInfo to RPackage

by Guillermo Polito

On Sun, Aug 5, 2012 at 1:41 PM, Mariano Martinez Peck <marianopeck(a)gmail.com > wrote: > > > On Sun, Aug 5, 2012 at 1:28 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > >> Hi guys >> >> PackageInfo has a large APi that is often not used. >> So I would suggest that we reduce the PackageInfo API first because it >> will lower the stress on RPackage to be offer a >> compatible interface. >> All the methods in the compatibility should somehow disappear or only >> serve as purpose to help temporary >> backwards compat. >> >> > I agree. But if you want to remove in the future PackageInfo, then > RPackage HAS to provide a way to get the classes/extension methods of a > MCPackage. That's why I need #allDefinedClasses and > #allDefinedExtensionMethods > > Unless we attack MCPackage at the same time > > > > > >> What do you think? >> >> Stef >> > > > > -- > Mariano > http://marianopeck.wordpress.com > >

Aug. 5, 2012

[Pharo-project] RE : About the migration from PackageInfo to RPackage

by GOUBIER Thierry

Hi Stef, what would be the suggested API then ? And in announcements, would that change the returned type of some events (MCWorkingCopyCreated / MCWorkingCopyDeleted) ? For Alt-Browser to navigate through the packages, I use MCWorkingCopy and PackageInfo. Is this the way it should be done ? Should I use RPackage instead ? Thierry ________________________________________ De : pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] de la part de StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] Date d'envoi : dimanche 5 aoÃ»t 2012 13:28 Ã : Pharo-project(a)lists.gforge.inria.fr Development Objet : [Pharo-project] About the migration from PackageInfo to RPackage Hi guys PackageInfo has a large APi that is often not used. So I would suggest that we reduce the PackageInfo API first because it will lower the stress on RPackage to be offer a compatible interface. All the methods in the compatibility should somehow disappear or only serve as purpose to help temporary backwards compat. What do you think? Stef

Aug. 5, 2012

Re: [Pharo-project] RPackage does not update extension methods to removed classes

by Guillermo Polito

http://code.google.com/p/pharo/issues/detail?id=6526 here you are :) On Sun, Aug 5, 2012 at 1:39 PM, Mariano Martinez Peck <marianopeck(a)gmail.com > wrote: > > > On Sun, Aug 5, 2012 at 1:07 PM, Guillermo Polito < > guillermopolito(a)gmail.com> wrote: > >> >> >> On Sat, Aug 4, 2012 at 2:41 PM, Mariano Martinez Peck < >> marianopeck(a)gmail.com> wrote: >> >>> >>> >>> On Sat, Aug 4, 2012 at 2:34 PM, Mariano Martinez Peck < >>> marianopeck(a)gmail.com> wrote: >>> >>>> Hi Stef. I notice that RPackage does not update the extension methods >>>> of removed classes. It is easy to reproduce in Pharo 2.0 by doing: >>>> >>>> (RPackageOrganizer default packageNamed: 'FreeType') >>>> allDefinedExtensionMethods (this fails because FreeType used to have a >>>> extension method in TTCFont which was removed) >>>> >>>> Or step by step: >>>> >>>> 1) Create package PackageX. >>>> 2) Create package PackageY and ClassY. >>>> 3) Create in ClassY a extension method with category *PackageX. If you >>>> now browse the instVar "classExtensionSelectors" of PackageX you will see >>>> ClassY. >>>> 4) Remove ClassY >>>> 5) notice that 'classExtensionSelectors' from PackageX still references >>>> ClassY. In fact, if you ask its extension methods you will have a >>>> KeyNotFound #ClassY in Smalltalk globals ;) >>>> >>>> So...I guess this is a bug. If true, I open an issue. >>>> >>>> >>> and to fix the already existing ones we can do: >>> >>> | extensions | >>> RPackage allInstances do: [:aPackage | >>> extensions := (aPackage instVarNamed: 'classExtensionSelectors'). >>> extensions keysDo: [:aClassName | >>> (Smalltalk globals includesKey: aClassName) ifFalse: [extensions >>> removeKey: aClassName]. >>> ]. >>> extensions := (aPackage instVarNamed: 'metaclassExtensionSelectors'). >>> extensions keysDo: [:aClassName | >>> (Smalltalk globals includesKey: aClassName) ifFalse: [extensions >>> removeKey: aClassName]. >>> ]. >>> ] >>> >>> >> Easier: >> >> 1) integrate http://code.google.com/p/pharo/issues/detail?id=6521 >> 2) RPackageOrganizer initialize. >> >> > > Indeed, I saw that later. That only helps to fix the existing ones but it > does not solve the problem. > > > >> >>> >>>> Cheers, >>>> >>>> -- >>>> Mariano >>>> http://marianopeck.wordpress.com >>>> >>>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >>> >> > > > -- > Mariano > http://marianopeck.wordpress.com > >

Aug. 5, 2012