|View Issue Details [ Jump to Notes ]||[ Issue History ] [ Print ]|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000020||mercury||Bug||public||2007-10-19 09:30||2010-02-05 15:43|
|Target Version||Fixed in Version|
|Summary||0000020: declarative debugger going up search tree when initial node trusted.|
|Description||If the declarative debugger is started on a trusted node, all of whose children are trusted too, then it will start searching up the call tree. This is because it is assuming the node must be inadmissible (the node cannot be erroneous, because it is trusted, also it cannot be correct, because then why would the user have started the declarative debugger at that node in the first place?)|
This behaviour can seem unintuitive.
There is an example of this behaviour in the following test:
Zoltan and I discussed the issue and agreed that the fix was to allow the user to assert whether the node was erroneous or inadmissible when they enter the dd command.
I now think a better solution is simply for the declarative debugger to say that it is searching up the call tree, because the node is trusted, so it is assuming it is inadmissible. A message like:
The call to io.read/3 and all its descendents are trusted, searching up the
call tree for an untrusted node..
This way you get the behaviour you want if you start the dd at a call to error and if you accidentally start it at a trusted node, you know immediately that the node is trusted, so you can then type "quit", untrust the predicate, and start again.
Zoltan, how does this sound to you?
|Tags||No tags attached.|
Last edited: 2007-10-19 09:32
See bug description.
|This tricked me yesterday. I agree with the proposed solution of informing the user that the node is trusted and that the debugger will begin to search up the call tree.|
|See r1.77 of browser/declarative_debugger.m.|
||Status||new => assigned|
||Assigned To||=> maclarty|
||Note Added: 0000035|
||Assigned To||maclarty => zs|
||Status||assigned => feedback|
||Note Edited: 0000035|
|2008-08-12 11:42||pbone||Note Added: 0000126|
|2010-01-29 17:04||juliensf||Assigned To||zs => maclarty|
|2010-01-29 17:04||juliensf||Status||feedback => assigned|
||Status||assigned => resolved|
||Resolution||open => fixed|
||Status||resolved => closed|
||Status||closed => feedback|
||Resolution||fixed => reopened|
||Note Added: 0000251|
||Status||feedback => resolved|
||Resolution||reopened => fixed|