Hello,
I am using clisp 2.41.2 on windows XP & cygwin, with emacs and slime.
I downloaded cells, and I am trying to install them with asdf. I am
getting the following sequence of warnings, from which I proceed
through by "assuming everything is OK" in the slime debugger. I am
giving the file name and the reported error:
detritus.fas: INTERN("SLOTDEF-NAME"): #1=#<PACKAGE CLOS> is locked
cells.fas: #:|31 31 (DEFINE-CONSTANT *C-OPTIMIZEP* T)-3|: symbol
CELLS::*C-OPTIMIZEP* has no value
cell-types.fas: #:|71 71 (DEFINE-CONSTANT *CD-USAGECT* 64)-10|: symbol
CELLS::*CD-USAGECT* has no value
integrity.fas: #:|64 64 (DEFINE-CONSTANT *UFB-OPCODES* '(:USER-
NOTIFY :OUTPUT :SETF ...))-10|: symbol CELLS::*UFB-OPCODES* has no
value
initialize.fas: FIND-CLASS: CELLS::C-DEPENDENT does not name a class
link.fas: FIND-CLASS: CELLS::C-DEPENDENT does not name a class
I tried evaluating the code in 01-Cell-basics.lisp, and barfed at
(defparameter *s2* (make-instance 'stone
:accel 32 ;; (constant) feet per second per
second
:time-elapsed (c-in 0)))
because of the undefined function c-in. Now c-in is defined as a
macro in contructors.lisp, which loaded without problems.
So, what other component (of clisp, cells or brain) am I missing?
Thank you,
Mirko
On Nov 26, 3:46 pm, ·············@gmail.com wrote:
> Hello,
>
> I am using clisp 2.41.2 on windows XP & cygwin, with emacs and slime.
>
> I downloaded cells, and I am trying to install them with asdf. I am
> getting the following sequence of warnings, from which I proceed
> through by "assuming everything is OK" in the slime debugger. I am
> giving the file name and the reported error:
>
> detritus.fas: INTERN("SLOTDEF-NAME"): #1=#<PACKAGE CLOS> is locked
> cells.fas: #:|31 31 (DEFINE-CONSTANT *C-OPTIMIZEP* T)-3|: symbol
> CELLS::*C-OPTIMIZEP* has no value
> cell-types.fas: #:|71 71 (DEFINE-CONSTANT *CD-USAGECT* 64)-10|: symbol
> CELLS::*CD-USAGECT* has no value
> integrity.fas: #:|64 64 (DEFINE-CONSTANT *UFB-OPCODES* '(:USER-
> NOTIFY :OUTPUT :SETF ...))-10|: symbol CELLS::*UFB-OPCODES* has no
> value
> initialize.fas: FIND-CLASS: CELLS::C-DEPENDENT does not name a class
> link.fas: FIND-CLASS: CELLS::C-DEPENDENT does not name a class
>
> I tried evaluating the code in 01-Cell-basics.lisp, and barfed at
> (defparameter *s2* (make-instance 'stone
> :accel 32 ;; (constant) feet per second per
> second
> :time-elapsed (c-in 0)))
>
> because of the undefined function c-in. Now c-in is defined as a
> macro in contructors.lisp, which loaded without problems.
>
> So, what other component (of clisp, cells or brain) am I missing?
>
> Thank you,
>
> Mirko
I did not correctly describe the last part of my problem (for reason,
see closing sentence above).
(defparameter *s2* ...), now evaluated (in-package :cells) fails
because of undefined function MAKE-C-DEPENDENT
Mirko
·············@gmail.com wrote:
> On Nov 26, 3:46 pm, ·············@gmail.com wrote:
>
>>Hello,
>>
>>I am using clisp 2.41.2 on windows XP & cygwin, with emacs and slime.
>>
>>I downloaded cells, and I am trying to install them with asdf. I am
>>getting the following sequence of warnings, from which I proceed
>>through by "assuming everything is OK" in the slime debugger. I am
>>giving the file name and the reported error:
>>
>>detritus.fas: INTERN("SLOTDEF-NAME"): #1=#<PACKAGE CLOS> is locked
>>cells.fas: #:|31 31 (DEFINE-CONSTANT *C-OPTIMIZEP* T)-3|: symbol
>>CELLS::*C-OPTIMIZEP* has no value
>>cell-types.fas: #:|71 71 (DEFINE-CONSTANT *CD-USAGECT* 64)-10|: symbol
>>CELLS::*CD-USAGECT* has no value
>>integrity.fas: #:|64 64 (DEFINE-CONSTANT *UFB-OPCODES* '(:USER-
>>NOTIFY :OUTPUT :SETF ...))-10|: symbol CELLS::*UFB-OPCODES* has no
>>value
>>initialize.fas: FIND-CLASS: CELLS::C-DEPENDENT does not name a class
>>link.fas: FIND-CLASS: CELLS::C-DEPENDENT does not name a class
>>
>>I tried evaluating the code in 01-Cell-basics.lisp, and barfed at
>>(defparameter *s2* (make-instance 'stone
>> :accel 32 ;; (constant) feet per second per
>>second
>> :time-elapsed (c-in 0)))
>>
>>because of the undefined function c-in. Now c-in is defined as a
>>macro in contructors.lisp, which loaded without problems.
>>
>>So, what other component (of clisp, cells or brain) am I missing?
>>
>>Thank you,
>>
>>Mirko
>
>
> I did not correctly describe the last part of my problem (for reason,
> see closing sentence above).
> (defparameter *s2* ...), now evaluated (in-package :cells) fails
> because of undefined function MAKE-C-DEPENDENT
I am afraid what you are missing might be a system definition facility
with half a brain. ASDF is retarded. It loads things in the wrong order
and I do not use it so any .asd file I offer is at best suspect and at
worst (and usually) out-od-date. Anyway...
1. Always do a full compile. I believe ":force t" is the inscrutablese
for that. It will only take a few seconds.
2. There should be no warnings, so hack away until those are gone. That
define-constant thing is not mine, maybe Clisp has a problem somewhere.
fwiw, I am not sure how many folks have used Clisp with Cells, tho that
is where Cells-Gtk began so how bad could it be?
3. I am worried about bit rot, but it looks as if I updated
01-cells-basics.lisp at some point. I just tested my copy against my
cells and all went well, but I have not committed in ages. (The Open
SOurce Fairy has left the building.)
4. Feel free to email me directly with issues. You might zip up all the
source and send that along with questions since we have much diff code
bases cells-wise.
kt
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
P� Tue, 27 Nov 2007 00:09:36 +0100, skrev Ken Tilton
<···········@optonline.net>:
>
> I am afraid what you are missing might be a system definition facility
> with half a brain. ASDF is retarded. It loads things in the wrong order
> and I do not use it so any .asd file I offer is at best suspect and at
> worst (and usually) out-od-date. Anyway...
>
> 1. Always do a full compile. I believe ":force t" is the inscrutablese
> for that. It will only take a few seconds.
>
> 2. There should be no warnings, so hack away until those are gone. That
> define-constant thing is not mine, maybe Clisp has a problem somewhere.
> fwiw, I am not sure how many folks have used Clisp with Cells, tho that
> is where Cells-Gtk began so how bad could it be?
>
> 3. I am worried about bit rot, but it looks as if I updated
> 01-cells-basics.lisp at some point. I just tested my copy against my
> cells and all went well, but I have not committed in ages. (The Open
> SOurce Fairy has left the building.)
>
> 4. Feel free to email me directly with issues. You might zip up all the
> source and send that along with questions since we have much diff code
> bases cells-wise.
>
I seem to have mentioned this before, but if you set serial: t it reads
them in the order listed.
This might help some.
(Example from by blog software.)
(defsystem :blog
:serial t
:components ((:file "packages")
(:file "common")
(:file "sql")
(:file "start-blog")
(:file "front-page")
(:file "blog")
(:file "manage-blog")
(:file "manage-entry"))
:depends-on (:hunchentoot :clsql :cl-who :cl-ppcre :iterate))
--------------
John Thingstad
On Nov 26, 6:32 pm, "John Thingstad" <·······@online.no> wrote:
> På Tue, 27 Nov 2007 00:09:36 +0100, skrev Ken Tilton
> <···········@optonline.net>:
>
>
>
>
>
> > I am afraid what you are missing might be a system definition facility
> > with half a brain. ASDF is retarded. It loads things in the wrong order
> > and I do not use it so any .asd file I offer is at best suspect and at
> > worst (and usually) out-od-date. Anyway...
>
> > 1. Always do a full compile. I believe ":force t" is the inscrutablese
> > for that. It will only take a few seconds.
>
> > 2. There should be no warnings, so hack away until those are gone. That
> > define-constant thing is not mine, maybe Clisp has a problem somewhere.
> > fwiw, I am not sure how many folks have used Clisp with Cells, tho that
> > is where Cells-Gtk began so how bad could it be?
>
> > 3. I am worried about bit rot, but it looks as if I updated
> > 01-cells-basics.lisp at some point. I just tested my copy against my
> > cells and all went well, but I have not committed in ages. (The Open
> > SOurce Fairy has left the building.)
>
> > 4. Feel free to email me directly with issues. You might zip up all the
> > source and send that along with questions since we have much diff code
> > bases cells-wise.
>
> I seem to have mentioned this before, but if you set serial: t it reads
> them in the order listed.
> This might help some.
>
> (Example from by blog software.)
>
> (defsystem :blog
> :serial t
> :components ((:file "packages")
> (:file "common")
> (:file "sql")
> (:file "start-blog")
> (:file "front-page")
> (:file "blog")
> (:file "manage-blog")
> (:file "manage-entry"))
> :depends-on (:hunchentoot :clsql :cl-who :cl-ppcre :iterate))
>
> --------------
> John Thingstad
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 <·······@nyc.rr.com>"
:version "2.0"
:maintainer "Kenny Tilton <·······@nyc.rr.com>"
: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"
"cells"))
(:file "initialize" :depends-on ("cells" "cell-types"))
(:file "md-slot-value" :depends-on ("integrity" "cell-
types"))
(: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"))
))
Thanks,
Mirko
P� Tue, 27 Nov 2007 02:45:08 +0100, skrev <·············@gmail.com>:
>
> 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 <·······@nyc.rr.com>"
> :version "2.0"
> :maintainer "Kenny Tilton <·······@nyc.rr.com>"
> :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"
> "cells"))
> (:file "initialize" :depends-on ("cells" "cell-types"))
> (:file "md-slot-value" :depends-on ("integrity" "cell-
> types"))
> (: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.
--------------
John Thingstad
John Thingstad wrote:
> P� Tue, 27 Nov 2007 02:45:08 +0100, skrev <·············@gmail.com>:
>
>>
>> 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 <·······@nyc.rr.com>"
>> :version "2.0"
>> :maintainer "Kenny Tilton <·······@nyc.rr.com>"
>> :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"
>> "cells"))
>> (:file "initialize" :depends-on ("cells" "cell-types"))
>> (:file "md-slot-value" :depends-on ("integrity" "cell-
>> types"))
>> (: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 ringing...bingo. 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
"slotdef-name".
sorry for not thinking of that sooner.
kt
>
> --------------
> John Thingstad
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Nov 26, 9:57 pm, Ken Tilton <···········@optonline.net> wrote:
> John Thingstad wrote:
> > På Tue, 27 Nov 2007 02:45:08 +0100, skrev <·············@gmail.com>:
>
> >> 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 <·······@nyc.rr.com>"
> >> :version "2.0"
> >> :maintainer "Kenny Tilton <·······@nyc.rr.com>"
> >> :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"
> >> "cells"))
> >> (:file "initialize" :depends-on ("cells" "cell-types"))
> >> (:file "md-slot-value" :depends-on ("integrity" "cell-
> >> types"))
> >> (: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 ringing...bingo. 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
> "slotdef-name".
>
> sorry for not thinking of that sooner.
>
> kt
>
>
>
> > --------------
> > John Thingstad
>
> --http://www.theoryyalgebra.com/
>
> "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:
;#+clisp
;(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
asdf.
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*. During the load, I get the following
message:
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>
WARNING: The generic function #<STANDARD-GENERIC-FUNCTION C-OUTPUT-
SLOT-NAME>
is being modified, but has already been called.
I am going to play a bit with it to see if I can decipher it. At this
point I wanted to let you know that I was able to load cells.
Many thanks for the help so far.
Mirko
·············@gmail.com wrote:
> On Nov 26, 9:57 pm, Ken Tilton <···········@optonline.net> wrote:
>
>>John Thingstad wrote:
>>
>>>P� Tue, 27 Nov 2007 02:45:08 +0100, skrev <·············@gmail.com>:
>>
>>>>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 <·······@nyc.rr.com>"
>>>> :version "2.0"
>>>> :maintainer "Kenny Tilton <·······@nyc.rr.com>"
>>>> :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"
>>>>"cells"))
>>>> (:file "initialize" :depends-on ("cells" "cell-types"))
>>>> (:file "md-slot-value" :depends-on ("integrity" "cell-
>>>>types"))
>>>> (: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 ringing...bingo. 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
>>"slotdef-name".
>>
>>sorry for not thinking of that sooner.
>>
>>kt
>>
>>
>>
>>
>>>--------------
>>>John Thingstad
>>
>>--http://www.theoryyalgebra.com/
>>
>>"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:
> ;#+clisp
> ;(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
> asdf.
>
> 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.
> WARNING: The generic function #<STANDARD-GENERIC-FUNCTION C-OUTPUT-
> SLOT-NAME>
> 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. :)
kt
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Nov 27, 7:10 pm, Ken Tilton <···········@optonline.net> wrote:
> ·············@gmail.com wrote:
> > On Nov 26, 9:57 pm, Ken Tilton <···········@optonline.net> wrote:
>
stuff deleted ...
Ken wrote
>
> >>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 ringing...bingo. 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
> >>"slotdef-name".
>
> >>sorry for not thinking of that sooner.
>
> >>kt
>
> >>>--------------
> >>>John Thingstad
>
> >>--http://www.theoryyalgebra.com/
>
> >>"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:
> > ;#+clisp
> > ;(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
> > asdf.
>
> > 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.
>
> > WARNING: The generic function #<STANDARD-GENERIC-FUNCTION C-OUTPUT-
> > SLOT-NAME>
> > 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. :)
>
> kt
>
> --http://www.theoryyalgebra.com/
>
> "In the morning, hear the Way;
> in the evening, die content!"
> -- Confucius
OK, I cleaned things up, and they go exactly as you say ... except :-)
I focused on the stone model in 01-Cells-basic. I don't think that
the value distance slot changes:
- when I change time, I am informed about the change in time, but not
in distance
- If I examine the values of time-elapsed and distance (using (slot-
value *s2* 'distance), the first one has the correct value, while the
second one is nil
- If I don't set the error handlers, I do get an error if I try to
set a value to accel, but not if I try to set a value to distance.
I tried changing the definition of distance :initform from 0 to (c-in
0) (following the examples of time-elapsed and accel, but that did
only allowed me to set distance, and not to calculate it (although
when setting it, I would get the correct echo message).
I suspect that some of our files our out of sync. Here is the
definition of stone that I downloaded yesterday from the web site.
(defmodel stone ()
((accel :cell t :initarg :accel :initform 0 :accessor accel)
(time-elapsed :cell t :initarg :time-elapsed
:initform (c-in 0)
:accessor time-elapsed)
(distance :cell t :initarg :distance :initform 0 :accessor
distance))
(:default-initargs
:distance (c? (/ (* (accel self)
(expt (time-elapsed self) 2))
2))))
Mirko
·············@gmail.com wrote:
> On Nov 27, 7:10 pm, Ken Tilton <···········@optonline.net> wrote:
>
>>·············@gmail.com wrote:
>>
>>>On Nov 26, 9:57 pm, Ken Tilton <···········@optonline.net> wrote:
>>
> stuff deleted ...
>
> Ken wrote
>
>>>>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 ringing...bingo. 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
>>>>"slotdef-name".
>>
>>>>sorry for not thinking of that sooner.
>>
>>>>kt
>>
>>>>>--------------
>>>>>John Thingstad
>>
>>>>--http://www.theoryyalgebra.com/
>>
>>>>"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:
>>>;#+clisp
>>>;(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
>>>asdf.
>>
>>>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.
>>
>>
>>>WARNING: The generic function #<STANDARD-GENERIC-FUNCTION C-OUTPUT-
>>>SLOT-NAME>
>>> 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. :)
>>
>>kt
>>
>>--http://www.theoryyalgebra.com/
>>
>>"In the morning, hear the Way;
>> in the evening, die content!"
>> -- Confucius
>
>
> OK, I cleaned things up, and they go exactly as you say ... except :-)
>
> I focused on the stone model in 01-Cells-basic. I don't think that
> the value distance slot changes:
>
> - when I change time, I am informed about the change in time, but not
> in distance
> - If I examine the values of time-elapsed and distance (using (slot-
> value *s2* 'distance), the first one has the correct value, while the
> second one is nil
Inconceivable. Well, if you did not do (cells-reset) Cells can look to
be completely non-functional, but you say other things do happen.
I just sent you my version. This tutorial does not get into any of the
edge cases addressed by recent work on Cells, so I am hopeful it will
work with the version you have.
I suggest not loading the file, because definitions lower down may
conflict with those above. (I think I intended this to be evaluated form
by form, maybe not, but let's play it safe. Of course if it won't work
this way, do the load first.)
Then just follow the tutorial and stop at the first problem and send me
the REPL output top to bottom. Tilton's Law: Always fix the first
problem. Corrollary: there is only ever one problem.
> - If I don't set the error handlers, I do get an error if I try to
> set a value to accel, but not if I try to set a value to distance.
>
> I tried changing the definition of distance :initform from 0 to (c-in
> 0) (following the examples of time-elapsed and accel, but that did
> only allowed me to set distance, and not to calculate it (although
> when setting it, I would get the correct echo message).
>
> I suspect that some of our files our out of sync. Here is the
> definition of stone that I downloaded yesterday from the web site.
>
> (defmodel stone ()
> ((accel :cell t :initarg :accel :initform 0 :accessor accel)
> (time-elapsed :cell t :initarg :time-elapsed
> :initform (c-in 0)
> :accessor time-elapsed)
> (distance :cell t :initarg :distance :initform 0 :accessor
> distance))
> (:default-initargs
> :distance (c? (/ (* (accel self)
> (expt (time-elapsed self) 2))
> 2))))
I note that you reported having cleaned things up, vs having
re-downloaded the original. We have discussed voided warranties, yes? :)
Tell you what, I sent you mine, you send me yours.
kt
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
Ken Tilton <···········@optonline.net> writes:
>
> I am afraid what you are missing might be a system definition facility
> with half a brain. ASDF is retarded. It loads things in the wrong order
> and I do not use it so any .asd file I offer is at best suspect and at
> worst (and usually) out-od-date. Anyway...
Under what circumstances do you see that? I'm pretty sure that when
I've listed my dependencies properly that everything has loaded
properly...
--
Robert Uhl <http://public.xdi.org/=ruhl>
A layman knows he has to kick it; An amateur knows where to kick it; A
professional knows how hard. --Mike Andrews
Robert Uhl <·········@NOSPAMgmail.com> writes:
> Ken Tilton <···········@optonline.net> writes:
>>
>> I am afraid what you are missing might be a system definition facility
>> with half a brain. ASDF is retarded. It loads things in the wrong order
>> and I do not use it so any .asd file I offer is at best suspect and at
>> worst (and usually) out-od-date. Anyway...
>
> Under what circumstances do you see that? I'm pretty sure that when
> I've listed my dependencies properly that everything has loaded
> properly...
Ha - Kenny gave up on ASDF when it was still in its early stages ;-) I
want to confirm that it works quite well now for dependencies -
and here's the working Cells ASDF file I am using:
--- CUT HERE ---
;;;; -*- Mode: Lisp; Syntax: ANSI-Common-Lisp; Base: 10 -*-
#+(or allegro lispworks cmu mcl clisp cormanlisp sbcl scl)
(progn
(declaim (optimize (debug 3) (speed 3) (safety 1) (compilation-speed 0)))
(asdf:defsystem :cells
:name "cells"
:author "Kenny Tilton <·········@gmail.com>"
:maintainer "Kenny Tilton <·········@gmail.com>"
:licence "Lisp LGPL"
:description "Cells"
:long-description "Cells: a dataflow extension to CLOS."
:serial t
:components ((:module "utils-kt"
:serial t
:components ((:file "defpackage")
(:file "debug")
(:file "flow-control")
(:file "detritus")
(:file "strings")
(:file "datetime")))
(:file "defpackage")
(:file "trc-eko")
(:file "cells")
(:file "integrity")
(:file "constructors")
(:file "cell-types")
(:file "synapse")
(:file "synapse-types")
(:file "initialize")
(:file "md-slot-value")
(:file "slot-utilities")
(:file "link")
(:file "propagate")
(:file "model-object")
(:file "defmodel")
(:file "md-utilities")
(:file "family")
(:file "fm-utilities")
(:file "family-values")
(:file "variables")))
(defmethod perform ((o load-op) (c (eql (find-system :cells))))
(pushnew :cells *features*))
(defmethod perform ((o test-op) (c (eql (find-system :cells))))
(oos 'load-op :cells-test))
(defmethod perform ((o test-op) (c (eql :cells)))
(oos 'load-op :cells-test)))
--- END CUT HERE ---
Hth - Frank
--
Frank Goenninger
frgo(at)mac(dot)com
"Don't ask me! I haven't been reading comp.lang.lisp long enough to
really know ..."