Re: Fwd: Create a new object.

On Dec 3, 2006, at 2:20 PM, Rob Van Pamel wrote:
....

> No not on the croquet Space but in real life. When somebody comes  
> into a room with an object (eg a monitor which is RFID tagged),  
> another program made in c++ see that and he adds that object to the  
> database with that object values( eg name, x, y, z). Now i notice  
> in my croquet process (the stepper) that the database has changed,  
> I have to create a new object and add that object to my croquet space.

OK. Even easier. You don't need to #signal: anything at all. The  
tweak stuff isn't necessary.

Your headless user is going to tell stuff to move using a future  
message, as I said in my last message.
Your headless uers is also going to tell the island to make #new:  
object, and add it to the space, both with future messages, as I said  
in my first message.

In both cases, you're doing the same thing that the various UI stuff  
does: there's a non-replicated user interface, unique to each user,  
that is outside the island. It injects messages into the island using  
one or two #future messages per "event."

That should work.

By 'do' I assume you mean 'doit':

1. You don't just type stuff in and hit enter like you would in a  
read-eval-print loop like you would in Lisp, Python, Forth,  
Postscript, Basic, HP or Sinclair calculator, ....
Instead, you have to explicitly "doit", which can be done in a number  
of ways, but most precisely by highlighting the code and pressing  
apple-d (mac) or (if I remember) alt-d (Windows).

2. You highlight eveything exclusively BETWEEN the single quotes when  
doing this. Single quote denotes a string literal.  So if your  
highlighting includes the quotes in the source you gave above, your  
'doit' is evaluating a string literal, which just evaluates to  
itself. Not very productive.

Rob Van Pamel wrote:
> Hi
>
> Hi Howard,
>
> I'm sorry to disturb you again but I think that I am missing something
> crucial to get access to the TFarRef that I am trying to create. I followed
> the code from the Croquet SDK from SimpleWorld>>#initialize and
> CroquetHarness>>#setupMaster but it still doesn't work.


