They may take more or less from it (sieve.tlv in particular takes
nothing since call depth doesn't help at all there), but what they take
is in the right order so that you can compare across apps.
Teliva isn't yet smart enough to know the caller of an indirect function
where the function being called goes through a local variable.
I'd expected fixing this to be a long death march. However, there's a
shockingly easy fix: just make every indirect call go through an
additional direct function call.
My policy for zet.tlv was that function 'main' could open any file. This
stopped working since I introduced spawn_main. But with this commit it's
working again.
I can also drop all my special-casing of 'main' since it's now a regular
Lua call.
We still can't rely on the caller of an indirect call. That affects
start_reading and start_writing, which really need to be part of the
framework.
File operations now always return a channel (or nil on error or
permission denied).
When start_reading() from a filename, you can repeatedly :recv() from
the channel it returns.
When :recv() returns nil, you're at the end of the file. Stop.
When you start_writing() to a filename, you can repeatedly :send() to
the channel it returns.
When you're done writing, :close() the channel. Writes to the file won't
be externally visible until you do.
To make this work I'm now always starting up the scheduler, so I need to
fix sieve.tlv.
Transparently running the scheduler is an abstraction, and whenever I
create an abstraction I always worry about how it might fail. There's
a hopefully-clear error when you read past end of a file.
If we press a key the computation now restarts instantly.
There's no fiction of multi-threading in Teliva. If the application
doesn't work right, it beach-balls. If it doesn't beach-ball under
normal circumstances you're more certain it'll never beach-ball. It's
more work up-front, but there's less variability in outcomes.
Until now you had to press ctrl-x twice in rapid succession to exit if
an app turned on non-blocking keyboard with nodelay(true). This became
particularly noticeable after the previous change to anagrams.tlv, which
could no longer exit.
Tasteful apps should only perform side-effects through 'window'
arguments rather than the 'curses' module directly. It's ok however to
read constants like curses.A_NORMAL or curses.stdscr().
There are some limitations, unfortunately. Ncurses wasn't designed with
testability in mind. For example, there's no way to curs_set or
assume_default_colors without the 'curses' module. Oh well.
They make it seem like you can use them to create simple REPL apps, but
you can't, because standard Teliva shortcuts won't work.
I _could_ make them work by emulating them using getch(), but that feels
like an unnecessary abstraction for now.
I introduced this ability when I packaged up the lfs directory, but it
can enable apps to circumvent sandboxing rules in some situations. If
you can socially engineer someone to allow reading a file called
'passwd' in the current directory, you can now change directory to /etc
and read something sensitive.
Protecting against stuff like this gets subtle. It's easy for people to
create policies that aren't robust to changing directories. Requiring
absolute paths is also pretty unfriendly. So the whole notion of current
directory is perhaps implicit state that is confusing to manage. Fix it
in the context of a single session.
When I started logging getch() events (which are just to help the reader
orient on the log), this suddenly became more urgent.
Now the log is larger, and it's also a circular buffer that rolls back
to the start when it fills up.
The next failure mode will be if we see the buffer filled up with just
getch() calls, reducing visibility over real file and network
operations. In which case we'll need to start coalescing getch() events.
We also made render dynamic, showing zettels in the first place it
encounters them in depth-first order.
Open question: how to show a collapsed outline view with the data model
I'm experimenting with. Not even clear 'outline' has meaning in the
presence of cross-links. Outliners privilege one view of the network.
Zettelkasten also does so; changing child/sibling relationships is a lot
of work. However, reading between the links it seems to try to provide
an escape hatch for rethinking connections using cross-links. I'm trying
to lean into that -- at the cost of providing outlines. We'll see if
this is a good trade-off.
