All over the Mu code I reflexively initialize all variables just to keep
unsafe SubX easy to debug. However I don't really need to do this for safe
Mu code, since the type- and memory-safety already ensures we can't read
from streams beyond what we've written to them. For now I'll continue mostly
with the same approach, but with one exception for streams of bytes.
Mu programs often emit traces, and in doing so they often use temporary
streams of bytes that can get quite long. I'm hoping avoiding initializing
KBs of data all over the place will measurably speed up the Mu shell.
All highly experimental. Current constraints:
* No tail recursion elimination
* No heap reuse
* Keep implementation simple
So it's slow, and I don't want to complicate it to speed it up. So I'm
investing in affordances to help deal with the slowness. However, in the
process I've taken the clean abstraction of a trace ("all you need to do
is add to the trace") and bolted on call counts and debug-prints as independent
mechanisms.
Before: we always drew pixels atop characters, and we only drew pixels
that were explicitly requested.
After: we always draw pixels atop characters, and we only draw pixels that
don't have color 0.
Both semantics should be identical as long as pixels are never drawn atop
characters.
Even if they duplicate lower-level ones, we have an opportunity for better
error messages. Any time I see a hard-to-debug error message, I should
be asking myself, "what higher-level primitive should catch and improve
this error?"
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 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.
Is flush-ata-cache even needed? Reading the ATA 5 spec more closely, it
looks like it's only required by ATAPI devices! (Packet Interface is what
the 'PI' stands for!) And it's unclear if my driver actually supports ATAPI
at the moment.
Among other things, we turned off the trace to significantly speed up the
debug cycle.
State as of https://merveilles.town/@akkartik/106079258606146213
Ohhh, as I save the commit I notice a big problem: I've been editing the
disk image directly because writes to the Mu disk lose indentation. But
I've been forgetting that the state in the Mu disk needs to be pre-evaluated.
So function bindings need extra parens for the environment. The `pixel`
calls in the previous commit message are the first statement in the body,
and they aren't actually considered part of the body right now. No wonder
they don't run.
There are lots of other problems, but this will clarify a lot.
I tried building a function to draw a horizontal line across the screen.
Here's what I have in data.txt:
(
(globals . (
(horline . (fn () (screen y)
(horline_1 screen y 0 (width screen))))
(horline_1 . (fn () (screen y lo hi)
(if (>= lo hi)
()
((fn ()
(pixel screen lo y 12)
(horline_1 screen y (+ lo 1) hi))))))
))
(sandbox . (horline_1 screen 0 0 20))
)
$ dd if=/dev/zero of=data.img count=20160
$ cat data.txt |dd of=data.img conv=notrunc
$ ./translate shell/*.mu && qemu-system-i386 -hda disk.img -hdb data.img
Result: I can't call (horline screen 0) over a fake screen of width 40.
Some stream overflows somewhere after all the tweaks to various fixed-size
buffers scattered throughout the app. Calling horline_1 gets to a 'hi'
column of 20, but not to 30.
Kartik K. Agaram