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.
We now use traces everywhere for error-checking. Null traces introduce
the possibility of changing a functions error response, and therefore its
semantics.
Another commit, another bugfix.
Some snippets from my currently exploding todo list:
- always investigate lookup errors immediately. Beyond the root cause, they should never happen at the moment, while we aren't reclaiming memory.
we should always return a more precise error message. Usually involving null pointer checks.
- on abort, print out stack trace
- emit mapping of labels to addresses during survey
- store a mapping of symbols somewhere in the code image
- stop allocating 1KB per token; expand space for tokens as needed
I don't understand why a second line in the keyboard is visible now where
it wasn't before. That whole aspect has unclear desires. What exactly do
I want to happen on newlines?
I keep running into one hole in Mu's memory-safety since dropping the Linux
dependency: null pointers no longer error when dereferenced. Here the problem
manifests as aliasing: lots of gap buffers share the same exact data near
address 0, because it was never initialized.
All highly experimental. Current constraints:
* No tail recursion elimination
* No heap reuse
* Keep implementation simple
So it's slow, and I don't want to complicate it to speed it up. So I'm
investing in affordances to help deal with the slowness. However, in the
process I've taken the clean abstraction of a trace ("all you need to do
is add to the trace") and bolted on call counts and debug-prints as independent
mechanisms.
Before: we always drew pixels atop characters, and we only drew pixels
that were explicitly requested.
After: we always draw pixels atop characters, and we only draw pixels that
don't have color 0.
Both semantics should be identical as long as pixels are never drawn atop
characters.
Filling pixels isn't a rare corner case. I'm going to switch to a dense
rather than sparse representation for pixels, but callers will have to
explicitly request the additional memory.
We now have a couple of protections:
- if we get close to running out of space in the trace we drop in an
error
- if we run out of space in the trace we stop trying to append
- if there are errors we cancel future evaluations
This is already much nicer. You can't do much on the Mu computer, but at
least it gracefully gives up and shows its limitations. On my computer
the Mu shell tries to run computations for about 20s before giving up.
That seems at the outer limit of what interactivity supports. If things
take too long, test smaller chunks.
Among other things, we turned off the trace to significantly speed up the
debug cycle.
State as of https://merveilles.town/@akkartik/106079258606146213
Ohhh, as I save the commit I notice a big problem: I've been editing the
disk image directly because writes to the Mu disk lose indentation. But
I've been forgetting that the state in the Mu disk needs to be pre-evaluated.
So function bindings need extra parens for the environment. The `pixel`
calls in the previous commit message are the first statement in the body,
and they aren't actually considered part of the body right now. No wonder
they don't run.
There are lots of other problems, but this will clarify a lot.
Kartik K. Agaram