- Pharo-dev - lists.pharo.org

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

by Sean P. DeNigris

Guillermo Polito wrote > > 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... > My motivation is to make the system live and direct. In the domain of files, an extension signifies a type. As a user, if I have a file type I'm not familiar with, I want to know what kinds of things I can do with it. This approach puts those behaviors in the object that I'm handed back, which represents the file in the Pharo world. I would expect that many of these will in fact simply forward the request to an object external to the file library, but the advantage is that they are reified in the object that the user already has in hand, so they don't have to go searching for that external object. -- View this message in context: http://forum.world.st/ENH-FileReference-subclasses-tp4643116p4643223.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Aug. 5, 2012

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

by Igor Stasenko

Will it make more sense to have direct conversion methods i.e.: someFileReference asSTFileReference specificBehavior. because detecting the file type on it's extension is too unreliable , IMO. On 4 August 2012 21:56, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Thoughts? Comments? Opinions? > > 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. > -- Best regards, Igor Stasenko.

Aug. 5, 2012

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

by StÃ©phane Ducasse

Nautilus displays too many packages :) We will have to fix that but ben is basically waiting for me to move on RPackage but I'm burnt on it. Stef On Aug 5, 2012, at 5:59 PM, GOUBIER Thierry wrote: > Well, what happened is that I renamed a package in Nautilus (from X-B to X-C, knowing there was already a X-A). It moved things from X-B to X-C, and created X as well. > > Now I erase X working copy on a regular basis (it's the Alt package you get when you load Alt-Browser), noticing today thanks to the discussion that RPackage was keeping a copy of Alt as well, so I unregistered it today. I hope I finally got rid of it ! > > 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 17:47 > Ã : Pharo-project(a)lists.gforge.inria.fr > Objet : Re: [Pharo-project] About the migration from PackageInfo to RPackage > > On Aug 5, 2012, at 2:54 PM, GOUBIER Thierry wrote: > >> Is this the reason why when I built my package tree in the AltBrowser, I get four packages (X, X-A, X-B, X-C) but X contains all the classes of X-A, X-B and X-C ? > > Which package classes? > because MC use a pattern matching based on category names and explicitly MCworking copy > > So if you declare an MC package we name X and X-A indeed you are in trouble. > The point with RPackage is to avoid the pattern matching approach of MC and to get rid of the scan of all categories. > >> Is this the reason why, in the current Alt-Browser packages, there is an auto-creation of an Alt package when you load it ? >> >> I also get confused by the relation between class categories and packages. Is there a plan to get rid of class categories ? > > yes > >> At the moment, if you create then unload a package, the system categories stay behind (Pharo 2.0). >> >> Thierry >> ________________________________________ > > >

Aug. 5, 2012

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

by GOUBIER Thierry

Well, what happened is that I renamed a package in Nautilus (from X-B to X-C, knowing there was already a X-A). It moved things from X-B to X-C, and created X as well. Now I erase X working copy on a regular basis (it's the Alt package you get when you load Alt-Browser), noticing today thanks to the discussion that RPackage was keeping a copy of Alt as well, so I unregistered it today. I hope I finally got rid of it ! 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 17:47 Ã : Pharo-project(a)lists.gforge.inria.fr Objet : Re: [Pharo-project] About the migration from PackageInfo to RPackage On Aug 5, 2012, at 2:54 PM, GOUBIER Thierry wrote: > Is this the reason why when I built my package tree in the AltBrowser, I get four packages (X, X-A, X-B, X-C) but X contains all the classes of X-A, X-B and X-C ? Which package classes? because MC use a pattern matching based on category names and explicitly MCworking copy So if you declare an MC package we name X and X-A indeed you are in trouble. The point with RPackage is to avoid the pattern matching approach of MC and to get rid of the scan of all categories. > Is this the reason why, in the current Alt-Browser packages, there is an auto-creation of an Alt package when you load it ? > > I also get confused by the relation between class categories and packages. Is there a plan to get rid of class categories ? yes > At the moment, if you create then unload a package, the system categories stay behind (Pharo 2.0). > > Thierry > ________________________________________

Aug. 5, 2012

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

by StÃ©phane Ducasse

Mariano I would suggest not to add the system Tanker but to develop it outside for now. Else we will have to change it all the time. Stef On Aug 5, 2012, at 3:18 PM, Mariano Martinez Peck wrote: > > > On Sun, Aug 5, 2012 at 2:33 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > 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). > > Ok, let me clarify something. First, let's decide where we discuss. Ok, here, not in the issue tracker. There you said: "You should not rely on MC layer for fuel.". First, it is not Fuel, it is Tanker. Second, the only think Tanker relies on is in a user-provided set of classes and extension methods. However, there is a separate package that helps using Tanker from RPackage or PackageInfo. Right now, if you have MCPackage X, and then categories X-A, X-B and X-C, then you have 3 RPackages. That's why I was talking about a "MCPackage mapping". If in the future, this is one RPackage then perfect. What I need to do is to have a RPackage for X where I ask classes and extension methods and it answers me also the included by its categories (X-A, X-B and X-C). To have that, is why I am using now #allDefinedClasses and #allDefinedExtensionMethods. > > > > > > > > > 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 > > > > > > > > > > > > > > > -- > Mariano > http://marianopeck.wordpress.com >

