| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
So far we've drawn a space implicitly at the cursor. Now I allow drawing
an arbitrary grapheme when drawing the cursor. But the caller has to
specify what to draw. (The alternative would be for layer 103 to
track every single grapheme on screen along with its color and any other
future attributes, just to be able to paint and unpaint the background
for a single character.)
I've modified existing helpers for drawing multiple graphemes to always
clear the final cursor position after they finish drawing. That seems
reasonable for terminal-like applications. Applications that need to
control the screen in a more random-access manner will need to track the
grapheme at the cursor for themselves.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I spent over a week agonizing over this.
* I had to come to terms with the fact that I don't really know how to
make pixel graphics testable. ASCII art on a pixel by pixel basis feels
inhuman. Just focus on text mode for now.
* I had to set aside the problem of non-English family languages.
Languages like Arabic that can stack complex graphemes together likely
can't be fixed-width. But I don't know enough at the moment to solve for
them.
* I spent a while trying to juggle two cursors, one invisible output
cursor for tracking the most recent print, and one visible one that's
just a hint to the user of what the next keystroke will do. But it looks
like I can fold both into a single cursor. Drawing things updates the
location of the cursor but doesn't display it. Explicitly moving the
cursor displays it, but future drawing can overwrite the cursor.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Don't assume screen dimensions.
|
| |
|
|
| |
Both issues of commit 7531 fixed.
|
| | |
|
| |
|
|
|
|
| |
This uncovers two open issues:
* incrementing the cursor after drawing a single grapheme
* needing to clear background pixels when drawing a grapheme
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Bring back runtime support for bounds-checking arrays. Again, the error
messages kinda suck, because I can't yet print integers. But something
is better than nothing.
|
| |
|
|
|
|
|
|
|
|
|
| |
Our infrastructure for displaying errors is far more rudimentary in
baremetal. Many ways things can go wrong. But making the attempt seems
better than not.
I'm also making some effort to keep it easy to see what has been copied
over from the top-level, by not modifying copied code to use syntax
sugar and so on. It may not be an important enough reason to mix
notations in a single file.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There's a dependency cycle here:
- draw-grapheme (Mu) uses read-grapheme (Mu) to be unicode-aware.
- read-grapheme uses read-byte (SubX). Streams are a fundamental data
structure in Mu. For the Mu compiler to be able to reason about the
safety of stream operations, they need to be an opaque type. All
stream primitives are written in SubX. To manipulate a stream's
internals we force people to reach for SubX. That way if there's no
SubX code there's confidence that things are safe.
- read-byte and other stream operations have unit tests, like they
should. The unit tests need to print data to screen when say a test
fails. To do this they use various check- functions (SubX) that take a
string argument.
- Printing a string to screen uses draw-grapheme (Mu).
Perhaps I should maintain variants of drawing primitives that operate
only on ASCII.
|
| |
|
|
|
|
|
|
| |
Even though baremetal has tests in SubX, they can only run in Mu
programs since the test harness is currently in a Mu layer. Baremetal
isn't really intended for running SubX programs at the moment. Is this a
step down the slippery slope towards C compilers that I complained about
in http://akkartik.name/akkartik-convivial-20200607.pdf?
|
| |
|
|
|
|
|
|
|
|
| |
It's not really manageable to make the fake screen pixel-oriented. Feels
excessive to compare things pixel by pixel when we will mostly be
writing text to screen. It'll also make expected screen assertions
more difficult to manage.
So I'm not sure how to make assertions about pixels for now. Instead
we'll introduce fake screens at draw-grapheme.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This is the right way to be direction-independent. Don't save the cursor
when drawing a single grapheme. Where the next char goes is just a
property of the direction-oriented primitives.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|