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!
snapshot: migrating call-path to store word handles rather than word indexes.
ctrl-a and ctrl-e are segfaulting. There are likely other problems.
The major new change here is that allocating a call-path-element no longer
initializes it.
I just needed to remove an obsolete guardrail in render-line.
Still seeing some bugs with left-arrow when playing around with the full
expansion of `1 2+`.
Starting to work. I'm still seeing problems in lines with multiple expanded
calls, but perhaps that's a rendering issue.
The code is absolutely ghastly.
Rendering is still ugly. Cursor isn't on the right row. But the hard part
is behind us.
This was a stupid mistake in function-body, and it happened because I've
been getting lazy and passing (addr handle) objects when I should be passing
in "constant" addr objects.
I'm not sure why I was so resistant to debugging by print here. I spent
3 days waffling about with this bug.
We don't have tests yet in the tile prototype, mostly because we don't
yet feel confident about what desired behavior should be. But it's still
helpful to have a non-interactive mode for tracking down segfaults.
Snapshot that requires a check in the Mu compiler.
Currently I don't spill a register if it could possibly be over-written
by a function output within. However, find-in-call-path is a good example
of where this constraint is too lenient and results in unsafe code. The
variable `curr` gets clobbered during loop update by the variable `match?`.
What's the answer? Perhaps we should ban all conditional updates to function
outputs? That'd be dashed inconvenient.
The final fix to the raytracing program involves rounding modes. It turns
out x86 processors round floats by default, unlike C which has trained
me to expect truncation. Rather than mess with the MXCSR register, I added
another instruction for truncation. Now milestone 3 emits perfectly correct
results.
The image is now visually indistinguishable from the baseline, though the
file isn't quite bit-for-bit correct.
I found 3 bugs:
a) I forgot to normalize the ray. After creating a helper to "automatically"
do it for me, it turns out said helper requires manually using.
b) I forgot to multiply by t at one place.
c) vec3-length was half-written.
For the umpteenth time, the bugs were all in the last place I looked. I
was worried about spending a lot of time transcribing `main` without any
feedback, but that turned out to be perfect.
Not yet right, but worth a snapshot just because it gives a cool result.
Here, try it out:
$ ./translate_mu_debug apps/raytracing/3.mu
$ ./a.elf > x.ppm
Now view x.ppm as an image.
In general, this was quite tedious to write. And a still-open question
is how to emit the progress bar to stderr. My options are to either duplicate
all my print-* functions (already proliferating) or add global variables
to Mu.
Move some implementation around for floating-point.
I originally thought I wouldn't bother supporting sigils like %xmm0. But
it turns out I need them to pass floats into SubX function calls. And it
turns out the sigils work fine for free.
For most of Mu's history we've selected between primitives based on types
just by checking whether a type is a literal or not. Now we've started
checking if it's a float as well. However, floats need one additional check:
the call site may have an (addr float) that is dereferenced.
The realization of commit 6916 means that we should be using jump-if-addr*
after comparing floats. Which is super ugly. Let's create aliases to them
called jump-if-float*.
Make a few tests more self-contained.
I'd prefer to just run a function called `setup` first thing on startup
and move this portion of convert-mu to it:
# initialize global data structures
c7 0/subop/copy *Next-block-index 1/imm32
8b/-> *Primitive-type-ids 0/r32/eax
89/<- *Type-id 0/r32/eax # stream-write
c7 0/subop/copy *_Program-functions 0/imm32
c7 0/subop/copy *_Program-functions->payload 0/imm32
c7 0/subop/copy *_Program-types 0/imm32
c7 0/subop/copy *_Program-types->payload 0/imm32
c7 0/subop/copy *_Program-signatures 0/imm32
c7 0/subop/copy *_Program-signatures->payload 0/imm32
However, this approach doesn't fix my run_one_test tooling.
Kartik Agaram