One thing that I understand that Lisp,Scheme, and Smalltalk have in
common is the following ability:
The program stops at some point in the debugger.
You can then modify the code in the "frame" where the debugger stopped
in and tell the debugger to reevalute the frame and proceed.Something
else you can do is go up to the call stack and edit code and tell the
debugger to reevaluate the frame and proceed.
I'm curious how this functionality is implemented, in particularly
implemented efficiently. ( I can think of ways to implement it
inefficiently. )
Inparticular how do you undo side effects of the frame. ( For example
changing the value of a global variable, or class variable. )
IIRC, in the Lisp debuggers I've seen with such a feature, complete
'redo' is not what that debugger option does. It merely executes the
frame's function again with the same arguments. No side effects from
the failed attempt are undone explicitly.
Jeff
"Thaddeus L Olczyk" <······@interaccess.com> wrote in message
·······················@nntp.interaccess.com...
> One thing that I understand that Lisp,Scheme, and Smalltalk have in
> common is the following ability:
> The program stops at some point in the debugger.
> You can then modify the code in the "frame" where the debugger stopped
> in and tell the debugger to reevalute the frame and proceed.Something
> else you can do is go up to the call stack and edit code and tell the
> debugger to reevaluate the frame and proceed.
> Inparticular how do you undo side effects of the frame. ( For example
> changing the value of a global variable, or class variable. )
"Thaddeus L Olczyk" <······@interaccess.com> wrote in message
·······················@nntp.interaccess.com...
> One thing that I understand that Lisp,Scheme, and Smalltalk have in
> common is the following ability:
> The program stops at some point in the debugger.
> You can then modify the code in the "frame" where the debugger stopped
> in and tell the debugger to reevalute the frame and proceed.Something
> else you can do is go up to the call stack and edit code and tell the
> debugger to reevaluate the frame and proceed.
>
> I'm curious how this functionality is implemented, in particularly
> implemented efficiently. ( I can think of ways to implement it
> inefficiently. )
I'm not sure what you mean? Why would you care about efficiency of you've
just stopped the program? What kind of efficiency are you talking about.
> Inparticular how do you undo side effects of the frame. ( For example
> changing the value of a global variable, or class variable. )
:-). You don't.
Regards,
Peter van Rooijen.
On Fri, 1 Feb 2002 02:50:22 +0100, "Peter van Rooijen"
<·····@vanrooijen.com> wrote:
>I'm not sure what you mean? Why would you care about efficiency of you've
>just stopped the program?
Doh!
In order to make the debugger handle continuation of execution after
code or values are changed, you are going to to need to
"instrument/setup" ( for lack of a better word ) the code being
handled. This is doubly so if you want
to go upn the stack frame and reexecute code.
Since the standard way to enter a debugger from these languages is
a program error or a break/halt statement, the same instrumentation
is going to be applied to standard executable code. Otherwise the
debugger is going to have a hell of a time reexecuting code.
That instrumention done badly could have a significant effect on
execution time. Done well it could have a slight effect on execution
time, or possibly no effect on execution time.
Hi Thad,
I would have pointed you to Eliot's article if Jim hadn't already. Read it.
It's great stuff.
Regards,
Peter van Rooijen
"Thaddeus L Olczyk" <······@interaccess.com> wrote in message
·······················@nntp.interaccess.com...
> On Fri, 1 Feb 2002 02:50:22 +0100, "Peter van Rooijen"
> <·····@vanrooijen.com> wrote:
>
> >I'm not sure what you mean? Why would you care about efficiency of you've
> >just stopped the program?
> Doh!
> In order to make the debugger handle continuation of execution after
> code or values are changed, you are going to to need to
> "instrument/setup" ( for lack of a better word ) the code being
> handled. This is doubly so if you want
> to go upn the stack frame and reexecute code.
> Since the standard way to enter a debugger from these languages is
> a program error or a break/halt statement, the same instrumentation
> is going to be applied to standard executable code. Otherwise the
> debugger is going to have a hell of a time reexecuting code.
> That instrumention done badly could have a significant effect on
> execution time. Done well it could have a slight effect on execution
> time, or possibly no effect on execution time.
>