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

Re: [Pharo-project] Move MetaObjectTools from core to PharoDev

by Mariano Martinez Peck

On Sat, Mar 20, 2010 at 4:44 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Thanks I will do that! > can you open a ticket because the list is starting to get long of the stuff > to integrate after martin's changes. > http://code.google.com/p/pharo/issues/detail?id=2180 > BTW did you check if the other class besides ProtocolCatcher are working? > > No. No time yet. > Stef > > On Mar 20, 2010, at 4:22 PM, Mariano Martinez Peck wrote: > > > This package should be removed from core but it should still be loadable. > Thus, when needed, they can be easily installed. On the other hand, it could > be in PharoDev image. > > > > - MetaObjectTools: This package is moved to PharoDev. It doesnt have any > users in PharoCore > > > > To fix, evaluate: > > > > (MCPackage named: 'ObjectMetaTools') unload. > > > > I created and put such code in > http://www.squeaksource.com/ObjectMetaTools > > > > To load it again in a Pharo image: > > > > Gofer new > > squeaksource: 'ObjectMetaTools'; > > package: 'ObjectMetaTools'; > > load. > > > > During the week I will analyze the CUIS' ProtocolCatcher and see if it > make sense to put it there too. > > > > 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

Re: [Pharo-project] nebraska?

by StÃ©phane Ducasse

>> > > 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

March 20, 2010

Re: [Pharo-project] Move MetaObjectTools from core to PharoDev

by StÃ©phane Ducasse

Thanks I will do that! can you open a ticket because the list is starting to get long of the stuff to integrate after martin's changes. BTW did you check if the other class besides ProtocolCatcher are working? Stef On Mar 20, 2010, at 4:22 PM, Mariano Martinez Peck wrote: > This package should be removed from core but it should still be loadable. Thus, when needed, they can be easily installed. On the other hand, it could be in PharoDev image. > > - MetaObjectTools: This package is moved to PharoDev. It doesnt have any users in PharoCore > > To fix, evaluate: > > (MCPackage named: 'ObjectMetaTools') unload. > > I created and put such code in http://www.squeaksource.com/ObjectMetaTools > > To load it again in a Pharo image: > > Gofer new > squeaksource: 'ObjectMetaTools'; > package: 'ObjectMetaTools'; > load. > > During the week I will analyze the CUIS' ProtocolCatcher and see if it make sense to put it there too. > > Cheers > > Mariano > _______________________________________________ > 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] nebraska?

by Lawson English

Marcus Denker wrote: > On Mar 20, 2010, at 12:39 AM, Mariano Martinez Peck wrote: > > >> Hi Lawson. Nebraska was removed intentionally from Pharo. Basically, because we want a clean, tested and working core. >> >> ANY package that we don't consider core, should be removed and loadable. I mean, if you want to use Nebraska, perfect, no problem. But you should load it by yourself from squeaksource or whatever. In the core (actually, we still trying) we put ONLY core code. In the PharoDev we put mostly Core + Dev tools or examples. >> We don't believe Nebraska should be neither in PharoDev in my opinion. Of course, if people think the opposite, we can include it. >> >> Regardless the above said, I am not sure Nebraska is working on Pharo. I invite you to try to load it, ask for help, and tell us the results. Then you can create a Metacello configuration for it and make it easy to manage and install. >> > > So of course this idea of "just load it" is very difficult (impossible) to realize if the software in question was just hacked and put code everywere in the base system.... > I think after Nebraska was removed, we cleaned up the rendering of handmorph, for example. Nebraska complicates a far too complex Morphic system a bit. > > In general, nebraska is one of the examples (others are eToys and Genie), that where *very cool experiments*, but where the last important step was never done: > to learn from them and than build abstractions in the base system to make these things implementable in a nice way. > > I know that it's sad. And some people I am sure will think this is the wrong way to go. But we felt that cutting out complexity especially regarding things that are > not used is important if we want to move forward. > > Darn. I was hoping I was getting my plug and play P2P networking on Second Life-ST-based collaboration stuff for free. 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. OTOH, maybe Nebraska can be implemented on top of TeaTime/Cobalt once its available in Pharo. Lawson

