2024-04-20 00:11 AEST
  

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000020mercuryBugpublic2007-10-19 09:302010-02-05 15:43
Reportermaclarty 
Assigned Tomaclarty 
PrioritynormalSeverityminorReproducibilityalways
StatusresolvedResolutionfixed 
Product Version 
Target VersionFixed in Version 
Summary0000020: declarative debugger going up search tree when initial node trusted.
DescriptionIf 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:
tests/debugger/declarative/io_read_bug

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?
TagsNo tags attached.
Attached Files

-Relationships
+Relationships

-Notes

~0000035

maclarty (developer)

2007-10-19 09:32

Last edited: 2007-10-19 09:32

 See bug description.

~0000126

pbone (administrator)

2008-08-12 11:42

 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.

~0000251

maclarty (developer)

2010-02-05 15:43

 See r1.77 of browser/declarative_debugger.m.
+Notes

-Issue History
Date Modified Username Field Change
2007-10-19 09:30 maclarty New Issue
2007-10-19 09:31 maclarty Status new => assigned
2007-10-19 09:31 maclarty Assigned To => maclarty
2007-10-19 09:32 maclarty Note Added: 0000035
2007-10-19 09:32 maclarty Assigned To maclarty => zs
2007-10-19 09:32 maclarty Status assigned => feedback
2007-10-19 09:32 maclarty 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
2010-02-05 15:37 maclarty Status assigned => resolved
2010-02-05 15:37 maclarty Resolution open => fixed
2010-02-05 15:40 maclarty Status resolved => closed
2010-02-05 15:42 maclarty Status closed => feedback
2010-02-05 15:42 maclarty Resolution fixed => reopened
2010-02-05 15:43 maclarty Note Added: 0000251
2010-02-05 15:43 maclarty Status feedback => resolved
2010-02-05 15:43 maclarty Resolution reopened => fixed
+Issue History