Re: BREAKing into Euphoria
Andy Drummond wrote:
>
> Ah, but I have this enormous program and somewhere, somehow,
> it is locking up in a loop. If I went around putting in
> timeouts & traces I'd take longer than modifying the source
> for the interpreter and recompiling it and using a ctl-C or
> whatever. No, what I *need* is a way of getting the
> interpreter to enter its trace routine from keyboard use
> and not from trace().
I got some "interesting" results (random crashes mainly) from this, however
enough of it works to show that something is possible (comments, Rob?):
Maybe there is a generic problem with trace in call_back routines??
-- NOTE: this is probably incompatible with allow_break/check_break().
with trace
include misc.e
constant CTRL_C_EVENT = 0,
CTRL_BREAK_EVENT = 1
function HandlerRoutine(integer event)
if event = CTRL_C_EVENT
or event = CTRL_BREAK_EVENT then
trace(1)
sleep(2)
return 1 -- handled
end if
return 0 -- not handled
end function
atom kernel32, xSetConsoleCtrlHandler, cbHR
include dll.e
kernel32 = open_dll("kernel32.dll")
xSetConsoleCtrlHandler = define_c_func(kernel32,"SetConsoleCtrlHandler",
{C_POINTER, -- PHANDLER_ROUTINE pHandlerRoutine, // address of handler
function
C_INT}, -- BOOL fAdd // handler to add or remove
C_INT) -- BOOL
cbHR = call_back(routine_id("HandlerRoutine"))
if not c_func(xSetConsoleCtrlHandler,{cbHR,1}) then ?9/0 end if
with trace
while 1 do
puts(1,"sleeping\n")
sleep(2)
puts(1,"awake\n")
end while
I suspect that if you could somehow call the trace(1) in HandlerRoutine but not
then trace any lines in that code, it might actually work.
When not interpreting source, or under an allow_break(False), then Ctrl Break
should not attempt to fire up the trace window, otherwise it should.
I don't think changing Ctrl C is a good idea, too easy to accidentally hit,
plus eg Edita happily uses it for Copy w/out problems as is.
Regards,
Pete
|
Not Categorized, Please Help
|
|