fun-a-day, day 5

so far today i got the patch to uxnemu working!

with the patch applied, emulators running in unix environments can fork
subproccesses and communicate with their child processes, either using
a pty or a pipe.

the spec is consistent with what i wrote yesterday:

    ADDR NAME      COMMENT
    0x10 vector    callback used when stdin has data ready
    0x12 stdin     characters from stdin become available here
    0x13 exec      (new) address of string describing program (see below)
    0x15 mode      (new) start execution with given mode (see below)
    0x16 dead      (new) whether program is running (0), dead (1), or failed to start (255)
    0x17 exit      (new) program's exit code (0 is ok, 1-255 is an error)
    0x18 stdout    write characters to stdout here
    0x19 stderr    write characters to stderr here

example exec string literal: "bash 00 "-i 00 "-l 00 00

mode flags:

    0x01    write to child stdin   (using Console/write)
    0x02    read from child stdout (using Console/read)
    0x04    read from child stderr (using Console/read)
    ....    ignored
    0x80    allocate a pty (implies 0x07)

in addition to testing with determ i've tested bidirectional
communication across standard pipes. in theory uxn programs should be
able to have read-only or write-only communication as well but so far
that isn't well-tested.

eventually i'd like to add support for this to femto, allowing
people to use external programs for things like spell-check.

here are the patches:

 * fork2.patch applies to the uxn repo
 * term-exec-device.patch applies to term.tal

UPDATE: i've applied the term.tal patch. on unpatched emulators the new
operations should be ignored, so it's safe to apply the patch already.

patches are applied from the base directory with patch -p1 < PATCHFILE.

the change is pretty large, it's possible neauoire will be
relucant to merge as-is. i can see a couple of alternatives:

 (a) merge more-or-less as-is
 (b) merge minimal support for determ only
 (c) move this functionality to a dedicated device
 (d) come up with an alternate spec

i'm not very opinionated about how this should go. it feels a bit bad
to merge a feature useful for only one rom but it's true that if we
only support the kind of pty determ needs then a lot of the other
details disappear since:

 * there's no need to support killing/restarting processes
 * there's no need to track exit codes
 * there's no need to support different read/write strategies
 * the forkpty case requires much less work than raw fork

however, being able to invoke programs (e.g. gcc or ispell) from a
uxn rom would be pretty compelling!

back to funaday 2023 home