Peter Hildebrandt wrote:
Ken, did you change anything in cells as to how circular references are dealt with?
ps. while I am looking, look for a comment dated 2008-03-15 in cells.lisp k
As you saw in my other mail, I found the intermediate cause of the problem: I had included a reference to (id self) in initialize-instance of widget. For some reason that causes the circularity detection to raise its voice.
What I don't understand, however, is why a reference to the slot in initialize-instance :after brings out circularity.
For now, I moved the stuff into the rule for the id slot itself, so when the id is calculated, I use it right away, and don't have to worry about cell access. slot-value would have been another option, I suppose.
But still: why???
Peter
(oh, and yes, my cells from cvs is brand new)
On Mon, Apr 14, 2008 at 6:38 PM, Ken Tilton kennytilton@optonline.net wrote:
Peter Hildebrandt wrote:
Ken, did you change anything in cells as to how circular references are dealt with?
ps. while I am looking, look for a comment dated 2008-03-15 in cells.lisp k
Peter Hildebrandt wrote:
As you saw in my other mail, I found the intermediate cause of the problem: I had included a reference to (id self) in initialize-instance of widget. For some reason that causes the circularity detection to raise its voice.
What I don't understand, however, is why a reference to the slot in initialize-instance :after brings out circularity.
For now, I moved the stuff into the rule for the id slot itself, so when the id is calculated, I use it right away, and don't have to worry about cell access. slot-value would have been another option, I suppose.
But still: why???
Recently some evil programming took forever to debug because I was re-entering a rule without realizing it. After figuring out that that was happening and fixing the cause of that, I looked to see why rule re-entrance had not been detected, which I seemed to recall it always had been.
Turns out the rule began with without-c-dependency as a trick to run only once. That macro simply:
`(let ((cells::*call-stack* nil)) ,@body)
And that worked because the dependent cell was always identifed as (car cells::*call-stack*).
Well, I like early bug detection you may have noticed recently <g>, so I decided the macro without-c-dependency should leave the *call-stack* intact and instead bind a separate new *depender* special to nil, with *depender* being the, well, depender honored by the Cells machinery.
You should not have been doing cells-y stuff in i-i, but you got away with it because of the old without-c-dependency behavior, so...
...congratulations, you are the first victim to fall into my new bug trap. :)
kt
Ken Tilton wrote:
Recently some evil programming took forever to debug because I was re-entering a rule without realizing it. After figuring out that that was happening and fixing the cause of that, I looked to see why rule re-entrance had not been detected, which I seemed to recall it always had been.
Turns out the rule began with without-c-dependency as a trick to run only once. That macro simply:
`(let ((cells::*call-stack* nil)) ,@body)And that worked because the dependent cell was always identifed as (car cells::*call-stack*).
In case that last bit is not clear, what I meant was "That worked [to avoid dependency] because the dependent cell was identified by taking the car of the *call-stack*"
btw, note that this undetected re-entrance would happen if /any/ rule in the chain leading back to the same cell did a without-c-dependency.
kt
On Mon, Apr 14, 2008 at 7:04 PM, Ken Tilton kennytilton@optonline.net wrote:
btw, note that this undetected re-entrance would happen if /any/ rule in the chain leading back to the same cell did a without-c-dependency.
If you write it like that, it's pretty clear given the scope. But for real world code, this must have been a pretty big loop hole -- allowing for dangerous code to pass through and break badly further down the road.
So I'm glad we're on the safe side now. :-)
Peter
Ken,
thanks for shadding some light on the issue.
I think I found a decent solution to the problem by abusing (what a contradiction) the rule for the id slot and dropping in my two lines:
#+libcellsgtk (gtk-signal-connect-swap id "configure-event" (cffi:get-callback 'reshape-widget-handler) :data id) (gtk-signal-connect-swap id "delete-event" (cffi:get-callback 'delete-widget-handler) :data id)
This way I can use id -- the local lexical variable holding the brand new id -- and work with it without any cells dependency. And one could argue that I do the required stuff right where it belongs.
Cheers, Peter On Mon, Apr 14, 2008 at 6:57 PM, Ken Tilton kennytilton@optonline.net wrote:
Peter Hildebrandt wrote:
As you saw in my other mail, I found the intermediate cause of the problem: I had included a reference to (id self) in initialize-instance of widget. For some reason that causes the circularity detection to raise its voice.
What I don't understand, however, is why a reference to the slot in initialize-instance :after brings out circularity.
For now, I moved the stuff into the rule for the id slot itself, so when the id is calculated, I use it right away, and don't have to worry about cell access. slot-value would have been another option, I suppose.
But still: why???
Recently some evil programming took forever to debug because I was re-entering a rule without realizing it. After figuring out that that was happening and fixing the cause of that, I looked to see why rule re-entrance had not been detected, which I seemed to recall it always had been.
Turns out the rule began with without-c-dependency as a trick to run only once. That macro simply:
`(let ((cells::*call-stack* nil)) ,@body)And that worked because the dependent cell was always identifed as (car cells::*call-stack*).
Well, I like early bug detection you may have noticed recently <g>, so I decided the macro without-c-dependency should leave the *call-stack* intact and instead bind a separate new *depender* special to nil, with *depender* being the, well, depender honored by the Cells machinery.
You should not have been doing cells-y stuff in i-i, but you got away with it because of the old without-c-dependency behavior, so...
...congratulations, you are the first victim to fall into my new bug trap. :)
kt
On Mon, Apr 14, 2008 at 6:57 PM, Ken Tilton kennytilton@optonline.net wrote:
Recently some evil programming took forever to debug because I was re-entering a rule without realizing it. After figuring out that that was happening and fixing the cause of that, I looked to see why rule re-entrance had not been detected, which I seemed to recall it always had been.
Turns out the rule began with without-c-dependency as a trick to run only once. That macro simply:
`(let ((cells::*call-stack* nil)) ,@body)And that worked because the dependent cell was always identifed as (car cells::*call-stack*).
Wow, congrats for figuring that out. Sounds like one of these things that take forever ...
Well, I like early bug detection you may have noticed recently <g>, so I decided the macro without-c-dependency should leave the *call-stack* intact and instead bind a separate new *depender* special to nil, with *depender* being the, well, depender honored by the Cells machinery.
Sounds good. And you obviously found some "unclean" stuff I was doing.
You should not have been doing cells-y stuff in i-i, but you got away with it because of the old without-c-dependency behavior, so...
Actually, the drawing area widget still gets away with it. Maybe because it does not have kids ... I don't know.
...congratulations, you are the first victim to fall into my new bug trap. :)
I'm proud :)
Peter
-
Ken Tilton -
Peter Hildebrandt