about summary refs log tree commit diff stats
Commit message (Collapse)AuthorAgeFilesLines
* .Kartik K. Agaram2021-06-031-5/+5
|
* .Kartik K. Agaram2021-06-032-17/+14
|
* .Kartik K. Agaram2021-06-031-2/+2
|
* .Kartik K. Agaram2021-06-031-2/+15
| | | | Drop some low-entropy trace lines.
* shell: more stable trace when rerunningKartik K. Agaram2021-06-023-3/+252
|
* .Kartik K. Agaram2021-06-021-2/+2
|
* .Kartik Agaram2021-05-311-17/+19
| | | | State as of https://archive.org/details/akkartik-mu-2021-05-31
* .Kartik Agaram2021-05-311-3/+5
| | | | | Until we get scrolling on functions, it's a little cleaner to draw the primitives on top.
* interrupt repl on keypressKartik K. Agaram2021-05-311-1/+7
|
* .Kartik K. Agaram2021-05-311-8/+8
|
* .Kartik K. Agaram2021-05-314-34/+36
|
* .Kartik Agaram2021-05-3145-8126/+9504
|
* clean up trace depth in a few placesKartik K. Agaram2021-05-311-0/+3
| | | | | 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.
* .Kartik K. Agaram2021-05-311-0/+2
|
* bugfix for disappearing traceKartik K. Agaram2021-05-311-0/+2
| | | | | | | | 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.
* .Kartik K. Agaram2021-05-311-3/+3
|
* data.limg now loading properly againKartik K. Agaram2021-05-312-2/+8
|
* clearer testKartik K. Agaram2021-05-311-34/+3
| | | | | It actually has nothing to do with macros. I just wasn't supporting backquotes outside macros before.
* multi-macroexpanding backquote != nested backquoteKartik K. Agaram2021-05-311-1/+129
| | | | | | | | | | | | | | | | | | | | | 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.
* clean up a few things in macro testsKartik K. Agaram2021-05-311-57/+46
|
* .Kartik K. Agaram2021-05-301-0/+75
|
* shell: raise errors when loading code on bootKartik K. Agaram2021-05-302-16/+29
|
* bugfix: unbound variables were not raising errorKartik K. Agaram2021-05-306-8/+40
| | | | | Since we switched error trace semantics from a designated label to a designated depth (commit 9831a8cef9 on May 19).
* .Kartik K. Agaram2021-05-301-3/+3
|
* unconditionally trace errorsKartik K. Agaram2021-05-301-60/+0
| | | | | | 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.
* .Kartik K. Agaram2021-05-301-0/+5
|
* .Kartik K. Agaram2021-05-301-1/+1
|
* first test re-running sandbox with a deeper traceKartik K. Agaram2021-05-302-3/+75
|
* .Kartik K. Agaram2021-05-301-10/+10
|
* .Kartik K. Agaram2021-05-301-1/+47
|
* first attempt doesn't workKartik K. Agaram2021-05-302-0/+38
| | | | | | 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_.
* start progressively increasing trace depthKartik K. Agaram2021-05-301-24/+30
| | | | | | | | | | | 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. Agaram2021-05-291-4/+45
|
* .Kartik K. Agaram2021-05-291-82/+54
|
* shell: scrolling the traceKartik K. Agaram2021-05-292-4/+211
|
* fix a bug in loading code diskKartik K. Agaram2021-05-291-1/+1
| | | | Identical bug to commit 2f10bc7302.
* shell: skeleton for scrollingKartik K. Agaram2021-05-294-4/+44
|
* cache visibility for all lines in traceKartik K. Agaram2021-05-291-15/+35
| | | | | | 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.
* .Kartik K. Agaram2021-05-291-4/+5
|
* .Kartik K. Agaram2021-05-291-1/+1
|
* .Kartik K. Agaram2021-05-291-1/+1
|
* .Kartik K. Agaram2021-05-291-1/+1
|
* shell: start implementing scrolling in the traceKartik K. Agaram2021-05-291-0/+1
| | | | | | | | | | | | | 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.
* .Kartik K. Agaram2021-05-291-0/+2
|
* .Kartik K. Agaram2021-05-291-0/+1
|
* shell: non-stream tokens are now smallKartik K. Agaram2021-05-291-3/+11
|
* .Kartik K. Agaram2021-05-291-6/+4
|
* .Kartik K. Agaram2021-05-291-9/+10
|
* .Kartik K. Agaram2021-05-291-4/+4
|
* .Kartik K. Agaram2021-05-291-2/+0
|