Actually, I’ve come to suspect that if you’re sufficiently devious it may not quite be true. I haven’t tested so I can’t promise this will work, but here’s a sketch of how I’ve imagined implementing breakpoints. For a “method” with 2 interior breakpoints, Rebugger would put code on your command-line that looks something like this (if you’ve not looked, the docs might help explain some of this):
rebug> @eval SomeModule let (vars..., label_at_exit) = getstored(uuid) begin
@goto $(label_at_exit)
# somecode
setstored!(uuid, varnames, varvals, :label1)
throw(StopException())
@label label1
# code just after the first breakpoint
setstored!(uuid, varnames, varvals, :label2)
throw(StopException())
@label label2
# code just after the second breakpoint
end
So if you enter this at the top, it will store program state just above label1
and then exit. (The StopException
would be caught by Rebugger…or maybe that should just be a return nothing
? Not sure.) Because it stored the label at which it exited, and loads from that storage at the top, if you just re-run this same command it will begin at label1
and continue on to label2
.
I’m sure this will need some modification, but this is the general gist.