| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
|
|
| |
Refreshing the fake screen is still a heavyweight operation. Double-buffering
makes it less obvious but doesn't actually reduce the amount of work. We
need to ensure that we do enough work between refreshes to make them economic.
|
|
|
|
|
| |
Before I only separately counted calls at each stack depth. I don't remember
if that seemed good enough or was just an oversight.
|
|
|
|
|
|
|
|
| |
Font rendering now happens off the real screen, which provides the effect
of double-buffering.
Apps can now also use convert-graphemes-to-pixels for more traditional
double-buffering.
|
|
|
|
|
| |
Roll back to commit 70919b45f0. Recent commits add lots of extra function
args for dubious benefit.
|
| |
|
|
|
|
|
|
| |
Rename cells containing screens to screen vars because of the ambiguity
that each grapheme in fake screens is represented by a type screen-cell.
While we're at it, we also analogously rename keyboard vars.
|
| |
|
|
|
|
| |
Add argument to a few functions.
|
| |
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
Drop some low-entropy trace lines.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
We now use traces everywhere for error-checking. Null traces introduce
the possibility of changing a functions error response, and therefore its
semantics.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
We really need to systematically check our trace streams.
|
|
|
|
|
| |
We still benefit from some helpers here because of the unrolling and multiple
calls to helpers.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
| |
|
| |
|
| |
|
| |
|