3 Using the Cecil Debugger
trace prints a line for every dynamically-dispatched message sent, and step continues execution until the next message is sent. Since messages are sent very frequently, these operations are of limited utility. It would be nice to support flavors of step that continue execution until a send returns (analogous to next in gdb), perhaps with variations that reenable stepping when a nested closure is invoked (to support stepping into a control structure's closure argument).
There is no way to set a breakpoint at a particular line of a Cecil program. To do this, edit the method directly to include a breakpoint() call at the desired place, and either recompile and rerun (slow) or install the edited method directly using the evaluator (see below) (fast, but doesn't always work in the presence of optimization). One defect of debugging runtime extension methods is that the stack frames displayed are those of the Cecil interpreter, not the interpreted method. The stack frame for runtime_extension_method signals the place where the interpreted method was first invoked, and send where the method made a call; these two frames bracket the execution of the interpreted method. To see the local and formal variables of the interpreted method, browse the env variable of the interpreter stack frames. Alternatively, go to an interpreter stack frame with an env local variable, enter eval to go to the Eval> prompt, and then type adopt_env. This makes all the local variables in env accessible directly.