Without this there's no way to convert an int to a byte. And that feels
too restrictive, and gives up a lot of safe things one might want to do
with bytes. (Such as divide a number by 10 and emit the remainder as a
byte.)
I've wrestled for a long time with how to support integer division with
its hard-coded registers. The answer's always been staring me in the face:
just turn it into a function! We already expect function outputs to go
to hard-coded registers.
Minor tweaks to get Mu shell running nicely on a Linux console atop Qemu.
We also need to switch a few 256-color codes to 8-color mode. I'm not
sure whether/how to patch the repo for those.
Both manual tests described in commit 7222 now work.
To make them work I had to figure out how to copy a file. It
requires a dependency on a new syscall: lseek.
Ok, I found a failing manual test for files as well.
Here are the two steelman tests, one for screens and one for files:
1.
5 5 fake-screen =s
s 1 down 1 right
ctrl-d foo
expand
final state:
s foo foo
s 1 down 1 right ⇗
┌─────┐ ┌─────┐
┌─────┐ 1 ┌─────┐ 1 ┌─────┐ │
┌─────┐ │ ┌─────┐ │ ─
│ │
│ │
─
└─────┘ └─────┘
└─────┘ └─────┘ └─────┘
└─────┘ └─────┘
2.
"x" open =f
f read f read
ctrl-d read2
expand
final state:
f read2 read2
f read f read ⇗
FILE ❝def❞
FILE ❝abc❞ FILE ❝❞
❝def❞ ❝ghi❞
In both cases there are 3 levels of issues:
- getting a single-line expression to work
- getting a single-line expression to work when operating on a binding
defined in a previous line
- getting an expanded function call to work
The third is where the rub is right now. And what both examples above share
is that the function performs 2 mutations to the screen/file.
So we need a deep copy after all. And it's not very clear how to copy a
file descriptor including the seek location. Linux's dup() syscall creates
an alias to the file descriptor. And opening /proc seems awfully Linux-specific:
https://stackoverflow.com/questions/54727231/duplicating-file-descriptor-and-seeking-through-both-of-them-independently/54727424#54727424
Even this isn't enough. While shallow copies keep us from transferring
new bindings to callers, the screen object is still the same, so mutations
to bindings are contagious.
Basically I'm losing IQ points from programming in a language that encourages
mutation over copying.
This bug was incredibly painful to track down: the one-line fix is to replace
'line' with 'first-line' in the call to 'evaluate' in render-line before
recursing.
Things that made it challenging:
- A high degree of coiling with recursive calls and multiple places of
evaluation.
- An accidental aliasing in bindings (when rendering the main column in
render-line) that masked the underlying bug and made things seem to work
most of the time.
- Too many fucking arguments to render-line, a maze of twisty line objects
all alike.
Attempt #3: always create a copy of the bindings before each column/evaluate.
The details are fuzzy in my head, but it seemed worth trying. I figured
I'd either see the old duplication behavior or everything will work. Instead
I'm seeing new problems.
commit 7208:
5 5 fake-screen =s
s 1 down 1 right
expected:
|
-
observed:
|
|
-
commit 7210-7212:
5 5 fake-screen =s
s 1 down 1 right
[define foo]
s foo
[expand foo]
observed: no bindings available when rendering foo expanded
commit 7213:
5 5 fake-screen =s
s 1 down 1 right
[define foo]
s foo
[expand foo]
expected within foo:
|
-
observed within foo:
|
|
-
commit 7215:
5 5 fake-screen =s
s 1 down 1 right
[define foo]
s foo
[expand foo]
observed: no bindings available when rendering foo expanded
Turns out even that doesn't work.
There are two distinct use cases here:
1. Keeping columns from infecting each other.
2. Expanding function calls.
Perhaps ping-ponging between them is a sign I need tests.
It turns out deciding when to initialize the table of bindings is quite
a thorny problem in the presence of function calls (since they need their
args bound). In time I should probably support a linked list of tables.
For now I'll just continue to reuse tables, but perform lookups in reverse
order so that the correct binding is always returned.
Only the final line shows the stack for now. No way to move cursor back
up.
One bug I'm noticing: creating a screen on one line and then reusing it
in a second causes operations to be performed multiple times.
We can copy non-zero literals only to non-addr non-offset scalars.
This change is surprisingly short for the magnitude of the limb I felt
myself going out on for it. Surprising that there were no unpleasant discoveries.
More bugfixes, now all apps are working.
In the process of fixing the bugs in translating apps/browse, I found a
typo in apps/tile that just happened to accidentally be compiling fine.
2 new tests:
test-return-unavailable-value - currently failing
test-convert-return-with-duplicate-values - currently passing
I don't yet know how to make both pass.
This isn't done, but an intermediate snapshot seems worth capturing.
Back in March (commit 6082), I made a plan to check writes to function
outputs using liveness analysis. I've been shying away from actually acting
on this plan ever since. In recent weeks I've had this gap bite me three
times.
Returning to the problem now, I think I don't actually need to compute
variable liveness. The compiler can, I think, do the same thing for output
registers whether their variables are alive or dead. The new rule is this:
Once a register gets a function output written to it, no local is popped
into it. Instead of popping outer locals to the register, we simply increment
the stack and keep going.
Since the function output will continue to live on the vars stack past
this point (see clean-up-block), any attempts to read shadowed variables
will throw an error as usual.
This rule is also now easy to explain to people, I think. "You wrote the
function output. Now the register can't be used for anything else."
It's really cool that this works (if it does). Another fruit from "Mu's
lovely property."
Amazing how easy this was. And it does feel more intuitive. If I decide
at some point that I want to bind something to a name I don't usually want
to lose the entire line after that point.
It also sidesteps for now the thorny question of whether to permit organically
switching to a new line (rather than using the 'name value' hotkey), and
how that should work.
Some more helpers that I want to avoid using, but they help me gain confidence
in the current implementation of file handles. Manual test:
"x" open dup read swap read
Assumes there's a file called `x` in the current directory that contains
at least two (short!) lines.
Turns out I've been including some unnecessary files when building apps/mu!
Treeshaken stats before:
LoC 26258 => 9717
LoC including common libraries: 29736 => 12719
binary size: 406K => 79K
After:
LoC 26258 => 9717
LoC including common libraries: 28322 => 12370
binary size: 406K => 77K
So our treeshaking isn't perfect. No surprise there..
The treeshaken build also starts to fail without the one-liner change to
mu.subx, which looks like a bug in the treeshaker.
Cursor now updating right.
Still a couple of bugs:
ctrl-e doesn't know about multiple lines
function calls don't expand right in multi-line sandboxes
(but at least I'm now getting to see them in action!)
Ok, I think we may finally be done crushing all the pesky bugs.
And now we can insert and delete words in the middle of a line, and have
expanded calls stay stable!
Kartik Agaram