Problem regarding replication of an object

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
RC
Reply | Threaded
Open this post in threaded view
|

Problem regarding replication of an object

RC
Hello, List.

I am attempting to modify the KAT demo so that an MPEG is displayed at start-up and then moved from its initial location a little while later.  The code I've assembled to do this works great when there are no collaborators replicating my island.  As soon as someone attempts to join, however, my Croquet session bombs and I see "Checkpoint failure - searching image references..." indicating an attempt to reference objects that have not been replicated.

I'm rather at a loss as to how to fix this; I've read the Croquet Programming Guide, reviewed this email list, and picked through the demos.  My sense is that there is something easy I'm overlooking.  Can anyone offer some insight into my error?  

Thanks in advance for any help!

Below is a synopsis of what I'm doing (code-wise):


1)  I use a subclass of TFrame (called MovieScreen) to create a TFrame and embed an MPEG player:

MovieScreen1>>configureWithURI: uri extent: movieExtentSize location:

  "Instantiate a movie as an embedded application."
  movie := TEmbeddedApp name: #TMorphicWorld extent: movieExtentSize data: { #makeMovie: . uri }.

  "Set the size of the movie display..."
  self extent: movieExtentSize.

  "...and add the movie to ourselves (recall that we're a subclass of TFrame)."
  self addChild: movie.


2)  Because I would like to alter the MovieScreen1 object's translation later on (while other end-users are collaborating in the KAT demo), I use the following to make it and its embedded MPEG player available to all replicated islands:

  space := self parent.

  movieRef := island new: MovieScreen1.
  movieRef configureWithURI: (movieURIs at: 1) extent: movieExtentSize location: initialTranslation.
  space addChild: movieRef.

Later on, the next bit of code is used to access the MovieScreen1 object:

  "Locate the movie screen we created earlier and change its
  translation."

  screen1 := (space find: [:frm | frm objectName = 'aMovieScreen1']) at: 1.
  screen1 translation: (movieScreenTranslations at: 2).


3)  The snippets of code in 2) reside in the 'step' method of a TVehicle subclass called 'TestLoop'.  This TVehicle subclass is instantiated inside of WisconsinWorld>>initialize with:

  mainLoop := TestLoop new initialize: self island.

  space addChild: mainLoop.

  mainLoop stepping: true.
  mainLoop startStepping.


Reply | Threaded
Open this post in threaded view
|

Re: Problem regarding replication of an object

Howard Stearns-3
Hi Richard,

I am suspicious of the reference to island in (2). Referring to the  
island in which you are running is kind of like referring to your own  
computer or operating system. Pretty rare, unless you're doing  
something like asking for the current time.  In general, all the  
replicated code executing on an island should just be normal single-
threaded Smalltalk code, without involving any far references:

   screen := MovieScreen1 new.
   screen configureWithURI: (movieURIs at: 1) extent: movieExtentSize  
location: initialTranslation.
   etc.

and in (3)
   mainLoop := TestLoop new.

-H

On Nov 4, 2007, at 1:05 PM, RC wrote:

