On 7/29/2010 5:08 AM, David Faught wrote:
On 7/29/2010, Andreas Raab wrote:
- Create a local proxy for the replicated object and have it control
the replicated target. This has the advantage that you don't need to replicate the script but the disadvantage that the script is disassociated from the object and won't persist if the local user drops out.
- Replicate the script into the island and run it there. This is
obviously more in line with the ideas of Croquet but the thought of all the things that could go wrong led me to never go down this path.
Option number 2 is what I used in the MockTurtle demo. This project only used a code editor in the local proxy instead of tile scripting, and when the edit was accepted the script text was first locally syntax checked and then sent to the associated replicated object. This was actually lots of fun, but needed to have some "future"s handcoded in the edited source as I recall. Some keystrokes in the harness directed to the target replicated object caused editing or script execution to start. In my isolated testing, this worked just fine.
How did you deal with persistence and replication? One of the main issues with the approach is having to include compiled methods in the island snapshot. Or did you have an explicit "code sync" step before replicating the island contents?
I guess that I cheated by ignoring persistence and took a very simple minded approach. By choice there were no compiled methods. And yes, that limited its usefulness, but it was still lots of fun. The locally edited code was sent to the target replicated object as a text string and the replicated object saved it in a single instance variable, so each replicated object could have exactly one script. When the target object was triggered to run the code, it essentially did a "doIt" on the string. There wasn't anything more to it than that.
Cheers, Dave
On Thu, Jul 29, 2010 at 3:10 PM, David Faught dave.faught@gmail.com wrote:
On 7/29/2010 5:08 AM, David Faught wrote:
On 7/29/2010, Andreas Raab wrote:
- Create a local proxy for the replicated object and have it control
the replicated target. This has the advantage that you don't need to replicate the script but the disadvantage that the script is disassociated from the object and won't persist if the local user drops out.
- Replicate the script into the island and run it there. This is
obviously more in line with the ideas of Croquet but the thought of all the things that could go wrong led me to never go down this path.
Option number 2 is what I used in the MockTurtle demo. This project only used a code editor in the local proxy instead of tile scripting, and when the edit was accepted the script text was first locally syntax checked and then sent to the associated replicated object. This was actually lots of fun, but needed to have some "future"s handcoded in the edited source as I recall. Some keystrokes in the harness directed to the target replicated object caused editing or script execution to start. In my isolated testing, this worked just fine.
How did you deal with persistence and replication? One of the main issues with the approach is having to include compiled methods in the island snapshot. Or did you have an explicit "code sync" step before replicating the island contents?
I guess that I cheated by ignoring persistence and took a very simple minded approach. By choice there were no compiled methods. And yes, that limited its usefulness, but it was still lots of fun. The locally edited code was sent to the target replicated object as a text string and the replicated object saved it in a single instance variable, so each replicated object could have exactly one script. When the target object was triggered to run the code, it essentially did a "doIt" on the string. There wasn't anything more to it than that.
I never made any claims about this being a clever and elegant implementation, but it worked and was lots of fun and interesting to play with. I found out some things I never knew before, such as how to do recursion in a single "doIt" string. It was a simple enough case to experiment with some of the basic ideas. And I haven't seen or heard of anyone who has completed a similar or better version of this, outside of some discussion of the concepts. Here is my virtual gauntlet being thrown to the floor. I will gladly yield to anyone with a serious challenge.
Cheers, Dave
On Fri, Jul 30, 2010 at 7:07 AM, David Faught dave.faught@gmail.com wrote:
On Thu, Jul 29, 2010 at 3:10 PM, David Faught dave.faught@gmail.com wrote:
On 7/29/2010 5:08 AM, David Faught wrote:
On 7/29/2010, Andreas Raab wrote:
- Replicate the script into the island and run it there. This is
obviously more in line with the ideas of Croquet but the thought of all the things that could go wrong led me to never go down this path.
Option number 2 is what I used in the MockTurtle demo. This project only used a code editor in the local proxy instead of tile scripting, and when the edit was accepted the script text was first locally syntax checked and then sent to the associated replicated object. This was actually lots of fun, but needed to have some "future"s handcoded in the edited source as I recall. Some keystrokes in the harness directed to the target replicated object caused editing or script execution to start. In my isolated testing, this worked just fine.
How did you deal with persistence and replication? One of the main issues with the approach is having to include compiled methods in the island snapshot. Or did you have an explicit "code sync" step before replicating the island contents?
I guess that I cheated by ignoring persistence and took a very simple minded approach. By choice there were no compiled methods. And yes, that limited its usefulness, but it was still lots of fun. The locally edited code was sent to the target replicated object as a text string and the replicated object saved it in a single instance variable, so each replicated object could have exactly one script. When the target object was triggered to run the code, it essentially did a "doIt" on the string. There wasn't anything more to it than that.
I never made any claims about this being a clever and elegant implementation, but it worked and was lots of fun and interesting to play with. I found out some things I never knew before, such as how to do recursion in a single "doIt" string. It was a simple enough case to experiment with some of the basic ideas. And I haven't seen or heard of anyone who has completed a similar or better version of this, outside of some discussion of the concepts. Here is my virtual gauntlet being thrown to the floor. I will gladly yield to anyone with a serious challenge.
Hhmm, now that I think about it, there was a project at U. of Minnesota dealing with robots or NPCs, but I don't recall that project actually did any interactive scripting.
Cheers, Dave
squeak-dev@lists.squeakfoundation.org