Print stack-trace error from trace prompt about alsprolog HOT 5 CLOSED

• deb_stack_trace/2 doesn’t appear to be defined anywhere.
  deb_stack_trace/4 is defined in dbg_class.pro

• dbg_class.pro is only loaded in alsdev:

  blt_dvsh.pro: reconsult(dbg_class),
  builtins.pro:% consult_builtins(BDir, dbg_class),

• In debugger.pro, the code for responding to “t” during “trace(…)” is:

%% === Print stack trace
act_on_response(stack_trace, Port,Box,Depth, Module,Goal,Wins,Response)
:-
builtins:clause(alsdev_running,_),
!,
builtins:get_primary_manager(ALSMgr),
alsdev:accessObjStruct(debugger_mgr, ALSMgr,DebuggerMgr),
% send(DebuggerMgr, show_stack),
send(DebuggerMgr, show_stack_list),
% show_again(Port,Box,Depth,Module,Goal,Wins,Response).
getresponse2(Wins,Port,Box,Depth, Module, Goal, Response).

The two uncommented occurrences of DebuggerMgr above appear to be the /only/ occurrences of DebuggerMgr in all of the builtins.

• Whether or not the deb_stack_trace/4 might work in the alsdev debugger is moot, since there is no button anywhere which can request a stack trace during a debugger trace.
  However, in debugwin.tcl, there is a commented-out spec of a trace button (comment markers dropped because markdown makes them big/bold):

  button $base.buttons.stack_trace
  -padx 2 -text stack
  -command { set DebugResponse Bt }

** It looks to me like all of this was in-prcoess when work was halted in the 90’s.

• Having a stack trace feature embedded in the debugger would certainly be helpful for real debugging, as well as for learning.
• The act_on_response code above suggests that there was an intent to consolidate the alspro and alsdev basic debugger code.

from alsprolog.

Digging a bit deeper into the stack trace mechanism inside the debugger (dog_class.pro), the actual stack trace is emitted by deb_stack_trace_list/4 [called from debugger_mgrAction( show_stack_list, State) ]. This is nearly isomorphic to the non-alsdev mechanism disp_stack_trace/2 at the end of blt_brk.pro.

from alsprolog.

What we do here is basically dependent on the decision for #37. If we go with the "all the sausage" display approach in #37, then here we should:
a) implement deb_stack_trace and deb_stack_trace_list/4, as nearly isomorphic to disp_stack_trace/2 as possible, possibly coalescing them with some unused args in the non-alsdev setting;
b) add a t-option button to the alsdev debugger window, and whatever additional code is needed.

from alsprolog.

deb_stack_trace/2 was added in 3b8e74a but was later commented out. It was finally deleted in 0cb0321.

If I replace the bad deb_stack_trace(1,1) call with builtins:stack_trace, then the bug is technically fixed (but ugly, see below). It looks like deb_stack_trace/2 filtered the stack.

(6) 4 call: user:pbi_debug(<c)?t
----begin stack trace----
(1) builtins:stack_trace(1)
(2) debugger:act_on_response(stack_trace,call,6,4,user,pbi_debug('<c'),tty...)
(3) debugger:showGoal(6,4,call,user,?,?)
(4) debugger:dogoal(6,4,debug_user,user,pbi_debug('<c'))
(5) user:c
(6) debugger:dogoal(5,3,debug_user,user,c)
(7) user:b
(8) debugger:dogoal(3,2,debug_user,user,b)
(9) user:a
(10) debugger:dogoal(1,1,debug_user,user,a)
(11) debugger:trace0(user,a)
(12) builtins:catch0(debugger,?,?)
----end stack trace----

from alsprolog.

Fixed via 3ccf625

from alsprolog.