>
> Hello, List.
>
> I am attempting to modify the KAT demo so that an MPEG is displayed at
> start-up and then moved from its initial location a little while  
> later.  The
> code I've assembled to do this works great when there are no  
> collaborators
> replicating my island.  As soon as someone attempts to join,  
> however, my
> Croquet session bombs and I see "Checkpoint failure - searching image
> references..." indicating an attempt to reference objects that have  
> not been
> replicated.
>
> I'm rather at a loss as to how to fix this; I've read the Croquet
> Programming Guide, reviewed this email list, and picked through the  
> demos.
> My sense is that there is something easy I'm overlooking.  Can  
> anyone offer
> some insight into my error?
>
> Thanks in advance for any help!
>
> Below is a synopsis of what I'm doing (code-wise):
>
>
> 1)  I use a subclass of TFrame (called MovieScreen) to create a  
> TFrame and
> embed an MPEG player:
>
> MovieScreen1>>configureWithURI: uri extent: movieExtentSize location:
>
>   "Instantiate a movie as an embedded application."
>   movie := TEmbeddedApp name: #TMorphicWorld extent:  
> movieExtentSize data: {
> #makeMovie: . uri }.
>
>   "Set the size of the movie display..."
>   self extent: movieExtentSize.
>
>   "...and add the movie to ourselves (recall that we're a subclass of
> TFrame)."
>   self addChild: movie.
>
>
> 2)  Because I would like to alter the MovieScreen1 object's  
> translation
> later on (while other end-users are collaborating in the KAT demo),  
> I use
> the following to make it and its embedded MPEG player available to all
> replicated islands:
>
>   space := self parent.
>
>   movieRef := island new: MovieScreen1.
>   movieRef configureWithURI: (movieURIs at: 1) extent: movieExtentSize
> location: initialTranslation.
>   space addChild: movieRef.
>
> Later on, the next bit of code is used to access the MovieScreen1  
> object:
>
>   "Locate the movie screen we created earlier and change its
>   translation."
>
>   screen1 := (space find: [:frm | frm objectName =  
> 'aMovieScreen1']) at: 1.
>   screen1 translation: (movieScreenTranslations at: 2).
>
>
> 3)  The snippets of code in 2) reside in the 'step' method of a  
> TVehicle
> subclass called 'TestLoop'.  This TVehicle subclass is instantiated  
> inside
> of WisconsinWorld>>initialize with:
>
>   mainLoop := TestLoop new initialize: self island.
>
>   space addChild: mainLoop.
>
>   mainLoop stepping: true.
>   mainLoop startStepping.
>
>
>
> --
> View this message in context: http://www.nabble.com/Problem- 
> regarding-replication-of-an-object-tf4748046.html#a13576629
> Sent from the Croquet - Dev mailing list archive at Nabble.com.
>

RC
Reply | Threaded
Open this post in threaded view
|

Re: Problem regarding replication of an object

RC
Thanks for your response, Howard!

My reference for the code I used in item 2 is found at http://osdir.com/ml/lang.smalltalk.croquet.devel/2006-11/msg00036.html.  There, you'll see a very interesting discussion about how to add a new object into a Croquet environment such that the object may be shared among replicated islands.  The author is Josh Gargus, I believe.

Perhaps my situation doesn't require the use of 'island' given that I'm creating the object in question during the initialization of the first island?  (By all means, please correct my sense of things if I'm wrong...I'm still trying very hard to get my "Croquet legs" underneath me.)

I should point out that I fixed my problem.  Apparently, Croquet is good with the use of 'fork' for in-island stuff...but not so happy about forking processes that deal with replicated objects outside of their originating island.  So, upon removing the use of 'fork' in the TVehicle 'step' method (item 3 from my original message), everything works quite well.

I realize I failed to mention my use of 'fork' to begin with:  I honestly had no idea it would be trouble!  I was using it to help time some activities in the 'step' method (e.g., forking off a block with a 'wait' in it so as to run the delay in the background).  I suppose I should just use 'future' messages instead?

I'll report back on how things turn out after I remove the 'island' identifier from my code.

Thanks again,

-RC

Howard Stearns-3 wrote
Hi Richard,

I am suspicious of the reference to island in (2). Referring to the  
island in which you are running is kind of like referring to your own  
computer or operating system. Pretty rare, unless you're doing  
something like asking for the current time.  In general, all the  
replicated code executing on an island should just be normal single-
threaded Smalltalk code, without involving any far references:

   screen := MovieScreen1 new.
   screen configureWithURI: (movieURIs at: 1) extent: movieExtentSize  
location: initialTranslation.
   etc.

and in (3)
   mainLoop := TestLoop new.

-H

On Nov 4, 2007, at 1:05 PM, RC wrote:

