| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I thought I needed these for this bouncing-ball demo:
def (bounce screen)
with (w (width screen)
h (height screen)
cx 16
cy 16
dx 12
dy 19)
while 1
clear screen
ring screen cx cy 16 3 5
cx += dx
cy += dy
when (or (cx > w) (cx < 0))
set dx 0-dx
when (or (cy > h) (cy < 0))
set dy 0-dy
for _ 0 (< _ 100) ++_ # delay
No matter how I adjusted the delay I couldn't get rid of the jitter. So
I built a double-buffered version:
(bounce2 . [def (bounce2 screen)
with (w (width screen)
h (height screen)
cx 16
cy 16
dx 12
dy 19
screen2 (new_screen (columns screen)
(lines screen)))
while 1
clear screen2
ring screen2 cx cy 16 3 5
cx += dx
cy += dy
when (or (cx > w) (cx < 0))
set dx 0-dx
when (or (cy > h) (cy < 0))
set dy 0-dy
blit screen2 screen
for _ 0 (< _ 100) ++_]) # delay
But it didn't make a difference! Turns out nothing will help you when
successive frames are too far apart. This is the correct tweak to
`bounce`:
- dx 12
- dy 19)
+ dx 1
+ dy (/ 19 12))
Still, we'll keep double-buffering around for the future.
|
| |
|
|
|
|
|
| |
Broken since commit c95648c96 on Jul 3.
Unclear what test to write for this. Should clear-stream check for NULL?
Should apply-clear?
|
| |
|
|
| |
Still no support for acute-angled control points.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
The Mu shell has no string literals, only streams. No random access,
only sequential access. But I've been playing fast and loose with its
read pointer until now. Hopefully things are cleaned up now.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
I can't reproduce the issue with the keyboard handler anymore :/
|
| | |
|
| |
|
|
|
| |
Turns out we don't need a special case for KVM.
https://qemu.readthedocs.io/en/latest/system/invocation.html
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
One error message gets a bit worse.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Still some gaps to track down.
|
| | |
|
| | |
|
| |
|
|
| |
We just need to support unary operators.
|
| |
|
|
| |
The at-head-of-list? is a really ugly hack, though.
|
| |
|
|
| |
We're now down to 4 failing tests. But these will require surgery.
|
| | |
|
| | |
|
| |
|
|
|
| |
Still a couple of failing tests before I switch gears to breaking down
symbols containing infix.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Like parenthesize, I'm copying tests over from https://github.com/akkartik/wart
Unlike parenthesize, though, I can't just transliterate the code itself.
Wart was operating on an intermediate AST representation. Here I'm all
the way down to cells. That seemed like a good idea when I embarked, but
now I'm not so sure. Operating with the right AST data structure allowed
me to more easily iterate over the elements of a list. The natural recursion
for cells is not a good fit.
This patch and the next couple is an interesting case study in what makes
Unix so effective. Yes, you have to play computer, and yes it gets verbose
and ugly. But just diff and patch go surprisingly far in helping build a
picture of the state space in my brain.
Then again, there's a steep gradient of skills here. There are people who
can visualize state spaces using diff and patch far better than me, and
people who can't do it as well as me. Nature, nurture, having different
priorities, whatever the reason. Giving some people just the right crutch
excludes others.
|
| | |
|
| |
|
|
| |
First step: undo operator support in tokenization.
|
| | |
|
| | |
|
| |
|
|
| |
The only remaining long lines now are in 'pair' and 'with'.
|
| | |
|