| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
| |
I dunno, this may all be a wild goose chase. I haven't been disciplined
in tagging in-out arguments in 'read-move' and its helpers. Maybe I
should just drop those 'nochange' oargs in 'read' and 'write'. Maybe I
should reserve output args only for return values that callers might
actually care about, and use more conventional metadata like 'const' or
'unique' or 'inout' on other args.
|
| |
|
|
|
|
|
|
|
|
|
| |
I just did this in 611; what's the point of all this if tests can't stay
passing?
I don't understand why buffered-stdin.mu needs to preempt itself. stdin
and buffered-stdin somehow end up sharing a single circular buffer,
that's probably causing a race condition.
|
|
|
|
|
|
| |
2 bugs found:
a) Have to slurp the newlines.
b) Have to clear the line-buffer at the start of each line.
|
| |
|
| |
|
|
|
|
| |
Chessboard now *almost* handles backspace perfectly.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Shove the complexity of reading newlines as low as possible.
|
| |
|
|
|
|
|
|
| |
Shove the complexity of printing newlines as low as possible.
Definite instability in that one trace.
|
|
|
|
|
|
|
|
|
|
| |
We need the hack of printing characters typed to screen right after we
see them. But only when it's the real screen. And there's no way to
write a test for that because it explicitly shouldn't happen for fake
terminals :(
Never mind, we'll be able to test it when we provide some mechanism for
suppressing print. The equivalent of 'stty -echo'.
|
|
|
|
|
| |
Still surprisingly hard to debug. We might be barking up the wrong tree.
Or we might just need to lump it. System software is hard.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Use asynchronous channels like 'stdin' for most tests.
Use the synchronous fakes for testing low-level stdin helpers.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Also cleaned up much of the mess in 594.
|
|
|
|
|
|
| |
I'd caused a bug in Arc: https://github.com/arclanguage/anarki/commit/97b3464256
Almost done interrupting and restarting routines.
|
| |
|
| |
|
|
|
|
|
| |
I don't remember what exactly we wanted to test in the second move.
But we can write it next time we need it.
|
| |
|
| |
|
|
|
|
|
| |
Now that there isn't a stdout channel we can postpone the test showing
the need to flush-stdout before clearing screen.
|
| |
|
|
|
|
| |
Dump yet another trying-to-be-polymorphic function.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Also clean up various prints from last few commits.
As a convention, for debugging we always print directly to host.
|
|
|
|
|
|
|
|
| |
I discovered the problem when playing more than 3 moves in the
chessboard app.
But it turns out we've been clobbering each other willy-nilly even in
the chessboard-retro app.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This requires creating a new data structure called buffer, because
strings are too inefficient for appending to, and we need to know how
long they need to be before we clear them.
But I'm not gonna bother to write tests for all the new primitives I
just introduced, because that's not expedient.
One test for mu is how nicely it handles situations like this without
requiring perfect test hygiene. In this case, I can imagine tools that
will extract tests for a particular function out of all known tests.
Especially if it's a pure function that should be easy. Then just show
each test to the programmer and ask him to give it a reasonable name.
|
|
|
|
|
|
|
| |
Minimize use of 'unless' forms, they're harder to follow.
Also, using one-sided checks like greater-or-equal or lesser-or-equal is
more defensive.
|
| |
|
|
|
|
| |
Feeling more confident now that prints are being managed right.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This will let me swap in a fake in tests.
Still hacky, though. I'm sure I'm not managing the parameter right in
the chessboard app.
And then there's the question of whether it should also appear as an
output operand.
But it's a start. And using nil to mean 'real' is a reasonable
convention.
If I ever need to handle multiple screens perhaps we'll have to switch
to 1:literal/terminal and 2:literal/terminal, etc. But those are equally
easy to guard on.
|