>
> Hello, List.
>
> I am attempting to modify the KAT demo so that an MPEG is displayed at
> start-up and then moved from its initial location a little while  
> later.  The
> code I've assembled to do this works great when there are no  
> collaborators
> replicating my island.  As soon as someone attempts to join,  
> however, my
> Croquet session bombs and I see "Checkpoint failure - searching image
> references..." indicating an attempt to reference objects that have  
> not been
> replicated.
>
> I'm rather at a loss as to how to fix this; I've read the Croquet
> Programming Guide, reviewed this email list, and picked through the  
> demos.
> My sense is that there is something easy I'm overlooking.  Can  
> anyone offer
> some insight into my error?
>
> Thanks in advance for any help!
>
> Below is a synopsis of what I'm doing (code-wise):
>
>
> 1)  I use a subclass of TFrame (called MovieScreen) to create a  
> TFrame and
> embed an MPEG player:
>
> MovieScreen1>>configureWithURI: uri extent: movieExtentSize location:
>
>   "Instantiate a movie as an embedded application."
>   movie := TEmbeddedApp name: #TMorphicWorld extent:  
> movieExtentSize data: {
> #makeMovie: . uri }.
>
>   "Set the size of the movie display..."
>   self extent: movieExtentSize.
>
>   "...and add the movie to ourselves (recall that we're a subclass of
> TFrame)."
>   self addChild: movie.
>
>
> 2)  Because I would like to alter the MovieScreen1 object's  
> translation
> later on (while other end-users are collaborating in the KAT demo),  
> I use
> the following to make it and its embedded MPEG player available to all
> replicated islands:
>
>   space := self parent.
>
>   movieRef := island new: MovieScreen1.
>   movieRef configureWithURI: (movieURIs at: 1) extent: movieExtentSize
> location: initialTranslation.
>   space addChild: movieRef.
>
> Later on, the next bit of code is used to access the MovieScreen1  
> object:
>
>   "Locate the movie screen we created earlier and change its
>   translation."
>
>   screen1 := (space find: [:frm | frm objectName =  
> 'aMovieScreen1']) at: 1.
>   screen1 translation: (movieScreenTranslations at: 2).
>
>
> 3)  The snippets of code in 2) reside in the 'step' method of a  
> TVehicle
> subclass called 'TestLoop'.  This TVehicle subclass is instantiated  
> inside
> of WisconsinWorld>>initialize with:
>
>   mainLoop := TestLoop new initialize: self island.
>
>   space addChild: mainLoop.
>
>   mainLoop stepping: true.
>   mainLoop startStepping.
>
>
>
> --
> View this message in context: http://www.nabble.com/Problem- 
> regarding-replication-of-an-object-tf4748046.html#a13576629
> Sent from the Croquet - Dev mailing list archive at Nabble.com.
>
Reply | Threaded
Open this post in threaded view
|

Re: Problem regarding replication of an object

Howard Stearns-3
I can't find the 'fork' in the code below, nor in TVehicle.  There  
shouldn't be.

Croquet evaluation is based on an event loop model, in which easy  
message is executed in its entirety, to completion, as a single  
thread.  If you want to do stuff over time, use temporal recursion  
(e.g., (self future: someMilliseconds) someMethod).  This used to be  
described as "temporal recursion" in "Croquet Programming -> Croquet  
System Overview -> Timing is everything", although I can't find it  
now on the Consortium web site.

For things OUTSIDE of Croquet -- non-replicated code -- you can fork,  
but then you're in the realm of all the messy stuff that Croquet  
frees you from.

On Nov 5, 2007, at 12:54 PM, RC wrote:

