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

Re: [Pharo-project] [BetaTesting] [ANN] Pharo-1.0-10515-rc3dev10.03.1

by Mariano Martinez Peck

Sorry, the link is actually this one: https://gforge.inria.fr/frs/download.php/26681/Pharo-1.0-10515-rc3dev10.03.… On Sat, Mar 20, 2010 at 8:40 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > Hi folks. We are proud to announce the (hopefully) last RC3 for Pharo 1.0. > > This image is based in PharoCore-1.0-10515rc3. The image also contain lot > of fixes and improvements of external packages: > > These, are the fixed issues of the external tools: > > OB: Issues 1891, 1748, 1670, 1667, 1705, 1667 > > O2: issues 1887, 1312, 1429, 1886, 2073 > > New Inspector: issues 1783, 1499 > > Refactoring Browser: issue 2108 > > The link is: > https://gforge.inria.fr/frs/download.php/26680/Pharo-1.0-10515-rc3dev10.03.… > > Cheers > > Mariano > >

March 20, 2010

Re: [Pharo-project] [ANN] Gofer Project Loader 1.0 (BETA)

by Dale Henrichs

George, At the moment there is no overall way to do that for Pharo. For GemStone I have attributes for specific versions, so for GemStone I can write a spec like this: spec for: #common do: [...]. spec for: #gemstone do: [...]. spec for: #'gs2.4.x' do: [...]. spec for: #'gs3.x' do: [...]. So I can specific packages that are only loaded in GemStone 2.4 or GemStone 3.0. For Pharo I would imagine doing something like the following: spec for: #common do: [...]. spec for: #squeakCommon do: [...]. spec for: #pharo do: [...]. spec for: #'pharo1.0' do: [...]. spec for: #'pharo1.1' do: [...]. Then packages that were specific to 1.0 and 1.1 can be specified. I haven't added this to Metacello for Pharo, because I was kind of waiting for the need to appear rather than add a feature that noone needs, so I've been waiting for someone to ask for the feature:) Dale ----- "George Herolyants" <george.herolyants(a)gmail.com> wrote: | Thanks for the explanation, Dale! | | May be it's obvious and I'm asking stupid questions but then I don't | understand how can I specify in my configuration the differences | between the versions of the target platform? | | 2010/3/20 Dale Henrichs <dale.henrichs(a)gemstone.com>: | > George, | > | > The mcz files containing the Metacello configurations _are_ copied, | but the configuration itself is not modified in the scheme. | > | > The idea of using different repositories is to indicate which of the | many different projects are _expected_ or _known_ to work in Pharo1.1 | or Pharo1.0. | > | > For GemStone, I have createed a GemSource MetacelloRepository and I | have copied the metacello configurations that I know have been ported | to GemStone. I've done this so that folks can know what is supported. | I make sure that all of the tests run green and that all of the | configs in the GemSource MetacelloRepository can be loaded. | > | > It does not stop someone from loading a configuration into GemStone | that isn't in the GemSource MetacelloRepository, but if you do and run | into trouble, my answer will probably be that it hasn't been ported | yet. | > | > The same thing can apply to Squeak, but someone would have to step | up to testing/approving metacello configurations that run with the | various versions. | > | > Without this extra step of approval/testing, it's difficult for | someone that doesn't have their finger on the pulse of the latest and | greatest happenings to know what to expect ... | > | > Dale

March 20, 2010

[Pharo-project] [BetaTesting] [ANN] Pharo-1.0-10515-rc3dev10.03.1

by Mariano Martinez Peck

Hi folks. We are proud to announce the (hopefully) last RC3 for Pharo 1.0. This image is based in PharoCore-1.0-10515rc3. The image also contain lot of fixes and improvements of external packages: These, are the fixed issues of the external tools: OB: Issues 1891, 1748, 1670, 1667, 1705, 1667 O2: issues 1887, 1312, 1429, 1886, 2073 New Inspector: issues 1783, 1499 Refactoring Browser: issue 2108 The link is: https://gforge.inria.fr/frs/download.php/26680/Pharo-1.0-10515-rc3dev10.03.… Cheers Mariano

March 20, 2010

Re: [Pharo-project] Rename DummySuperclassOfColorPickerMorph

by StÃ©phane Ducasse

