| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
Since we switched error trace semantics from a designated label to a designated
depth (commit 9831a8cef9 on May 19).
|
| | |
|
| |
|
|
|
|
| |
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_.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
slightly improve colors
|
| | |
|
| | |
|
| |
|
|
|
| |
We're soon going to be dynamically rerunning the sandbox in other ways
when browsing the trace.
|
| | |
|
| | |
|
| |
|
|
| |
We'll gradually make this more dynamic.
|
| |
|
|
|
|
| |
We now use traces everywhere for error-checking. Null traces introduce
the possibility of changing a functions error response, and therefore its
semantics.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
We're going to carve out depth 0 for errors.
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
Clean up menus.
|
| |
|
|
| |
Clean up trace colors.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
We'll save tab for inserting graphemes.
|
| | |
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
| |
We run out of memory fairly early in the course of drawing a chessboard
on the whole screen.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
Also clean up the menu. Mode-specific stuff goes after Tab.
|
| |
|
|
| |
These are familiar for Vim users.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|
|
Baremetal is now the default build target and therefore has its sources
at the top-level. Baremetal programs build using the phase-2 Mu toolchain
that requires a Linux kernel. This phase-2 codebase which used to be at
the top-level is now under the linux/ directory. Finally, the phase-2 toolchain,
while self-hosting, has a way to bootstrap from a C implementation, which
is now stored in linux/bootstrap. The bootstrap C implementation uses some
literate programming tools that are now in linux/bootstrap/tools.
So the whole thing has gotten inverted. Each directory should build one
artifact and include the main sources (along with standard library). Tools
used for building it are relegated to sub-directories, even though those
tools are often useful in their own right, and have had lots of interesting
programs written using them.
A couple of things have gotten dropped in this process:
- I had old ways to run on just a Linux kernel, or with a Soso kernel.
No more.
- I had some old tooling for running a single test at the cursor. I haven't
used that lately. Maybe I'll bring it back one day.
The reorg isn't done yet. Still to do:
- redo documentation everywhere. All the README files, all other markdown,
particularly vocabulary.md.
- clean up how-to-run comments at the start of programs everywhere
- rethink what to do with the html/ directory. Do we even want to keep
supporting it?
In spite of these shortcomings, all the scripts at the top-level, linux/
and linux/bootstrap are working. The names of the scripts also feel reasonable.
This is a good milestone to take stock at.
|