May 2004 - cells-devel - mailman3.common-lisp.net

[cells-devel] Call for Cells Regression Test Suite Additions
by Kenny Tilton 23 May '04

23 May '04

This is mostly for Thomas who is actually using a couple of features I have added to Keep Other People Happy, but I thought the list would be interested... I am ripping out the disgusting dataflow-interference code. The bad news is that if I succeed I will have to kill myself, because the replacement solution is about ten lines of code /and/ works better, whereas you just need to look at the original code to see what a nightmare it was getting that to work. Anyway, it occurs to me the regression test does not include any checking of either lazy cells or unbounditude handling. Speaking of laziness, I probably will not do tests for those on my own, so if you would like Cells II tested out before release for either of those please send along some tests. It would be nice if they worked via cv-assert. Note that in some places I also confirm that an error is produced on deliberate no-nos. You might want to do some of that, too. kenny -- Home? http://tilton-technology.com Cells? http://www.common-lisp.net/project/cells/ Cello? http://www.common-lisp.net/project/cello/ Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film Your Project Here! http://alu.cliki.net/Industry%20Application

2 1

[cells-devel] cv-laziness
by Kenny Tilton 20 May '04

20 May '04

Oops, just noticed I did do a cv-laziness regression test, which has now been added to cv-test and still works under Cells II (the (so far) marvelous revision eliminating a whole lot of really dumb code). Anyone interested in the lazy thing can add to the that, or just do their own separate test. kt -- Home? http://tilton-technology.com Cells? http://www.common-lisp.net/project/cells/ Cello? http://www.common-lisp.net/project/cello/ Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film Your Project Here! http://alu.cliki.net/Industry%20Application

1 0

[cells-devel] Constructor syntax
by tfb＠OCF.Berkeley.EDU 14 May '04

14 May '04

Kenny Tilton <ktilton(a)nyc.rr.com> writes: > nikodemus(a)random-state.net wrote: > > > This is quite off-topic for the thread, but I for one always cringe when I > > see Cells code due to C? and friends. > > > > If the syntax were: > > > > RULE-LAMBDA (binding) form* > > > > or > > > > RULE-LAMBDA binding form* > > Garnet's KR had (I forget)-formula. But when one is /really/ using > Cells, one is spraying CVs and C?s around all the time, and this is more > a candidate for something like collapsing QUOTE into ' or FUNCTION into > #' then it is expansion into big-huge-name useful at the application > level where, as we all know, excessive abbreviation saves so very little > and detracts so much from readability. > > That said, if some contributor wanted to create c-formula and c-variable > macros and add them to Cells I would not mind. Okay, how are these for a start? (defmacro cv (&optional (value +unbound+)) `(cells::make-c-variable :value ,value)) (defmacro c-formula ((&rest keys &key lazy cyclic-p cyclic-value) &body forms) (declare (ignore lazy cyclic-p cyclic-value)) `(cells::make-c-dependent :code ',forms :rule (c-lambda ,@forms) ,@keys)) (defmacro c-variable ((&rest keys &key cyclic-p) &optional (value nil valuep)) (declare (ignore cyclic-p)) `(cells::make-c-variable :value ,(if valuep value '+unbound+) ,@keys)) They don't capture all the options (yet), but syntactically I think I like it. I agree that cv and c? are so common they should have their own short abbreviations. However, c?_8... seems like maybe not the best road syntactically. This syntax has the advantage of not needing to export a new macro if more options are added later (not that I can think of any types of cells still missing, of the top of my head). Actually, I just changed my code to use c-formula instead of c?_, and I like it. It even saves me two columns of horizontal space. I have no desire to change my c? forms, but it's not like my lazy formulas were one-liners anyway.

3 15

[cells-devel] Major Cells fix (?)
by Kenny Tilton 14 May '04

14 May '04

I decided to address something about Cells I recently decided was Not Good: The echo of a cell (something conceived to permit side-effects outside the model dataflow) is permitted to kick off top-level (if you will) dataflow by setting some c-variable-mediated other slot. Fine. But echos run immediately after a new value has been assumed by a cell, before propagation to other cells. So what we had was echo-initiated top-level dataflow running to completion before the dataflow being echoed really got very far off the ground. And, yes, some very tricky misbehavior resulted, and I think is responsible for a lot of nasty code in Cells. Anyway, tonight I hacked a quick single-threading of such things: (defun (setf md-slot-value) .....<snip> ...unchanged testing for cyclicity.... (let ((absorbed-value (c-absorb-value c new-value))) ;; dicey: decide absorbed-value now or just before setf? ;; ...but we need a value to return even if actual setf will be deferred. ;; (count-it :md-slot-value-setf slot-spec) (if *df-entry* (progn (nconc *df-entry* (list (cons c (cons absorbed-value *cause*)))) absorbed-value) (let ((*df-entry* (list nil))) (c-slot-value-absorb c absorbed-value) (loop for (c-deferred . (deferred-value . echoing-asker)) in (cdr *df-entry*) do (let ((*cause* echoing-asker)) ;; sketchy (c-slot-value-absorb c-deferred deferred-value))) absorbed-value)))))) (defun c-slot-value-absorb (c absorbed-value) (with-dataflow-management (c) (md-slot-value-assume (c-model c) (c-slot-spec c) absorbed-value))) "absorb"? "assume"? gotta work on that. The light panel still works, but tracing shows not a lot of very challenging cases. RoboCup was the worst stress test Cells has gotten, stumping it easily even after seven years of refinement. I may dust off TeamKenny to see what I can see. I prefer real-world stressors to artifices. Actually, what I should do is disable all the "m/cmdead" testing, which I believe arose to handle problems caused only by overlapping dataflow steps: some echo would cause some instance (the active player task) to leave the model (supplanted or completed), but already in the call stack was code that was going to be operating on those instances in some way shape or form. So in a mad dash before ILC 2003 I ended up sprinkling "dead" tests about thirty times around the system. My hope is that this new patch will clear the dataflow propagation stack before the echo zaps the instance. More to come, I guess. kt -- Home? http://tilton-technology.com Cells? http://www.common-lisp.net/project/cells/ Cello? http://www.common-lisp.net/project/cello/ Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film Your Project Here! http://alu.cliki.net/Industry%20Application

1 0