about summary refs log tree commit diff stats
Commit message (Collapse)AuthorAgeFilesLines
* shell: primitives 'and' and 'or'Kartik K. Agaram2021-04-252-11/+87
|
* shell: primitive 'not'Kartik K. Agaram2021-04-251-4/+45
|
* failing tests not printing since show-stack-stateKartik K. Agaram2021-04-251-1/+10
|
* .Kartik K. Agaram2021-04-252-4/+4
|
* .Kartik K. Agaram2021-04-251-56/+56
|
* .Kartik K. Agaram2021-04-252-1/+1
|
* .Kartik K. Agaram2021-04-251-94/+0
|
* expand stack to 16MBKartik K. Agaram2021-04-253-6/+6
| | | | It's also no longer contiguous with code.
* shell: tab inserts two spacesKartik K. Agaram2021-04-251-0/+8
|
* shell: use ctrl-m rather than tab to bounce to traceKartik K. Agaram2021-04-252-10/+10
| | | | We'll save tab for inserting graphemes.
* .Kartik K. Agaram2021-04-251-1/+2
| | | | Show all builtins now that we have more space.
* devote 2/3rds of screen to definitionsKartik K. Agaram2021-04-252-3/+3
|
* add some padding to the sandboxKartik K. Agaram2021-04-252-2/+2
|
* a troubleshooting noteKartik K. Agaram2021-04-251-0/+11
|
* .Kartik K. Agaram2021-04-251-2/+0
|
* expand memory to 2GBKartik K. Agaram2021-04-253-7/+11
| | | | | | | | It requires more than 1GB to fill the screen with a chessboard pattern using the definition in shell/iterative-definitions.limg. I also speed up the chessboard program by clearing the screen up front and then only rendering the white pixels.
* expand heap to Qemu defaultKartik Agaram2021-04-252-3/+3
|
* .Kartik Agaram2021-04-242-257/+0
| | | | Get rid of my experiment adding Game of Life to the shell.
* bugfix; thanks Max BernsteinKartik Agaram2021-04-241-1/+1
|
* .Kartik Agaram2021-04-231-2/+16
|
* shell: some example definitionsKartik Agaram2021-04-233-0/+180
|
* .Kartik Agaram2021-04-2212-40737/+41324
|
* better error message on trace overflowKartik K. Agaram2021-04-221-1/+8
|
* faster emulationKartik K. Agaram2021-04-221-2/+2
| | | | Thanks Maxwell Bernstein for pointing this out 🤦‍♂️
* clean up with the final bugfixKartik K. Agaram2021-04-222-62/+9
|
* snapshotKartik K. Agaram2021-04-222-2/+62
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It took me _way_ too long to realize that I'm not checking for errors within the loop, and that will cause it to manifest as an infinite loop as inner evaluations fail to run. Debugging notes, for posterity: printing one row of a chessboard pattern over fake screen (chessboard screen 4 0 0 15) gets stuck in an infinite loop halfway through debug pattern during infinite loop: VWEX. It's still in the loop but it's not executing the body raw (fill_rect screen 16 0 20 4 15) works fine same number of calls to fill_rect work fine replacing calls to fill_rect with pixel inside chessboard2 works fine at the point of the infinite loop it's repeatedly going through the hline loop -- BUT it never executes the check of the loop (< lo hi) with lo=20, hi=20. Something is returning 1, but it's not inside < stream optimization is not implicated simple test case with a single loop ( (globals . ( (foo . (fn () (screen i n) (while (< i n) (pixel screen 4 4 i) (pixel screen 5 4 i) (pixel screen 6 4 i) (pixel screen 7 4 i) (set i (+ i 1))))) )) (sandbox . (foo screen 0 100)) ) simpler (if you reset cursor position before every print): ( (globals . ( (foo . (fn () (screen i n) (while (< i n) (print screen i) (set i (+ i 1))))) )) (sandbox . (foo screen 0 210)) ) I now believe it has nothing to do with the check. The check always works. Sometimes no body is evaluated. And so the set has no effect.
* .Kartik K. Agaram2021-04-222-0/+39
|
* .Kartik K. Agaram2021-04-221-0/+13
|
* .Kartik K. Agaram2021-04-221-2/+9
|
* shell: non-recursive 'while'Kartik K. Agaram2021-04-211-14/+58
|
* shell: refuse to 'def' duplicate namesKartik K. Agaram2021-04-212-2/+46
|
* shell: separate 'def' from 'set'Kartik K. Agaram2021-04-214-7/+272
| | | | | 'def' creates new bindings (only in globals) 'set' only modifies existing bindings (either in env or globals)
* slightly more responsive animationKartik K. Agaram2021-04-211-1/+1
|
* clear old output when new run is in progressKartik K. Agaram2021-04-212-69/+94
| | | | I'm currently doing this extremely naively/slowly/uglily. Not a bottleneck.
* .Kartik K. Agaram2021-04-212-14/+14
|
* .Kartik K. Agaram2021-04-211-1/+1
|
* .Kartik K. Agaram2021-04-212-67/+67
|
* opt: don't clear streams of bytes on the stackKartik K. Agaram2021-04-212-3/+152
| | | | | | | | | | | | All over the Mu code I reflexively initialize all variables just to keep unsafe SubX easy to debug. However I don't really need to do this for safe Mu code, since the type- and memory-safety already ensures we can't read from streams beyond what we've written to them. For now I'll continue mostly with the same approach, but with one exception for streams of bytes. Mu programs often emit traces, and in doing so they often use temporary streams of bytes that can get quite long. I'm hoping avoiding initializing KBs of data all over the place will measurably speed up the Mu shell.
* .Kartik Agaram2021-04-21243-45738/+47168
|
* shell: show screen state during evaluationKartik K. Agaram2021-04-213-17/+41
| | | | | | | | | | | | | | 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.
* .Kartik K. Agaram2021-04-211-0/+11
|
* an interface approximating stack tracesKartik K. Agaram2021-04-206-27/+51
|
* get bresenham line drawing working with a traceKartik K. Agaram2021-04-202-11/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (brline . (fn () (screen x0 y0 x1 y1 color) ((fn (dx dy sx sy) ((fn (err) (brline1 screen x0 y0 x1 y1 dx dy sx sy err color)) (+ dx dy))) (abs (- x1 x0)) (- 0 (abs (- y1 y0))) (sgn (- x1 x0)) (sgn (- y1 y0))))) (brline1 . (fn () (screen x y xmax ymax dx dy sx sy err color) (pixel screen x y color) (if (andf (= x xmax) (= y ymax)) () ((fn (e2) (brline1 screen (if (>= e2 dy) (+ x sx) x) (if (<= e2 dx) (+ y sy) y) xmax ymax dx dy sx sy (+ err (+ (if (>= e2 dy) dy 0) (if (<= e2 dx) dx 0))) color)) (* err 2))))) sandbox: (brline screen 1 1 5 5 12) There are two ideas stemming from this commit: - I need an extremely compact on-screen trace to underlie the trace UX - perhaps we should start truncating trace lines
* deemphasize fn arg evaluation slightlyKartik K. Agaram2021-04-191-0/+2
|
* reimplement pixel graphicsKartik K. Agaram2021-04-192-74/+147
| | | | | | | | | | | 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.
* .Kartik K. Agaram2021-04-191-33/+33
|
* .Kartik K. Agaram2021-04-191-1/+2
|
* add some checksKartik K. Agaram2021-04-191-2/+18
| | | | | | | Even if they duplicate lower-level ones, we have an opportunity for better error messages. Any time I see a hard-to-debug error message, I should be asking myself, "what higher-level primitive should catch and improve this error?"
* start cleaning up pixel graphicsKartik K. Agaram2021-04-197-54/+54
| | | | | | 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.
* re-enable testsKartik K. Agaram2021-04-181-13/+13
| | | | Disabled in commit 1354161a3, and then I forgot about them for a while.