future at: message.

Hi,

I am new to Croquet and I look at the code trying to
understand how to run Croquet.  I checked
CroquetHarness and found this in setUpMaster

        space := island future at: #masterSpace.
        portal := island future at:#portal1.
        portal3D := island future at:#portal3D.

I check message future and it returns TFutureMaker
which is a sub subclass of ProtoObject.  I didn't see
at: message selector at ProtoObject level but found it
in Object level.  The question is why the statements
above does not complain the MessageNotUnderstood
error.  Am I missing something basic in class
hierarchy?  Thank you for you help.



Watt P.


      ____________________________________________________________________________________
Get easy, one-click access to your favorites.
Make Yahoo! your homepage.
http://www.yahoo.com/r/hs 

Hi Watt,

Good question.  There are two parts to the answer...

1) Notice that TFutureMaker implements the method  
#doesNotUnderstand:.  Whenever the VM cannot find a method to match a  
received message, it sends #doesNotUnderstand: to the original  
receiver.  So, when a TFutureMaker receives almost any message, it  
uses #doesNotUnderstand: to send a future message to the original  
receiver of the #future message (in your example 'island').

2) In fact, it is somewhat inefficient to create a TFutureMaker for  
each future message.  Instead, the compiler treats #future specially,  
and causes #futureSend:at:args: to be sent directly to the receiver  
without instantiating a TFutureMaker.  The semantics are the same as  
if a TFutureMaker were actually created.

As an aside, this kind of compiler trick is not without precedent in  
Squeak.  The most common example is the handling of #ifTrue: and  
friends.  Although the semantics are defined in terms of Squeak  
messages, the compiler recognizes these messages and inlines them  
using special bytecodes for efficiency (the #future message doesn't  
introduce new bytecodes, it simply avoids instantiating a TFutureMaker).

Josh



On Dec 2, 2007, at 11:40 PM, Watt Poosanguansit wrote:

Fasten your seatbelts. This is going to be an odd mix of concrete and  
abstract.

On Dec 3, 2007, at 5:41 AM, Kjell Godo wrote:

> Is there any documentation about how to use futures and islands etc?
> I got the .pdf file that came with Croquet and I got about half way  
> through it
> but it seemed to be a superficial overview without a lot of details  
> about
> what talks to who via which messages.

I once told a religious friend that I thought the Bible was a  
superficial enumeration of who begat whom. My friend was rightfully  
exasperated.

There's some subtlety in http://opencroquet.org/index.php/ 
Programming_Croquet and its worth a close read.
Consider also http://opencroquet.org/index.php/The_Core_Model

A deep internalization of that material would reveal that:

1.  aFarRef future someMessage
is only used when injecting an event into the collaboration from non-
replicated code.  It is primarily used in writing the kind of user-
interface (or program-interface) that does not execute on everyone's  
machine, but rather just to one user (or program) with the results  
going into the space. (Other kinds of user-interfaces are entirely  
"in-world" and don't use #future.)
The examples of this in the programming guide are not really the  
common everyday things that an application programmer does. Instead,  
start by looking at things like:
   TAvatarUser>>moveDown:
   TAvatarUser>>stopDriving
   CroquetHarness>>dropForm:
It would be cool if we just painted all off-island classes blue, or  
all TFarRef variables blue. But we don't. So I'll tell you that:
   *Harness*, *Menu*, and *AvatarUser* classes are off-island, not  
replicated, and have farRef variables like activeSpace and replica.
   *AvatarReplica* and most descendants of TFrame are on-island.

2. (anObject future: someMilliseconds) someMessage
is only used within replicated code to cause someMessage to happen  
someMilliseconds from now. This is how we write loops in-world.
See http://opencroquet.org/index.php/ 
Programming_Croquet#Getting_Started:_Simulations

> Is it possible to get two islands to collaborate across the Internet?

There's two things you might mean here:

   1. You have one island that is replicated on two machines, both  
participating in a collaboration (aka shared simulation, aka Tea  
Party). We don't refer to this as being two islands, because  
semantically, there is just one definition that is happening the same  
way on multiple machines. The answer to your question in this case  
is, "Yes, that's the whole point of Croquet."

   2. You have two separate islands - two separate simulations/
collaborations/parties - and you want to communicate between the two.  
The answer here is, "No, you cannot send messages from one island to  
another."  This case is a matter of some subtlety. Of course you can  
keep an island id and an object id on that island (aka a Postcard) in  
one island, and you can write code that will resolve that postcard  
and future send a message to it. However, remember that everything  
happening on, e.g., the first island is replicated on several  
machines. We don't want them all to send the message to the second  
island.  Some machines might be joined with both islands and the  
message could just be sent locally, but other machines might be just  
joined with, say, the second island. How would these one-island  
machines learn about the message injected into it? The current  
version of Croquet has no means of recognizing that these are all the  
same message.  (This "some to some" messaging problem  distinguishes  
Croquet's "Simplified Tea Time" from David Reed's "Full Tea Time.")  
There are, however, some special cases that the current version of  
Croquet does handle by other means. For example:

   + one island can contain a postcard (in a portal) and resolve that  
to another island, and LOCALLY send messages to the other island in  
order to render it. The effect is that the second island is seen from  
within the first. This only works because rendering is defined as not  
having an effect on the definition of an island, and so we have  
special machinery for rendering without sending future messages on  
the network.

   + Your non-replicated user interface (outside of the island,  
called the Harness) can learn that you have driven into a portal, and  
it can future send a message into the first island to tell everyone  
that you're leaving, and can future send another message into the  
second island to tell everyone that you're arriving.  Note that the  
messages come from your non-replicated harness, rather than from the  
replicated first island.

> If I get Croquet and my friend gets Croquet and we both know our IP  
> addresses
> how do we get the whole thing rolling with two worlds and moving  
> from one
> world to another via portals?

http://opencroquet.org/index.php/Croquet_Collaborative
http://opencroquet.org/index.php/ 
A_Beginners_Guide#Connecting_Two_Computers
http://opencroquet.org/index.php/Getting_Started#Connecting_to_Others
http://opencroquet.org/index.php/WAN/LAN%2C_Connecting_and_Discovery

> If I want to understand how futures work what are the essential  
> methods
> involved?

My guess is that this is the wrong question. I'm thinking that you  
want to understand how to use them, not how to implement them. It's  
generally not a good idea to try to understand a program by looking  
at the solid-state physics of integrated circuits. That's the wrong  
level of abstraction and won't really illuminate you.

If you want to get a better practical feel for future sends to far  
refs (case #1, above), have a look at:
http://www.nabble.com/Re%3A--croquet--get-a-handle-to-an-object- 
p8773178.html


> What are the essential core Router methods and Controller methods?
> ( there was something connected to a Router but I am not sure it is
> called a Controller or not. )

I'm not sure how to answer because I don't know what you want to do.  
I suspect that don't need to be talking directly to the router or  
controller in code at all.