| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
No support yet for drawing wide graphemes.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
We'll need this when rendering 16-bit glyphs. They'll occupy two
8x16 display units on screen, but the grapheme is a single unit as far
as fake screens are concerned.
|
| | |
|
| |
|
|
| |
Convert some old code to current idioms.
|
| |
|
|
| |
We can't yet render the latter 8 bits.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
If I forgot a 'var', Mu would interpret the ':' in the var declaration
as a named block, and all parsing after would be thrown off.
Perhaps I should use separate characters for defining blocks vs vars.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While all test pass, this change is disquieting. When I first designed
Mu I deliberately chose to exclude literal strings from most primitive
instructions both for type-checking and to avoid silently passing
through strange constructions. Nobody really needs to add a string to a
number, and am I sure no SubX instruction will cause a memory safety
issue when passed a string literal instead of a number?
But clearly I have no tests encoding this desire. And any string literal
could be replaced by an integer literal containing the exact same value,
so what are we protecting against anyway.
Let me fix the bug for now. If I run into problems I'll come back and do
this right.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While I'm doing this I might as well lay out a story I don't seem to
have told before in this commit log.
I translated Mu programs to Linux before I did so to bare metal like I
do in the top-level these days. The translator programs still run from
the linux/ directory. However they don't always have good error
messages. As long as I was translating to Linux this wasn't a huge deal
because I always translated Mu programs using the bootstrap translator
in linux/bootstrap/ -- which has great error messages. However,
linux/bootstrap/ can't build bare-metal programs because boot.subx uses
real-mode instructions that aren't supported. As a hack I created a
script called misc_checks that at least tries to run everything besides
boot.subx -- even though translation can never succeed. If I run it and
get to errors about unknown variables I know everything besides
boot.subx raised no errors.
Having labels too far in /disp8 args is is the single biggest reason we
need the misc_checks hack. Hopefully it's now obsolete.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
One less error that's only in the bootstrap phase.
On the other hand, for simplicity I got rid of the ability to override
the Entry label. One less special case, but we're also going further
from the ability to run subsets of layers. We haven't really been
exercising it for a long time, though (commit 7842, March 2021 when we
made baremetal the default).
|
| | |
|
| | |
|
| |
|
|
| |
Now that it's been used in a second app without needing any changes.
|
| | |
|
| | |
|
| |
|
|
| |
Test required.
|
| |
|
|
| |
Make it more obvious that we always do a full repaint if dirty is set.
|
| |
|
|
| |
Test required.
|
| |
|
|
| |
Test required. And a clean fixture.
|
| |
|
|
|
| |
Comments contain indices back to the parent. Reordering items completely
messes up the indices.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
This is worth a first test.
|
| |
|
|
| |
I don't actually have per-user feeds yet. Just drop the feature for now.
|
| | |
|
| |
|
|
|
| |
Pretty klunky that it's always on the topmost item. But it gets us
going.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
First step: switch to arrow keys for navigating by item.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Bug in channel view.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|