Sorry, I've only just got round to dealing with this.
Thanks for your comments on the debugger. I don't think it's had the same degree of use as other parts of Poly/ML so I'm not surprised there are issues. I'm planning to look at the debugger shortly so I'll bear these in mind. If you find any more problems let me know.
Regards, David On 23/02/2015 18:08, Brian Campbell wrote:
Hi, I've encountered a few bugs when using the debugger, and I've managed to distill them down into a useful form. The first is that the compiler is too keen to avoid multiple calls to the debugger in one line. For example, if I debug the function below, 1 fun f n = 2 let val l = [1,2,3,4] 3 val x = map (fn y => y+n) l 4 in x 5 end then stepOver() will skip line 3, because the compiler places the only call to the debugger inside the anonymous function. I've been working around this by adding an extra newline after map. The second is that when support was added to stop execution when an exception is raised, it used the same code as when an exception exits a function, and pops an extra entry off the debug stack. The stepOver and stepOut functions get very confused as a result. I've hacked my copy to check whether the name ends in -raise before popping the stack, but there's probably a more elegant solution. Finally, the tracing doesn't seem to like datatypes declared inside structures: structure S = struct datatype t = A of int fun f (x:t) = x; end; > PolyML.Debug.trace true; val it = (): unit > S.f (S.A 5); S.f Exception- Subscript raised I can examine the value of x in the debugger, though, but my attempts to make the way tracing prints values more like the debugger toplevel haven't been successful. Best regards, Brian _______________________________________________ polyml mailing list [email protected] http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
_______________________________________________ polyml mailing list [email protected] http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
