Hi all!

I've taken to writing a Unicode text renderer for uxn/varvara. In uxn I
see a VM that can be expected to run in all kinds of weird environments
forever so targeting it is a good way to ensure you "write once, execute
for a million years".

But obviously, the platform (varvara) still needs work. :)

In particular, it NEEDS some kind of native support for juggling large
data stores. Unicode is implemented as a bunch of databases and it
normally operates together with fonts (and input mappers) which are
themselves databases. These databases aren't big by modern standards -
a few MiB at most - but for uxn, they are *ginormous*!

I don't want to implement my own emulator because then the code won't
be portable to other people's emulators and *the entire point* is to be
portable and permanent.

Obviously I will need to precompute these databases. One option is to
cut them up into tiny files and then use the filesystem device as-is,
and seek through the database by performing a thousand file lookups.

But it would be better (easier on the host system) if I were able to
perform a fseek(). I saw there are at least two other proposals for
this. I didn't write a patch - at least not yet - but I can offer that
it's enough to allocate another bit from the "append" byte and have
this bit mean the writes or reads are meant to be seeks. Bit 0 would
then be meaningless. This setup is 100% percent backwards compatible,
observe:

0x00 -> writes and reads start at the beginning of the file and proceed
        linearly
0x01 -> write starts at the end of the file, read starts at the
        beginning of the file and they both proceed linearly
0x02 -> no writes or reads are performed, instead the file pointers
        associated with them get moved; presumably the read pointer
        won't be able to seek beyond the beginning or end of file and
        presumably the write pointer can't seek beyond the beginning of
        the file but CAN seek beyond the end of the file. Writing to
        beyond the end of the file automatically expands the file to
        that length and fills the space with NULLs.
     -> it's obviously possible to forbid seeks of the write pointer
        from leaving the bounds of the file
0x03 -> behaves the same way as 0x20
     -> it might be a good idea to make 0x03 undefined
all others -> undefined

When thinking about this, it's very important to not allow lithified
thinking to get to us. "The filesystem" as it exists today is just a
lithified hierarchical database. In my humble opinion, varvara
shouldn't marry itself to hierarchical databases but should keep its
options open. In practical terms - we shouldn't strive to copy the
behavior of POSIX. It's OK to be weird. :) ...but some kind of a seek
SHOULD be implemented tho. xD

-- 
Svi moji e-mailovi su kriptografski potpisani. Proverite ih.
All of my e-mails are cryptographically signed. Verify them.
--
You don't need an AI for a robot uprising.
Humans will do just fine.
--