| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Thanks Maxwell Bernstein for pointing this out 🤦♂️
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It took me _way_ too long to realize that I'm not checking for errors within
the loop, and that will cause it to manifest as an infinite loop as inner
evaluations fail to run.
Debugging notes, for posterity:
printing one row of a chessboard pattern over fake screen (chessboard screen 4 0 0 15) gets stuck in an infinite loop halfway through
debug pattern during infinite loop: VWEX. It's still in the loop but it's not executing the body
raw (fill_rect screen 16 0 20 4 15) works fine
same number of calls to fill_rect work fine
replacing calls to fill_rect with pixel inside chessboard2 works fine
at the point of the infinite loop it's repeatedly going through the hline loop
-- BUT it never executes the check of the loop (< lo hi) with lo=20, hi=20. Something is returning 1, but it's not inside <
stream optimization is not implicated
simple test case with a single loop
(
(globals . (
(foo . (fn () (screen i n)
(while (< i n)
(pixel screen 4 4 i)
(pixel screen 5 4 i)
(pixel screen 6 4 i)
(pixel screen 7 4 i)
(set i (+ i 1)))))
))
(sandbox . (foo screen 0 100))
)
simpler (if you reset cursor position before every print):
(
(globals . (
(foo . (fn () (screen i n)
(while (< i n)
(print screen i)
(set i (+ i 1)))))
))
(sandbox . (foo screen 0 210))
)
I now believe it has nothing to do with the check. The check always works.
Sometimes no body is evaluated. And so the set has no effect.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
'def' creates new bindings (only in globals)
'set' only modifies existing bindings (either in env or globals)
|
| | |
|
| |
|
|
| |
I'm currently doing this extremely naively/slowly/uglily. Not a bottleneck.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(brline . (fn () (screen x0 y0 x1 y1 color)
((fn (dx dy sx sy)
((fn (err)
(brline1 screen x0 y0 x1 y1 dx dy sx sy err color))
(+ dx dy)))
(abs (- x1 x0))
(- 0 (abs (- y1 y0)))
(sgn (- x1 x0))
(sgn (- y1 y0)))))
(brline1 . (fn () (screen x y xmax ymax dx dy sx sy err color)
(pixel screen x y color)
(if (andf (= x xmax) (= y ymax))
()
((fn (e2)
(brline1 screen
(if (>= e2 dy)
(+ x sx)
x)
(if (<= e2 dx)
(+ y sy)
y)
xmax
ymax
dx
dy
sx
sy
(+ err
(+
(if (>= e2 dy)
dy
0)
(if (<= e2 dx)
dx
0)))
color))
(* err 2)))))
sandbox: (brline screen 1 1 5 5 12)
There are two ideas stemming from this commit:
- I need an extremely compact on-screen trace to underlie the trace UX
- perhaps we should start truncating trace lines
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
Disabled in commit 1354161a3, and then I forgot about them for a while.
|
| |
|
|
| |
It causes us to run out of memory during tests.
|
| | |
|
| | |
|
| |
|
|
|
| |
There are several things in the codebase right now that don't seem sustainable.
I need to take them out and bring them back in more gradually.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
We run out of memory fairly early in the course of drawing a chessboard
on the whole screen.
|
| | |
|
| |
|
|
| |
So far we aren't running out of memory. Might as well loosen our belts.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Current state of code in the Mu computer:
(
(globals . (
(hline1 . (fn () (screen y lo hi color)
(if (>= lo hi)
()
((fn ()
(pixel screen lo y color)
(hline1 screen y (+ lo 1) hi color))))))
(vline1 . (fn () (screen x lo hi color)
(if (>= lo hi)
()
((fn ()
(pixel screen x lo color)
(vline1 screen x (+ lo 1) hi color))))))
(hline . (fn () (screen y color)
(hline1 screen y 0 (width screen) color)))
(vline . (fn () (screen y color)
(vline1 screen y 0 (height screen) color)))
(andf . (fn () (a b)
(if a
(if b
1
())
())))
(brline . (fn () (screen x0 y0 x1 y1 color)
((fn (dx dy sx sy)
((fn (err)
(brline1 screen x0 y0 x1 y1 dx dy sx sy err color))
(+ dx dy)))
(abs (- x1 x0))
(- 0 (abs (- y1 y0)))
(sgn (- x1 x0))
(sgn (- y1 y0)))))
(brline1 . (fn () (screen x y xmax ymax dx dy sx sy err color)
(pixel screen x y color)
(if (andf (= x xmax) (= y ymax))
()
((fn (e2)
(brline1 screen
(if (>= e2 dy)
(+ x sx)
x)
(if (<= e2 dx)
(+ y sy)
y)
xmax
ymax
dx
dy
sx
sy
(+ err
(+
(if (>= e2 dy)
dy
0)
(if (<= e2 dx)
dx
0)))
color))
(* err 2)))))
(read_line_2 . (fn () (keyboard stream)
((fn (c)
(if (= c 10)
stream
(if (= c 0)
stream
(read_line_2 keyboard (write stream c)))))
(key keyboard))))
(read_line . (fn () (keyboard)
(read_line_2 keyboard (stream))))
(fill_rect . (fn () (screen x1 y1 x2 y2 fill_color)
(if (>= y1 y2)
()
((fn ()
(hline1 screen y1 x1 x2 fill_color)
(fill_rect screen x1 (+ y1 1) x2 y2 fill_color))))))
(chessboard . (fn () (screen px)
(chessboard1 screen px 0 15)))
(chessboard1 . (fn () (screen px y color)
(if (>= y (height screen))
()
((fn ()
(chessboard2 screen px y 0 color)
(chessboard1 screen px (+ y px) (- 15 color)))))))
(chessboard2 . (fn () (screen px y x color)
(if (>= x (width screen))
()
((fn ()
(fill_rect screen x y (+ x px) (+ y px) color)
(chessboard2 screen px y (+ x px) (- 15 color)))))))
))
(sandbox . (chessboard screen 8))
)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
When I edit disk images directly, it's easy to forget a pair of parens.
Then the first expression of the body never executes.
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
"Make sure to do a Cache Flush (ATA command 0xE7) after each write command
completes."
https://wiki.osdev.org/index.php?title=ATA_PIO_Mode&oldid=25664#Writing_28_bit_LBA
|
| | |
|
| | |
|
| |
|
|
|
|
| |
It only works because the part that's truncated is cleanly the sandbox.
I need better error-checking in `read`.
|