On 27/09/2015 15:20, Phil Clayton wrote:
24/09/15 08:44, David Matthews wrote:
On 22/09/2015 19:00, Phil Clayton wrote: As a shameless plug for the newly updated debugger, I used that to set a breakpoint on the exception and then it was easy to see what was going on. The new debugger is a great deal faster than the old version so it's perfectly feasible to build the whole compiler with debugging enabled.
I tried the debugger many years ago but it couldn't cope with large examples. I seem to recall that compiling with PolyML.Compiler.debug set to true sometimes failed. I'll give it another go sometime.
I just had a quick look at the tutorial. How do you exit from the debug prompt? (Ctrl+C didn't work.)
I've just done some timings with the new debugger and the old one. Building the compiler with debugging enabled with the new version is roughly 8 times slower. With the old version it was approximately 100 times slower! Note that to get the advantage with the version in git it's necessary to run "make compiler".
At the moment to exit the debug prompt you need to continue the debuggee with "continue" or "continueWithEx". The latter is often the easiest way but it needs to be with an exception that isn't handled by the debuggee or by an exception break-point (breakEx exn).
I've wondered about whether there should be a way to simply discard the current debuggee completely. The only way I can see to do that would be to run every top-level expression as a new thread with the REPL waiting for that thread to complete. The top-level doesn't know when it starts running something that it contains debugging code.
One other point, when trying to cut examples down to the smallest case that demonstrates a bug, it's worth playing with PolyML.Compiler.maxInlineSize. It's often the case that a bug only shows up when an example is large enough that it isn't inlined so setting this to something small, e.g. 1, may allow more of the surrounding code to be pruned away.
That's useful to know. I checked the latest commit with maxInlineSize set to 1 and it still compiles.
I was hopeful that increasing maxInlineSize would provide a work-around for 5.5.2. It does, by setting maxInlineSize to 175, but at the expense of much longer compilation times - see the tables below. Also, the executable size of the example is much larger with 5.5.3. Is that expected?
There have been quite a few changes to the compiler that may increase the size of the executable and I'd have to look carefully to see exactly why it has affected that particular example.
David