| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
|
| |
|
|
|
|
|
| |
This implies it must be side-effect free. We still need to figure out
how to convey that to the computer owner.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
No way to select between them. That complicates the UI too much when we
do so much with the cursor. But it's still useful to suggest things to
type in after ctrl-g.
|
|
|
|
|
| |
I think this is significantly slowing things down. Perhaps we should
sample or something.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This opens up a whole new can of worms: Teliva's ability to show clear
error messages hinges on apps having decent error handling.
I suppose that's ok. A new app someone downloads that throws out strange
error messages and puts them in the equivalent of the console doesn't
exactly engender trust. It's reasonable to treat poor error handling as
breakage.
Here's my running list of open questions from working on the permissions
screen so far:
- how to teach people to care about the difference between:
- permissions known to be unsafe
- permissions unknown to be safe
- how to show syntax errors in the permissions screen
- how to detect syntax errors in the permissions screen (lots of stuff
only shows up when running)
- how to deal with apps with poor error handling (this commit; punt for now)
- how to engender skepticism in people towards what apps tell them
("oh, just go into the permissions screen and type ___ to fix this error")
- how to help people judge the quality of their permissions
(mode == 'r' vs mode ~= 'w')
|
| |
|
|
|
|
|
|
|
| |
Still highly non-ideal. Lua is a dynamic language, and has low ability
to detect syntax errors within functions.
Perhaps I should run a test call after every edit.
|
|
|
|
| |
I believe kilo kinda naturally enforces that. We'll see.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Extremely cruddy implementation:
- I'm still unclear on how to represent the advice function:
- How to handle errors when loading user configuration?
Currently I refuse to start.
- Whole function? More errors to handle in header and so on. What if
the function is renamed?
- Just body? Needs more structured editing support.
- Lots of duplication, particularly between the permissions in the menu
and the permissions screen.
I don't know how to show the hostname at the time of connect() or
bind(), so networking is going to remain a boolean for now. It's also
unclear what effective constraints we can impose on what gets discussed
with a specific hostname. Everything outside the computer is out of
one's control.
One trick I learned is for consistently grabbing ASan logs on abort:
It's always safe to redirect stderr with ncurses!
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Zero guarantees of compatibility at this point.
|
| |
|
|
|
|
|
|
|
| |
I _think_ I don't need to gate other socket calls; you can't do anything
without bind() and connect(). And they should be good places to dump
more precise details later about the kind of server or client connection
being attempted.
|
|
|
|
|
|
|
| |
In the process we now also have a mechanism for Teliva to overlay errors
while apps run. Might make sense to make that available to apps as well.
But I'm starting to realize that any app access to the Teliva areas of
the screen is fraught with risk.
|
| |
|
|
|
|
|
|
|
| |
Our sandboxing model is a blunt caricature, just two booleans. But let's
see how far this gets us.
Still doesn't persist, and definitely has no effect.
|
| |
|
| |
|
| |
|
| |
|