| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
| |
Now that we aren't loading system software for every test we can afford
to log the loading of test functions.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
For now we want to parse two labels:
'run', identifying call stack, op and args
'mem', distinguishing reads and writes
This should give us fodder for a few weeks, to build both a folding UI
for individual statements and descending the call stack, and also a
query engine that can figure out sources and sinks in the trace graph.
|
| |
|
|
| |
Typo in a recent test.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
(Another attempt at 623.)
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 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.
|
| |
|
|
| |
Chessboard now *almost* handles backspace perfectly.
|
| |
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
| |
Each clause creates its own default-space for local variables.
Now we can justify prepending bodies on every 'function' form.
Later we can optimize away the duplicate default-spaces.
Another cost: we can't mindlessly use 'next-input' anymore. Pity.
|
| | |
|
| |
|
|
| |
Tests for terminating when there's just helpers left.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Fork syntax is now: fork <function> [global space] [max cycle limit] args*
|
| | |
|
| |
|
|
|
| |
Disquieting that I can't make each of these five tests fail in
isolation. We have to fix them all at once.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Still no reason uncovered to avoid non-pointers.
|
| |
|
|
|
|
|
| |
I could swear there was an issue earlier where tagged-values had to
contain pointers for some core function. But I can't find it anymore.
Ok, assume we can store primitives in it and pointers only for
aggregates (and-records and arrays).
|