>
> Thanks for your response, Howard!
>
> My reference for the code I used in item 2 is found at
> http://osdir.com/ml/lang.smalltalk.croquet.devel/2006-11/ 
> msg00036.html.
> There, you'll see a very interesting discussion about how to add a new
> object into a Croquet environment such that the object may be  
> shared among
> replicated islands.  The author is Josh Gargus, I believe.
>
> Perhaps my situation doesn't require the use of 'island' given that  
> I'm
> creating the object in question during the initialization of the first
> island?  (By all means, please correct my sense of things if I'm  
> wrong...I'm
> still trying very hard to get my "Croquet legs" underneath me.)
>
> I should point out that I fixed my problem.  Apparently, Croquet is  
> good
> with the use of 'fork' for in-island stuff...but not so happy about  
> forking
> processes that deal with replicated objects outside of their  
> originating
> island.  So, upon removing the use of 'fork' in the TVehicle 'step'  
> method
> (item 3 from my original message), everything works quite well.
>
> I realize I failed to mention my use of 'fork' to begin with:  I  
> honestly
> had no idea it would be trouble!  I was using it to help time some
> activities in the 'step' method (e.g., forking off a block with a  
> 'wait' in
> it so as to run the delay in the background).  I suppose I should  
> just use
> 'future' messages instead?
>
> I'll report back on how things turn out after I remove the 'island'
> identifier from my code.
>
> Thanks again,
>
> -RC
>
>
> Howard Stearns-3 wrote:
>>
>> Hi Richard,
>>
>> I am suspicious of the reference to island in (2). Referring to the
>> island in which you are running is kind of like referring to your own
>> computer or operating system. Pretty rare, unless you're doing
>> something like asking for the current time.  In general, all the
>> replicated code executing on an island should just be normal single-
>> threaded Smalltalk code, without involving any far references:
>>
>>    screen := MovieScreen1 new.
>>    screen configureWithURI: (movieURIs at: 1) extent: movieExtentSize
>> location: initialTranslation.
>>    etc.
>>
>> and in (3)
>>    mainLoop := TestLoop new.
>>
>> -H
>>
>> On Nov 4, 2007, at 1:05 PM, RC wrote:
>>
>>>
>>> Hello, List.
>>>
>>> I am attempting to modify the KAT demo so that an MPEG is  
>>> displayed at
>>> start-up and then moved from its initial location a little while
>>> later.  The
>>> code I've assembled to do this works great when there are no
>>> collaborators
>>> replicating my island.  As soon as someone attempts to join,
>>> however, my
>>> Croquet session bombs and I see "Checkpoint failure - searching  
>>> image
>>> references..." indicating an attempt to reference objects that have
>>> not been
>>> replicated.
>>>
>>> I'm rather at a loss as to how to fix this; I've read the Croquet
>>> Programming Guide, reviewed this email list, and picked through the
>>> demos.
>>> My sense is that there is something easy I'm overlooking.  Can
>>> anyone offer
>>> some insight into my error?
>>>
>>> Thanks in advance for any help!
>>>
>>> Below is a synopsis of what I'm doing (code-wise):
>>>
>>>
>>> 1)  I use a subclass of TFrame (called MovieScreen) to create a
>>> TFrame and
>>> embed an MPEG player:
>>>
>>> MovieScreen1>>configureWithURI: uri extent: movieExtentSize  
>>> location:
>>>
>>>   "Instantiate a movie as an embedded application."
>>>   movie := TEmbeddedApp name: #TMorphicWorld extent:
>>> movieExtentSize data: {
>>> #makeMovie: . uri }.
>>>
>>>   "Set the size of the movie display..."
>>>   self extent: movieExtentSize.
>>>
>>>   "...and add the movie to ourselves (recall that we're a  
>>> subclass of
>>> TFrame)."
>>>   self addChild: movie.
>>>
>>>
>>> 2)  Because I would like to alter the MovieScreen1 object's
>>> translation
>>> later on (while other end-users are collaborating in the KAT demo),
>>> I use
>>> the following to make it and its embedded MPEG player available  
>>> to all
>>> replicated islands:
>>>
>>>   space := self parent.
>>>
>>>   movieRef := island new: MovieScreen1.
>>>   movieRef configureWithURI: (movieURIs at: 1) extent:  
>>> movieExtentSize
>>> location: initialTranslation.
>>>   space addChild: movieRef.
>>>
>>> Later on, the next bit of code is used to access the MovieScreen1
>>> object:
>>>
>>>   "Locate the movie screen we created earlier and change its
>>>   translation."
>>>
>>>   screen1 := (space find: [:frm | frm objectName =
>>> 'aMovieScreen1']) at: 1.
>>>   screen1 translation: (movieScreenTranslations at: 2).
>>>
>>>
>>> 3)  The snippets of code in 2) reside in the 'step' method of a
>>> TVehicle
>>> subclass called 'TestLoop'.  This TVehicle subclass is instantiated
>>> inside
>>> of WisconsinWorld>>initialize with:
>>>
>>>   mainLoop := TestLoop new initialize: self island.
>>>
>>>   space addChild: mainLoop.
>>>
>>>   mainLoop stepping: true.
>>>   mainLoop startStepping.
>>>
>>>
>>>
>>> --
>>> View this message in context: http://www.nabble.com/Problem-
>>> regarding-replication-of-an-object-tf4748046.html#a13576629
>>> Sent from the Croquet - Dev mailing list archive at Nabble.com.
>>>
>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Problem- 
> regarding-replication-of-an-object-tf4748046.html#a13593115
> Sent from the Croquet - Dev mailing list archive at Nabble.com.
>

RC
Reply | Threaded
Open this post in threaded view
|

Re: Problem regarding replication of an object

RC
Right--sorry, I was unclear...  I had failed to mention that I was using 'fork' in the TVehicle's 'step' method in my first message.  Moreover, I didn't bother including the 'fork' code in my Squeak snippets because it didn't seem relevant at the time.

Your last response confirms my suspicions that I can/should use 'future' messages to handle what I was trying to use 'fork' to do.

Thanks,

-RC

Howard Stearns-3 wrote
I can't find the 'fork' in the code below, nor in TVehicle.  There  
shouldn't be.

