| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
|
|
| |
Perhaps this is a bad idea. It feels arbitrary, what methods Lua happens
to include in string and table objects without having to go through the
respective modules.
|
| | |
|
| |
|
|
|
| |
Looks like Lua's local functions lose access to outer scopes (upvalues)
or something like that..
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When should code go in the template used by new apps vs the .lua files
distributed with Teliva?
- from a privilege perspective there's no difference
- from a compatibility perspective stuff in .tlv will not get upgraded
with Teliva.
- for me the maintainer, functions in .lua files are easier to upgrade
in a single place.
- for the reader of an app, functions in .lua files will not show up to
be edited. They can still be overloaded, but the current version isn't
as discoverable. Putting something in the app is a slight nudge to
readers that they're encouraged to mess with it.
- Stuff in .lua files can use local functions and so have more internal
complexity. Apps can also hide details within functions, but that'll
make them more likely to run into limitations with Teliva's editing
environment.
I'm not yet sure how to reason about the second point in practice.
- Stuff in .tlv files I don't have to worry about compatibility
guarantees for.
- Stuff in .lua files I _do_ have to worry about compatibility
guarantees for.
Perhaps this means I'm doing things exactly wrong in this commit?
Functions like map/reduce/filter/append seem more timeless, whereas I'm
still just feeling my way around with start_reading and start_writing.
We'll see. For now I'm ruled by the fourth point. Messing with tasks and
the scheduler is much more advanced than anything else in template.tlv;
it seems to make sense to add some friction to modifying them.
Bottomline: Complex sub-systems go in .lua files. Simple, self-contained
definitions go into apps. Both are probably equally burdensome now from
a compatibility perspective.
|
| |
|
|
|
|
| |
I'm starting to get quite indisciplined about where I introduce global
bindings. Seems reasonable since any modules in Teliva will come from
within the framework.
|
| |
|
|
|
| |
Really everywhere except zet.tlv. toot-toot is intended to emit
throwaway files anyway.
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
| |
For starters, this detail was puzzling when I returned to the Game of
Life app.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
| |
Now we cancel screen-painting if any key is pressed.
However it looks like just computing the list of anagrams can take a
long time.
|
| | |
|
| |
|
|
|
| |
We don't care to distinguish modes like "rw" or "a+". An app is
permitted to perform either just reads or both reads and writes.
|
| | |
|
| | |
|
| |
|
|
| |
In particular, the periods looked like passing tests.
|
| | |
|
| |
|
|
|
| |
This feels more intrusive. Let's see how we like it. Will I start having
ctrl-x ctrl-x in my muscle memory?
|
| |
|
|
|
| |
I'm totally fine with lexical scope in other languages. Why does it feel
like such a big deal in C?
|
| | |
|
| | |
|
| |
|
|
|
| |
Let's see if we can live with this rather than some way to let apps
indicate if they want confirmation or not..
|
| |
|
|
|
| |
In any case, I want the convention to be '|' for alternation. '/' is
more likely to be a real hotkey.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
| |
Also a little test program to demo channels in action.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
| |
For starters, drop some redundant prose here.
|
| |
|
|
| |
They aren't evaluating strings after all.
|
| | |
|
| |
|
|
|
|
| |
This is for what the app does, as opposed to 'doc:main', which is also
intended to include commentary about the internal organization of the
app.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
Need for tests growing more acute..
|
| | |
|