On 28/09/2007, at 7:55 AM, Kish Shen wrote: > Hi Malcolm, > > I don't think there is any easy way to debug constraints. The > delayed goals that implements the propagation of the constraints do > not necessarily map easily to the constraints. You can trace the > execution of these delayed goals using the tracer, and sometimes > you may be able to tell what the `source' constraint for it was. If I was writing the system again from scratch, I'd tag each delayed goal with the details of the place in the code where it was initially suspended. This could then be used in a debugger as a replacement for the calling stack (which is clearly not very helpful). That way you could see not only the fine-grained constraints, but also where they originated from, rather than having to guess. Going further, you could even use this information to place breakpoints on certain constraints, by anotating the line where they were delayed (rather than the code of the constraint itself, which may be called in many places). The breakpoint could identify the particular goal created, and then interrupt when that goal is executed. Basically, imagine that there were no delays and that goals executed in standard top-to-bottom order. What would the calling stack be at each point in time? Delayed goals allow us to shuffle the order of execution, but we should still be able to reconstruct that same calling stack, which would provide much more useful debugging information. Malcolm -- "Cleanliness is not next to godliness nowadays, for cleanliness is made an essential and godliness is regarded as an offence. - G.K.Chesterton, On Lying in BedReceived on Tue Oct 02 2007 - 01:18:16 CEST
This archive was generated by hypermail 2.3.0 : Wed Sep 25 2024 - 15:13:20 CEST