| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
Longer name, but it doesn't lie. We have no data structure right now for
combining multiple code points. And it makes no sense for the notion of
a grapheme to conflate its Unicode encoding.
|
| | |
|
| |
|
|
| |
I'm increasingly missing CI.
|
| |
|
|
| |
By definition that function can't support combining characters.
|
| |
|
|
| |
Fake screens can't handle them yet.
|
| | |
|
| |
|
|
|
| |
Inline render-code-point in one of its call-sites before we add support
for combining characters.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Unix text-mode terminals transparently support utf-8 these days, and so
I treat utf-8 sequences (which I call graphemes in Mu) as fundamental.
I then blindly carried over this state of affairs to bare-metal Mu,
where it makes no sense. If you don't have a terminal handling
font-rendering for you, fonts are most often indexed by code points and
not utf-8 sequences.
|
| |
|
|
| |
No support yet for drawing wide graphemes.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Smoked out some issues by rendering a single frame of Game of Life.
Incredibly slow.
|
| | |
|
| |
|
|
| |
We'll gradually make this more dynamic.
|
| | |
|
| | |
|
| |
|
|
|
| |
Move abort to SubX. We'll need to do some unsafe stuff to display the call
stack here.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I spent a while building a little keyboard scancode printer:
$ ./translate ex1.mu && qemu-system-i386 disk.img
..and wondering why up-arrow was 0x48 in hex but 724 in decimal. I ended
up paranoidly poking at a bunch of crap (though there _is_ a cool chromatography-based
debugging technique in 126write-int-decimal.subx) before I realized:
- 724 just has one extra digit over the correct answer
- the 0xe0 scan code is a 3-digit number in decimal -- and the final digit is '4'
There's nothing actually wrong.
|
| |
|
|
| |
Top-level and linux/ now have separate vocabulary.md files.
|
|
|
Baremetal is now the default build target and therefore has its sources
at the top-level. Baremetal programs build using the phase-2 Mu toolchain
that requires a Linux kernel. This phase-2 codebase which used to be at
the top-level is now under the linux/ directory. Finally, the phase-2 toolchain,
while self-hosting, has a way to bootstrap from a C implementation, which
is now stored in linux/bootstrap. The bootstrap C implementation uses some
literate programming tools that are now in linux/bootstrap/tools.
So the whole thing has gotten inverted. Each directory should build one
artifact and include the main sources (along with standard library). Tools
used for building it are relegated to sub-directories, even though those
tools are often useful in their own right, and have had lots of interesting
programs written using them.
A couple of things have gotten dropped in this process:
- I had old ways to run on just a Linux kernel, or with a Soso kernel.
No more.
- I had some old tooling for running a single test at the cursor. I haven't
used that lately. Maybe I'll bring it back one day.
The reorg isn't done yet. Still to do:
- redo documentation everywhere. All the README files, all other markdown,
particularly vocabulary.md.
- clean up how-to-run comments at the start of programs everywhere
- rethink what to do with the html/ directory. Do we even want to keep
supporting it?
In spite of these shortcomings, all the scripts at the top-level, linux/
and linux/bootstrap are working. The names of the scripts also feel reasonable.
This is a good milestone to take stock at.
|