| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
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?
|
| | |
|
|
|
Port some support for unicode to baremetal.
|