It turns out I have a problem with trace depth somewhere which I just wasn't
noticing before. Running certain sandboxes (line; maybe loops?) twice was
causing traces to no longer start at depth 1, which implies that they weren't
terminating at depth 1. This became a lot more obvious since I instituted
a max-depth.
This was quite difficult to diagnose. The issue I noticed was that brline
had stopped working. All the bugs in previous commits were hiding the cause.
Once I cleaned them up, I realized the problem was that the `(,x0 ,y0)
was triggering the nested-backquote check. The fix was fairly straightforward
then (even though I didn't yet understand why). But how to write a test
for this? I spent some time trying to do so without defining a macro using
literal macros, before I realized:
You can't call literal macros; we don't have first-class macros.
Trying to insert literal macro support just breaks everything because we
have no way to distinguish between a literal macro call and the stage in
macroexpand where a symbol has been replaced with its macro definition.
How do you explain stuff like this? I grow weary of Lisp.
There's still some issue in loading the entire definition of brline from
data.limg.
Now that we never have a null trace, tracing errors is always safe. And
now that we're running with low trace max-depth we're more likely to run
into problems with missing errors in the trace.
I was aware of some complications. The various indexes and y coordinates
in the trace's cache would be unstable and need to be recomputed. But it's
surprising that the trace _completely disappears_.
The goal: the sandbox initially maintains a shallow trace. As you expand
into the trace, the environment reruns the sandbox at greater depth as
needed.
The challenge: expanding happens within edit-trace, which doesn't have
the whole sandbox needed to re-run the sandbox. We'll either need to expand
the trace's capabilities to include the whole sandbox, or duplicate some
logic to decide when to run the sandbox.
Kartik K. Agaram