camera in CroquetEvent?

> Somewhere between Croquet-Harness-das.84 and Croquet-Harness-bgf.100,
> CroquetEvent grew a 'camera' instance variable.
> It looks like this is set by CroquetHarness>>mouseDown:, mouseMove:, and
> mouseUp:, but never actually read by anyone.
>
> This is causing me problems that I didn't have before: My controller
> indirectly holds on to my harness. Since harness has an event, and event
> now has a camera, I now sometimes run into cross-island references when
> I try to take a snapshot (e.g., for sync'ing).
>
> Am I being evil?
>
>
>
>

> Hi Howard -
>
> There must be something else wrong. Both event and camera are owned  
> by the harness (created in #initialize and #bounds: respectively)  
> and not by any particular island, so creating a reference from one  
> to the other doesn't violate any island discipline and shouldn't  
> cause problems.
>
> Cheers,
>   - Andreas
>
> Howard Stearns wrote:
>> Somewhere between Croquet-Harness-das.84 and Croquet-Harness-bgf.
>> 100, CroquetEvent grew a 'camera' instance variable.
>> It looks like this is set by CroquetHarness>>mouseDown:,  
>> mouseMove:, and mouseUp:, but never actually read by anyone.
>> This is causing me problems that I didn't have before: My  
>> controller indirectly holds on to my harness. Since harness has an  
>> event, and event now has a camera, I now sometimes run into cross-
>> island references when I try to take a snapshot (e.g., for sync'ing).
>> Am I being evil?

> I don't know how to look at it right. Here's my thinking, but it would
> lead me to believe that snapshots would reliably fail all the time,
> which they don't:
>    The snapshot trace (below) shows that when the event holds the
> camera, then the Island default (outside) has a reference to the camera.
> OK, that's fair.  And it shows that the island being sync'ed has created
> a TFarRef to the camera.  Thus the island (inside) and the outside both
> reference the camera. Bad.  I think the reason the island makes a
> TFarRef to the camera is that event handlers like #pointerDown: pass the
> CroquetEvent, which is passByClone:, and so it tries to pass the camera
> in turn. Since the camera is passByProxy:, it creates a TFarRef.

> Howard Stearns wrote:
>> What's the definition of "island discipline?"  I think it has  
>> something to do with no island (including the Island default)  
>> holding on to any long-lived references to something in another  
>> island.
>
> Really only that an object mustn't refer directly to objects in  
> other islands.
>
>>   - But there are exceptions that are allowed, such as classes.
>
> Unfortunately, yes. Couldn't make it work for the time being  
> without those :-(((
>
>>   - And I'm not sure what the limitations are on transiently held  
>> references. Empirically, I know that the execution of a future  
>> message from the Island default to another island can pass  
>> something on to the Island default (e.g., a CroquetEvent), but I  
>> imagine that the island better not store that reference such that  
>> it's still around when the island tries to sync.
>
> With proper future messaging this isn't a problem. A CroquetEvent  
> for example gets copied when it's passed into the island. So  
> storing isn't a problem at all. Generally, all objects get copied  
> when you pass them into an island unless you pass a reference to an  
> object inside that island. The only exceptions are classes (as you  
> noted above).
>
>> I don't know how to look at it right. Here's my thinking, but it  
>> would lead me to believe that snapshots would reliably fail all  
>> the time, which they don't:
>>    The snapshot trace (below) shows that when the event holds the  
>> camera, then the Island default (outside) has a reference to the  
>> camera. OK, that's fair.  And it shows that the island being  
>> sync'ed has created a TFarRef to the camera.  Thus the island  
>> (inside) and the outside both reference the camera. Bad.  I think  
>> the reason the island makes a TFarRef to the camera is that event  
>> handlers like #pointerDown: pass the CroquetEvent, which is  
>> passByClone:, and so it tries to pass the camera in turn. Since  
>> the camera is passByProxy:, it creates a TFarRef.
>
> Yes, but this wouldn't apply in the case of a future message. Your  
> analysis makes sense in the situation that the event is used in a  
> synchronous send; but I'm not sure where this would happen. Here is  
> something to try: Change TCamera class>>howToPassAsArgument to  
> something that will raise an error when you try to execute it (say  
> #passByFoo:) to see where exactly that reference is created.
>
> Cheers,
>   - Andreas
>