Re: Problems loading cells on cygwin

Mirko.Vukovic@xxxxxxxxx wrote:
On Nov 26, 9:57 pm, Ken Tilton <kennytil...@xxxxxxxxxxxxx> wrote:

John Thingstad wrote:

På Tue, 27 Nov 2007 02:45:08 +0100, skrev <Mirko.Vuko...@xxxxxxxxx>:

The the asd file already has a :serial t in the modules definition. I
naively tried adding it in front, but that did not change things. But
see my reply to Ken regarding compilation issues.

(asdf:defsystem :cells
:name "cells"
:author "Kenny Tilton <ktil...@xxxxxxxxxx>"
:version "2.0"
:maintainer "Kenny Tilton <ktil...@xxxxxxxxxx>"
:licence "MIT Style"
:description "Cells"
:long-description "The Cells dataflow extension to CLOS."
:components ((:module "utils-kt"
:serial t
:components ((:file "defpackage")
(:file "debug")
(:file "detritus")
(:file "flow-control")
(:file "strings")))
(:file "defpackage" :depends-on ("utils-kt"))
(:file "cells" :depends-on ("defpackage"))
(:file "cell-types" :depends-on ("defpackage"))
(:file "integrity" :depends-on ("cell-types" "cells"))
(:file "constructors" :depends-on ("integrity"
(:file "initialize" :depends-on ("cells" "cell-types"))
(:file "md-slot-value" :depends-on ("integrity" "cell-
(:file "slot-utilities" :depends-on ("cells"))
(:file "optimization" :depends-on ("cells"))
(:file "link" :depends-on ("cells"))
(:file "propagate" :depends-on ("cells" "integrity"))
(:file "synapse" :depends-on ("cells"))
(:file "synapse-types" :depends-on ("cells"))
(:file "model-object" :depends-on ("defpackage"))
(:file "defmodel" :depends-on ("model-object"
"propagate" "constructors"))
(:file "md-utilities" :depends-on ("cells"))
(:file "family" :depends-on ("defmodel"))
(:file "fm-utilities" :depends-on ("cells"))
(:file "family-values" :depends-on ("family"
"propagate" "defmodel" ))
(:file "test" :depends-on ("family"))

Difficult to say it this works, but I would try to order the files so
the files are loaded before required. As far as I can see this has
already been done. As you have no cyclic dependencies it seems you cold
try to remove the :depends-on bit. (Make a backup first..)
Make sure it all hangs on :components. It looks like the parens are
closed after strings.

That closes (:module "utils-kt"...

I hope I have not misdirected anyone, I just offered ASD as one
/possible/ issue to be kept in mind.

The first thing I would do is take the first form that warns or produces
an error and try evaluating that directly... doh! Some distant bells
just started I just forwarded to you a patch for Clisp
for Cells 2.0. Not sure if that is what you found, but it does involved

sorry for not thinking of that sooner.


John Thingstad


"In the morning, hear the Way;
in the evening, die content!"
-- Confucius

The patch that Ken mentions modifies (comments out) a few lines in the
detritus.lisp and defpackage.lisp files:
In detritus.lisp the following are commented out:
;(defun slot-definition-name (slot)
; (clos::slotdef-name slot))
and in defpackage.lisp this line is commented out:
; #+clisp #:slot-definition-name

In my case (windows XP, cygwin), I needed to comment out only the
lines in detritus.lisp. The cells package then loaded just fine with

I can even (load "01-Cell-basics") demo. It looks like it is running
-- well it is not crashing, but I am not getting the echo after I
change the values of *S2*.

You might need to be more specific. That tutorial has two consecutive:

(setf (time-elapsed *s2*) 1)

....steps, the second demonstrating that Cells does not propagate (including echo) on non-changing changes.

> During the load, I get the following
> message:

Strange. The "action" is all featured out, the only thing that should happen during a load should be definitions. I just compiled and loaded my 01-cells-basics.lisp without a problem, fwiw being that our code is not the same. :)

C-STOP> stopping because
((setf md-slot-value)> cellular slot ~a of ~a cannot be setf unless
initialized as inputp
ACCEL #<STONE #x10212F7D>)c-break > stopping >
((setf md-slot-value)> cellular slot ~a of ~a cannot be setf unless
initialized as inputp
ACCEL #<STONE #x10212F7D>)
0> error is | #<SIMPLE-ERROR #x10441CC5>

That might be OK. The tutorial at that point is making a deliberate error for pedagogic purposes. I use AllegroCL which is non-conforming: a handler-case can trap BREAK which is supposed to land one ineluctably in the debugger. I think you can see the error is producing the same information the tutorial is trying to trap and then present to you.

Possibly CLisp handles BREAK correctly?

Unfortunately, the requisite post-goof call to cells-reset is part of the error handling being bypassed, so before continuing the tutorial you should evaluate (cells-reset) yourself.

is being modified, but has already been called.

Whoa. No clue. What led to that? Were all those messages together? ie, you /were/ loading the file and got all those? Did you take out the #+evaluatethis's? If so, put 'em back, you have voided the warranty. :)



"In the morning, hear the Way;
in the evening, die content!"
-- Confucius