January 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Presenter and Project will die aren't they ?

by Mariano Martinez Peck

Ok...and what about CodeLoader? I ask because it seems it uses ImageSegment to export categories and classes to disk. On Mon, Jan 11, 2010 at 2:20 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Yes! > > > I mean, the classes will be completely removed ? > > > > Just to be sure what I can cleanUp from ImageSegment > > > > cheers > > > > Mariano > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 11, 2010

Re: [Pharo-project] Package names

by StÃ©phane Ducasse

But marcus the - does not change anything this is not a special character if we want to avoid to have PolymorphSystemSettings to be save with Polymorph as well (berk) we have to follow SystemSettings-Polymorph I guess. Or we should have Compiler out and Compiler-Core Compiler-SystemSettings Stef On Jan 11, 2010, at 2:44 PM, Marcus Denker wrote: > > On Jan 11, 2010, at 2:36 PM, Torsten Bergmann wrote: > >> Shouldnt we rename some packages/class categories: >> >> "PolymorphSystemSettings" -> "Polymorph-SystemSettings" >> "CompilerSystemSettings" -> "Compiler-SystemSettings" >> ... >> >> so they would align with existing ones? >> > > The problem is that with PackageInfo, Compiler-SystemSettings ist part of Compiler. > And that leads to very strange effects (klasses are part of two packages). > > The idea is that the settings packages can be unloaded.... there are no dependencies > from the system the settings. > > Marcus > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 11, 2010

Re: [Pharo-project] Package names

by Marcus Denker

On Jan 11, 2010, at 2:36 PM, Torsten Bergmann wrote: > Shouldnt we rename some packages/class categories: > > "PolymorphSystemSettings" -> "Polymorph-SystemSettings" > "CompilerSystemSettings" -> "Compiler-SystemSettings" > ... > > so they would align with existing ones? > The problem is that with PackageInfo, Compiler-SystemSettings ist part of Compiler. And that leads to very strange effects (klasses are part of two packages). The idea is that the settings packages can be unloaded.... there are no dependencies from the system the settings. Marcus

Jan. 11, 2010

Re: [Pharo-project] Alien & (using Gofer and Flair)

by Danie Roux

2010/1/11 Mariano Martinez Peck <marianopeck(a)gmail.com>: > You will have only ONE class ConfigurationOfMoose which will have > different versions. Then you will be able to evaluate: > > Â (ConfigurationOfMoose project version: '4.1') load To add to that: ConfigurationOfMoose project latestVersion Will always resolve to the latest version that is blessed as stable. Development versions can be marked with "blessing: #development", and will not be used to determine the latest version. In this way, you can maintain a set of stable and development packages in the same Configuration. -- Danie Roux *shuffle* Adore Unix - http://danieroux.com

Jan. 11, 2010

[Pharo-project] Package names

by Torsten Bergmann

Shouldnt we rename some packages/class categories: "PolymorphSystemSettings" -> "Polymorph-SystemSettings" "CompilerSystemSettings" -> "Compiler-SystemSettings" ... so they would align with existing ones? Bye T. -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser

Jan. 11, 2010

Re: [Pharo-project] Alien & (using Gofer and Flair)

by StÃ©phane Ducasse

On Jan 11, 2010, at 2:28 PM, Mariano Martinez Peck wrote: > > > On Mon, Jan 11, 2010 at 2:24 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > > > Mariano > > > > I think that projects should publish in their repository a ConfigurationOfXXX > > and when this is stable copy it to MetacelloRepository. > > > > I agree more or less. Depends what you are meaning with stable. It is ok to commit ConfigurationOfXXX in your own repository until you have a first version. I just did that with SqueakDBX, but for the rest of the projects, I commit to local repo until it worked. And then, directly to MetacelloRepository. Of course, each person can do whatever they want. > > > > Then, you can directly commit it to MetacelloRepository. However, after that, the ConfigurationOfXXX can perfectly be unstable, using another version. For example, if you take ConfigurationOfPharo and load the version 1.0, it will work. Howver, it won't with 1.1 because I am still working. > > my point is that we should pay attention and have a limited set of configuration that are working for each release. > I imagine > > ConfigurationOfMoose4-Pharo1.0 > ConfigurationOfMoose4.1-Pharo1.0 > ConfigurationOfMoose4.1-Pharo1.0-105005 > ConfigurationOfMoose4.1-Pharo1.1 > > Not unstable version. Commit in the pharoTaskForces if this helps you. > > > Stef: On Friday we can see it together because that's not the idea of Metacello. You will have only ONE class ConfigurationOfMoose which will have different versions. Then you will be able to evaluate: > > (ConfigurationOfMoose project version: '4.1') load ok > > or whatever... > > But anyway, it will be better to see it together. > > Cheers > > Mariano > > > > > > Ok. No problem for me. My own "advice" is to put it *also* in MetacelloRepository. > > But we should get some guidelines else soon this will be a mess. > I suggest that we get a list of working stable configuration all the other should be moved into PharoTreated or something like that. > > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 11, 2010

Re: [Pharo-project] Alien & (using Gofer and Flair)

by Mariano Martinez Peck