Croquet evaluation is based on an event loop model, in which easy  
message is executed in its entirety, to completion, as a single  
thread.  If you want to do stuff over time, use temporal recursion  
(e.g., (self future: someMilliseconds) someMethod).  This used to be  
described as "temporal recursion" in "Croquet Programming -> Croquet  
System Overview -> Timing is everything", although I can't find it  
now on the Consortium web site.

For things OUTSIDE of Croquet -- non-replicated code -- you can fork,  
but then you're in the realm of all the messy stuff that Croquet  
frees you from.

On Nov 5, 2007, at 12:54 PM, RC wrote:

>
> Thanks for your response, Howard!
>
> My reference for the code I used in item 2 is found at
> http://osdir.com/ml/lang.smalltalk.croquet.devel/2006-11/ 
> msg00036.html.
> There, you'll see a very interesting discussion about how to add a new
> object into a Croquet environment such that the object may be  
> shared among
> replicated islands.  The author is Josh Gargus, I believe.
>
> Perhaps my situation doesn't require the use of 'island' given that  
> I'm
> creating the object in question during the initialization of the first
> island?  (By all means, please correct my sense of things if I'm  
> wrong...I'm
> still trying very hard to get my "Croquet legs" underneath me.)
>
> I should point out that I fixed my problem.  Apparently, Croquet is  
> good
> with the use of 'fork' for in-island stuff...but not so happy about  
> forking
> processes that deal with replicated objects outside of their  
> originating
> island.  So, upon removing the use of 'fork' in the TVehicle 'step'  
> method
> (item 3 from my original message), everything works quite well.
>
> I realize I failed to mention my use of 'fork' to begin with:  I  
> honestly
> had no idea it would be trouble!  I was using it to help time some
> activities in the 'step' method (e.g., forking off a block with a  
> 'wait' in
> it so as to run the delay in the background).  I suppose I should  
> just use
> 'future' messages instead?
>
> I'll report back on how things turn out after I remove the 'island'
> identifier from my code.
>
> Thanks again,
>
> -RC
>
>
> Howard Stearns-3 wrote:
>>
>> Hi Richard,
>>
>> I am suspicious of the reference to island in (2). Referring to the
>> island in which you are running is kind of like referring to your own
>> computer or operating system. Pretty rare, unless you're doing
>> something like asking for the current time.  In general, all the
>> replicated code executing on an island should just be normal single-
>> threaded Smalltalk code, without involving any far references:
>>
>>    screen := MovieScreen1 new.
>>    screen configureWithURI: (movieURIs at: 1) extent: movieExtentSize
>> location: initialTranslation.
>>    etc.
>>
>> and in (3)
>>    mainLoop := TestLoop new.
>>
>> -H
>>
>> On Nov 4, 2007, at 1:05 PM, RC wrote:
>>
>>>
>>> Hello, List.
>>>
>>> I am attempting to modify the KAT demo so that an MPEG is  
>>> displayed at
>>> start-up and then moved from its initial location a little while
>>> later.  The
>>> code I've assembled to do this works great when there are no
>>> collaborators
>>> replicating my island.  As soon as someone attempts to join,
>>> however, my
>>> Croquet session bombs and I see "Checkpoint failure - searching  
>>> image
>>> references..." indicating an attempt to reference objects that have
>>> not been
>>> replicated.
>>>
>>> I'm rather at a loss as to how to fix this; I've read the Croquet
>>> Programming Guide, reviewed this email list, and picked through the
>>> demos.
>>> My sense is that there is something easy I'm overlooking.  Can
>>> anyone offer
>>> some insight into my error?
>>>
>>> Thanks in advance for any help!
>>>
>>> Below is a synopsis of what I'm doing (code-wise):
>>>
>>>
>>> 1)  I use a subclass of TFrame (called MovieScreen) to create a
>>> TFrame and
>>> embed an MPEG player:
>>>
>>> MovieScreen1>>configureWithURI: uri extent: movieExtentSize  
>>> location:
>>>
>>>   "Instantiate a movie as an embedded application."
>>>   movie := TEmbeddedApp name: #TMorphicWorld extent:
>>> movieExtentSize data: {
>>> #makeMovie: . uri }.
>>>
>>>   "Set the size of the movie display..."
>>>   self extent: movieExtentSize.
>>>
>>>   "...and add the movie to ourselves (recall that we're a  
>>> subclass of
>>> TFrame)."
>>>   self addChild: movie.
>>>
>>>
>>> 2)  Because I would like to alter the MovieScreen1 object's
>>> translation
>>> later on (while other end-users are collaborating in the KAT demo),
>>> I use
>>> the following to make it and its embedded MPEG player available  
>>> to all
>>> replicated islands:
>>>
>>>   space := self parent.
>>>
>>>   movieRef := island new: MovieScreen1.
>>>   movieRef configureWithURI: (movieURIs at: 1) extent:  
>>> movieExtentSize
>>> location: initialTranslation.
>>>   space addChild: movieRef.
>>>
>>> Later on, the next bit of code is used to access the MovieScreen1
>>> object:
>>>
>>>   "Locate the movie screen we created earlier and change its
>>>   translation."
>>>
>>>   screen1 := (space find: [:frm | frm objectName =
>>> 'aMovieScreen1']) at: 1.
>>>   screen1 translation: (movieScreenTranslations at: 2).
>>>
>>>
>>> 3)  The snippets of code in 2) reside in the 'step' method of a
>>> TVehicle
>>> subclass called 'TestLoop'.  This TVehicle subclass is instantiated
>>> inside
>>> of WisconsinWorld>>initialize with:
>>>
>>>   mainLoop := TestLoop new initialize: self island.
>>>
>>>   space addChild: mainLoop.
>>>
>>>   mainLoop stepping: true.
>>>   mainLoop startStepping.
>>>
>>>
>>>
>>> --
>>> View this message in context: http://www.nabble.com/Problem-
>>> regarding-replication-of-an-object-tf4748046.html#a13576629
>>> Sent from the Croquet - Dev mailing list archive at Nabble.com.
>>>
>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Problem- 
> regarding-replication-of-an-object-tf4748046.html#a13593115
> Sent from the Croquet - Dev mailing list archive at Nabble.com.
>
RC
Reply | Threaded
Open this post in threaded view
|

