[cells-devel] Cells: Why am I put in the debugger here ?

[Frank Goenninger]

Am 21.05.2009 um 13:18 schrieb Kenneth Tilton:
> Frank Goenninger wrote:
>> Hi !
>> I have:
>> (defmd color ()
>>  red
>>  green
>>  blue
>>  alpha
>>  foreign-object
>>  :md-name (gensym "CELLO-COLOR-")
>>  :red     (c-in 0)
>>  :green   (c-in 0)
>>  :blue    (c-in 0)
>>  :alpha   (c-in 0)
>>  :foreign-object (c? (progn
>>                        (when (and (^foreign-object)
>
> use .cache to get the current value of the same cell a rule  
> mediates. going through the normal slot accessor establishes a  
> dependency of the cell on itself. Not good.

Yes, of course - it was late and hot and I had not really thought  
about it. Sorry and thanks.

> Leads specifically to....
>
>
>>                                   (not (null-pointer-p (^foreign- 
>> object))))
>>                          (foreign-free (^foreign-object)))
>>                        (let ((fo (foreign-alloc :float :count 4)))
>>                          (when (not (null-pointer-p fo))
>>                            (progn
>>                               (setf (mem-aref fo :float 0)
>>                                    (/ (^red) 255.00000000000f0))
>>                               (setf (mem-aref fo :float 1)
>>                                     (/ (^green) 255.0000000000f0))
>>                               (setf (mem-aref fo :float 2)
>>                                     (/ (^blue) 255.0000000000f0))
>>                               (setf (mem-aref fo :float 3)
>>                                     (/ (^alpha)  
>> 255.0000000000f0))))))))
>> So far so good. Compiling this works ok. Now I do:
>> CL-USER> (make-instance 'cnx::color :red 255 :green 128 :blue  
>> 0 :alpha 0)
>> A NEW CELLS::C-DEPENDENT struct @ #x10c95502 = <...>
>>   0 Class --------> #<STRUCTURE-CLASS CELLS::C-DEPENDENT>
>>   1 MODEL --------> CELLO-COLOR-12992
>>   2 SLOT-NAME ----> The symbol CNX::FOREIGN-OBJECT
>>   3 VALUE --------> The symbol NIL
>>   4 INPUTP -------> The symbol NIL
>>   5 SYNAPTIC -----> The symbol NIL
>>   6 CALLER-STORE -> (NIL), a proper list with 1 element
>>   7 STATE --------> The symbol :AWAKE
>>   8 VALUE-STATE --> The symbol :UNEVALUATED
>>   9 PULSE --------> fixnum 0 [#x00000000]
>>  10 PULSE-LAST-CHANGED -> fixnum 0 [#x00000000]
>>  11 PULSE-OBSERVED -> fixnum 0 [#x00000000]
>>  12 LAZY ---------> The symbol NIL
>>  13 OPTIMIZE -----> The symbol T
>>  14 DEBUG --------> The symbol NIL
>>  15 MD-INFO ------> The symbol NIL
>>  16 CODE ---------> ((PROGN ...)), a proper list with 1 element
>>  17 RULE ---------> #<Function (:INTERNAL
>>                                 (MOP:CLASS-DEFAULT-INITARGS
>>                                  CNX::COLOR
>>                                  :FOREIGN-OBJECT)
>>                                 0)
>>                       @ #x10cb44ca>
>>  18 USEDS --------> The symbol NIL
>>  19 USAGE --------> A simple-bit-vector (16) #*0000000000000000
>> [Current process: new-repl-thread]
>> [1i] CL-USER(1):
>> The only way out is a :reset - not good. What I am doing wrong ?  
>> (This is on AllegroCL 8.1).
>
> Actually, the above does not show a problem. "Only way out" of what?

Well, out of the inspector. When cells detects a circularity it calls  
(inspect ...) and I ended up in the AllegroCL inspector directly.

> Possibly just printing the thing, since without *print-circle* set  
> you will get into an infinite recursion when the cell lists its  
> dependencies which include itself.

I have set *print-circle* to t. So that was not the cause here.

>
>
> hth, kt

Yes, it did help ;-)

Frank

--
   Frank Goenninger

   Cell: 	+49 175 4321058
   E-Mail: 	frgo at me.com





-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2227 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/cells-devel/attachments/20090521/14b769d4/attachment.bin>