[Bese-devel] Backtracking bug still present in my runs.

[Marco Baringer]

William Halliburton <whalliburton at gmail.com> writes:

> Darcs a fresh arnesi_dev (the website still says that arnesi_cvs is
> the development branch). 

thanks for pointing that out.

>                           Darcs a fresh ucw_dev. Load into sbcl +
> araneida.
>
> The calltest component from the previous email still displays the
> same behavior.

i get the correct behaviour (openmcl+mod_lisp and sbcl+mod_lisp on
darwin, latest ucw).

here's a short description of the machanics of backtracking which i
hope will help you in your debugging (you may or may not have already
figured this out):

every frame has a list representing the stuff it needs to
backtrack. for every place (which is usally a slot but can be any
setf'able form) have a cons cell composed of value and place, value is
some lisp object and place is an instance of the PLACE class with the
three closures for getting, setting and copying the value.

whenever a reuest comes in we call REINSTATE-BACKTRACK (this, all the
following two methods, are defined in ucw/src/backtrack.lisp) which
simply calls the setter closure and attempts to create the state of
the UI at the time the frame was generated. we now create a new frame
(representing this request/respone cycle) and call CLONE-BACKTRACK to
create the new frame's backtrack list, atm this is just a call to
copy-tree. we then call the action which probably changes the values
of the backtrack'd place and maybe adds new place (by calling the
BACKTRACK method). When the action is done, just _before_ calling the
render-on method, we store the current values of all the places which
need backtracking by calling SAVE-BACKTRACKED. By tracing these 4
methods you can get a very good idea of what's getting saved, what's
getting reloaded and when. hth.

-- 
-Marco
Ring the bells that still can ring.
Forget the perfect offering.
There is a crack in everything.
That's how the light gets in.
	-Leonard Cohen