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
_______________________________________________
polyml mailing list
[email protected]
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
