Login  Register

Re: camera in CroquetEvent?

Posted by Howard Stearns on Aug 12, 2006; 3:50am
URL: https://forum.world.st/Re-camera-in-CroquetEvent-tp129390p129394.html


On Aug 11, 2006, at 6:00 PM, Andreas Raab wrote:

> Hi Howard -
>
> Sorry for not getting back earlier but something struck me about  
> your message as being really, really wrong and I finally realized  
> what my problem with it is:
>
> Howard Stearns wrote:
>> Andreas, you're right about the TFarRef happening outside a future  
>> message. It happens in:
>> TChattyAvatarReplica>>prointerLeave: evt
>>     super pointerLeave: evt.
>>     self root signal: #hideID with: evt with: nickname.
>
> No, this can't be it. If, at this point, the event contains a  
> TFarRef for the camera we're already hosed and need to look at  
> where that reference came from. The reason being that pointerLeave:  
> should have been invoked as a future message, and future messages  
> *never* create FarRefs for their arguments (all arguments in future  
> messages are copied verbatim). So if there's a FarRef in the event  
> at that point things already went wrong. I strongly suspect that  
> the problem is happening elsewhere.

Could it be a script in myEventMap that is a FarRef but shouldn't be?  
Otherwise I'm without a clue.

When I wave the mouse around over portals, before attempting to  
supply a snapshot, I see this:

TIsland>>execute: aTMessage (for #doPointerLeave:)
=> TFrame>>doPointerLeave:
   => TChattyAvatarReplica>>pointerLeave:
           ....
          Transcript show: '', evt, ' ',  evt camera; cr.
               "This prints: a CroquetEvent a TCamera (not a TFarRef  
in sight)
                Is that because these are on-island copies which are  
(correctly) made in a proper future message?
               Otherwise, I would be confused because this code should (I  
think) be executed on the island,
                and so evt and it's camera would be TFarRefs from in  
here."
           self root signal: #hideID with: evt with: nickname
             => ...TSpace(Object)>>signalEvent:
               => TSpace(Object)>>privateSignalEvent: anEvent
                    | map list msg |
                        map := self myEventMap ifNil:[^self].
                        list := map at: anEvent selector ifAbsent:[^self].
                        1 to: list size do:[:i|
                           (msg := list at: i) ifNotNil:[msg valueWithEvent:  
anEvent clone]].  "we're at #valueWithEvent: at this point"
                 =>passByCopy: aScriptEvent
                          => passByClone: aCroquetEvent
                             => pass: aCamera  <- This defaults to  
passByProxy:, which creates the TFarRef for the camera.

It seems that the msg local variable in #privateSignalEvent: is a  
FarRef (not a TFarRef) to a ScriptMessageSend on the Squeak Island,  
and thus it tries to pass anEvent clone using the island copier.  Is  
that where things are getting goofy?


>
>> Or we can change it to pass a copy of the event, as is done by:
>> TAvatarUserMenu>>doBlueButtonUp: event
>>     | eventCopy |
>>     eventCopy := event copy.
>>     eventCopy selection: event selection copy.
>>     eventCopy selection target future signal: #blueButtonUp with:  
>> eventCopy.
>
> Huh? This works? How very strange. You're not changing the camera  
> in the above so the copy should refer to the camera just like the  
> old event and should cause precisely the same problems.

It may do. Not my code, so I don't know whether the event copy is  
intended to avoid this sort of problem being discussed or something  
else, or whether it succeeds in doing so.

There are also a bunch of TAvatarUserVehicle methods that do evt  
camera: nil, which could conceivably be another attempt at this issue.

Tony?

>
>> But I'm not clear on the philosophy by which to decide what the  
>> right path is. (I guess it would be up to Tony.)  Naively, it  
>> seems weird to have events be #passByClone:, only to have to have  
>> to make copies whenever we want to actually pass one.
>
> Yeah, that's certainly not the right way to deal with it. Well,  
> first let's try to nail the issue with the camera in the event - if  
> there's really a FarRef in there then something is really, really  
> wrong and we need to find out where that reference is coming from.  
> If there isn't a FarRef in there it's back to square one, e.g.,  
> find the sync message that causes the camera to be "injected" into  
> the replicated space by way of some far ref.
>
> Cheers,
>   - Andreas
>