OK, I will look at this tomorrow, working on getting out Cells3 and Celtk tonight. Some notes below...

On 3/15/06, momerath michael@guildsoftware.com wrote:

Wow that was weird:) I used the google toolbar spellchecker right before sending, and it acted a bit odd, so I checked the sent copy and saw that it had left all the spellchecker formatting in the message! Here it is as plain text. There are still some extraneous spaces, but I don't think they'll make it hard to read, so...

Thanks for getting back to me. I was beginning to wonder which of the 5 ways to interpret the silence :) I think it must be in the genes: ( http://en.wikipedia.org/wiki/Warnock%27s_Dilemma)

Anyway, here is what I've got:

( defmodel cargo-hold () (ship-owner capacity ;; a set of cargo-types (types :cell t : initarg :types : initform nil)

A while ago I changed the default on :cell from nil to t since I found I almost never said :cell nil. You cannot setf a cell unless it is initialzed to be an input (c-input or c-in), so at least add :cell nil to the non-cell slots.

;; cargo-type -> quantity (quantities :cell t : initarg :quantities : initform (make-hash-table))))

Note that this cell is initialized with a non-cell value. That's OK, but nothing will get triggered as you /mutate/ the hashtable contents. So you either do not want this to be a Cell, or you need to use something like a list and then specify 'equal as the "changed" test (I use that so rarely I will have to look it up for you when I have time!).

( defmodel cargo () ;; a type-id, name and the number of ;; cargo-hold units it takes up (1-3) (type name volume ;; the character-id of the owner of ;; the cargo-hold unless cargo is spaced (holder :cell t : initarg :holder : initform (c-in nil) : accessor holder)

Holder? What is that? if the comment above applies, I still do not get it.

( auth-list :cell t : initarg : auth-list : initform nil : accessor auth-list) (recipient :cell t : initarg :recipient : initform nil : accessor recipient) (stolen :cell t : initarg :stolen : initform (c? (when (member (^holder) (^ auth-list)) t))

You could just say (member ....). And I think you meant (not (member...))

       : accessor stolen)

(spaced :cell t : initarg :spaced : initform (c? (when holder t)) : accessor spaced)

You could just say (c? (^holder)) since this is not scheme. And if it really is always this simple (maybe not?), then you could just as easily say:

(defun spaced (x) (holder x))

ie, Do not use Cells unnecessarily. But I am guessing this will get more complicated, if so never mind. :)

(delivered :cell t : initarg :delivered : initform (c? (when ( eql (^holder) (^recipient)) t))

Again, this is not Scheme. But maybe you find that more readable?

          : accessor delivered)))

The first thing you'll probably notice is that there is no mechanism for the cargo-holds to actually "contain" cargo objects. I know I could do as the "summer" example of the cell-basics doc does, and push them onto a list,

My first question will be, What is "them"? ie, How exactly do things happen in this game? Maybe a player types "Allocate <qty> <cargo> to <ship> in hold <hold>" and then away we go? Anyway, let me address this point:

and recalculate based on the whole list every time it changes, but I was hoping for something more elegant and efficient.

I understand. It is a common problem. A stock changes price, and an index must be recalculated. Why recalculate the whole index when a little Algebra can let the price change even if weighted be used to compute a delta in the index.

(a) We can definitely make this more elegant (possibly using synapses) but... (b) Let's defer this optimization a while since it is an advanced topic

Only one entry in the quantities hash needs to change when an item is added for instance. I thought of having in and out slots (set the slot to a cargo object to add or remove; the other slots do their thing and then clear the in/out slot), but that seems ugly and I wasn't even sure how to pull it off.

That is how another Cells user handled such a problem. You can make the slot clear itself after processing by specifying:

(in :cell :ephemeral ....)

But I have a feeling you will want instead to simply push a new "allocation" instance onto a list of allocations of the cargo and handle the update of the hold by having an observer forward the new info to the concerned ship via SETF, at which point the holds of the ship can check to see if it was for them. Or the observer can go straight to the hold. We'll work something out clean as well as efficient. For now please try a pure declarative approach. the computation of the stock index simply recalculated the whole index on every relevant trade and was able to keep up with realtime, realworld trading.

And then there is the whole thing with cargo-sets which is closer to what I'd like to do with Cells on the larger scale. Basically what I want is to have a large number of sets and their unions/intersections efficiently accessible anywhere in my code- stuff like "all characters of faction X in sector Y carrying at least one Z in their cargo hold.

That sounds like an adhoc query. :) But I think you are talking about groups known beforehand. I have some tricks in mind for that. One has Cells recompute certain gross cross-sections as things happen, then queries can look at relatively few instances, still doing some of the work but not so much as to kill performance. The key is granularity and having the right partial aggregates computed by Cells.

I hope this makes my level of understanding more clear. I think I'm probably more prepared for the paradigm shift than most, owing, no doubt, to my long infatuation with Ted Nelson's ZigZag.

Off to Google I go. :)

ken