freenode/#sicl - IRC Chatlog

14:14:55 beach jackdaniel: As you might know, I am writing a paper about debugging to submit to ELS, and I would like to include several existing implementations into the "previous work" section. So, when you have time, could you tell me: 1. whether ECL has the concept of breakpoints at all. 2. If so how they are implemented. 3. How ECL TRACE works. 4. How the stepper works. ? Thanks in advance.

14:18:02 Bike for clasp it's 1. no 2. n/a 3. changes the fdefinition 4. there is no stepper, if you wanna throw that in

14:18:30 beach Excellent! Thanks!

14:22:29 jackdaniel beach: sure. stepping works in the bytecodes vm (interpreter has a special opcode for stepping). trace is implemented by changing the fdefinition (there is a funny bug, because when you compile traced function, then you may trace again result what looks weird)

14:22:56 beach Thanks.

14:22:59 jackdaniel as of break and working with code compiled to native via C, there is gdb (and ECL has a perpared gdbinit with some definitions)

14:23:09 jackdaniel prepared*

14:23:11 Bike you can trace a function that's already traced?

14:23:31 jackdaniel Bike: yes, as I said, it is a bug. it happens only when you do

14:23:33 jackdaniel (trace foo)

14:23:35 jackdaniel (compile 'foo)

14:23:37 jackdaniel (trace foo)

14:23:47 beach I think he means that DEFUN will remove the wrapper.

14:23:48 jackdaniel the original definition is not "visible", because tracing parts were "compiled in"

14:24:16 jackdaniel defun would remove the wrapper, sure

14:24:44 jackdaniel beach: is that information sufficient or you want know more details?

14:24:52 Bike i rewrote clasp trace a while back so it doesn't compile anything itself, and stuff. nothing in it is clasp specific i think so you could probably use it. of course, it's a different situation since clasp compiles everything anyway

14:25:08 beach I think that's sufficient. If I think of something else, I'll ask again. Thank you very much.

14:26:08 jackdaniel Bike: are changes local to trace.lsp and in clasp's dev branch?

14:26:14 jackdaniel maybe I could take some of it, sure

14:26:35 Bike yes https://github.com/clasp-developers/clasp/blob/dev/src/lisp/kernel/lsp/trace.lsp

14:26:42 jackdaniel ecl also compiles everything right away (sometimes to bytecode)

14:27:06 jackdaniel thank you, I'll compare sources

14:27:06 Bike oh, also changed a few things in tpl to work with it though

14:27:16 jackdaniel noted

14:27:23 Bike just the :trace :untrace things. i never used them but maybe you do

14:27:58 jackdaniel afaik there are few other issues (at least with ecl) -- small disparities between documentation and functionality, but that will need to be investigated

14:28:19 jackdaniel https://gitlab.com/embeddable-common-lisp/ecl/issues/16

14:28:28 jackdaniel one of early issues :)

16:41:17 beach I just had another idea with respect to debugging. As the paper currently describes, every function called (directly or indirectly) under the control of the debugger will automatically execute the debugging (so slow) version of the function body.

16:41:30 beach I am thinking we should have a third table that indicates, per function, whether it should be excluded from debugging. The debugger would initially populate this table with all the standard Common Lisp functions.

16:41:38 beach The user can indicate that certain application functions should be entered into the table. The debugging version of function bodies would start by consulting this table, and if the current function is excluded, it jumps right back to the non-debugging version of the function body.

16:41:39 beach This way, the user can avoid slowing down the code too much in case the application has functions that do not require debugging.

16:42:35 beach Similarly, the user can use a debugger command to remove some system function from the table, thereby making it possible to set breakpoints in it.

17:09:14 beach As the proposal is right now, only leaf-functions should be excluded, since a function that is not being debugged, when it makes a function call, the callee is also not debugged.