Ramarren wrote:
> On Tue, Mar 24, 2009 at 9:00 PM, Kenneth Tilton <[email protected]> wrote:
>> btw, If this version of Cells-Gtk is built on the latest Cells the
>> with-integrity call can be omitted (but is harmless) because the SETF code
>> will notice no one is managing integrity and take over integrity management
>> itself.
> 
> Well, it is built on slightly modified Cells from common-lisp.net CVS,
> so I don't know how latest it is. It says last modified five months
> ago. I tried looking into the source, but the SETF in question
> contains a COND which completely confused me... I mean, if it signals
> an error saying that it has to be wrapped in with-integrity, then why
> doesn't it just do it, especially considering that it does just that
> in the other branch?

Well, first of all, the second branch happens only if we are not already 
under integrity management and is just being helpful as I indicated by 
auto-supplying IM. That is just a little convenience.

Once we are under IM, one SETF needs to finish before the next begins. 
(Yes, wild and crazy types can bind *defer-changes* to nil and wreak 
havoc. Let's forget them.)

Now consider what happens if the internals silently defers a setf when 
it sees IM underway already IIRC:

(print (setf (^x) 42))
-> a closure in which the desired state change gets bottled up until it 
is time to run. No, wait. I think I changed that to actually say 
:DEFERRED or something. And more confusing (they likely will not think 
to capture and log the the return value of the SETF since we all know 
what that has to be, right? 42!) no propagation happens.

Of course the poor programmer has no idea or has forgotten this little 
oddity because hopefully with Cells they do not do many SETFs any more 
so they go quietly mad trying to understand where the 42 went.

ie, it is a Very Bad Idea to mess with the behavior of something like 
SETF, but I had to, so what I did was: if you understand all this, you 
will effectively sign a waiver saying you understand all this by 
wrapping a SETF in with-integrity. Conversely, if no waiver is provided, 
the code alerts you.

Somewhere else in Cells a user provided a 250-word error message cum 
tutorial on something very similar, and IIRC it helped even me once. 
Maybe we need another.

kt



> 
> (cond
>    ((find (c-lazy c) '(:once-asked :always t))
>     (md-slot-value-assume c new-value nil))
> 
>    (*defer-changes*
>     (c-break "SETF of ~a must be deferred by wrapping code in
> WITH-INTEGRITY" c))
> 
>    (t
>     (with-integrity (:change slot-name)
>       (md-slot-value-assume c new-value nil))))
> 
> Regards, Jakub
> 
> 
> ------------------------------------------------------------------------
> 
> 
> No virus found in this incoming message.
> Checked by AVG - www.avg.com 
> Version: 8.0.238 / Virus Database: 270.11.26/2020 - Release Date: 03/24/09 
> 09:19:00
> 

_______________________________________________
cells-gtk-devel site list
[email protected]
http://common-lisp.net/mailman/listinfo/cells-gtk-devel

Reply via email to