Re: Installing CCPainter

On Jul 15, 2006, at 9:50 PM, David Faught wrote:

Put the tool in WiscWorlds. There's a menu item to cache the current  
state of the current world to your disk. It's sort of like 'save  
image' for islands.

   If you run in the provided routers at UW, you don't need to do  
anything at all to save. (It's not really stable enough yet to rely  
on that, but that's why you can save locally. We're working on a more  
reliable version.)

   If you do run your own routers, and there is no one else connected  
when the machine on which you saved connects, then the cached  
definition of the world is the one that will be used for everyone on  
that router.

-H

Hhhmm, okay I think I understand what you are saying about the routers
and caching, but whoa!  Back up a mite!  When you say "Put the tool in
WiscWorlds" are you saying that common code isn't really necessary?
That as long as my code builds the TFrame(s)/TMesh properly through
the island routers (where "properly" is a stretch for me right now)
that the code that built it isn't really needed by other people to
view the object?  Otherwise, it would be up to you to put the tool in
WiscWorlds, wouldn't it?????  Or are you speaking of the great
metaphorical WiscWorlds where all avatars are created equal in the
others' cameras?  In any case, it might be desirable someday to be
able to save/load the 2D image created by CPainter locally as a .png
or .jpeg file.

On 7/16/06, Howard Stearns <[hidden email]> wrote:

On Jul 16, 2006, at 1:45 PM, David Faught wrote:

> Hhhmm, okay I think I understand what you are saying about the routers
> and caching, but whoa!  Back up a mite!  When you say "Put the tool in
> WiscWorlds" are you saying that common code isn't really necessary?
> That as long as my code builds the TFrame(s)/TMesh properly through
> the island routers (where "properly" is a stretch for me right now)
> that the code that built it isn't really needed by other people to
> view the object?

This is basically true, although I didn't actually cover this in what  
I wrote. But since you ask, here's the story:

When you join an island, or more precisely, when you synch, you get a  
binary definition that you can #install: as your copy of the current  
definition of that island. You need to have all the classes referred  
to by that definition. (This restriction may be lifted in the  
future.) But you don't need the code that was used to construct that  
result.

So based on that, you and I could be participating in a WiscWorld (or  
any other Croquet app).  I might build something on the island by  
sending a bunch of future messages in a Workspace or Inspector. You  
might have code on your machine that you use to build something on  
the island.  When a third person joins, they get the island  
definition, and they'll need the classes that represent the result,  
but not the stuff used to create it.  You and the new person didn't  
have my Workspace code. The new person and I didn't have your  
building code.

There are two catches:

1. Everyone needs to have the replicated part of the code used to  
build stuff. That is, everyone needs to have the code that responds  
to the messages that you or I send into the island using #future.  
For example, suppose my workspace code was creating a new box by  
getting ahold of the harness, and saying:
    harness activeSpace future addChild: (harness activeIsland new:  
TCube).
Because you are in the space at the same time, you need the code for  
#addChild: and for #new:.  Of course, you already have that code.  
Also note that the new person joining may need this code, too. All  
the messages, whatever their source, are ordered in time by the  
router for that island.  This includes the request by the new guy for  
synch'ing, and the instruction that the router makes in response to  
the synch request, for one of the participants to actually make a  
serialized copy of the island state.  Now, suppose the instruction to  
make a serialized copy comes in during the midst of some construction  
sequence by you or I.  The new guy will get all the messages since  
joining, and will ignore all those that happen to come before the  
time the island he gets was actually made. But the new guy will need  
to be able to handle all the messages since then.

You know have the outline of all the information you need to know  
what it means to create a "TFrame(s)/TMesh properly," above.  Except  
for...

2. Not everything is in the island. In addition to classes, it is  
helpful, but not required, to keep immutable stuff in a cache outside  
the island. Andreas/David have provided a wonderful example of this  
in the TFormManager.  In using WiscWorlds, we have found  
experimentally that your experience and reliability suffer when the  
island is too large.  So Josh is working hard on getting more stuff  
into a cache mechanism outside the island. Movies, sounds, even  
meshes.  Anyone joining late will also need to have a compatible  
caching mechanism.

In short, whatever isn't in the island (classes and cache) need to be  
consistent between machines, and the island mechanism itself won't  
help you. The situation is a something like where, during the Jasmine  
version of Croquet, something new would get changed and you'd have to  
clear your Jasmine data cache before things would work again.

>   Otherwise, it would be up to you to put the tool in
> WiscWorlds, wouldn't it?????  Or are you speaking of the great
> metaphorical WiscWorlds where all avatars are created equal in the
> others' cameras?

WiscWorlds is an application, complete with installer and routers run  
by yours truly. But it is also a set of code that you can use however  
you want. When you install, you get the code. You can run your own  
routers. Alter the code. Knock yourself out.

Josh and I are working towards having a Monticello package for the  
next version of the WiscWorlds functionality. This will make it  
easier for you to add classes and, e.g., menu items in a way that  
will get propagated to others of the code.

>   In any case, it might be desirable someday to be
> able to save/load the 2D image created by CPainter locally as a .png
> or .jpeg file.

There are several approaches to this. See my 6/7 reply: https://
lists.wisc.edu/read/messages?id=1131812

Note that things don't just go to the external cache automatically.  
You have to have code that puts the data in the cache and a reference  
to it in the island. I don't recall, but I'm guessing the TPainter  
code does not do this.

Another unfortunate expediency in the current version of WiscWorlds  
is that a 2D image in the cache is always represented as jpeg.  
Simple, but not always the best choice.