| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
There's a new example app showing this ability.
Still to go: support for combining characters when rendering text and
streams.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Unfortunately the Unicode database doesn't actually provide obvious
metadata for combining characters. The process I followed is as follows.
I noticed that GNU Unifont provides the following files for download:
- unifont-13.0.06.hex: All Plane 0 glyphs
- unifont_sample-13.0.06.hex: The above .hex file with combining circles added
Downloading and diffing the two yields all code-points with combining
circles. I assume they are exactly the combining characters I care
about.
One mechanical difficulty is cross-correlating the above files that
include the code-point in each line with font.subx which does not. I got
things to work by modifying the above files in place until they have the
same format as font.subx, using the following Vim commands on each file:
:%s|.\{64\}|10/size^M00/is-combine^M&|
:%s|^.\{32\}$|08/size^M00/is-combine^M&00000000000000000000000000000000|
:%s|..|& |g
:%s|10 /s iz e|10/size|
:%s|08 /s iz e|08/size|
:%s|00 /i s- co mb in e|00/is-combine|
Now I can update the metadata with a Vim macro which jumps to the next
hunk and increments /is-combine on the previous line.
|
| |
|
|
|
|
|
|
|
|
|
| |
https://en.wikipedia.org/wiki/Combining_character
The plan: just draw the combining character in the same space as the
previous character. This will almost certainly not work for some Unicode
blocks (tibetan?)
This commit only changes the data/memory/disk model to make some space.
As always in Mu, we avoid bit-mask tricks even if that wastes memory.
|
| | |
|
| |
|
|
|
|
|
|
| |
Yet another gnarly reason to start checking all arg metadata in
linux/pack.subx or something like that. With this bug most of my
programs (including browser-slack!) were working even though the
instruction stream was almost certainly misdecoded halfway through every
attempt to draw glyphs.
|
| | |
|
| | |
|
| |
|
|
| |
Open question fixed.
|
| |
|
|
|
| |
Open question: why does column 0 get cropped? The spacing also seems
excessive. Are we taking up 3 grid points?
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
We can't really translate purely SubX code anyway at the top-level. Stop
exposing those scripts.
|
| | |
|
| |
|
|
|
| |
Now we load all the code, but it overwrites the extended BIOS area.
640KB is no longer enough. Need to rethink loading strategy.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
shell/ is currently broken; we've overflowed available contiguous space
for code.
Block names based on https://www.compart.com/en/unicode/block:
0x0000 - 0x007f Basic Latin 128
0x0080 - 0x00ff Latin-1 Supplement 128
0x0100 - 0x017f Latin Extended-A 128
0x0180 - 0x024f Latin Extended-B 208
0x0250 - 0x02af IPA Extensions 96
0x02b0 - 0x02ff Spacing Modifier Letters 80
0x0300 - 0x036f Combining Diacritical Marks 112
0x0370 - 0x03ff Greek and Coptic 135
0x0400 - 0x04ff Cyrillic 256
0x0500 - 0x052f Cyrillic Supplement 48
0x0530 - 0x058f Armenian 91
0x0590 - 0x05ff Hebrew 88
0x0600 - 0x06ff Arabic 255
0x0700 - 0x074f Syriac 77
0x0750 - 0x077f Arabic Supplement 48
0x0780 - 0x07bf Thaana 50
0x07c0 - 0x07ff NKo 62
0x0800 - 0x083f Samaritan 61
0x0840 - 0x085f Mandaic 29
0x0860 - 0x086f Syriac Supplement 11
0x08a0 - 0x08ff Arabic Extended-A 84
0x0900 - 0x097f Devanagari 128
0x0980 - 0x09ff Bengali 96
0x0a00 - 0x0a7f Gurmukhi 80
0x0a80 - 0x0aff Gujarati 91
0x0b00 - 0x0b7f Oriya 91
0x0b80 - 0x0bff Tamil 72
0x0c00 - 0x0c7f Telugu 98
0x0c80 - 0x0cff Kannada 89
0x0d00 - 0x0d7f Malayalam 118
0x0d80 - 0x0dff Sinhala 91
0x0e00 - 0x0e7f Thai 87
0x0e80 - 0x0eff Lao 82
0x0f00 - 0x0fff Tibetan 211
0x1000 - 0x109f Myanmar 160
0x10a0 - 0x10ff Georgian 88
But don't trust the block sizes above. Thanks to gdb[1] for this helper:
define z
print 2 * (0x$arg1 - 0x$arg0 + 1)
end
e.g:
(gdb) z 10a0 10ff
192
[1] https://sourceware.org/gdb/current/onlinedocs/gdb/Define.html
|
| | |
|
| |
|
|
|
| |
Any command in shell that rendered the screen resulted in an infinite
loop. But it took me forever to even realize it was an infinite loop.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
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.
|