| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Support newlines. Looks like we pasted the input from the browser window
during the pairing session.
|
| |
|
|
|
| |
https://adventofcode.com/2017/day/1
https://archive.org/details/2021-06-02-akkartik-sumeet
|
| | |
|
| |
|
|
| |
This is an old 'optimization' that turns out to not actually matter.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
| |
I should really stop using /disp8 jumps at the top-level given how inconvenient
it is to check for overly large offsets.
|
| | |
|
| |
|
|
| |
This should have gotten cleaned up during commit e0f6dd5240 (Mar 23).
|
| |
|
|
|
| |
These helpers don't actually help render to buffers with geometries different
from video RAM.
|
| | |
|
| |
|
|
|
| |
Roll back to commit 70919b45f0. Recent commits add lots of extra function
args for dubious benefit.
|
| |
|
|
| |
Looks like what's slowing down screen rendering is in fact _font_ rendering.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Two interesting things:
- We don't really need double-buffering for rendering the screen on the
sandbox as a progress indicator. Everything else is untouched, and render-screen
should be doing that as well.
- Rendering just pixels of the fake screen is buttery smooth. It's the
_graphemes_ that are slowing things down. Even though there's so many
fewer of them!
As a result, drawing the fake screen less frequently in `evaluate` doesn't
actually help with flicker. Even though it'll make the debug cycle shorter.
So my current plan is to attack flicker in isolation before I mess with
the render frequency.
In this commit I optimized away the cursor handling. Still doesn't seem
to be helping. In fact it actually seems _worse_.
|
| | |
|
| |
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Needed because we don't yet have a primitive in the shell to truncate/round
non-integers to integers.
Before:
(nth (/ 31 10) # we don't have float literals yet
'(1 2 3 4))
=> NULL
..with an unpleasant abort likely later on.
Really the correct thing to do is ensure none of my primitives ever returns
NULL. Start with car/cdr.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
After all that, I'm not sure this is the desired behavior. If a function
defines multiple bindings, we shouldn't rename all their keys. So how to
choose?
Perhaps it's not so bad to have "symlinks" in this "file system". To unlink
two bindings you now need to define one of them in the sandbox.
All the refactoring is still useful, though.
|
| |
|
|
| |
I'm ready again to take on commit 6169ec59c after lots of refactoring.
|
| |
|
|
|
|
|
|
| |
Save a single trace to potentially multiple globals just like a gap buffer
(if say we have a single let binding defining multiple functions).
I don't have a strong use for this yet, but it seems cleaner. Maybe it's
redundant or wrong.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|