about summary refs log tree commit diff stats
path: root/src/lua.c
Commit message (Collapse)AuthorAgeFilesLines
* standardize some namesKartik K. Agaram2022-03-161-1/+1
|
* stop running task.scheduler by defaultKartik K. Agaram2022-03-161-1/+2
| | | | | sieve.tlv is 50% slower (18s vs 12s) with the new function call instrumentation.
* stop loading libraries after app codeKartik K. Agaram2022-03-071-7/+2
| | | | This whole approach of disallowing overriding is suspect.
* slightly firm up phases in pmainKartik K. Agaram2022-03-071-2/+9
|
* fix the security vulnerabilityKartik K. Agaram2022-03-071-2/+4
| | | | | | | | | We now have a notion of libraries that we load after app code, to prevent them from getting overridden. Should I just load all libraries after the app? There might be value in allowing apps to override library functions. Disallowing that too much may be going against Lua's dynamic nature.
* call app's main() from within Lua pmainKartik K. Agaram2022-03-071-1/+5
|
* decode json from channelsKartik K. Agaram2022-03-061-0/+2
|
* move start_reading/start_writing out of templateKartik K. Agaram2022-03-061-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* import https://github.com/majek/lua-channelsKartik K. Agaram2022-02-261-0/+2
| | | | Also a little test program to demo channels in action.
* get Teliva running on NetBSDKartik K. Agaram2022-01-241-0/+4
| | | | | | | | 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.
* .Kartik K. Agaram2022-01-021-1/+1
|
* reorg: pull Teliva-specific stuff out of lua.cKartik K. Agaram2021-12-251-998/+4
| | | | It should now be easier to diff against the Lua 5.1 sources upstream.
* tlv format for transient editor stateKartik K. Agaram2021-12-251-17/+20
| | | | | Stop interpreting arbitrary Lua code when loading editor state. We don't need that power or security risk.
* cleaner test messageKartik K. Agaram2021-12-231-3/+2
| | | | Was printing over passing tests for some reason.
* errors during tests are now handledKartik K. Agaram2021-12-221-1/+8
| | | | | | | | | | | | | | | | I should have documented that I'd never actually seen that code path trigger before. Here's a minimal test that did it just now: function test_foo() return a+1 end E2: [string "test_foo"]:2: attempt to perform arithmetic on global 'a' (a nil value) A simple missing variable doesn't do it since it just evaluates to nil. Without this commit, the above test was silently continuing to the main app after failing tests.
* fix arrow keys in big picture view on MacKartik K. Agaram2021-12-211-5/+5
| | | | Turns out arrow keys are considered `isprint()` on Mac.
* bugfix: ensure definition to edit has some nameKartik K. Agaram2021-12-211-4/+6
|
* less confusing nameKartik K. Agaram2021-12-211-5/+3
|
* arrow keys in big picture viewKartik K. Agaram2021-12-211-12/+104
|
* nail down trusted Teliva channels a little moreKartik K. Agaram2021-12-211-1/+6
| | | | | | | | | | | | | | | | | | | | | | In each session, Teliva has to bootstrap a trusted channel with the computer owner while running arbitrarily untrusted code. So let's get really, really precise about what the trusted channel consists of: - the bottom-most row of screen containing the menu - the keystrokes the owner types in - ncurses COLOR_PAIR slots 254 (menu) and 255 (error) One reason the menu colors are important: we don't want people to get used to apps that hide the menu colors by setting default foreground/background to invisible and then drawing their own menu one row up. The error COLOR_PAIR I don't see any reason to carve out right now, but it seems like a good idea for Teliva the framework to not get into the habit of apps doing some things for it. I'm not sure how realistic all this is (I feel quite ill-equipped to think about security), but it seems worthwhile to err on the side of paranoia. Teliva will be paranoid so people don't have to be.
* pay more attention to where we display the cursorKartik K. Agaram2021-12-181-1/+2
| | | | | It's still just in app control; I'm resisting the urge to introduce "smarts".
* better copy on test failuresKartik K. Agaram2021-12-171-1/+4
|
* correct count of test failuresKartik K. Agaram2021-12-171-1/+1
|
* keep tests from messing up big pictureKartik K. Agaram2021-12-171-0/+19
|
* one more protection against Lua stack leakKartik K. Agaram2021-12-171-6/+6
|
* experimental support for test errorsKartik K. Agaram2021-12-171-3/+8
|
* start of a test frameworkKartik K. Agaram2021-12-171-0/+35
| | | | | Follows https://github.com/akkartik/wart, https://github.com/akkartik/mu0, https://github.com/akkartik/mu1 and https://github.com/akkartik/mu.
* yet another stab at reorganizing stack assertionsKartik K. Agaram2021-12-171-9/+14
|
* .Kartik K. Agaram2021-12-171-0/+3
|
* .Kartik K. Agaram2021-12-171-4/+4
|
* more protection against data lossKartik K. Agaram2021-12-171-2/+2
|
* protect against data loss in some rare situationsKartik K. Agaram2021-12-161-3/+32
| | | | | | | | | | | Examples: - you try to write file but disk is full - you have two Teliva files being edited at the same time Both are situations where it's impossible to avoid some data loss. However, we should now at least have some valid state of the .tlv file saved to disk where we'd previously end up with a zero-size file or garbage.
* fix another leak in the Lua stackKartik K. Agaram2021-12-161-2/+9
| | | | | This fixes a segfault when scanning through a long history of recent changes (say > 20 changes)
* more consistently show notes in recent changesKartik K. Agaram2021-12-161-1/+5
| | | | | | | | | Teliva emits timestamps in multi-line format end in a newline. As a result, notes get rendered on the next line and are then immediately overwritten by the contents of the definition. This bug was masked by my hacky 'original' timestamps which don't use multi-line format.
* stop leaking on the Lua stack, reduxKartik K. Agaram2021-12-161-11/+19
| | | | | An empty stack is too rigorous a line to hold. Instead we'll just ensure we leave the stack the way we found it.
* Revert "stop leaking on the Lua stack"Kartik K. Agaram2021-12-161-2/+2
| | | | | | | This reverts commit 7c1b9d0b91295323b5ed5ec3e09b46566288bc75. The 'big hammer' isn't good enough. The recent changes view seems to need state on the stack across invocations of the editor.
* stop leaking on the Lua stackKartik K. Agaram2021-12-161-2/+2
| | | | | ..even if at the expense of leaking on the heap. Because the Lua stack has very limited space (~20 slots). When it overflows, we segfault.
* show all functions in big pictureKartik K. Agaram2021-12-131-2/+6
| | | | We were missing functions in some larger programs.
* can again edit notes on changesKartik K. Agaram2021-12-111-4/+4
|
* bring back commandline argsKartik K. Agaram2021-12-111-1/+18
|
* snapshot: writing working?Kartik K. Agaram2021-12-111-34/+7
| | | | | | This is a complete mess. I want to abstract reading multiline strings behind a function, but the lookahead requirements for that are quite stringent. What's a reasonable abstraction here?
* snapshot: start reading a new formatKartik K. Agaram2021-12-111-26/+3
| | | | | | | | | | | | | | | I really wanted to avoid getting into defining or parsing new file formats. However, using the entire power of Lua is not ideal, as described earlier in Konrad Hinsen's bug. In addition to everything else, it's a vector for arbitrary code execution when someone loads an untrusted image. I could use JSON, but it requires ugly string escaping. Seems cleaner to just use YAML. But YAML is complex and needs its own dependencies. If I'm going to do my own, might as well make the multi-line string format really clear. I can't yet write the new format.
* .Kartik K. Agaram2021-12-071-1/+1
|
* cleanerKartik K. Agaram2021-12-071-2/+2
|
* slightly improve experience on Konrad Hinsen's bugKartik K. Agaram2021-12-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Steps to reproduce: * Run teliva with some app. * Press ctrl-e to edit the app. * Select some function. * Press ctrl-g and type in some Lua keyword like 'function' or 'while' (Since the first word in a function is often 'function', it becomes the default if you press ctrl-g immediately after entering the editor for a function.) * Type nothing. Run the app. Desired behavior: app continues to run. The definition for the keyword is silently ignored (in future we may want to provide an error message) Behavior before this commit: app silently exited with non-zero status, and refused to restart thereafter until the .tlv file was manually edited to delete the definition for the Lua keyword. Behavior after this commit: app throws an error message like these: * For `function`: ``` src/teliva: x.tlv:99: '(' expected near '=' sorry, you'll need to edit the image directly. press any key to exit. ``` * For `while`: ``` src/teliva: x.tlv:99: unexpected symbol near 'while' sorry, you'll need to edit the image directly. press any key to exit. ``` You still need to edit the .tlv file manually, but the steps for recovery are a bit more discoverable. To fix this properly I also need to fix a looming security hole I've been thinking about for some time. The long-term goal of Teliva is to put the human running apps in control of what they do, by sandboxing accesses to the file system, network and so on. However, even after we build gates on all of Lua's standard libraries, we're still parsing .tlv files as Lua, with all of its power available. Solution: load .tlv files as some sort of JSON-like subset of Lua. Maybe I should just use JSON, and rely on code that's already in Teliva, even if I'm introducing a new notation in the process.
* fix colors in startup errorsKartik K. Agaram2021-12-061-0/+1
|
* slightly more obvious menu copyKartik K. Agaram2021-12-061-4/+21
| | | | Still sucks, though..
* more configurable colorsKartik K. Agaram2021-12-061-18/+20
| | | | | Also start using 256 colors, under the assumption most people will have them.
* grey rather than harsh white backgroundKartik K. Agaram2021-12-041-2/+2
|
* start showing call stack on errorsKartik K. Agaram2021-12-041-19/+54
| | | | | | | | It turns out Lua has been providing us this information all along! I'd just not created the space on screen to show it. Make it persist better. Kilo now no longer tracks its own status messages, which is a regression in a rare condition.
generated by cgit-pink 1.4.1-2-gfad0 (git 2.36.2.497.gbbea4dcf42) at 2024-11-14 22:54:23 +0000