Re: Problem regarding replication of an object

RC
Quick follow-up:  indeed, the use of 'island' in the code snippets from my original message was superfluous.  Everything works fine without it (and, of course, without fork!).

-RC

RC wrote
Right--sorry, I was unclear...  I had failed to mention that I was using 'fork' in the TVehicle's 'step' method in my first message.  Moreover, I didn't bother including the 'fork' code in my Squeak snippets because it didn't seem relevant at the time.

Your last response confirms my suspicions that I can/should use 'future' messages to handle what I was trying to use 'fork' to do.

Thanks,

-RC

Howard Stearns-3 wrote
I can't find the 'fork' in the code below, nor in TVehicle.  There  
shouldn't be.

Croquet evaluation is based on an event loop model, in which easy  
message is executed in its entirety, to completion, as a single  
thread.  If you want to do stuff over time, use temporal recursion  
(e.g., (self future: someMilliseconds) someMethod).  This used to be  
described as "temporal recursion" in "Croquet Programming -> Croquet  
System Overview -> Timing is everything", although I can't find it  
now on the Consortium web site.

For things OUTSIDE of Croquet -- non-replicated code -- you can fork,  
but then you're in the realm of all the messy stuff that Croquet  
frees you from.

On Nov 5, 2007, at 12:54 PM, RC wrote:

