When I began work on what eventually became Konilo, I chose to
impose a number of restraints on its access to the underlying
host. This has helped in portability, but does present some
challenges for using Konilo alongside other tools.

For me, this is not really an issue. I wrote Konilo to serve as
a self contained system, with minimal ties to its host. But I
do see value in having options for using it alongside other
programs on its hosts.

I'm going to briefly cover the limitations that ilo imposes,
and then provide some information on how to work around them.

The standard ilo computer has only a few i/o channels that
we can use. There is a text display (possibly with DEC escape
sequence support), a keyboard, and block storage that can be
read or written to.

No access to a file system, sockets, or pipes is provided. This
presents a very small surface for interaction, but we can do a
little.

My first avenue of interacting with Konilo is to use blocks.
The block format on disk is simple; each block is a 4096 byte
sequence containing 1024 32-bit signed integers. The on-disk
format is little endian.

RetroForth provides words for interacting with an ilo-format
block set.

    block:set-file
    Sets the target block set to use. Provide it with a file
    name on the stack.

    block:read
    Provide a block number and target address on the stack.
    The requested block will be read into memory.

    block:write
    Provide a block number and source address on the stack.
    The requested block will be updated.

These are sufficient to build a variety of import and export
tools. I use them to extract the blocks in the manual for
conversion to HTML, and to update my blog.

There is not currenty a good set of tools in other languages
for working with Konilo's blocks. Arland is working on a Python
class for this (see konilo.org/blocktools.py). Apart from this
writing some sample code in C is on my todo list, but I do not
yet know when I'll be working on this.

Apart from working directly with the blocks, you can (at least
on Unix systems) communicate with Konilo using named pipes.

Create a pair of named pipes with mkfifo(1):

    mkfifo in
    mkfifo out

Then start the ilo computer, redirecting the I/O:

    tail -f in | ./ilo > out

At this point you can write into the `in` file to send code or
data into Konilo and read the output from `out`.

The use of pipes here allows more control under a host system.
If you use an editor that allows sending data to a shell, you
could use a script to write the code to the `in` fifo and then
update the results from reading the `out` fifo.

With a bit of work, it's also possible to do things along the
lines of converting a plain text file into block format and
piping it into Konilo's basic block editor. I've explored this
a little in my (unreleased) text editor written in RetroForth.

So where does this leave us?

While the i/o surfaces ilo provides are limited, it is possible
to control Konilo from outside, and data can be imported or
exported, though there is very little tooling for doing any of
this as of March 2024. Over the next year Arland & I expect to
make considerable improvements on these fronts. Expectations
should remain tempered though; we are not going to be changing
the design to add new host dependencies.