Re: help understanding debugger

Hi,

>My main question is why, after c-c, bt doesn't show me the stack past the c-c break
> - why not all the way down to the load?

  Break 1 [2]> ^C
  *** - Ctrl-C: User break
  [...]
  <8/214> #<SYSTEM-FUNCTION SYSTEM::DRIVER>

CLISP has always had the notion of stacked interactive REPLs (cf. in Emacs a recursive edit in the mini buffer, note that this has been disabled by default in recent versions of Emacs). From that viewpoint, it's quite logical to display stack frames only downto the most recent such REPL. SYSTEM::DRIVER drives such a REPL. There are a few others too.

Maybe that was thought to help people. Maybe on the contrary, it's better to remind people that the stack is actually deeper and there are more nested levels.


>A secondary question is what determines what "where" shows.

Your ^C doesn't make you quit the "Break 1" level, you're still positioned at an inner REPL driver. Hence WHERE displays the little information it has from within that inner loop. Just T, because there's nothing more on this inner stack.

>Similarly, up and top - I imagine that if BT showed load as I think it should,
>then top would also show it.

UP and DOWN has always confused the hell out of me since I first came across CLISP over 25 years ago.

I quite think that the user-friendliness of the debugger could be increased, but never put much thought into it. I tend not to use it much, because it would work best with interpreted code, however not byte-compiling was too slow back then.
What I used a lot are the pre- and postconditions of TRACE. CLISP's TRACE macro presents lots of non-standard, interesting options.

Regards,
	Jörg

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
clisp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/clisp-list