OpenEuphoria

Re: trace in eu 2.0 and eu 2.1

• Posted by Ralf Nieuwenhuijsen <nieuwen at XS4ALL.NL> Apr 07, 1999
• 582 views

-----
> Sadly, that never was an option.  While we're on the topic, though, what
> does everybody else think about adding features like breakpoints, variable
> tracepoints, and being able to move the instruction pointer around (i.e.
> making trace a full-fledged debugger)?

The first two are already support code-wise.
You could do things like this:

if x < 0 or x > max_integer then
    trace (1) -- conditional breakpoint
end if

The above looks like an extremely powerful conditional breakpoint system.
You could just put trace (1) in front of the statement that needs to 'break' as
well as check for certain variable values, or
whatever complex condition you need to check for. However, about moving the
instruction-pointer, I don't see that as an option.
(it would be too messy)

What I would like in the debugger.
1)- jump clauses control, pressing 'tab' makes it go to the next statement
    and if its a jump clause (if, while, call_func,
call_proc) it lets you choose which way to go.
2)-- being able to immediate execute a statement. (default output of ? goes
    to file-handle 2, the error-device, which comes
into the trace-console, and is stored into ex.err, rather then ending up on the
screen. (trace mode or not)
3)-- down and enter move to the next jump-clause statement, rather than
    jumping over all statements.
    4)-- shift-down/enter moves to the next statement
    5)-- space skips the current statement.
6)-- right makes it step to the next evaluation. (so you can see the
    arguments getting formed.
7)-- output by the program, going to file handle 2 ends up in the trace
    console as well as in ex.err
8)-- in trace mode, at the end the program will not just stop, but be
    officially 'halted' .. we should still be able to
execute an immediate statement, or check some variables, etc. Or output some
data (or thoughts: puts (2, "My thought") etc.

This would greatly improve tracing.
Point 1 would be the most difficult to implement, however point 2, 3, 4, 5, 7
and 8 would be fairly easy to implement.

Robert, tell us, which of these suggestions are 'do-able' in the way the
interpreter currently works, and which improvement, do
you plan to add ?

Ralf N.