about summary refs log tree commit diff stats
path: root/shell
Commit message (Collapse)AuthorAgeFilesLines
* load large definitionsKartik K. Agaram2021-04-291-1/+1
|
* adjust some colors and paddingKartik K. Agaram2021-04-295-85/+102
|
* bugfix: initialize gap buffers before using themKartik K. Agaram2021-04-282-2/+5
| | | | | | | 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.
* fix renderingKartik K. Agaram2021-04-281-1/+1
|
* shell: load/store from/to disk with indentKartik K. Agaram2021-04-282-25/+82
| | | | | Once I came up with the right approach, this worked on the first try once I got the types and registers to line up!
* .Kartik K. Agaram2021-04-281-3/+1
|
* shell: bugfix for stream literalsKartik K. Agaram2021-04-281-2/+33
| | | | | I was forgetting that callers sometimes reuse outputs between successive tokens.
* start rendering definitions with indentationKartik K. Agaram2021-04-281-12/+6
|
* start stashing and clearing sandbox after definitionsKartik K. Agaram2021-04-283-9/+80
|
* .Kartik K. Agaram2021-04-281-1/+1
|
* .Kartik K. Agaram2021-04-282-36/+20
|
* shell: stream literalsKartik K. Agaram2021-04-274-3/+47
|
* .Kartik K. Agaram2021-04-271-17/+17
|
* .Kartik K. Agaram2021-04-271-73/+18
|
* shell: tokenizing stream (string) literalsKartik K. Agaram2021-04-271-1/+78
| | | | We're calling them streams since they support appending.
* .Kartik K. Agaram2021-04-271-8/+1
|
* .Kartik Agaram2021-04-261-5/+5
|
* bresenham circlesKartik K. Agaram2021-04-251-1/+22
| | | | Known issue: circles of radius 9 crash. (Multiples of 9 overflow the trace.)
* bug in bresenham linesKartik K. Agaram2021-04-251-2/+2
|
* 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
|
* 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-252-6/+10
| | | | | | | | 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.
* .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
|
* 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-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-212-7/+182
| | | | | '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
|
generated by cgit-pink 1.4.1-2-gfad0 (git 2.36.2.497.gbbea4dcf42) at 2024-12-22 20:22:54 +0000