- Pharo-dev - lists.pharo.org

Re: [Pharo-project] nebraska?

by Marcus Denker

On Mar 21, 2010, at 12:29 AM, Lawson English wrote: >>>> >>> Hi Marcus, actually I'm pretty sure most everyone on the Squeak side >>> agrees with you here. The real difference is that Squeak wants to >>> take the approach that we *do* that last step; >> >> Since when? for the last 12 years, this *never* happend. >> >> Marcus >> >> >> > > So why does everyone ignore TeaTime? I admit I don't understand the internals, but it obviously *looks* like it could be the basis of Nebraska (or any other P2P solution). > Can you point me to a real good publication about it? I mean, a *real* one? Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

March 20, 2010

Re: [Pharo-project] nebraska?

by Marcus Denker

On Mar 20, 2010, at 4:43 PM, Lawson English wrote: >> > > Darn. I was hoping I was getting my plug and play P2P networking on Second Life-ST-based collaboration stuff for free. > nothing is 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. > Hmm... I am now expert on either of Nebraska or Croquet... but I used Nebraska over the internet (vs. local network) once: When Alan gave his keynote at CERN using my computer. We had to use a 1-bit black-and-white hacked version of nebraska and nevertheless Alan had a lag of some seconds (!!!) between what happend on my machine and what he saw via nebraska on his. Of course, the talk went *perfect* and we could have sold Squeak/Nebraska to the audience as *the* collaboration tool. But in practice, this was barely usable. (on the local network it works quite well, though). > OTOH, maybe Nebraska can be implemented on top of TeaTime/Cobalt once its available in Pharo. This is definitlly the way to go: have a good model for cross-image replication, than use that as the basis. Having two mechanisms that work completely differently is bound to make more problems than you want to deal with. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

March 20, 2010

Re: [Pharo-project] nebraska?

by Lawson English

Marcus Denker wrote: > On Mar 20, 2010, at 10:41 PM, Chris Muller wrote: > > >>> 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. >>> >> Hi Marcus, actually I'm pretty sure most everyone on the Squeak side >> agrees with you here. The real difference is that Squeak wants to >> take the approach that we *do* that last step; >> > > Since when? for the last 12 years, this *never* happend. > > Marcus > > > So why does everyone ignore TeaTime? I admit I don't understand the internals, but it obviously *looks* like it could be the basis of Nebraska (or any other P2P solution). Lawson

March 20, 2010

Re: [Pharo-project] SmalltalkImage or SystemDictionary

by Lukas Renggli

FYI: The refactoring engine also uses this method quite heavily. Lukas On Saturday, March 20, 2010, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > hasSpecialSelector: ifTrueSetByte: > > is heavily used by SystemNavigation but either invoked via Smalltak or self environment or classEnviroment > > I would tend to think that this is something that should be part of SmalltalkImage but this is not that clear. > What do you think? > > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch

March 20, 2010

Re: [Pharo-project] about nextPut: returned argument

by StÃ©phane Ducasse

Cool since I like the idea. This is really where the ANSI standard shows that there were probably conflict of interest. > FWIW, Gemstone returns the arg.. > > Dale > ----- "stephane ducasse" <stephane.ducasse(a)free.fr> wrote: > > | hi guys > | > | I saw that nicolas fixed all the add: ... in squeak to return the > | argument and I like the idea I created an issue. > | Now I saw that nicolas fixed also nextPut: > | > | Item was changed: > | ----- Method: DummyStream>>nextPut: (in category 'accessing') ----- > | nextPut: aByte > | + "do nothing" > | + ^aByte! > | - "do nothing"! > | > | I checked the ANSI standard and this is unspecified. So I was > | wondering what the others dialects are doing? > | What do we do? > | > | 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

March 20, 2010

Re: [Pharo-project] about nextPut: returned argument

by StÃ©phane Ducasse

On Mar 20, 2010, at 11:00 PM, Nicolas Cellier wrote: > This is a very minor change, but to me as important as having class > comments, 'at last classified' categories etc... I imagine and for me I spent time looking at your squeak changes just for exactly the same reason. > My rationale is : > 1) #nextPut: #nextPutAll: are just like #add: #addAll: > 2) that's how they historically behave > 3) it's good to have homogeneity in the system yes but you did not reply to my question GS, VA, VW, GNU? Because before jumping to follow you I hold down my horses for once :) Stef

March 20, 2010

Re: [Pharo-project] nebraska?

by Marcus Denker

On Mar 20, 2010, at 10:41 PM, Chris Muller wrote: >> 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. > > Hi Marcus, actually I'm pretty sure most everyone on the Squeak side > agrees with you here. The real difference is that Squeak wants to > take the approach that we *do* that last step; Since when? for the last 12 years, this *never* happend. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

March 20, 2010

Re: [Pharo-project] nebraska?

by StÃ©phane Ducasse

Chris be sure that if somebody clean the core of morphic we are interested. >> 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. > > Hi Marcus, actually I'm pretty sure most everyone on the Squeak side > agrees with you here. The real difference is that Squeak wants to > take the approach that we *do* that last step; make the abstractions, > do the work, extricate it from Morphic, clean it up, make it loadable. > > For Pharo's direction and needs, Nebraska has, understandably, not > been not a priority. But why don't we move forward from always > highlighting philosophical (or other) differences anyway? The > interesting question is, can a single refactored-Nebraska work on both > Pharo and Squeak? Now it can be a read pain without the right infrastructure. Stef

March 20, 2010

Re: [Pharo-project] about nextPut: returned argument

by Dale Henrichs

FWIW, Gemstone returns the arg.. Dale ----- "stephane ducasse" <stephane.ducasse(a)free.fr> wrote: | hi guys | | I saw that nicolas fixed all the add: ... in squeak to return the | argument and I like the idea I created an issue. | Now I saw that nicolas fixed also nextPut: | | Item was changed: | ----- Method: DummyStream>>nextPut: (in category 'accessing') ----- | nextPut: aByte | + "do nothing" | + ^aByte! | - "do nothing"! | | I checked the ANSI standard and this is unspecified. So I was | wondering what the others dialects are doing? | What do we do? | | Stef | _______________________________________________ | 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] SmalltalkImage or SystemDictionary

by StÃ©phane Ducasse

On Mar 20, 2010, at 10:32 PM, Nicolas Cellier wrote: > 2010/3/20 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> hasSpecialSelector: ifTrueSetByte: >> >> is heavily used by SystemNavigation but either invoked via Smalltak or self environment or classEnviroment >> >> I would tend to think that this is something that should be part of SmalltalkImage but this is not that clear. >> What do you think? >> > > I just don't know. Since it is an information shared by the VM, maybe > it's better letting it here. After looking more at the code I think that SmalltalkImage is an ok place. > Just for curiousity, I checked how these special selectors where > shared in Encoder... Huh, not straightforward ! Well this was ok when the machines were that small and slow. Now the complexity to avoid just to have ifTrue: in literal arrays is not really worth. I would be curious to know the size we gain. Stef

March 20, 2010