Debugging Lisp Part 1: Recompilation
malisper.me
Debugging Lisp Part 1: Recompilation
1–9 of 9 posts
Re: Debugging Lisp Part 1: Recompilation
#2On more than one occation when writing web code I found myself in the debugger in the middle of a request handler. The browser just sits there waiting for a response. I found the bug and restarted the handler before the browser time-outed. The browser recieved the response as if a bug never existed. Of course this only works if you can find and fix a bug in under 120 seconds :)
Re: Debugging Lisp Part 1: Recompilation
#3As a non-lisp user, this {easy-debug -> fix -> resume program} appears to be extremely useful, and something that only lisp offers.
e.g. wading through clojure stack traces seems very primitive in comparison.
How important is it in practice? Can/could other languages do this?
As an outsider looking at new (to me) languages, it's hard to judge what the pros and cons of a language are - especially the cons - e.g. several years ago, when looking at clojure, it took a lot of searching before I concluded that clojure did not have this feature (maybe that has changed now?). Meanwhile the 'learn language x' books always seem to focus only on syntax, rather than workflow.
Re: Debugging Lisp Part 1: Recompilation
#4As a non-lisp user, this {easy-debug -> fix -> resume program} appears to be extremely useful, and something that only lisp offers. e.g. wading through clojure stack traces seems very primitive in comparison. How important is it in practice? Can/could other languages do this? As an outsider looking at new (to me) languages, it's hard to judge what the pros and cons of a language are - especially the cons - e.g. sever…
There is an interesting story on how NASA used similar techniques to debug a problem on Deep Space 1, from earth, they were using Common LISP, you can find a bit more detail in here (http://www.flownet.com/gat/jpl-lisp.html) look for 1994-1999 - Remote Agent. I remember one of the guys who worked on this gave a talk which was in youtube but I was not able to find it again.
Re: Debugging Lisp Part 1: Recompilation
#5As a non-lisp user, this {easy-debug -> fix -> resume program} appears to be extremely useful, and something that only lisp offers. e.g. wading through clojure stack traces seems very primitive in comparison. How important is it in practice? Can/could other languages do this? As an outsider looking at new (to me) languages, it's hard to judge what the pros and cons of a language are - especially the cons - e.g. sever…
Edit and Continue in Visual Studio is similar to that.
You can change the source code while the program is paused in the debugger, for instance in a breakpoint, and continue after your modifications.
Re: Debugging Lisp Part 1: Recompilation
#6As a non-lisp user, this {easy-debug -> fix -> resume program} appears to be extremely useful, and something that only lisp offers. e.g. wading through clojure stack traces seems very primitive in comparison. How important is it in practice? Can/could other languages do this? As an outsider looking at new (to me) languages, it's hard to judge what the pros and cons of a language are - especially the cons - e.g. sever…
Edit and Continue in Visual Studio is similar to that. You can change the source code while the program is paused in the debugger, for instance in a breakpoint, and continue after your modifications.
Interesting, thanks.
Do you get the ability to move the execution point back to before the the error, in order to resume execution? - from what I can tell, this isn't possible - from https://msdn.microsoft.com/library/y740d9d3.aspx#BKMK_Set_th...
"Setting the next statement causes the program counter to jump directly to the new location. Use this command with caution:"
"If you move the execution point backwards, intervening instructions are not undone. "
Re: Debugging Lisp Part 1: Recompilation
#7Earlier quoted context omitted.
Edit and Continue in Visual Studio is similar to that. You can change the source code while the program is paused in the debugger, for instance in a breakpoint, and continue after your modifications.
Interesting, thanks. Do you get the ability to move the execution point back to before the the error, in order to resume execution? - from what I can tell, this isn't possible - from https://msdn.microsoft.com/library/y740d9d3.aspx#BKMK_Set_th... "Setting the next statement causes the program counter to jump directly to the new location. Use this command with caution:" "If you move the execution point backwards, inte…
Not sure, I have never tried moving the instruction pointer after Edit & Continue.
Moving the instruction pointer backwards has been fine in my experience if you choose a suitable line to reset your state.
Re: Debugging Lisp Part 1: Recompilation
#8Earlier quoted context omitted.
Edit and Continue in Visual Studio is similar to that. You can change the source code while the program is paused in the debugger, for instance in a breakpoint, and continue after your modifications.
Interesting, thanks. Do you get the ability to move the execution point back to before the the error, in order to resume execution? - from what I can tell, this isn't possible - from https://msdn.microsoft.com/library/y740d9d3.aspx#BKMK_Set_th... "Setting the next statement causes the program counter to jump directly to the new location. Use this command with caution:" "If you move the execution point backwards, inte…
> Do you get the ability to move the execution point back to before the the error, in order to resume execution?
You can in Visual Studio 2012 and in Visual 2015 some corner cases were fixed.
Just drag the arrow backwards with the mouse.
Re: Debugging Lisp Part 1: Recompilation
#9As a non-lisp user, this {easy-debug -> fix -> resume program} appears to be extremely useful, and something that only lisp offers. e.g. wading through clojure stack traces seems very primitive in comparison. How important is it in practice? Can/could other languages do this? As an outsider looking at new (to me) languages, it's hard to judge what the pros and cons of a language are - especially the cons - e.g. sever…
It's typical for Smalltalk coding.