nebraska?
Locked
12
12
 
|
I was fooling around and noticed that Nebraska isn't in the Pharo RC
image. Is it compatible at all with pharo, since it is based on Morphic? lawson _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
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. Cheers Mariano On Fri, Mar 19, 2010 at 10:41 PM, Lawson English <[hidden email]> wrote: I was fooling around and noticed that Nebraska isn't in the Pharo RC image. Is it compatible at all with pharo, since it is based on Morphic? _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
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. > Thanks, I did try to load it. I got various dependency issues which appeared to go back to: PluggableFileList>>morphicOpenLabel:in I found that in http://www.squeaksource.com/Pharo and attempted to load Morphic-MarcusDenker.551 but it had a nifty error that wasn't possible to read clearly because the error window was partly outside the boundries of the Phara desktop window and the interface froze. Although the system window was still dragable, none of the interior windows were. I eventually force-quit and tried again (3 times with same result). Lawson _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Mariano Martinez Peck
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. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
+1
sad for genie ;( may be now with the new event handler if should be esaier to plug > 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. > > Marcus > > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
This is something I will be interested to look at, but not right now yet.
Hilaire Stéphane Ducasse a écrit : > +1 > > sad for genie ;( > may be now with the new event handler if should be esaier to plug > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Would be really great.
Stef On Mar 20, 2010, at 8:34 AM, Hilaire Fernandes wrote: > This is something I will be interested to look at, but not right now yet. > > > Hilaire > > Stéphane Ducasse a écrit : >> +1 sad for genie ;( >> may be now with the new event handler if should be esaier to plug > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Marcus Denker-4
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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
>>
> > 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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
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 > 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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Marcus Denker-4
> 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? - Chris _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Chris Muller-3
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. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by LawsonEnglish
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. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by LawsonEnglish
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). > Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Burned out Sophie team members can talk to you about Tweak and TeaTime.... Don' t go there...
Not that "a bit of effort" couldn't "fix it" >> 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 -- =========================================================================== John M. McIntosh <[hidden email]> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com =========================================================================== _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
smime.p7s (3K) |
|
In reply to this post by Marcus Denker-4
On 3/20/10 4:35 PM, Marcus Denker wrote:
>> 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? AFAIK TeaTime never happened but they (Croquet/Cobalt) switched to some multiplayer game like sync scheme (at least the poor me understood when I saw the implementation ;-) ). Michael _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Marcus Denker-4
Marcus Denker wrote:
> 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 > > Nope. In fact, I was surprised to learn that Cobalt doesn't even use TeaTime and that the last version of Croquet that used it was around 0.3. Apparently network latency for reliable message sending of an entire 3D world was greater than expected, so it was tweaked almost out of existence, at least in its original form. I am often wrong about these things of course, so corrections are welcome. OTOH, even if its NOT suitable for message sending in Croquet/Cobalt, it seems intuitively obvious that it MIGHT still be viable for use in less demanding 2D P2P scenarios. At least, I'm hoping it will be, because honestly, SVN sucks and doesn't apply at all for some of the stuff I'm hoping to use squeak for: P2P backend for plugins in virtual world viewers to share collaborative projects, obects, physics and whatever else people can come up with. One could certainly make the case that smalltalk won''t be fast enough for the high end requirements of such use-cases, but as it stands now the infrastructure really isn't in place for testing even the lowest end (person to person collaboration without requiring a web host for clunky flash based-games and drawing apps). Imagine collaborative etoys or scrabble or whatever tunning on a prim in second life, well integrated into the SL 3D environment where the etoy is controlling a 3D environment that is used by about 1 million people per month. As it stands, I can use squeak to POST messages to individual objects in Second Life and control all of their programmable behavior via a seaside-rendered GUI in a HUD object. My intent is to bypass http and directly use the Second Life media plugin to render a Morphic widow or squeak desktop onto that HUD without the overhead of SVN or http or html and and thereby create the beginnings of a squeak plugin to SL. As an aside, while people debated the utility of making it easier to embed squeak in games and such, the SL scripting team that has been working over the past 4 years to replace the Linden Scripting Langage with the mono CLR and allow C#/etc programming of SL objects, considered using Squeak as the basis for scripting the open source Second Life viewer, and rejected it because they didn't think it a viable way to go for various reasons, all of which have been raised at one point or another in the debate about embedding squeak in general. They're now planing on using mono as the basis of viewer scripting... Oh well, opportunities lost.. Lawson _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
>>
> > Nope. In fact, I was surprised to learn that Cobalt doesn't even use TeaTime and that the last version of Croquet that used it was around 0.3. Apparently network latency for reliable message sending of an entire 3D world was greater than expected, so it was tweaked almost out of existence, at least in its original form. I am often wrong about these things of course, so corrections are welcome. > > OTOH, even if its NOT suitable for message sending in Croquet/Cobalt, it seems intuitively obvious that it MIGHT still be viable for use in less demanding 2D P2P scenarios. > > At least, I'm hoping it will be, because honestly, SVN sucks and doesn't apply at all for some of the stuff I'm hoping to use squeak for: P2P backend for plugins in virtual world viewers to share collaborative projects, obects, physics and whatever else people can come up with. One could certainly make the case that smalltalk won''t be fast enough for the high end requirements of such use-cases, but as it stands now the infrastructure really isn't in place for testing even the lowest end (person to person collaboration without requiring a web host for clunky flash based-games and drawing apps). Imagine collaborative etoys or scrabble or whatever tunning on a prim in second life, well integrated into the SL 3D environment where the etoy is controlling a 3D environment that is used by about 1 million people per month. > > As it stands, I can use squeak to POST messages to individual objects in Second Life and control all of their programmable behavior via a seaside-rendered GUI in a HUD object. My intent is to bypass http and directly use the Second Life media plugin to render a Morphic widow or squeak desktop onto that HUD without the overhead of SVN or http or html and and thereby create the beginnings of a squeak plugin to SL. > > As an aside, while people debated the utility of making it easier to embed squeak in games and such, the SL scripting team that has been working over the past 4 years to replace the Linden Scripting Langage with the mono CLR and allow C#/etc programming of SL objects, considered using Squeak as the basis for scripting the open source Second Life viewer, and rejected it because they didn't think it a viable way to go for various reasons, all of which have been raised at one point or another in the debate about embedding squeak in general. I can imagine. When a smart guy opened Squeak in the past, his first reaction was to laugh or cry. (I do not say that against squeak - I got so burned by people looking at me in this strange way when I said that smalltalk was cool and they opened squeak in the past). > They're now planing on using mono as the basis of viewer scripting... Obvious I would say. > > Oh well, opportunities lost.. Yes and this is what we are trying to fix. Make a credible opensource smalltalk. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |