about summary refs log tree commit diff stats
path: root/shell/trace.mu
Commit message (Collapse)AuthorAgeFilesLines
* .Kartik K. Agaram2021-06-041-1/+1
|
* .Kartik K. Agaram2021-06-041-0/+2
| | | | Menu shortcut for jumping to function definition.
* .Kartik K. Agaram2021-06-041-3/+3
|
* .Kartik K. Agaram2021-06-041-3/+3
| | | | Keep hotkeys stable when different elements are in focus.
* .Kartik K. Agaram2021-06-031-4/+3
|
* shell: more stable trace when rerunningKartik K. Agaram2021-06-021-2/+138
|
* .Kartik K. Agaram2021-06-021-2/+2
|
* bugfix for disappearing traceKartik K. Agaram2021-05-311-0/+2
| | | | | | | | It turns out I have a problem with trace depth somewhere which I just wasn't noticing before. Running certain sandboxes (line; maybe loops?) twice was causing traces to no longer start at depth 1, which implies that they weren't terminating at depth 1. This became a lot more obvious since I instituted a max-depth.
* bugfix: unbound variables were not raising errorKartik K. Agaram2021-05-301-0/+14
| | | | | Since we switched error trace semantics from a designated label to a designated depth (commit 9831a8cef9 on May 19).
* first test re-running sandbox with a deeper traceKartik K. Agaram2021-05-301-0/+1
|
* first attempt doesn't workKartik K. Agaram2021-05-301-0/+29
| | | | | | I was aware of some complications. The various indexes and y coordinates in the trace's cache would be unstable and need to be recomputed. But it's surprising that the trace _completely disappears_.
* .Kartik K. Agaram2021-05-291-4/+45
|
* .Kartik K. Agaram2021-05-291-82/+54
|
* shell: scrolling the traceKartik K. Agaram2021-05-291-3/+209
|
* shell: skeleton for scrollingKartik K. Agaram2021-05-291-2/+28
|
* cache visibility for all lines in traceKartik K. Agaram2021-05-291-15/+35
| | | | | | So far we were only doing so for the first few lines, just enough to render one page's worth of lines. We'd have probably noticed if we collapsed some lines after re-evaluating.
* .Kartik K. Agaram2021-05-291-4/+5
|
* .Kartik K. Agaram2021-05-291-1/+1
|
* .Kartik K. Agaram2021-05-291-1/+1
|
* .Kartik K. Agaram2021-05-291-1/+1
|
* shell: start implementing scrolling in the traceKartik K. Agaram2021-05-291-0/+1
| | | | | | | | | | | | | I've been stymied for a week wondering how to reliably compute trace-line identity. A trace can have multiple identical lines. Only some of them may be visible at any point. How to remember which is which across re-evaluations? There's no easy answer. I'm just going to keep things ad hoc. When you re-evaluate, new lines can currently pop into visibility. However we guarantee that just moving around the trace will be stable, thanks to the visible bit being cached within each trace-line. Scrolling will be similar. Reevaluating may cause the trace to be perturbed up or down. However, just scrolling around will work reliably.
* .Kartik K. Agaram2021-05-231-5/+9
| | | | slightly improve colors
* ctrl-s in trace: show entire current lineKartik K. Agaram2021-05-231-7/+55
|
* .Kartik K. Agaram2021-05-231-1/+1
|
* disable ctrl-s when browsing traceKartik K. Agaram2021-05-231-4/+6
| | | | | We're soon going to be dynamically rerunning the sandbox in other ways when browsing the trace.
* shrink trace menuKartik K. Agaram2021-05-231-8/+2
|
* start truncating trace linesKartik K. Agaram2021-05-231-1/+1
|
* shell: reduce trace depth in sandboxKartik K. Agaram2021-05-221-0/+16
| | | | We'll gradually make this more dynamic.
* disallow null tracesKartik K. Agaram2021-05-191-12/+57
| | | | | | We now use traces everywhere for error-checking. Null traces introduce the possibility of changing a functions error response, and therefore its semantics.
* .Kartik K. Agaram2021-05-191-6/+6
|
* shell: traces track a maximum depth to recordKartik K. Agaram2021-05-191-29/+40
|
* shell: depth 0 as the check for errorsKartik K. Agaram2021-05-191-14/+17
|
* shell: start traces at depth 1 rather than 0Kartik K. Agaram2021-05-191-57/+59
| | | | We're going to carve out depth 0 for errors.
* first passing test for macroexpandKartik K. Agaram2021-05-061-1/+32
| | | | | | | | In the process I spent a long time tracking down a stray TODO in 108write.subx that I thought would abort but didn't since the switch to baremetal. Then after I reintroduced that assertion I had to go track down a bunch of buffer sizes. Stream sizes continue to be a huge mess.
* .Kartik K. Agaram2021-05-011-1/+1
| | | | Clean up menus.
* .Kartik K. Agaram2021-05-011-3/+3
| | | | Clean up trace colors.
* move color scheme closer to Solarized darkKartik K. Agaram2021-05-011-14/+14
| | | | | | | | | | | | | sed -i 's,0x12/bg=almost-black,0xdc/bg=green-bg,g' shell/*.mu sed -i 's, 0/bg, 0xc5/bg=blue-bg,g' shell/*.mu sed -i 's, 7/fg=trace, 0x38/fg=trace,g' shell/*.mu sed -i 's, 7/bg=grey, 0x5c/bg=black,g' shell/*.mu Still a few issues. Thanks Adrian Cochrane and Zach DeCook. https://floss.social/@alcinnz/106152068473019933 https://social.librem.one/@zachdecook/106159988837603417
* shell: use ctrl-m rather than tab to bounce to traceKartik K. Agaram2021-04-251-1/+1
| | | | We'll save tab for inserting graphemes.
* better error message on trace overflowKartik K. Agaram2021-04-221-1/+8
|
* start cleaning up pixel graphicsKartik K. Agaram2021-04-191-24/+24
| | | | | | Filling pixels isn't a rare corner case. I'm going to switch to a dense rather than sparse representation for pixels, but callers will have to explicitly request the additional memory.
* shell: ctrl-r runs on real screen without a traceKartik K. Agaram2021-04-171-1/+3
| | | | | We run out of memory fairly early in the course of drawing a chessboard on the whole screen.
* shell: reenable the traceKartik K. Agaram2021-04-171-0/+12
| | | | | | | | | | | | | | We now have a couple of protections: - if we get close to running out of space in the trace we drop in an error - if we run out of space in the trace we stop trying to append - if there are errors we cancel future evaluations This is already much nicer. You can't do much on the Mu computer, but at least it gracefully gives up and shows its limitations. On my computer the Mu shell tries to run computations for about 20s before giving up. That seems at the outer limit of what interactivity supports. If things take too long, test smaller chunks.
* shell: start jumping to keyboard using TabKartik K. Agaram2021-04-101-2/+2
|
* support for arrow keysKartik K. Agaram2021-04-051-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Mu's keyboard handling is currently a bit of a mess, and this commit might be a bad idea. Ideally keyboards would return Unicode. Currently Mu returns single bytes. Mostly ASCII. No support for international keyboards yet. ASCII and Unicode have some keyboard scancodes grandfathered in, that don't really make sense for data transmission. Like backspace and delete. However, other keyboard scancodes don't have any place in Unicode. Including arrow keys. So Mu carves out an exception to Unicode for arrow keys. We'll place the arrow keys in a part of Unicode that is set aside for implementation-defined behavior (https://en.wikipedia.org/wiki/C0_and_C1_control_codes#C1_controls): 0x80: left arrow 0x81: down arrow 0x82: up arrow 0x83: right arrow The order is same as hjkl for mnemonic convenience. I'd _really_ to follow someone else's cannibalization here. If I find one later, I'll switch to it. Applications that blindly assume the keyboard generates Unicode will have a bad time. Events like backspace, delete and arrow keys are intended to be processed early and should not be in text. With a little luck I won't need to modify this convention when I support international keyboards.
* get rid of ctrl-d/ctrl-u when browsing traceKartik K. Agaram2021-03-081-42/+26
| | | | Also clean up the menu. Mode-specific stuff goes after Tab.
* Add j/k keybindings for navigating traceMax Bernstein2021-03-081-0/+16
| | | | These are familiar for Vim users.
* 7866Kartik Agaram2021-03-071-6/+6
|
* 7864 - shell: clean up the trace some moreKartik K. Agaram2021-03-071-0/+5
|
* 7857 - shell: first function callKartik K. Agaram2021-03-051-0/+30
|
* 7853Kartik K. Agaram2021-03-051-1/+88
|
generated by cgit-pink 1.4.1-2-gfad0 (git 2.36.2.497.gbbea4dcf42) at 2024-11-16 11:48:07 +0000