about summary refs log tree commit diff stats
path: root/shell
Commit message (Collapse)AuthorAgeFilesLines
* shell: better screenshotKartik Agaram2021-06-151-1/+1
|
* always print black pixels when rendering screensKartik K. Agaram2021-06-151-2/+0
| | | | This is an old 'optimization' that turns out to not actually matter.
* shell: improve docsKartik Agaram2021-06-151-5/+14
|
* .Kartik Agaram2021-06-151-33/+34
|
* document responsiveness trade-offKartik K. Agaram2021-06-152-35/+28
|
* do more work per fake-screen refreshKartik K. Agaram2021-06-151-1/+1
| | | | | | 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.
* more precisely track count of calls to evalKartik K. Agaram2021-06-152-20/+13
| | | | | Before I only separately counted calls at each stack depth. I don't remember if that seemed good enough or was just an oversight.
* flickerlessly render fake screens in environmentKartik K. Agaram2021-06-152-34/+10
| | | | | | | | 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.
* periodic run of misc_checksKartik K. Agaram2021-06-121-2/+2
| | | | | I should really stop using /disp8 jumps at the top-level given how inconvenient it is to check for overly large offsets.
* .Kartik K. Agaram2021-06-127-178/+138
| | | | | Roll back to commit 70919b45f0. Recent commits add lots of extra function args for dubious benefit.
* snapshotKartik K. Agaram2021-06-121-12/+41
| | | | Looks like what's slowing down screen rendering is in fact _font_ rendering.
* .Kartik K. Agaram2021-06-121-16/+14
|
* trying to eliminate flicker when rendering screenKartik K. Agaram2021-06-121-13/+26
| | | | | | | | | | | | | | | | | | | 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_.
* eliminate some implicit writes to real screenKartik K. Agaram2021-06-127-120/+120
|
* .Kartik K. Agaram2021-06-125-66/+69
| | | | | | 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.
* shell: larger fake screenKartik K. Agaram2021-06-124-37/+41
|
* .Kartik Agaram2021-06-111-3/+3
|
* .Kartik K. Agaram2021-06-111-42/+1
|
* try to abolish NULL from primitivesKartik K. Agaram2021-06-111-77/+504
|
* car/cdr of nil is now nilKartik K. Agaram2021-06-111-2/+18
|
* hacky bugfix: support floats in nthKartik K. Agaram2021-06-111-1/+1
| | | | | | | | | | | | | | | 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.
* better nameKartik K. Agaram2021-06-111-2/+3
|
* cancel pending testKartik K. Agaram2021-06-111-64/+0
| | | | | | | | | | | 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.
* back to the pending testKartik K. Agaram2021-06-111-60/+4
| | | | I'm ready again to take on commit 6169ec59c after lots of refactoring.
* .Kartik K. Agaram2021-06-111-3/+25
| | | | | | | | 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.
* .Kartik K. Agaram2021-06-111-1/+0
|
* .Kartik K. Agaram2021-06-111-29/+9
|
* .Kartik K. Agaram2021-06-111-2/+2
|
* .Kartik K. Agaram2021-06-111-82/+6
|
* .Kartik K. Agaram2021-06-113-4/+4
|
* .Kartik K. Agaram2021-06-112-2/+2
|
* .Kartik K. Agaram2021-06-112-41/+41
|
* .Kartik K. Agaram2021-06-111-3/+3
|
* .Kartik K. Agaram2021-06-111-4/+0
|
* .Kartik K. Agaram2021-06-112-22/+25
|
* .Kartik K. Agaram2021-06-111-1/+0
|
* .Kartik K. Agaram2021-06-111-12/+11
|
* .Kartik K. Agaram2021-06-111-54/+50
| | | | | | Inline a function by patching a few variable names. I don't even have to worry about `return` statements if there's a single call and it's in tail position in the caller.
* .Kartik K. Agaram2021-06-111-11/+13
|
* start showing parse errors under definitionsKartik K. Agaram2021-06-111-2/+10
| | | | | | We don't have support for browsing them yet. Just errors for now, which should only be a line or two. Larger traces might be useful for inspecting results of macroexpansion.
* .Kartik K. Agaram2021-06-111-6/+6
|
* .Kartik K. Agaram2021-06-111-13/+34
|
* .Kartik K. Agaram2021-06-092-36/+36
|
* .Kartik K. Agaram2021-06-092-47/+32
|
* .Kartik K. Agaram2021-06-092-15/+19
|
* .Kartik K. Agaram2021-06-091-3/+4
|
* .Kartik K. Agaram2021-06-095-44/+52
| | | | Add argument to a few functions.
* .Kartik K. Agaram2021-06-092-3/+3
|
* make tests pass againKartik K. Agaram2021-06-092-1/+6
| | | | | I'm temporarily disabling the pending state. I'm also providing a clearer error message when we encounter the bug.
* snapshot: attempt at modifying a function nameKartik K. Agaram2021-06-092-11/+121
| | | | | | | | | | | | | | | | | | | | | | | | | | | | It turns out there's another problem, and it predates the ability to create new definitions: ctrl-s triggers a call to `evaluate`, which inserts a new definition into globals. which has a null gap buffer. All this happens long before the new code in this commit, resulting in a null gap buffer by the time we get to word-at-cursor. Which in turn happens because we perform a raw `evaluate`, which doesn't update the gap buffer like `run` does (using `maybe-stash-gap-buffer-to-global`). And arguably `evaluate` shouldn't mess with the gap buffer. Gap buffers are a UI concern. The hardest version of this immediate scenario: It's unclear how to guarantee that every definition have a gap buffer, when two definitions may share one (closures sharing a lexical environment). New plan: - improve the logic for detecting definitions. Looking at the outermost layer isn't enough. And a single expression can create multiple definitions. - extract a helper to attach a single gap buffer to multiple definitions. - have the UI detect conflicts in gap buffers and prompt the user for a decision if a different gap buffer already exists for a definition.