Tuesday, October 12, 2004

Jasmine Debugging

I must have killed a dozen bugs today already. Most of them are between the crack bugs - that is, bugs that were created by porting the MadHatter architecture onto the Solar replication model. Nothing fundamentally wrong, just tracking them down and checking with Solar on how the objects computation should be replicated.

There is one potentially serious problem that I am in the middle of fixing. When an avatar traverses through a portal into another space, currently the remote version of the avatar is not making the transition. The reason was pretty simple - the transition was never sent remotely. The problem is that we send the following message:

avatar future: 0.0 perform: #goToPortal:transform: withArguments: { toPortal . trans }.

which is in effect telling the avatar to jump through the portal asap. What we really want is

avatar meta future: 0.0 perform: #goToPortal:transform: withArguments: { toPortal . trans }.

Subtly different and guaranteed to lock up the system. Why? When we send a message between machines that reference TObjects like the avatar, we don't send the actual object - we send it's name. The target of the message is encoded as well as the arguments. The problem is that this is not done recursively. That is, the actual message that is being sent here is

#future:perform:withArguments:

and its arguments are the message #goToPortal:transform and... an array. We don't do a recursive lookup. That means that we try to send the array and it's contents in toto. Well, in this case, toPortal is a member of the array and is also a TObject that is somewhere inside of a space. It is actually a TPortal, but that doesn't matter. What we are trying to do is package up the TPortal and everything it references and send that. This will fail because we are trying to send the entire contents of the croquet session that probably references all of the Squeak image in some way. Not particularly efficient.

Squeak actually has something that is designed to address this problem that I used in a previous version of Croquet. Unfortunately, I can't find that code exactly, but it is based upon a SmartRefStream, which in turn is a subclass of RefStream, which is simply a way to convert objects to streams and back again. A SmartRefStream is "smart" because it is very aware of multiply referenced objects and can eliminate redundency - very important if you don't want to turn one local object into multiple remote objects. What I did before was added a bit of code that would dereference the objects to their TeaNames if they had one, otherwise it would just encode the actual object.

Once this is in place, then remarkably,

avatar meta future: 0.0 perform: #goToPortal:transform: withArguments: { toPortal . trans }.

will just work.

Magic.

4 comments:

Anonymous said...

Newbie here, but was a squeak hacker 4 years ago. Does any of the peer to peer stuff work? I'm just curious to see other people's metaverses...

deanmao (at) gmail (dot) com

Croqueteer said...

The peer-to-peer stuff is working in controlled situations. If you and your friends are on a LAN, and start the same morph, it is pretty seamless. We will get around to a more complete version later this month.

Anonymous said...

Dave you have a lot of useful comments here. Since Croquet is public now, have you thought of placing a link to your blog on the opencroquet website or advertising it on the dev-list. I'm sure a lot of folks would like to read this.

Croqueteer said...

I will probably do that. It is unabashedly technical - with no warning at all. Just dives in, but it might be useful to some people.