On Mar 20, 2010, at 5:52 PM, Mariano Martinez Peck wrote: > > > On Thu, Mar 18, 2010 at 4:19 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > We should remove this class. It is plain bad. > For that we should replace colorPickerMorph with ColorChooser. > > > I am not sure which is the direction here. ColorPickerMorph is from Morphic-Widgets. > ColorChoose is from Polymorph. If we change ALL places of PharoCore to use ColorChooser instead of ColorPickerMorph we will be completely couple to Polymorph. I mean, I would really like to be able to load and unload Polymoprh from core without problem. So..I am not sure which is the intention here. may be the colorPicker users should not be core. > > Polymorph will be in core always ? or as something optional ? I would love to have a nice core and "polymorph" an extension but it probably means that part of polymorph should be core. > > Cheers > > Mariano > > Stef > On Mar 18, 2010, at 4:11 PM, Mariano Martinez Peck wrote: > > > But I don't have a better name for that. Any ideas? It has a subclass ColorPickerMorph > > > > 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 20, 2010

Re: [Pharo-project] [ANN] Gofer Project Loader 1.0 (BETA)

by George Herolyants

Thanks for the explanation, Dale! May be it's obvious and I'm asking stupid questions but then I don't understand how can I specify in my configuration the differences between the versions of the target platform? 2010/3/20 Dale Henrichs <dale.henrichs(a)gemstone.com>: > George, > > The mcz files containing the Metacello configurations _are_ copied, but the configuration itself is not modified in the scheme. > > The idea of using different repositories is to indicate which of the many different projects are _expected_ or _known_ to work in Pharo1.1 or Pharo1.0. > > For GemStone, I have createed a GemSource MetacelloRepository and I have copied the metacello configurations that I know have been ported to GemStone. I've done this so that folks can know what is supported. I make sure that all of the tests run green and that all of the configs in the GemSource MetacelloRepository can be loaded. > > It does not stop someone from loading a configuration into GemStone that isn't in the GemSource MetacelloRepository, but if you do and run into trouble, my answer will probably be that it hasn't been ported yet. > > The same thing can apply to Squeak, but someone would have to step up to testing/approving metacello configurations that run with the various versions. > > Without this extra step of approval/testing, it's difficult for someone that doesn't have their finger on the pulse of the latest and greatest happenings to know what to expect ... > > Dale

March 20, 2010

Re: [Pharo-project] [ANN] Gofer Project Loader 1.0 (BETA)

by Dale Henrichs

George, The mcz files containing the Metacello configurations _are_ copied, but the configuration itself is not modified in the scheme. The idea of using different repositories is to indicate which of the many different projects are _expected_ or _known_ to work in Pharo1.1 or Pharo1.0. For GemStone, I have createed a GemSource MetacelloRepository and I have copied the metacello configurations that I know have been ported to GemStone. I've done this so that folks can know what is supported. I make sure that all of the tests run green and that all of the configs in the GemSource MetacelloRepository can be loaded. It does not stop someone from loading a configuration into GemStone that isn't in the GemSource MetacelloRepository, but if you do and run into trouble, my answer will probably be that it hasn't been ported yet. The same thing can apply to Squeak, but someone would have to step up to testing/approving metacello configurations that run with the various versions. Without this extra step of approval/testing, it's difficult for someone that doesn't have their finger on the pulse of the latest and greatest happenings to know what to expect ... Dale ----- "George Herolyants" <george.herolyants(a)gmail.com> wrote: | 2010/3/18 Adrian Lienhard <adi(a)netstyle.ch>: | > Here is yet another way how we could model universes. We just have | multiple Metacello repositories: | > | > - MetacelloRepository is the one that everybody can commit to | (testing universe) | > - MetacelloRepositoryPharo1.0 is the stable universe for Pharo 1.0 | > - MetacelloRepositoryPharo1.1 is the stable universe for Pharo 1.1 | > - etc. | > | > A package always first gets into the testing universe and when it is | known to work in a particular version it is copied into the | appropriate repository. The Gofer Project Loader would just need to | know the repository for the current Pharo version. Like in Debian, one | can add the testing universe to get unstable versions if needed. | > | > This setup would not need any code changes in Metacello and it | allows us to use access rights to assign people to manage the process | and assert a certain level of quality. | | And what if my project is intended to load in Squeak also? Or | gemtone? | Where should I put it? Does this approach imply that there should be | created appropriate repositories? Doesn't this imply duplication of | code between different configurations (which is avoided now using | #common specifier) if the package can be loaded with only minor | changes in all forks? And doesn't this imply removing all the code | related to the fork specifier handling in Metacello? | | Just curious :) | | | George | | _______________________________________________ | Pharo-project mailing list | Pharo-project(a)lists.gforge.inria.fr | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 20, 2010

Re: [Pharo-project] [ANN] Gofer Project Loader 1.0 (BETA)

by George Herolyants

2010/3/18 Adrian Lienhard <adi(a)netstyle.ch>: > Here is yet another way how we could model universes. We just have multiple Metacello repositories: > > - MetacelloRepository is the one that everybody can commit to (testing universe) > - MetacelloRepositoryPharo1.0 is the stable universe for Pharo 1.0 > - MetacelloRepositoryPharo1.1 is the stable universe for Pharo 1.1 > - etc. > > A package always first gets into the testing universe and when it is known to work in a particular version it is copied into the appropriate repository. The Gofer Project Loader would just need to know the repository for the current Pharo version. Like in Debian, one can add the testing universe to get unstable versions if needed. > > This setup would not need any code changes in Metacello and it allows us to use access rights to assign people to manage the process and assert a certain level of quality. And what if my project is intended to load in Squeak also? Or gemtone? Where should I put it? Does this approach imply that there should be created appropriate repositories? Doesn't this imply duplication of code between different configurations (which is avoided now using #common specifier) if the package can be loaded with only minor changes in all forks? And doesn't this imply removing all the code related to the fork specifier handling in Metacello? Just curious :) George