Aug. 5, 2012

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

by StÃ©phane Ducasse

On Aug 5, 2012, at 3:18 PM, Mariano Martinez Peck wrote: > > > On Sun, Aug 5, 2012 at 2:33 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > 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). > > Ok, let me clarify something. First, let's decide where we discuss. Ok, here, not in the issue tracker. There you said: "You should not rely on MC layer for fuel.". First, it is not Fuel, it is Tanker. Second, the only think Tanker relies on is in a user-provided set of classes and extension methods. However, there is a separate package that helps using Tanker from RPackage or PackageInfo. Right now, if you have MCPackage X, and then categories X-A, X-B and X-C, then you have 3 RPackages. That's why I was talking about a "MCPackage mapping". If in the future, this is one RPackage then perfect. What I need to do is to have a RPackage for X where I ask classes and extension methods and it answers me also the included by its categories (X-A, X-B and X-C). To have that, is why I am using now #allDefinedClasses and #allDefinedExtensionMethods. Mariano before RPackage fully works we cannot promise anything. So I suggest to test tanker only on package without X-A patterns then in addition making progress on that front: - helping for package-info tag import - do not use MCPackage - do not use the compatibility layer of RPackage Sorry but this is the only answer I have right now. First fixing the systemAnnouncer to fully work then slowly checking packageInfo api then cleaning PackageOrganizer then rethinking the import of RPackage and map fucking categories to tags). then ... Stef

Aug. 5, 2012

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

by StÃ©phane Ducasse

On Aug 5, 2012, at 2:54 PM, GOUBIER Thierry wrote: > Is this the reason why when I built my package tree in the AltBrowser, I get four packages (X, X-A, X-B, X-C) but X contains all the classes of X-A, X-B and X-C ? Which package classes? because MC use a pattern matching based on category names and explicitly MCworking copy So if you declare an MC package we name X and X-A indeed you are in trouble. The point with RPackage is to avoid the pattern matching approach of MC and to get rid of the scan of all categories. > Is this the reason why, in the current Alt-Browser packages, there is an auto-creation of an Alt package when you load it ? > > I also get confused by the relation between class categories and packages. Is there a plan to get rid of class categories ? yes > At the moment, if you create then unload a package, the system categories stay behind (Pharo 2.0). > > Thierry > ________________________________________

Aug. 5, 2012

Re: [Pharo-project] Monticello changes not working

by Sean P. DeNigris

EstebanLM wrote > > not all the time, but yes, some times it happens to me too > Anybody have a reproducible case? -- View this message in context: http://forum.world.st/Monticello-changes-not-working-tp4643184p4643198.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Aug. 5, 2012

[Pharo-project] Integrating Issue 6524: StartupPreferences loads non-Smalltalk files

by Sean P. DeNigris

Issue 6524: StartupPreferences loads non-Smalltalk files http://code.google.com/p/pharo/issues/detail?id=6524 I'd like to get this integrated ASAP. Thanks, Sean -- View this message in context: http://forum.world.st/Integrating-Issue-6524-StartupPreferences-loads-non-S… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Aug. 5, 2012

Re: [Pharo-project] Monticello changes not working

by Esteban Lorenzano

not all the time, but yes, some times it happens to me too Esteban On Aug 5, 2012, at 3:27 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Hi guys. I am the only one that noticies that "Changes" is showing whatever but the correct changes? > I think this is a stop-the-world-issue because I cannot commit anything because I cannot really see and make sure of what I changed. > You should not merge ether if you cannot clearly see what has been changed. > > thanks > > -- > Mariano > http://marianopeck.wordpress.com >

Aug. 5, 2012