>
> Thanks for your response, Howard!
>
> My reference for the code I used in item 2 is found at
> http://osdir.com/ml/lang.smalltalk.croquet.devel/2006-11/ 
> msg00036.html.
> There, you'll see a very interesting discussion about how to add a new
> object into a Croquet environment such that the object may be  
> shared among
> replicated islands.  The author is Josh Gargus, I believe.
>
> Perhaps my situation doesn't require the use of 'island' given that  
> I'm
> creating the object in question during the initialization of the first
> island?  (By all means, please correct my sense of things if I'm  
> wrong...I'm
> still trying very hard to get my "Croquet legs" underneath me.)
>
> I should point out that I fixed my problem.  Apparently, Croquet is  
> good
> with the use of 'fork' for in-island stuff...but not so happy about  
> forking
> processes that deal with replicated objects outside of their  
> originating
> island.  So, upon removing the use of 'fork' in the TVehicle 'step'  
> method
> (item 3 from my original message), everything works quite well.
>
> I realize I failed to mention my use of 'fork' to begin with:  I  
> honestly
> had no idea it would be trouble!  I was using it to help time some
> activities in the 'step' method (e.g., forking off a block with a  
> 'wait' in
> it so as to run the delay in the background).  I suppose I should  
> just use
> 'future' messages instead?
>
> I'll report back on how things turn out after I remove the 'island'
> identifier from my code.
>
> Thanks again,
>
> -RC
>
>
> Howard Stearns-3 wrote:
>>
>> Hi Richard,
>>
>> I am suspicious of the reference to island in (2). Referring to the
>> island in which you are running is kind of like referring to your own
>> computer or operating system. Pretty rare, unless you're doing
>> something like asking for the current time.  In general, all the
>> replicated code executing on an island should just be normal single-
>> threaded Smalltalk code, without involving any far references:
>>
>>    screen := MovieScreen1 new.
>>    screen configureWithURI: (movieURIs at: 1) extent: movieExtentSize
>> location: initialTranslation.
>>    etc.
>>
>> and in (3)
>>    mainLoop := TestLoop new.
>>
>> -H
>>
>> On Nov 4, 2007, at 1:05 PM, RC wrote:
>>
>>>
>>> Hello, List.
>>>
>>> I am attempting to modify the KAT demo so that an MPEG is  
>>> displayed at
>>> start-up and then moved from its initial location a little while
>>> later.  The
>>> code I've assembled to do this works great when there are no
>>> collaborators
>>> replicating my island.  As soon as someone attempts to join,
>>> however, my
>>> Croquet session bombs and I see "Checkpoint failure - searching  
>>> image
>>> references..." indicating an attempt to reference objects that have
>>> not been
>>> replicated.
>>>
>>> I'm rather at a loss as to how to fix this; I've read the Croquet
>>> Programming Guide, reviewed this email list, and picked through the
>>> demos.
>>> My sense is that there is something easy I'm overlooking.  Can
>>> anyone offer
>>> some insight into my error?
>>>
>>> Thanks in advance for any help!
>>>
>>> Below is a synopsis of what I'm doing (code-wise):
>>>
>>>
>>> 1)  I use a subclass of TFrame (called MovieScreen) to create a
>>> TFrame and
>>> embed an MPEG player:
>>>
>>> MovieScreen1>>configureWithURI: uri extent: movieExtentSize  
>>> location:
>>>
>>>   "Instantiate a movie as an embedded application."
>>>   movie := TEmbeddedApp name: #TMorphicWorld extent:
>>> movieExtentSize data: {
>>> #makeMovie: . uri }.
>>>
>>>   "Set the size of the movie display..."
>>>   self extent: movieExtentSize.
>>>
>>>   "...and add the movie to ourselves (recall that we're a  
>>> subclass of
>>> TFrame)."
>>>   self addChild: movie.
>>>
>>>
>>> 2)  Because I would like to alter the MovieScreen1 object's
>>> translation
>>> later on (while other end-users are collaborating in the KAT demo),
>>> I use
>>> the following to make it and its embedded MPEG player available  
>>> to all
>>> replicated islands:
>>>
>>>   space := self parent.
>>>
>>>   movieRef := island new: MovieScreen1.
>>>   movieRef configureWithURI: (movieURIs at: 1) extent:  
>>> movieExtentSize
>>> location: initialTranslation.
>>>   space addChild: movieRef.
>>>
>>> Later on, the next bit of code is used to access the MovieScreen1
>>> object:
>>>
>>>   "Locate the movie screen we created earlier and change its
>>>   translation."
>>>
>>>   screen1 := (space find: [:frm | frm objectName =
>>> 'aMovieScreen1']) at: 1.
>>>   screen1 translation: (movieScreenTranslations at: 2).
>>>
>>>
>>> 3)  The snippets of code in 2) reside in the 'step' method of a
>>> TVehicle
>>> subclass called 'TestLoop'.  This TVehicle subclass is instantiated
>>> inside
>>> of WisconsinWorld>>initialize with:
>>>
>>>   mainLoop := TestLoop new initialize: self island.
>>>
>>>   space addChild: mainLoop.
>>>
>>>   mainLoop stepping: true.
>>>   mainLoop startStepping.
>>>
>>>
>>>
>>> --
>>> View this message in context: http://www.nabble.com/Problem-
>>> regarding-replication-of-an-object-tf4748046.html#a13576629
>>> Sent from the Croquet - Dev mailing list archive at Nabble.com.
>>>
>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Problem- 
> regarding-replication-of-an-object-tf4748046.html#a13593115
> Sent from the Croquet - Dev mailing list archive at Nabble.com.
>