March 20, 2010

Re: [Pharo-project] nebraska?

by Lawson English

StÃ©phane Ducasse wrote: >> Darn. I was hoping I was getting my plug and play P2P networking on Second Life-ST-based collaboration stuff for free. >> > > not quite so :) > > >> The "Cobalt on a Prim" plugin should work pretty well, but its only going to be an oddity. Far more interesting will be to allow Nebraska-like/Cobalt-like sharing of applications without the extra overhead of VNC. My original plan was to somehow extract the TeaTime/Cobalt Island functionality and make it the networking layer between two instances of the Squeak-SL Plugin: >> >> >> Second Life <=> Squeak <=> Cobalt island (sans avatars and such) <=> Cobalt island <=> Squeak <=> Second Life >> >> Replacing "Cobalt" with "Nebraska" looked like a much simpler way to go (on paper) but obviously, it won't work with Pharo. Eventually, Cobalt will be remerged with Trunk so that it can work with the latest Squeak or Pharo. I guess I can fudge something for P2P that isn't quite so elegant in the meantime. >> > > Squeak certainly Pharo not necessary because we cleaned a lot and we will clean again. Now it depends on people energy. > >> OTOH, maybe Nebraska can be implemented on top of TeaTime/Cobalt once its available in Pharo. >> > > But Squeakers are pushing to get Cobalt on top of squeak not pharo so do not expect that it will work in pharo > except if you make it happen (which we support). My point is not to be negative but to avoid giving false dreams. > > > Stef > Well, Matt is working on the situation as we speak. I think the hope is that meging Cobalt to squeak trunk will make it MUCH easier to put it on top of Pharo, eventually. It would be nice if full TeaTime was available as its own separate module though. It may not be fast enough for 3D world events, but it might be fast enough for Nebraska P2P and smaller tasks, and I believe its considered perfect for message dispatching in multi-core SiliconSqueak. Lawson

March 20, 2010

Re: [Pharo-project] Rename DummySuperclassOfColorPickerMorph

by Mariano Martinez Peck

On Thu, Mar 18, 2010 at 4:19 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > We should remove this class. It is plain bad. > For that we should replace colorPickerMorph with ColorChooser. > > I am not sure which is the direction here. ColorPickerMorph is from Morphic-Widgets. ColorChoose is from Polymorph. If we change ALL places of PharoCore to use ColorChooser instead of ColorPickerMorph we will be completely couple to Polymorph. I mean, I would really like to be able to load and unload Polymoprh from core without problem. So..I am not sure which is the intention here. Polymorph will be in core always ? or as something optional ? Cheers Mariano > Stef > On Mar 18, 2010, at 4:11 PM, Mariano Martinez Peck wrote: > > > But I don't have a better name for that. Any ideas? It has a subclass > ColorPickerMorph > > > > 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 >

March 20, 2010

[Pharo-project] what is the status of the final clean of Utilities ?

by stephane ducasse

Hi jb you told us that you were turning Utilities -> Updater What is the status? Because removing Utilities is another dream that we can realize (hobbes smiling with large smile). Stef a great site of a coooooool comix http://worldofcalvinandhobbes.blogspot.com/ "if you knew today was your last day on earth, what would you do different? ... especially if, by doing something different, today might not be your last day on earth" Calvin&Hobbes

March 20, 2010