| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
| |
Roll back all buffering of Stdout.
|
| |
|
|
| |
Yeah, this isn't working.
|
| |
|
|
|
|
|
|
|
| |
tile is already visibly slow (49x212 screen) :/ So programmer needs more
control over performance.
But this may not be the right approach. That extra flush-stdout in tui.mu
suggests it's either going to be finicky, or we have to flush on every
attribute change. And going through a buffered-file may be slower. May.
|
| |
|
|
| |
This was surprisingly hard; bugs discovered all over the place.
|
| |
|
|
| |
Print answers in decimal in apps/arith.mu
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
For example:
fn main -> r/ebx: int {
var x/eax: grapheme <- copy 0x9286e2 # code point 0x2192 in utf-8
print-grapheme-to-real-screen x
print-string-to-real-screen "\n"
}
Graphemes must fit in 4 bytes (21 bits for code points). Unclear what we
should do for longer clusters since graphemes are a fixed-size type at
the moment.
|
| |
|
|
| |
Another stupid bug: I've been printing out 3 nulls for every byte of ascii.
|
| |
|
|
|
| |
This is stupid; all this while I've been writing escape sequences to the
screen they've been going out on stderr.
|
| |
|
|
|
|
|
|
|
|
| |
Both have the same size: 4 bytes.
So far I've just renamed print-byte to print-grapheme, but it still behaves
the same.
I'm going to support printing code-points next, but grapheme 'clusters'
spanning multiple code-points won't be supported for some time.
|
| |
|
|
|
| |
We now have all existing apps and prototypes going through the dependency-injected
wrapper, even though it doesn't actually implement the fake screen yet.
|
| | |
|
| | |
|
| |
|