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

Re: [Pharo-project] RE : RE : Configuration Browser feedback

by Mariano Martinez Peck

Each configuration can have just a specific message #projectDescription or whatever (a method and a pragma) that just answers that.... On Sat, Aug 4, 2012 at 2:40 PM, GOUBIER Thierry <thierry.goubier(a)cea.fr>wrote: > A naive proposition : > > Use a comment in the header of the mcz of the configuration (or whatever > appropriate metadata about one of the file of the mcz) so that the > description of the package (a configuration is a package, right?) can be > retrieved without loading the zip in complete. > > In the same way when opening a package repository, you can get the last > commit release ? > > Equivalent approaches could then be designed for other formats than the > mcz. > > Thierry > ________________________________________ > De : pharo-project-bounces(a)lists.gforge.inria.fr [ > pharo-project-bounces(a)lists.gforge.inria.fr] de la part de Esteban > Lorenzano [estebanlm(a)gmail.com] > Date d'envoi : samedi 4 aoÃ»t 2012 14:20 > Ã : Pharo-project(a)lists.gforge.inria.fr > Objet : Re: [Pharo-project] RE : Configuration Browser feedback > > Yes, that would be a good addition, but sadly is not so easy... if you > have an idea of how to implement it, I would be happy to introduce it :) > > Cheers, > Esteban > > On Aug 4, 2012, at 2:06 PM, GOUBIER Thierry <thierry.goubier(a)cea.fr> > wrote: > > > +100 on the configuration description ! > > > > Thierry > > ________________________________________ > > De : pharo-project-bounces(a)lists.gforge.inria.fr [ > pharo-project-bounces(a)lists.gforge.inria.fr] de la part de Ben Coman > [btc(a)openInWorld.com] > > Date d'envoi : samedi 4 aoÃ»t 2012 13:14 > > Ã : Pharo-project(a)lists.gforge.inria.fr > > Objet : [Pharo-project] Configuration Browser feedback > > > > Just thinking that the second tab of the Configuration Browser being > > called "Untrusted" is a bit harsh and not really socially engaging. > > "Community" has a better feel to me. > > And perhaps not "Configurations" for the first tab either, since both > > tabs are configurations. Perhaps "Core" or "Supported" or "Vetted" or > > "Gold" or something similar. > > > > Also, what would be really fantastic would be some description of each > > configuration being displayed in a pane on the right hand side. There > > are A LOT of configurations listed there - which is great - but I don't > > feel inclined to go looking up every single one to see if they interest > > me. Sometimes what gets people interested in trying out new things is > > that it just catches their eye in casual browsing. > > > > I guess a pre-requisite of that would be the ConfigurationOf file > > containing such a description, as well as perhaps something on the back > > end server that caches those descriptions into one file. > > > > cheers -ben > > > > > > > > -- Mariano http://marianopeck.wordpress.com

Aug. 5, 2012

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

by Mariano Martinez Peck

I have just reviewed. Hopefully someone will integrate soon :) On Sun, Aug 5, 2012 at 4:15 PM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > 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. > > -- Mariano http://marianopeck.wordpress.com

Aug. 5, 2012

Re: [Pharo-project] Monticello changes not working

by Mariano Martinez Peck

In my case, I can reproduce it always. Each time I ask changes, not necessary slices. Modify something in a package and see changes. On Sun, Aug 5, 2012 at 7:44 PM, Camillo Bruni <camillobruni(a)gmail.com>wrote: > I think it happens quite reproducible when asking for changes of packages > with references (slices)... > > On 2012-08-05, at 16:20, "Sean P. DeNigris" <sean(a)clipperadams.com> wrote: > > 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. > > > > > -- Mariano http://marianopeck.wordpress.com

Aug. 5, 2012

Re: [Pharo-project] Monticello changes not working

by Sean P. DeNigris

Camillo Bruni-3 wrote > > I think it happens quite reproducible when asking for changes of packages > with references (slices)... > Oh yeah, I reported that last month... Issue 6340: [BUG]: Browsing changes on a slice http://code.google.com/p/pharo/issues/detail?id=6340 -- View this message in context: http://forum.world.st/Monticello-changes-not-working-tp4643184p4643229.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Aug. 5, 2012

Re: [Pharo-project] Monticello changes not working

by Camillo Bruni

I think it happens quite reproducible when asking for changes of packages with references (slices)... On 2012-08-05, at 16:20, "Sean P. DeNigris" <sean(a)clipperadams.com> wrote: > 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

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

by Sean P. DeNigris

Igor Stasenko wrote > > detecting the file type on it's extension is too unreliable , IMO. > I used the file extension in the example because that's what I'm familiar with in other systems. The FileReference subclass could do any checks it wants to prevent false positives (e.g. a .zip file could check that it begins with a local file header signature). Also, this is how file services are already handled in Pharo (browse implementors of #fileReaderServicesForFile:suffix:) -- View this message in context: http://forum.world.st/ENH-FileReference-subclasses-tp4643116p4643224.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Aug. 5, 2012

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