Stop right there. (I don't have a system here to look at, but as I recall..)

SimpleWorld>>initialize should have nothing to do with TFarRefs.  As I
think the doc says, the FooWorld classes are basically just a stand-in
for a script that gets run on-island.

"Something" from outside the island causes a replicated island to be
created, producing a TFarRef to the island itself.  That "something"
sends thatIslandFarRef future new: SomeWorld.  This causes a single
instance of the SomeWorld class to be instantiated ON THE ISLAND.
Instantiating anything causes its #initialize method to be run. Again,
that's ON THE ISLAND.  Nothing executing on the island should see a
TFarRef, and that includes SomeWorld>>initialize.

All of what I've said here ought to be pretty straightforward and
consistent with what you see in a careful reading of the programming guide.

I think it's crucial that you get a clear understanding of what is
on-island (which is the same as saying replicated) and what is
off-island (which is the same as saying non-replicated). Everything that
should happen in the simulation should be replicated, and should execute
on-island. Only the "inputs" should be non-replicated, and come from
off-island. The harness and its handling of user-interface gestures is
an example of something creating inputs. So is your "headless user"
(database process).  The off-island stuff is the only thing that deals
with TFarRef and future, and there should be as little of that as possible.

(Some people hate the idea of extra messages going on the network. So if
it helps you to cut down on doing a lot of interaction between off- and
on-island, think of every #future message as going on the network.  A
whole series of computations with #future messages can almost always be
reduced down to just one or two #future messages instead. For example,
consider the creation of "a bunch of stuff to create a space and
initially populate it."  That could be lots of TFarRef future messages,
but it's much cleaner to send one future #new: message to the island
that causes all the other stuff to happen from WITHIN the island.)

However, what about that "something" that creates the island in the
first place?  That's a bit of a mess. CroquetParticipant defines one way
to do it. The BFD... classes define a slightly different way to do it. I
don't really like the master/slave concept, so I have a third way to do
it in the K... classes. SimpleDemoMaster/SimpleDemoWorld might provide
the easiest model on which to get started. But none of this is well
documented because, in my opinion, there's no consensus yet on the right
way to do it. (Or maybe more accurately, folks are still trying to
understand the non-Croquet constraints on the situation in which Croquet
is run.) But as long as you stick to the clean stuff above, I think you
can do some minimal setup like SimpleDemoMaster/World and you'll be ok.
Just don't try to make that setup hairier.

I will explain the
--
Howard Stearns
University of Wisconsin - Madison
Division of Information Technology
mailto:[hidden email]
jabber:[hidden email]
voice:+1-608-262-3724

Ok I think I'm starting to understand it. I'm not trough it completely but
it's starting to resolve. I'm going to re-create my classes now with all
this in my mind.

I'll would like to thank you a lot for your patience!

Kind Regards
  Rob  

-----Oorspronkelijk bericht-----
Van: Howard Stearns [mailto:[hidden email]]
Verzonden: dinsdag 5 december 2006 22:54
Aan: Rob Van Pamel
CC: Croquet-Devel devlist
Onderwerp: Re: [croquet] Fwd: Create a new object.

Rob Van Pamel wrote:
> Hi
>
> Hi Howard,
>
> I'm sorry to disturb you again but I think that I am missing something
> crucial to get access to the TFarRef that I am trying to create. I
followed
> the code from the Croquet SDK from SimpleWorld>>#initialize and
> CroquetHarness>>#setupMaster but it still doesn't work.


Stop right there. (I don't have a system here to look at, but as I recall..)

SimpleWorld>>initialize should have nothing to do with TFarRefs.  As I
think the doc says, the FooWorld classes are basically just a stand-in
for a script that gets run on-island.

"Something" from outside the island causes a replicated island to be
created, producing a TFarRef to the island itself.  That "something"
sends thatIslandFarRef future new: SomeWorld.  This causes a single
instance of the SomeWorld class to be instantiated ON THE ISLAND.
Instantiating anything causes its #initialize method to be run. Again,
that's ON THE ISLAND.  Nothing executing on the island should see a
TFarRef, and that includes SomeWorld>>initialize.

All of what I've said here ought to be pretty straightforward and
consistent with what you see in a careful reading of the programming guide.

I think it's crucial that you get a clear understanding of what is
on-island (which is the same as saying replicated) and what is
off-island (which is the same as saying non-replicated). Everything that
should happen in the simulation should be replicated, and should execute
on-island. Only the "inputs" should be non-replicated, and come from
off-island. The harness and its handling of user-interface gestures is
an example of something creating inputs. So is your "headless user"
(database process).  The off-island stuff is the only thing that deals
with TFarRef and future, and there should be as little of that as possible.

(Some people hate the idea of extra messages going on the network. So if
it helps you to cut down on doing a lot of interaction between off- and
on-island, think of every #future message as going on the network.  A
whole series of computations with #future messages can almost always be
reduced down to just one or two #future messages instead. For example,
consider the creation of "a bunch of stuff to create a space and
initially populate it."  That could be lots of TFarRef future messages,
but it's much cleaner to send one future #new: message to the island
that causes all the other stuff to happen from WITHIN the island.)

However, what about that "something" that creates the island in the
first place?  That's a bit of a mess. CroquetParticipant defines one way
to do it. The BFD... classes define a slightly different way to do it. I
don't really like the master/slave concept, so I have a third way to do
it in the K... classes. SimpleDemoMaster/SimpleDemoWorld might provide
the easiest model on which to get started. But none of this is well
documented because, in my opinion, there's no consensus yet on the right
way to do it. (Or maybe more accurately, folks are still trying to
understand the non-Croquet constraints on the situation in which Croquet
is run.) But as long as you stick to the clean stuff above, I think you
can do some minimal setup like SimpleDemoMaster/World and you'll be ok.
Just don't try to make that setup hairier.

I will explain the (is
--
Howard Stearns
University of Wisconsin - Madison
Division of Information Technology
mailto:[hidden email]
jabber:[hidden email]
voice:+1-608-262-3724