| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
Arc version is 15% faster (8.3s vs 9.9s for print-board test) if I use
an intermediate array rather than list. I'm starting to question the
whole tagged-value design, and the current tagged-value implementation
was treating squares as integers in one place anyway, so its benefits
for typing are not great. Might as well create a good baseline for the
Arc vs C++ performance test.
|
| |
|
|
|
| |
Still hacky, but now we can standardize the couple of different
workflows we need.
|
| | |
|
| |
|
|
|
| |
Now that we aren't loading system software for every test we can afford
to log the loading of test functions.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|