Smalltalk
› Squeak
› Croquet
›
Croquet - Dev
more scripting discussion
Locked
 
|
The type of scripting that I (and I think a few others) favor runs
inside the replicated island and deals with in-island objects directly, although there may be an API to hide and expose particular object properties and methods. One reason for favoring this type of scripting is to reduce network bandwidth by depending on replicated computation. I keep falling back on my experience with MockTurtle as limited scripting of this type. One thing that came up in MockTurtle as a result of the recursion discussion at http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-November/111662.html was that I needed to put in #future: messages in the recursive call in order to "give up control" and allow rendering to interleave with the script execution. Otherwise the script execution just ran to completion without rendering ever happening until the end. This kind of effect is something to keep in mind when designing control structures for this type of scripting language. I guess that this would be a similar idea to the EToys clock timer. The only drawback with this is that each #future: message gets replicated out across the network, so there is an overhead that may not be strictly necessary. A conscious decision that I made in designing the end-user interaction with MockTurtle scripting was to put the script editing strictly in the local non-replicated UI. I thought that replicating all the individual keystrokes of the editing would add a lot of unneeded overhead to the process. When editing is complete and the script is accepted, only then does it get sent to the target in-island replicated object. At that point, because it has been replicated, any other participant can request that the script be sent back to their local UI to look at as an example, or for further editing. This design was chosen for efficiency, not necessarily for value. I could see the value of at least being able to view the script inside the island, if not full editing, for teaching purposes or collaborative discussion. What are your thoughts about these issues? Dave |
Re: more scripting discussion
|
|
I'm someone that's been basically sitting at the sidelines who has more experience with SecondLife than Croquet, but let's see how this goes...
While designing script in SecondLife, most of my time is spent staring at windows where nothing important really happens until I push the "save" button. Because of this, I doubt that the script editor should really be replicated in-world, and that this should probably be made obvious with the editor not being a window within the islandspace (by default). I also however see a need for the ability for a participant to open up a morphic window within croquet space where others could see (and participate) in manipulating his/her nonreplicated window (any window, not just the proposed script editor); in this way someone could have either a replicated or nonreplicated script window, but either way the script changes are not sent to the island until the save button is pushed. I'm also curious in knowing what the scripting would look like. Would it be translated directly to smalltalk for speed or kept in an interpreted language closer to the "turn right 10" that is visible elsewhere in the system? Since this scripting would be a way of introducing people towards creating island content, the ability to see your code translated to smalltalk could end up being a good tutorial for people wanting to make the leap towards more powerful coding, although I do recognize that such script could be mechanically translated no matter what its internal implementation ends up looking like. On 9/28/07, David Faught <[hidden email]> wrote: The type of scripting that I (and I think a few others) favor runs |
|
|
Hi Erik,
On 9/28/07, Erik Anderson <[hidden email]> wrote: > I'm someone that's been basically sitting at the sidelines who has more > experience with SecondLife than Croquet, but let's see how this goes... > > While designing script in SecondLife, most of my time is spent staring at > windows where nothing important really happens until I push the "save" > button. Because of this, I doubt that the script editor should really be > replicated in-world, and that this should probably be made obvious with the > editor not being a window within the islandspace (by default). I also > however see a need for the ability for a participant to open up a morphic > window within croquet space where others could see (and participate) in > manipulating his/her nonreplicated window (any window, not just the proposed > script editor); in this way someone could have either a replicated or > nonreplicated script window, but either way the script changes are not sent > to the island until the save button is pushed. To me this sounds similar to the Filters and Tasks white paper at http://croquetconsortium.org/index.php/About_the_Technology#Selected_Papers.2FPublications I would love to have a single window type that could be changed between replicated or non-replicated at will, complete with a nice UI widget set that behaves likewise. I think there may be some beginnings of this somewhere in Croquet, but I haven't seen a nice complete example in the SDK. > I'm also curious in knowing what the scripting would look like. Would it be > translated directly to smalltalk for speed or kept in an interpreted > language closer to the "turn right 10" that is visible elsewhere in the > system? Since this scripting would be a way of introducing people towards > creating island content, the ability to see your code translated to > smalltalk could end up being a good tutorial for people wanting to make the > leap towards more powerful coding, although I do recognize that such script > could be mechanically translated no matter what its internal implementation > ends up looking like. The choice of translating, compiling, or interpreting is, I think, still undecided. I'm not sure that this type of scripting would lead up to anything. I think it would just be an additional mechanism to the smalltalk code. Dave > On 9/28/07, David Faught <[hidden email]> wrote: > > The type of scripting that I (and I think a few others) favor runs > > inside the replicated island and deals with in-island objects > > directly, although there may be an API to hide and expose particular > > object properties and methods. One reason for favoring this type of > > scripting is to reduce network bandwidth by depending on replicated > > computation. > > > > I keep falling back on my experience with MockTurtle as limited > > scripting of this type. One thing that came up in MockTurtle as a > > result of the recursion discussion at > > > http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-November/111662.html > > was that I needed to put in #future: messages in the recursive call in > > order to "give up control" and allow rendering to interleave with the > > script execution. Otherwise the script execution just ran to > > completion without rendering ever happening until the end. This kind > > of effect is something to keep in mind when designing control > > structures for this type of scripting language. I guess that this > > would be a similar idea to the EToys clock timer. The only drawback > > with this is that each #future: message gets replicated out across the > > network, so there is an overhead that may not be strictly necessary. > > > > A conscious decision that I made in designing the end-user interaction > > with MockTurtle scripting was to put the script editing strictly in > > the local non-replicated UI. I thought that replicating all the > > individual keystrokes of the editing would add a lot of unneeded > > overhead to the process. When editing is complete and the script is > > accepted, only then does it get sent to the target in-island > > replicated object. At that point, because it has been replicated, any > > other participant can request that the script be sent back to their > > local UI to look at as an example, or for further editing. This > > design was chosen for efficiency, not necessarily for value. I could > > see the value of at least being able to view the script inside the > > island, if not full editing, for teaching purposes or collaborative > > discussion. > > > > What are your thoughts about these issues? > > > > Dave > > > > |
«
Return to Croquet - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |