freenode/#ccl - IRC Chatlog
Search
21:34:05
devon
phoe: pjb: Thanks, the stepper steps. Can it display the execution point in the source file, as, e.g., the emacs-lisp stepper does?
5:39:19
devon
stepper-notes.txt mentions Eager/Lazy/Macro options. I don't fully understand but I imagine LOAD, COMPILE-FILE and READ would suffice to record source info but this is not yet implemented.
5:40:35
pjb
devon: well, sldb can locate the source of a frame, by typing v on that frame. So I would assume that you can use the same functions to find the souroce of any form.
5:41:15
pjb
devon: slime/swank use implementation dependent mechanisms for that (this is why it doesn't work with all implementations0.
5:41:45
pjb
cl-stepper is purely conforming CL code. It should work on all implementation (but it's much slower, and requires that you recompile the code you want to instrument).
5:42:33
pjb
So indeed, by using a set of reader macros, or a conforming reader (and therefore load and compile-file), we could take note of the source positions to help debuging in a purely conforming way.
5:42:54
pjb
That said, given that nowadays we have the sources of most implementations, this may be not the best strategy.
5:43:32
pjb
A little like what beach does with SICL, implementing modules that can be re-used in implementations.
5:44:21
pjb
It might be better to improve on it, and to implement good debugging tools on such an API, and to implement this API in all the implementations.
5:44:55
pjb
cl-stepper was a desesperate move to step using ccl… But if I had time and resources, the next step would be to implement the CL:STEP in ccl.
5:51:27
pjb
Looking at the implementation of frame-source-location in the various swank implementation files is instructive. Here you see the problem.
5:52:39
pjb
swank doesn't define an API to find the source location of an instruction or a function; but it has that internally depending on the implementation, so you can use those internals to implement an API to do that, and use it in a stepper or debugger.
5:54:47
devon
A friend at Red Hat worked for years on kernel support for a debugger API but the project delivered no results I ever saw.
5:55:00
pjb
cl-stepper wouldn't know the PC, but it would know the source form (since we compile it with cl-stepper), and it would know the function. There are also ways to instrument compiled functions (setting a wrapper in symbol-function). So you can choose to implement this form to source operation in a conforming way by taking note of the source position when reading the source in cl-stepper, or without cl-stepper, you could implement ano
5:55:37
pjb
devon: well, debuggers exist, so it's possible. But defining an API general enough for all languages is difficult.
5:57:21
pjb
But if we restrict ourselves to CL implementation, the trick is that once you define the API, you would modify the implementations to implement this API to the fullest. This means work (N implementations, 1 debugger).
6:03:20
devon
Who was that fellow who'd wave a rubber snake and say "snake in the grass" lecturing on omniscient debugging a decade ago? Even GDB has step-backwards (not available on all platforms) and to my mind it's essential.
6:07:12
devon
There are plenty of cases where the compiler has rearranged the code so much, no possible mapping of execution state to source code would make much sense.
6:07:44
pjb
well, when designing the API, you may want to integrate features to be able to implement modern debugging features such as time-travelling debugger…
6:08:31
pjb
when compiling with (debug 3) it's the responsibility of the compiler to generate what is needed to help debugging, ie. to instrument the code.
6:11:25
devon
I've got so many tabs open searching for those notes you mentioned by beach, my fans are roaring and this Vivaldi browser I'm trying out grinds to a standstill for minutes at a time.
6:13:21
pjb
Note that time travelling debugging requires taking snapshots at each syscalls. Then the state that be rebuild to the point in the past by re-executing from the last previous snapshot.