| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
Drop pending tests for the old plan of liveness analysis.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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."
|
|
|
|
| |
Am I starting to have too much code duplication?
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Lots of copy-pasta.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Hacking on apps has created some urgency now for several additional safety
checks.
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
More consistent spacing in sandbox render.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
Starting to polish 'line-count' demo:
filename line-count
= filename open lines len
|
|
|
|
| |
Requires a quick hacky change to Mu compiler.
|
|
|
|
|
| |
Stack display is messed up when file contents contain newlines. Ignoring
that for now.
|
| |
|
| |
|
|
|
|
| |
We really need to clean up the Mu compiler's logic around function outputs.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|