March 20, 2010

[Pharo-project] Move MetaObjectTools from core to PharoDev

by Mariano Martinez Peck

This package should be removed from core but it should still be loadable. Thus, when needed, they can be easily installed. On the other hand, it could be in PharoDev image. - MetaObjectTools: This package is moved to PharoDev. It doesnt have any users in PharoCore To fix, evaluate: (MCPackage named: 'ObjectMetaTools') unload. I created and put such code in http://www.squeaksource.com/ObjectMetaTools<http://www.squeaksource.com/MetaObjectTools> To load it again in a Pharo image: Gofer new squeaksource: 'ObjectMetaTools'; package: 'ObjectMetaTools'; load. During the week I will analyze the CUIS' ProtocolCatcher and see if it make sense to put it there too. Cheers Mariano

March 20, 2010

[Pharo-project] isInMemory :)

by stephane ducasse

Mariano I was wondering (since we already removed a lot of the behavior related to inMemory) if we could not remove is in traitNames "Answer a SortedCollection of all traits (not including class-traits) names." | names | names := OrderedCollection new. self do: [:cl | (cl isInMemory and: [(cl isKindOf: Trait) and: [(cl name beginsWith: 'AnObsolete') not]]) ifTrue: [names add: cl name]]. ^ names and friend Stef

March 20, 2010

Re: [Pharo-project] on the way to smalltalkimage/systemdictionary

by StÃ©phane Ducasse

I'm doing the first step now. tx On Mar 20, 2010, at 2:50 PM, Igor Stasenko wrote: > On 20 March 2010 15:38, stephane ducasse <stephane.ducasse(a)free.fr> wrote: >> Hi guys >> >> I think that we should remove all the code that is not about class management from SystemDictionary. >> this is the easy part. >> >> Now what do we do for the class management behavior defined in Smalltalk image (allclasses, allTraits, associationsAt:, at:, at:put:.......) >> because now this code is in systemDictionary >> >> - we could replace Smalltalk >> by Smalltalk globals >> >> - deprecate the Smalltalk associationAt:.at:...and others >> >> What do you think? >> > > Yes. This is a logical step, which should follow the initial > refactoring, to slowly separate concerns and > create a clean and nice protocols. > >> Stef >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > 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] on the way to smalltalkimage/systemdictionary

by Igor Stasenko

On 20 March 2010 15:38, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > Hi guys > > I think that we should remove all the code that is not about class management from SystemDictionary. > this is the easy part. > > Now what do we do for the class management behavior defined in Smalltalk image (allclasses, allTraits, associationsAt:, at:, at:put:.......) > because now this code is in systemDictionary > > Â Â Â Â - we could replace Smalltalk > Â Â Â Â Â Â Â Â by Smalltalk globals > > Â Â Â Â - deprecate the Smalltalk associationAt:.at:...and others > > What do you think? > Yes. This is a logical step, which should follow the initial refactoring, to slowly separate concerns and create a clean and nice protocols. > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

March 20, 2010

[Pharo-project] on the way to smalltalkimage/systemdictionary

by stephane ducasse

Hi guys I think that we should remove all the code that is not about class management from SystemDictionary. this is the easy part. Now what do we do for the class management behavior defined in Smalltalk image (allclasses, allTraits, associationsAt:, at:, at:put:.......) because now this code is in systemDictionary - we could replace Smalltalk by Smalltalk globals - deprecate the Smalltalk associationAt:.at:...and others What do you think? Stef

March 20, 2010

Re: [Pharo-project] Pharo party at Annecy

by Hilaire Fernandes

Yes, I am comming. Hilaire laurent laffont a Ã©crit : > Yes. Will you come ? > > Laurent Laffont > > > On Sat, Mar 20, 2010 at 1:03 PM, Hilaire Fernandes > <hilaire(a)ofset.org > <mailto:hilaire@ofset.org>> wrote: > > Is it still maintained today at 14:00 ? > > Hilaire > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > <mailto:Pharo-project@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