| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
| |
Keyboard state machine for jumping to function definition.
|
| |
|
|
| |
Menu shortcut for jumping to function definition.
|
| | |
|
| |
|
|
| |
Keep hotkeys stable when different elements are in focus.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Drop some low-entropy trace lines.
|
| | |
|
| | |
|
| |
|
|
| |
State as of https://archive.org/details/akkartik-mu-2021-05-31
|
| |
|
|
|
| |
Until we get scrolling on functions, it's a little cleaner to draw the
primitives on top.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
It turns out the problem was that `and` wasn't cleaning up after itself
when it short-circuited evaluation. Similar problems in a couple more places.
|
| | |
|
| |
|
|
|
|
|
|
| |
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.
|
| | |
|