| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
| |
It actually has nothing to do with macros. I just wasn't supporting backquotes
outside macros before.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Since we switched error trace semantics from a designated label to a designated
depth (commit 9831a8cef9 on May 19).
|
| | |
|
| |
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Identical bug to commit 2f10bc7302.
|
| | |
|
| |
|
|
|
|
| |
So far we were only doing so for the first few lines, just enough to render
one page's worth of lines. We'd have probably noticed if we collapsed some
lines after re-evaluating.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
I've been stymied for a week wondering how to reliably compute trace-line
identity. A trace can have multiple identical lines. Only some of them
may be visible at any point. How to remember which is which across re-evaluations?
There's no easy answer. I'm just going to keep things ad hoc. When you
re-evaluate, new lines can currently pop into visibility. However we guarantee
that just moving around the trace will be stable, thanks to the visible
bit being cached within each trace-line. Scrolling will be similar. Reevaluating
may cause the trace to be perturbed up or down. However, just scrolling
around will work reliably.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Minor counter infrastructure. We invoke next-token 1400 times while loading
the shell's data disk, so we're wasting around 1.4MB during tokenization.
|
| |
|
|
| |
slightly improve colors
|
| | |
|
| | |
|
| |
|
|
|
| |
We're soon going to be dynamically rerunning the sandbox in other ways
when browsing the trace.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|