Re: Fwd: Create a new object.

[Howard Stearns]

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."

> ....
>
> Maybe I can ask something else. Where can I change the underscore  
> problem. I want to file-in some code which is written with _ and  
> Croquet doesn’t allow that. I tried to ‘do’ the following code in a  
> workspace like they say on the developers list.
>
> 'Preferences enable:
> #allowUnderscoreAssignment'
>
> But is still isn’t working. Is there something else that I should  
> change?

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.

[Howard Stearns]

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

> things I have. Perhaps I need an extra class to create?
>
> I have the following code.
> A : navigatorMaster Class which is a subclass of SimpleDemoMaster.
> navigatorMaster>>#setup
> Here I want to access my space to add a green cube. (Is this
> the   Right place to do this?)
> ...
> SpaceRef := island "a TFarRef to the island" future at:
> #masterSpace.
> fooCubeRef := island future new: Greencube.
> SpaceRef future addChild: fooCubeRef.
> ...
> navigatorMaster>>#registerPortal: in:
> ...
>
> B : navigatorWorld Class which is a subclass of SimpleDemoWorld.
>
> navigatorWorld>>#initialize
> Here I register my space Global with the following code
> ...
> space := TSpace new.
> space registerGlobal: #masterSpace.
> self makeLight: space
> ...
> To 'run' and see my world I add the following to my workspace and 'doit' (is
> there an other way to do this? )
>
> nm:= NavigatorMaster new  openInWorld .
> win:=   SystemWindow new.
> lf:= LayoutFrame new.
> lf leftFraction:0.
> lf rightFraction:1.
> lf topFraction:0.
> lf bottomFraction:1.
> win setLabel: 'This is a kutworld'.
> win addMorph: nm fullFrame:lf.
> win openInWorldExtent: 600@450.
>
> But the green cube doesn't show up. I don't think it can be so hard?  
>

--
Howard Stearns
University of Wisconsin - Madison
Division of Information Technology
mailto:hstearns@...
jabber:hstearns@...
voice:[phone]

[Rob Van Pamel]

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:hstearns@...]
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

> things I have. Perhaps I need an extra class to create?
>
> I have the following code.
> A : navigatorMaster Class which is a subclass of SimpleDemoMaster.
> navigatorMaster>>#setup
> Here I want to access my space to add a green cube. (Is this
> the   Right place to do this?)
> ...
> SpaceRef := island "a TFarRef to the island" future at:
> #masterSpace.
> fooCubeRef := island future new: Greencube.
> SpaceRef future addChild: fooCubeRef.
> ...
> navigatorMaster>>#registerPortal: in:
> ...
>
> B : navigatorWorld Class which is a subclass of SimpleDemoWorld.
>
> navigatorWorld>>#initialize
> Here I register my space Global with the following code
> ...
> space := TSpace new.
> space registerGlobal: #masterSpace.
> self makeLight: space
> ...
> To 'run' and see my world I add the following to my workspace and 'doit'

(is

> there an other way to do this? )
>
> nm:= NavigatorMaster new  openInWorld .
> win:=   SystemWindow new.
> lf:= LayoutFrame new.
> lf leftFraction:0.
> lf rightFraction:1.
> lf topFraction:0.
> lf bottomFraction:1.
> win setLabel: 'This is a kutworld'.
> win addMorph: nm fullFrame:lf.
> win openInWorldExtent: 600@450.
>
> But the green cube doesn't show up. I don't think it can be so hard?  
>

--
Howard Stearns
University of Wisconsin - Madison
Division of Information Technology
mailto:hstearns@...
jabber:hstearns@...
voice:[phone]