about summary refs log tree commit diff stats
path: root/shell/evaluate.mu
Commit message (Collapse)AuthorAgeFilesLines
* .Kartik K. Agaram2021-06-081-7/+3
| | | | | | | I wrote a comment about how some code was not covered by tests, and then promptly forgot what it was for. This is why we need tests. Now the hack is gone.
* clean up a large memory leakKartik K. Agaram2021-06-051-15/+6
| | | | | | | | | | | It turns out (bowboard screen 128) on a real screen massively slowed down and ran out of memory since commit e2ab1b30b1 on May 19. The culprit was these changes, which created memory allocations for a new trace on every recursive call. I originally had some vague desire to isolate these calls from the user-visible trace. That's expensive enough that I'll wait until it becomes a concern before trying to isolate again.
* rename the definition primitive to 'def'Kartik K. Agaram2021-06-041-7/+7
|
* .Kartik K. Agaram2021-06-031-2/+15
| | | | Drop some low-entropy trace lines.
* interrupt repl on keypressKartik K. Agaram2021-05-311-1/+7
|
* .Kartik K. Agaram2021-05-311-8/+8
|
* .Kartik K. Agaram2021-05-311-0/+2
|
* 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.
* bugfix: unbound variables were not raising errorKartik K. Agaram2021-05-301-1/+1
| | | | | Since we switched error trace semantics from a designated label to a designated depth (commit 9831a8cef9 on May 19).
* 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-191-3/+0
|
* disallow null tracesKartik K. Agaram2021-05-191-69/+171
| | | | | | We now use traces everywhere for error-checking. Null traces introduce the possibility of changing a functions error response, and therefore its semantics.
* shell: traces track a maximum depth to recordKartik K. Agaram2021-05-191-2/+2
|
* shell: clean up trace for macroexpandKartik K. Agaram2021-05-181-0/+4
|
* shell: add a lot of error-checkingKartik K. Agaram2021-05-181-0/+145
|
* a full-circle rainbowKartik K. Agaram2021-05-081-1/+1
|
* all apps working again after null get checkKartik K. Agaram2021-05-071-2/+33
|
* .Kartik K. Agaram2021-05-071-35/+35
|
* an often-overflowing stream when running brcircleKartik K. Agaram2021-05-071-1/+1
| | | | We really need to systematically check our trace streams.
* clean up chessboardKartik K. Agaram2021-05-071-1/+3
| | | | | We still benefit from some helpers here because of the unrolling and multiple calls to helpers.
* starting to implement first macrosKartik K. Agaram2021-05-071-0/+9
| | | | | | | | | | | | | | | 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
* literal macrosKartik K. Agaram2021-05-061-0/+28
| | | | | | | | | | | Current plan: - some way to define macros. For now: (def f (litmac litfn () (a b) `(+ ,a , b))) - macroexpand will expand calls by passing them through the cdr (f 3 4) macroexpand: ((litfn () (a b) `(+ ,a ,b)) 3 4) => (+ 3 4) eval: (+ 3 4) => 7
* .Kartik K. Agaram2021-05-061-2/+15
|
* .Kartik K. Agaram2021-05-061-4/+21
|
* .Kartik K. Agaram2021-05-041-0/+40
|
* .Kartik K. Agaram2021-05-041-3/+8
|
* .Kartik K. Agaram2021-05-041-1/+1
|
* shell: unquote spliceKartik K. Agaram2021-05-041-0/+120
|
* shell: unquoteKartik K. Agaram2021-05-041-2/+78
|
* shell: start evaluating backquoteKartik K. Agaram2021-05-031-0/+146
|
* .Kartik K. Agaram2021-05-031-63/+63
|
* .Kartik K. Agaram2021-05-031-0/+21
|
* .Kartik K. Agaram2021-05-031-1/+1
|
* move color scheme closer to Solarized darkKartik K. Agaram2021-05-011-35/+35
| | | | | | | | | | | | | sed -i 's,0x12/bg=almost-black,0xdc/bg=green-bg,g' shell/*.mu sed -i 's, 0/bg, 0xc5/bg=blue-bg,g' shell/*.mu sed -i 's, 7/fg=trace, 0x38/fg=trace,g' shell/*.mu sed -i 's, 7/bg=grey, 0x5c/bg=black,g' shell/*.mu Still a few issues. Thanks Adrian Cochrane and Zach DeCook. https://floss.social/@alcinnz/106152068473019933 https://social.librem.one/@zachdecook/106159988837603417
* shell: allow 'def' to overwriteKartik K. Agaram2021-04-291-1/+1
|
* keep the temporary progress screen off the keyboardKartik K. Agaram2021-04-291-1/+1
|
* .Kartik K. Agaram2021-04-281-1/+1
|
* .Kartik K. Agaram2021-04-281-36/+6
|
* shell: stream literalsKartik K. Agaram2021-04-271-0/+9
|
* shell: primitives 'and' and 'or'Kartik K. Agaram2021-04-251-0/+86
|
* failing tests not printing since show-stack-stateKartik K. Agaram2021-04-251-1/+10
|
* .Kartik K. Agaram2021-04-251-2/+2
|
* clean up with the final bugfixKartik K. Agaram2021-04-221-61/+9
|
* snapshotKartik K. Agaram2021-04-221-2/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* shell: non-recursive 'while'Kartik K. Agaram2021-04-211-14/+58
|
* shell: refuse to 'def' duplicate namesKartik K. Agaram2021-04-211-1/+1
|
* shell: separate 'def' from 'set'Kartik K. Agaram2021-04-211-7/+157
| | | | | '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
|
* shell: show screen state during evaluationKartik K. Agaram2021-04-211-15/+39
| | | | | | | | | | | | | | 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.
* an interface approximating stack tracesKartik K. Agaram2021-04-201-24/+23
|
generated by cgit-pink 1.4.1-2-gfad0 (git 2.36.2.497.gbbea4dcf42) at 2024-12-04 22:40:04 +0000