On Mon, Jan 11, 2010 at 2:24 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > > > > Mariano > > > > I think that projects should publish in their repository a > ConfigurationOfXXX > > and when this is stable copy it to MetacelloRepository. > > > > I agree more or less. Depends what you are meaning with stable. It is ok > to commit ConfigurationOfXXX in your own repository until you have a first > version. I just did that with SqueakDBX, but for the rest of the projects, I > commit to local repo until it worked. And then, directly to > MetacelloRepository. Of course, each person can do whatever they want. > > > > Then, you can directly commit it to MetacelloRepository. However, after > that, the ConfigurationOfXXX can perfectly be unstable, using another > version. For example, if you take ConfigurationOfPharo and load the version > 1.0, it will work. Howver, it won't with 1.1 because I am still working. > > my point is that we should pay attention and have a limited set of > configuration that are working for each release. > I imagine > > ConfigurationOfMoose4-Pharo1.0 > ConfigurationOfMoose4.1-Pharo1.0 > ConfigurationOfMoose4.1-Pharo1.0-105005 > ConfigurationOfMoose4.1-Pharo1.1 > > Not unstable version. Commit in the pharoTaskForces if this helps you. > > Stef: On Friday we can see it together because that's not the idea of Metacello. You will have only ONE class ConfigurationOfMoose which will have different versions. Then you will be able to evaluate: (ConfigurationOfMoose project version: '4.1') load or whatever... But anyway, it will be better to see it together. Cheers Mariano > > > > > Ok. No problem for me. My own "advice" is to put it *also* in > MetacelloRepository. > > But we should get some guidelines else soon this will be a mess. > I suggest that we get a list of working stable configuration all the other > should be moved into PharoTreated or something like that. > > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 11, 2010

Re: [Pharo-project] Alien & (using Gofer and Flair)

by StÃ©phane Ducasse

> > Mariano > > I think that projects should publish in their repository a ConfigurationOfXXX > and when this is stable copy it to MetacelloRepository. > > I agree more or less. Depends what you are meaning with stable. It is ok to commit ConfigurationOfXXX in your own repository until you have a first version. I just did that with SqueakDBX, but for the rest of the projects, I commit to local repo until it worked. And then, directly to MetacelloRepository. Of course, each person can do whatever they want. > > Then, you can directly commit it to MetacelloRepository. However, after that, the ConfigurationOfXXX can perfectly be unstable, using another version. For example, if you take ConfigurationOfPharo and load the version 1.0, it will work. Howver, it won't with 1.1 because I am still working. my point is that we should pay attention and have a limited set of configuration that are working for each release. I imagine ConfigurationOfMoose4-Pharo1.0 ConfigurationOfMoose4.1-Pharo1.0 ConfigurationOfMoose4.1-Pharo1.0-105005 ConfigurationOfMoose4.1-Pharo1.1 Not unstable version. Commit in the pharoTaskForces if this helps you. > > Ok. No problem for me. My own "advice" is to put it *also* in MetacelloRepository. But we should get some guidelines else soon this will be a mess. I suggest that we get a list of working stable configuration all the other should be moved into PharoTreated or something like that. Stef

Jan. 11, 2010

Re: [Pharo-project] Presenter and Project will die aren't they ?

by StÃ©phane Ducasse

Yes! > I mean, the classes will be completely removed ? > > Just to be sure what I can cleanUp from ImageSegment > > cheers > > Mariano > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 11, 2010

Re: [Pharo-project] Alien & (using Gofer and Flair)

by Mariano Martinez Peck

On Mon, Jan 11, 2010 at 2:01 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Mariano > > I think that projects should publish in their repository a > ConfigurationOfXXX > and when this is stable copy it to MetacelloRepository. > I agree more or less. Depends what you are meaning with stable. It is ok to commit ConfigurationOfXXX in your own repository until you have a first version. I just did that with SqueakDBX, but for the rest of the projects, I commit to local repo until it worked. And then, directly to MetacelloRepository. Of course, each person can do whatever they want. Then, you can directly commit it to MetacelloRepository. However, after that, the ConfigurationOfXXX can perfectly be unstable, using another version. For example, if you take ConfigurationOfPharo and load the version 1.0, it will work. Howver, it won't with 1.1 because I am still working. > I think that this is important to have a dsitrbuted but with a possible > entry point infrastructure. > Loader can use MetacelloRepository as the only entry point No. You can set multiples repositories in Loader. > and this is ok but project should > have a configuration by themselves in the folder. > > Ok. No problem for me. My own "advice" is to put it *also* in MetacelloRepository. > Stef > > On Ja > > > > Yes, the web page is outdated. Thanks for pointing that out, i will > modify the info now. > > > > We are working together with Tudor on ConfigurationOfAlien, as soon as > it's finished i'll publish it. > > > > > > Cool. Please do it in MetacelloRepository ;) > > > > Fernando > > > > > > > > > indeed flair is dead. "le roi est mort vive le roi" > > > Fernando could u update the Alien loader? > > > > > > Stef > > > On Jan 11, 2010, at 10:36 AM, John M McIntosh wrote: > > > > > >> Whoever is looking after the Alien Gofer & Flair loader needs to > revisit the logic since Flair fights and > > >> loses against the current Gofer. Which then prevents Alien from > loading as per the instructions supplied > > >> on: http://www.squeaksource.com/Alien.html > > >> > > >> -- > > >> > =========================================================================== > > >> John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: > squeaker68882 > > >> Corporate Smalltalk Consulting Ltd. > http://www.smalltalkconsulting.com > > >> > =========================================================================== > > >> > > >> > > >> > > >> > > >> > > >> _______________________________________________ > > >> Pharo-project mailing list > > >> Pharo-project(a)lists.gforge.inria.fr > > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > > > > _______________________________________________ > > > Pharo-project mailing list > > > Pharo-project(a)lists.gforge.inria.fr > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 11, 2010