- Pharo-dev - lists.pharo.org

Re: [Pharo-project] PackageOrganizer packages vs. categories

by Esteban Lorenzano

Marcus proposal is good: map RPackage with MCPackage, tag the subcategories (RPackage allow adding attributes). That solve all problems with few difficulties (and well... with time packages will adapt) this provides a transparent migration path, which is what we need. Esteban On Jun 16, 2012, at 12:06 PM, Mariano Martinez Peck wrote: > > > On Sat, Jun 16, 2012 at 5:41 AM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > I was expecting "PackageOrganizer default packageOfClass: FileSystemError" to > return "FileSystem-Core" but it returned "FileSystem-Core-Kernel", which is > not a package. It's a category, but it's packaged in "FileSystem-Core". Is > this a bug? Will PackageOrganizer go away when RPackage takes over? > > > We have been discussing this with Esteban last Monday. Indeed, there is something that does not work. > With PackageInfo or whatever (before RPackage) you used to have a package and categories. > So for example, the *Monticello* package Fuel has several categories: Fuel-Clusters, Fuel-Collections, Fuel-Errors, etc. > From what I can see in RPackage, those categories are called packages as well. > > So... I can get the RPackage for each of those categories: > > (RPackageOrganizer default packageNamed: 'Fuel-Clusters') classes -> ok > (RPackageOrganizer default packageNamed: 'Fuel-Collections') classes -> ok > etc... > > The problem is that so far you *cannot* get a RPackage representing a Monticello package. This is because a Monticello package could be represented as a *list* of RPackages. > How do I get the classes of the monticello package Fuel? > (RPackageOrganizer default packageNamed: 'Fuel') classes -> does not work > > The problem is that 'Fuel' is considered as an individual RPackage (just as Fuel-Clusters, Fuel-Collections, etc). This problem is that > > MCPackage >> correspondingRPackage > > | symbol | > symbol := Symbol readFromString: '#', self name. > ^ RPackageOrganizer default packageNamed: symbol ifAbsent: [ nil ] > > answers *one* RPackage where actually should be a list. So for example for the MCPackage of 'Fuel' I should get a list of all RPackages (Fuel-Clusters, Fuel-Collections, etc). Then I can do the inject:into or whatever if I want to ask/calculate sutff (like #classes and #extensionMethods). > > Cheers > > > > > > Sean > > -- > View this message in context: http://forum.world.st/PackageOrganizer-packages-vs-categories-tp4635069.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > > > > -- > Mariano > http://marianopeck.wordpress.com >

June 16, 2012

Re: [Pharo-project] PackageOrganizer packages vs. categories

by StÃ©phane Ducasse

sorry but I do not have the energy to discuss that publicly and via email. The problem is that lot of people want a lotâ¦ and my energy is limited. Stef On Jun 16, 2012, at 12:06 PM, Mariano Martinez Peck wrote: > > > On Sat, Jun 16, 2012 at 5:41 AM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > I was expecting "PackageOrganizer default packageOfClass: FileSystemError" to > return "FileSystem-Core" but it returned "FileSystem-Core-Kernel", which is > not a package. It's a category, but it's packaged in "FileSystem-Core". Is > this a bug? Will PackageOrganizer go away when RPackage takes over? > > > We have been discussing this with Esteban last Monday. Indeed, there is something that does not work. > With PackageInfo or whatever (before RPackage) you used to have a package and categories. > So for example, the *Monticello* package Fuel has several categories: Fuel-Clusters, Fuel-Collections, Fuel-Errors, etc. > From what I can see in RPackage, those categories are called packages as well. > > So... I can get the RPackage for each of those categories: > > (RPackageOrganizer default packageNamed: 'Fuel-Clusters') classes -> ok > (RPackageOrganizer default packageNamed: 'Fuel-Collections') classes -> ok > etc... > > The problem is that so far you *cannot* get a RPackage representing a Monticello package. This is because a Monticello package could be represented as a *list* of RPackages. > How do I get the classes of the monticello package Fuel? > (RPackageOrganizer default packageNamed: 'Fuel') classes -> does not work > > The problem is that 'Fuel' is considered as an individual RPackage (just as Fuel-Clusters, Fuel-Collections, etc). This problem is that > > MCPackage >> correspondingRPackage > > | symbol | > symbol := Symbol readFromString: '#', self name. > ^ RPackageOrganizer default packageNamed: symbol ifAbsent: [ nil ] > > answers *one* RPackage where actually should be a list. So for example for the MCPackage of 'Fuel' I should get a list of all RPackages (Fuel-Clusters, Fuel-Collections, etc). Then I can do the inject:into or whatever if I want to ask/calculate sutff (like #classes and #extensionMethods). > > Cheers > > > > > > Sean > > -- > View this message in context: http://forum.world.st/PackageOrganizer-packages-vs-categories-tp4635069.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > > > > -- > Mariano > http://marianopeck.wordpress.com >

June 16, 2012

[Pharo-project] RE : Re: start thinking on summer release of Pharo 1.4

by Philippe Back

I am experimenting with that right now. Seems to work. EnvoyÃ© depuis un mobile Samsung Esteban Lorenzano <estebanlm(a)gmail.com> a Ã©critÂ : Hi, you are asking for two things there: -a sound package for pharo 1.4 (I don't know if it exists, and in any case we cannot add it as a core package, you need to install it and see how it works by yourself) -a working sound plugin for iOS. TBH, while I'm including it in regular compilations, I never tested it, so I don't know if is working properly. Of course, to do games and others, is clear that we need a working sound system into iOS... . Esteban On Jun 15, 2012, at 11:36 PM, phil(a)highoctane.be wrote: > Well, spotlight is really cool indeed. Shift-Space XXX Enter. yay! > > But I like to have a view on several classes and typing HOPRÂ¨helps. > > Same when exploring the system for doing something (like > sound-synthesis for example). > > BTW, any new stuff on the MP3 front? I am looking at the sophie 1.0 > extract of yours. > > As of Pharo 1.4 Summer Release, having a somewhat cleaned up > Sound-synthesis in it would be nice. > > I am currently creating a little game in Smalltalk targeting the iPad > and a game without sound is not that of a game. > > For beginners and motivating people to move aboard the platform, sound > is important to have. > > KR > Philippe > > 2012/6/15 Sean P. DeNigris <sean(a)clipperadams.com>: >> >> philippeback wrote >>> >>> Have been using Nautilus and OB and albeit Nautilus is nicer looking, >>> I find my way better with OB. Especially with the top search bar and >>> categorizing into protocols. More buttons under the lists in OB but I >>> do prefer them actually. >>> >> >> Overall, I like Nautilus' workflow better, but I know what you mean about >> the buttons. Even with the visual feedback, I'm never quite sure if I'm "in" >> class-side mode, or I have to hit the button to "get" class-side mode. I was >> missing the search bar, but with spotlight, it's moot. >> >> Sean >> >> -- >> View this message in context: http://forum.world.st/start-thinking-on-summer-release-of-Pharo-1-4-tp46345… >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> > > > > -- > Philippe Back > Dramatic Performance Improvements > Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: > phil(a)highoctane.be | Web: http://philippeback.eu | Blog: > http://philippeback.be > > High Octane SPRL > rue cour Boisacq 101 > 1301 Bierges > Belgium >

June 16, 2012

Re: [Pharo-project] start thinking on summer release of Pharo 1.4

by Esteban Lorenzano

Hi, you are asking for two things there: -a sound package for pharo 1.4 (I don't know if it exists, and in any case we cannot add it as a core package, you need to install it and see how it works by yourself) -a working sound plugin for iOS. TBH, while I'm including it in regular compilations, I never tested it, so I don't know if is working properly. Of course, to do games and others, is clear that we need a working sound system into iOS... . Esteban On Jun 15, 2012, at 11:36 PM, phil(a)highoctane.be wrote: > Well, spotlight is really cool indeed. Shift-Space XXX Enter. yay! > > But I like to have a view on several classes and typing HOPRÂ¨helps. > > Same when exploring the system for doing something (like > sound-synthesis for example). > > BTW, any new stuff on the MP3 front? I am looking at the sophie 1.0 > extract of yours. > > As of Pharo 1.4 Summer Release, having a somewhat cleaned up > Sound-synthesis in it would be nice. > > I am currently creating a little game in Smalltalk targeting the iPad > and a game without sound is not that of a game. > > For beginners and motivating people to move aboard the platform, sound > is important to have. > > KR > Philippe > > 2012/6/15 Sean P. DeNigris <sean(a)clipperadams.com>: >> >> philippeback wrote >>> >>> Have been using Nautilus and OB and albeit Nautilus is nicer looking, >>> I find my way better with OB. Especially with the top search bar and >>> categorizing into protocols. More buttons under the lists in OB but I >>> do prefer them actually. >>> >> >> Overall, I like Nautilus' workflow better, but I know what you mean about >> the buttons. Even with the visual feedback, I'm never quite sure if I'm "in" >> class-side mode, or I have to hit the button to "get" class-side mode. I was >> missing the search bar, but with spotlight, it's moot. >> >> Sean >> >> -- >> View this message in context: http://forum.world.st/start-thinking-on-summer-release-of-Pharo-1-4-tp46345… >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> > > > > -- > Philippe Back > Dramatic Performance Improvements > Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: > phil(a)highoctane.be | Web: http://philippeback.eu | Blog: > http://philippeback.be > > High Octane SPRL > rue cour Boisacq 101 > 1301 Bierges > Belgium >

June 16, 2012

Re: [Pharo-project] PackageOrganizer packages vs. categories

by Mariano Martinez Peck

On Sat, Jun 16, 2012 at 5:41 AM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > I was expecting "PackageOrganizer default packageOfClass: FileSystemError" > to > return "FileSystem-Core" but it returned "FileSystem-Core-Kernel", which is > not a package. It's a category, but it's packaged in "FileSystem-Core". Is > this a bug? Will PackageOrganizer go away when RPackage takes over? > > We have been discussing this with Esteban last Monday. Indeed, there is something that does not work. With PackageInfo or whatever (before RPackage) you used to have a package and categories. So for example, the *Monticello* *package* Fuel has several *categories*: Fuel-Clusters, Fuel-Collections, Fuel-Errors, etc. >From what I can see in RPackage, those *categories* are called *packages*as well. So... I can get the RPackage for each of those categories: (RPackageOrganizer default packageNamed: 'Fuel-Clusters') classes -> ok (RPackageOrganizer default packageNamed: 'Fuel-Collections') classes -> ok etc... The problem is that so far you *cannot* get a RPackage representing a Monticello package. This is because a Monticello package could be represented as a *list* of RPackages. How do I get the classes of the monticello package Fuel? (RPackageOrganizer default packageNamed: 'Fuel') classes -> does not work The problem is that 'Fuel' is considered as an individual RPackage (just as Fuel-Clusters, Fuel-Collections, etc). This problem is that MCPackage >> correspondingRPackage | symbol | symbol := Symbol readFromString: '#', self name. ^ RPackageOrganizer default packageNamed: symbol ifAbsent: [ nil ] answers *one* RPackage where actually should be a list. So for example for the MCPackage of 'Fuel' I should get a list of all RPackages (Fuel-Clusters, Fuel-Collections, etc). Then I can do the inject:into or whatever if I want to ask/calculate sutff (like #classes and #extensionMethods). Cheers > Sean > > -- > View this message in context: > http://forum.world.st/PackageOrganizer-packages-vs-categories-tp4635069.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > -- Mariano http://marianopeck.wordpress.com

June 16, 2012

Re: [Pharo-project] Auto create new and initialize methods for new class?

by StÃ©phane Ducasse

On Jun 16, 2012, at 11:00 AM, Nicolas Cellier wrote: > 2012/6/16 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> >>> >>> On Jun 15, 2012, at 12:06 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> >>>> why do you need an automatic new method? >>>> Because by default >>>> new invoke initialize >>>> >>>> and it works well. >>>> >>> >>> StÃ©phane, I have been using VW Smalltalk and it creates new classes ,by default, with a #new method on the class side and a #initialize method on the instance side. >> >> yes I always hated hated so much to force teacher to kill student on metaclass altar after two weeks of smalltalk > > Another point of view: creating an instance is on class side what is the class side? :) > because > instances are created from a kind of structural template (how many > variables, etc...). You can also create an instance by cloning with > copyâ¦ I have been there. Teaching a lot during many years and there is no simple explanation: after two hours of lecture you do not want to explain metaclasses. Just because people forgot (CLOS did not do this mistake) to invoke an initialize method when creating an object. At the end I added in all my system the Behavior new>> self basicNew initialize and the students were happy and me too. > But initialize is on instance size because it modifies the private > instance variables: > one object can't directly modify another, except by kindly asking by > sending a message. > The instance is an object, the class is another, so the class kindly > ask the instance to initialize itself. > > There's no trick here and it can't be more clear. > The only trick is how a class side new inherits from instance side > Behavior new, but we don't need this to explain initialize... > > Nicolas >

June 16, 2012

Re: [Pharo-project] Auto create new and initialize methods for new class?

by Nicolas Cellier

2012/6/16 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> >> >> On Jun 15, 2012, at 12:06 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >>> why do you need an automatic new method? >>> Because by default >>> Â new invoke initialize >>> >>> and it works well. >>> >> >> StÃ©phane, I have been using VW Smalltalk and it creates new classes ,by default, with a #new method on the class side and a #initialize method on the instance side. > > yes I always hated hated so much to force teacher to kill student on metaclass altar after two weeks of smalltalk Another point of view: creating an instance is on class side because instances are created from a kind of structural template (how many variables, etc...). You can also create an instance by cloning with copy... But initialize is on instance size because it modifies the private instance variables: one object can't directly modify another, except by kindly asking by sending a message. The instance is an object, the class is another, so the class kindly ask the instance to initialize itself. There's no trick here and it can't be more clear. The only trick is how a class side new inherits from instance side Behavior new, but we don't need this to explain initialize... Nicolas

June 16, 2012

Re: [Pharo-project] start thinking on summer release of Pharo 1.4

by StÃ©phane Ducasse

On Jun 16, 2012, at 12:57 AM, Schwab,Wilhelm K wrote: > But if I'm building a new image *today*, I want it to do the right thing now (automatically for the current version), with the same incantation as worked months ago or months from now. Bill when do you take the time to have a look at Metacello. Why people like me are spending days on writing 45 pages of documentation to hear you saying that. This scenario is supported since months nearly since Barcelona 2010. > If we can't do that, the config browser is pretty much a dream vs. reality. > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Sean P. DeNigris [sean(a)clipperadams.com] > Sent: Friday, June 15, 2012 2:49 PM > To: pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] start thinking on summer release of Pharo 1.4 > > Schwab,Wilhelm K wrote >> >> My gripe is... that configs... work (very) differently over time >> > With the current evolution of Metacello, this should not be the case. Done > right, what a config loads can be 100% static and repeatable. If you load a > literal version (e.g. '1.4'), which loads literal versions of dependent > projects (which they should unless there is a reason not to, e.g. a loose > dependency like Seaside on OB), which load literal versions all the way > down, it will do the same thing today, tomorrow, and ten years from now. > > The only hill to climb now is getting the word out about Metacello > conventions/best practices. > > > Schwab,Wilhelm K wrote >> >> If pre-loading, how about FFI? >> > I think "easily loadable" is the correct state, not included by default. > > -- > View this message in context: http://forum.world.st/start-thinking-on-summer-release-of-Pharo-1-4-tp46345… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >

June 16, 2012

Re: [Pharo-project] start thinking on summer release of Pharo 1.4

by StÃ©phane Ducasse

On Jun 15, 2012, at 11:36 PM, phil(a)highoctane.be wrote: > Well, spotlight is really cool indeed. Shift-Space XXX Enter. yay! > > But I like to have a view on several classes and typing HOPRÂ¨helps. > > Same when exploring the system for doing something (like > sound-synthesis for example). > > BTW, any new stuff on the MP3 front? I am looking at the sophie 1.0 > extract of yours. > > As of Pharo 1.4 Summer Release, having a somewhat cleaned up > Sound-synthesis in it would be nice. our agenda is more than full. Do not expect anything from us on this side. we have athens FFI/NativeBoost and a lot of other points to fix. > I am currently creating a little game in Smalltalk targeting the iPad > and a game without sound is not that of a game. Load the packages and try. > > For beginners and motivating people to move aboard the platform, sound > is important to have. > > KR > Philippe > > 2012/6/15 Sean P. DeNigris <sean(a)clipperadams.com>: >> >> philippeback wrote >>> >>> Have been using Nautilus and OB and albeit Nautilus is nicer looking, >>> I find my way better with OB. Especially with the top search bar and >>> categorizing into protocols. More buttons under the lists in OB but I >>> do prefer them actually. >>> >> >> Overall, I like Nautilus' workflow better, but I know what you mean about >> the buttons. Even with the visual feedback, I'm never quite sure if I'm "in" >> class-side mode, or I have to hit the button to "get" class-side mode. I was >> missing the search bar, but with spotlight, it's moot. >> >> Sean >> >> -- >> View this message in context: http://forum.world.st/start-thinking-on-summer-release-of-Pharo-1-4-tp46345… >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> > > > > -- > Philippe Back > Dramatic Performance Improvements > Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: > phil(a)highoctane.be | Web: http://philippeback.eu | Blog: > http://philippeback.be > > High Octane SPRL > rue cour Boisacq 101 > 1301 Bierges > Belgium >

June 16, 2012

Re: [Pharo-project] Auto create new and initialize methods for new class?

by StÃ©phane Ducasse

> > > On Jun 15, 2012, at 12:06 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> why do you need an automatic new method? >> Because by default >> new invoke initialize >> >> and it works well. >> > > StÃ©phane, I have been using VW Smalltalk and it creates new classes ,by default, with a #new method on the class side and a #initialize method on the instance side. yes I always hated hated so much to force teacher to kill student on metaclass altar after two weeks of smalltalk

June 16, 2012