Peter Hildebrandt wrote:
On Sun, Apr 13, 2008 at 5:21 PM, Ken Tilton kennytilton@optonline.net wrote:
Right, thanks, sorry for the head fake. Eventually something should be added to the regression test.
Well, we don't want to end up with more lines of test code than program code. So I'd leave that to the debugger for now ;-)
Not an XP fan? :) Cells is pretty stable (but that will come unglued if people like you and Andy keep showing up) but I love taking things that go wrong and throwing them into a regression test suite precisely so I can continue hacking like a cowboy and then just re-running the test to see what broke, and if nothing breaks the code is declared perfect cuz if there is any behavior one does not like one has to get into the regression test.
I know the XP guys write the tests first -- that might be a good policy for RFEs: if someone wants something changed they have to specify it in the form of a test that will not pass now. Just a great exercise for clarifying what one wants, seeing if it might already be there, and doing so in a way that guarantees no future change will back it out.
(Sorry, just thinking out loud here.)
I am not quite sure about the implications, though.
Yeah, it is not clear what to do. The instance is no longer part of the model, so some rules will outright fail and those that do not would possibly be circular or at least form crazy dependencies of things no longer extant on those that are.
I assume that c-value is at least safe (that is, it is bound to return *something*) to do, so the only issue we're facing is that the value might be old.
So my question becomes: How old can the value in the c-value slot become? I do not understand cells well enough to know whether we can safely assume that every change (setf) from before the changing of the kids list has trickled down to every ruled cell *before* not-to-be gets called as a result of a (distinct) change to the kids slot. I assume it would, though.
Ah, I was wondering why you were surprised that 3 had gotten through. A naked SETF ends up wrapped in a within-integrity call that ensures data integrity as defined in cells-manifesto.txt (half-way in look for a list of a half-dozen things defining "integrity"). I think that will clarify things greatly.
It is trickier if the change to one input cell through a bunch of dependencies leads to a change in the kids list of some family member. Then not-to-be gets called, and we have no way of being sure which consequences of the original change have already been propagated and which haven't.
But then, again, the value in c-value should be a max of one change old, that is, it should reflect the correct value from before the change which affected the kid to get thrown out.
And now I realize I have just reinvented what you wrote. Damn, I should read the whole message *before* responding.
Hmmm. I see 'not-to-be gets called pretty early, pretty much as soon as a slot value has changed and owned things are seen to be no longer in that slot, right during propagation. So where a dying instance reads slot X and slot X is still alive and would normally update when read (and still will later during this same propagation (I think <g>)) then the dying instance will see either an obsolete value or (I just realized) a new value if propagation got to X first by another path.
Nothing like a little non-determinism to start the day. :)
Well, The Lisp Way is to let people shoot themselves in the foot, we can probably just leave it as it is and see what happens.
Agreed. Especially since I feel the situations in which that could cause a problem are academic in nature. Usually not-to-be will only be concerned with cleanup stuff, and the cell values which are needed therefore would normally be somewhat stable, I assume.
So if it will actually become an issue, we can still go back and invent the :death-bed stage in which not-to-be's are called after all changes have been propagated.
Right, a new :ex-parrot unfinished-business queue to be processed before (I suppose) looking for a new change perhaps kicked off by an observer.
If there was any documentation we could document not-to-be and point all this out and remind them that code in not-to-be should not be doing things in or with the model, it should be, eg, notifying C libraries that blocks they allocated can be scavenged.
I guess the cells-devel archives serve as a doc in some way, so by that logic it is already part of the documentation.
Hmmm, those /could/ be the result of Cell rules, I guess it is good to return the old value.
This is hard now. Because it implies that *no* changes should be propagate dbefore not-to-be is called. But how to do that? Build a queue for *all* changes, filter out the changes to the kids,... call not-to-be on the old, intact model, then propagate the changes from the queue? And what if not-to-be inflicts changes? My head is spinning ... I have to wait until after I have finished that bottle of wine.
Right, it's a lost cause. The Real Problem is not clearly dividing model-time from non-model-time by doing anything modelly during not-to-be. It was a bit extreme (as I once had it and did again by mistake) to force... ha, maybe that /is/ the way to go, force them to use slot-value. I like things like that that say to the user "I do not think you will forget you are in not-to-be as long as only slot-value works.
Anyway...
kt