| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
Teliva's model doesn't include any way to change directory. We just have
relative paths and absolute paths. Relative paths should not be able to
reach into parent directories.
The current test is a bit hacky; it also disallows directories ending in
a period. Hopefully not an issue.
|
| |
|
|
|
|
|
|
|
|
| |
This serves two purposes:
- Things get confusing if function being defined doesn't match the
definition name. Displaying the current definition helps diagnose this
situation.
- We're already able to see callers at a glance even if the cursor is
below the fold. The name of the current definition is arguably more
important in that situation.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
This reclaims all the slowdown in sieve.tlv, and it also is now smart
enough to detect calls to global bindings that pass through variables.
On the flip side, we lose names for non-globals. But that's not very
useful anyway in Teliva's context.
This is still not enough to detect callers through coroutines
(intervening anonymous functions), though.
|
| |
|
|
| |
Partially undoes commit f2d29c22f86a88.
|
| |
|
|
| |
This brings down the slowdown in sieve.tlv from 50% to 25% (15s).
|
| | |
|
| |
|
|
|
| |
sieve.tlv is 50% slower (18s vs 12s) with the new function call
instrumentation.
|
| | |
|
| |
|
|
|
|
|
|
| |
src/ldo.c now has a minimal diff with Lua 5.1.
It might be a bit slower than it was before, but not noticeably so..
This approach doesn't support indirect calls.
|
| | |
|
| |
|
|
|
|
| |
It's a mess. I calculate call-graph depth one way and calculate caller
names another way. At least one of the ways fails to work with indirect
calls. Hopefully the other way works?
|
| | |
|
| |
|
|
|
| |
This bug was caused by me forgetting that lua_setglobal affects the
stack.
|
| |
|
|
| |
In the process I found a couple of bugs in fake screen primitives.
|
| |
|
|
|
| |
Implication: os.rename now needs to be sandboxed. Hopefully it's
tractable to treat it as conceptually identical to opening two files.
|
| |
|
|
|
|
|
|
|
| |
We're now back to the problem of how to transparently allow Teliva to
create temporary filenames without every app having to explicitly allow
them.
I think I may need to define start_writing in C, so that it can use a
non-sandboxed version of io.open.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The interface for apps looks much nicer now, see 'main' in zet.tlv.
However there are some open issues:
- It can still be confusing to the computer owner that an app tries to
write to some temporary file that isn't mentioned anywhere.
- File renames can fail if /tmp is on a different volume.
- What happens if an app overrides start_writing()? The computer owner
may think they've audited the caller of start_writing and give it
blanket file permissions. Teliva tunnels through start_writing when
computing the caller. If the app can control what start_writing does,
the app could be performing arbitrary malicious file operations.
Right now things actually seem perfectly secure. Overriding
start_writing has no effect. Our approach for loading .tlv files (in
reverse chronological order, preventing older versions from overriding
newer ones) has the accidentally _great_ property that Teliva apps can
never override system definitions.
So we have a new reason to put standard libraries in a .lua file: if
we need to prevent apps from overriding it.
This feels like something that needs an automated test, both to make
sure I'm running the right experiment and to ensure I don't
accidentally cause a regression in the future. I can totally imagine a
future rewrite that tried a different approach than
reverse-chronological.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
The problem I'm running into is that apps might want to perform their
own editing. So I can't take up prime estate like the ctrl-e hotkey or a
menu name of 'edit'.
I'm still prioritizing rendering Teliva's edit and permissions menu. If
the window is too narrow the app's settings will be overwritten and
Teliva's hotkeys will be preferentially displayed. Seems safer.
|
| | |
|
| |
|
|
|
| |
This will help people cross-correlate when the app performs specific
calls.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I fucking hate feature macros. Egregious discharge of our
division-of-labor-obsessed society. People should be able to introduce
names. People should be able to give up names to lower levels of
abstraction when they encounter conflicts.
Feature macros seem to exist[1] to support more than two levels of
abstraction. You try to build, one of your libraries fails to build
because of a conflict between it and one level down. You don't want to
modify this library. Just fucking https://catern.com/change_code.html
already. But no, I have to litter my code with feature macros even
though I just want the abstraction the original library provides.
[1] https://man7.org/linux/man-pages/man7/feature_test_macros.7.html
https://lwn.net/Articles/590381
|
| |
|
|
|
|
| |
I made the changes reverted here out of a mistaken sense that
big-picture edits would interfere with Teliva's memory of what is
currently being edited (teliva_editor_state).
|
| |
|
|
|
| |
Previously we weren't dynamically selecting how to highlight a buffer
after navigating with ctrl-g. That should work now.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Going to big picture from doc:bp still goes to the default
auto-generated big picture view.
While doc:bp provides some programmability, it's also far klunkier than
the default view. Rendering is worse, and it's always in edit mode
because I'm trying to avoid complicating the UX with a notion of
rendered markup. That means cursor movement is less convenient. It's
also easy to accidentally edit the big-picture view.
|
| | |
|
| | |
|
| |
|
|
| |
I've always found "Documentation" too pretentious.
|
| |
|
|
| |
This is long overdue.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
First step: when a "definition" starts with "doc:" it's not a
definition, just a buffer. Stop trying to interpret it as Lua.
|
| |
|
|
|
|
|
|
| |
NetBSD still uses curses by default. One _could_ install ncurses, but I
don't have access to a NetBSD box with permissions to install ncurses,
so I'm experimenting to see how far we can get with just curses. So far
most of the apps seem to work, with the exception of one bug that I'll
commit next.
|
| | |
|
| | |
|
| |
|
|
|
| |
This implies it must be side-effect free. We still need to figure out
how to convey that to the computer owner.
|
| | |
|
| | |
|