| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Port some support for unicode to baremetal.
|
| |
|
| |
|
|
|
|
|
|
|
| |
https://en.wikipedia.org/wiki/GNU_Unifont#The_.hex_font_format
http://unifoundry.com/unifont/index.html
Since GNU Unifont is covered under the GPL v2, so I believe is this repo.
|
| |
|
| |
|
|
|
|
|
| |
It also clears keys after reading them, allowing us to read more than 16
keys.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
I was wrong in commit 7437 that only one keystroke was working. The problem
was just that I was getting _too_ many events. I wasn't handling key-up
events, and they were entering the buffer, and I was not skipping null
events since the circular buffer is currently considered to be null-terminated.
ex3 isn't done yet; it can only handle 16 events. Apps need to be clearing
the keyboard buffer.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
The ol' 8-byte-register-names issue strikes again. There's no way to access
the lower 8 bits of ESI.
There's still a bug in baremetal/ex2.mu; it's printing transposed somehow.
|
|
|
|
|
| |
It doesn't _quite_ do what it should, so this is more precisely the first
_buggy_ baremetal Mu program. But the tooling works, at least.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
It's now clear that our keyboard handler doesn't trigger after the first
event.
|