| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Each phase implicitly calls previous phases.
Most C++ scenarios implicitly call one, two or three of the phases.
More clear now that 'load' does more than just add recipes.
|
| | |
|
| |
|
|
|
| |
This first step is just stopping run() after a fixed number of
instructions. But the scheduler layer isn't done yet.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
There's a test in this commit, but it doesn't actually fail, because by
some accident the memory at index 2 of recipe 'f' has data at the
is_label offset and breaks out of the loop. Graah. How did I ever
misplace that "Reading One Instruction" waypoint? I could swear I was
concerned about this possibility when I implemented calls.
Today has been tough on my confidence. STL helps avoid memory leaks but
doesn't help with buffer overflows nearly as much as I thought.
Oh brilliant, valgrind caught the problem! And there weren't any others.
I feel much better.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Dump deprecated interface.
|
| |
|
|
| |
Reindent termbox.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. Drop the ability to run just some C++ tests. It's a lousy interface
to use line numbers, we can't selectively run mu tests, we haven't used
it in a while because our tests run plenty fast, and it's complicating
other parts, like Next_recipe_number and test space handling.
2. Create a new layer right up top to show the usage message and all the
different forms that are possible. Good for documentation until we come
up with a way to put the different forms in their own layers. At least
it's out of the test layer now.
3. Strengthen the assertion that no recipes exist in test space before
we start running any sorts of tests. Earlier it was possible for
files loaded explicitly to overflow into test space because we were
asserting before load, not after. Now we check if we need to run tests,
load all files, then make the assertion, run tests, and exit if
necessary.
Now we don't need to mess with commandline args at all in layer 50.
That's a sign that we're on the right track.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Reorganized commandline handling to perform test space assertion in just
one place at the right layer. Hopefully this issue will not bite us
again.
|
| |
|
|
|
|
|
|
|
|
| |
Move assertions about test space right before running all tests. (But
not before running *every* test.)
This is a good trip-wire, but it requires that we remember to set it in
any new code paths running tests.
Still one wart: layer 1 depends on layer 10.
|
| |
|
|
|
|
|
| |
Required still more tweaking of Recipe namespaces. Mindlessly inserting
setup() took a couple of hours to debug because the test function and
the function it was testing ended up getting the same recipe number,
with the inevitable infinite loop :/
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
My methodology of tracing and testing isn't intended to eliminate
undefined behavior. But mu will, eventually.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Instead of adding a third-level hack for the new bug (failing test) with
multiple directives, I'm giving up on deducing #line directives
directly. Instead I'm going to maintain the file and line for every
single line as I read it, and then emit directives on their basis as a
post-processing step. This way tangling itself can remain oblivious to
line numbers, even if we're passing objects around rather than naked
strings.
|
| | |
|
| |
|
|
| |
(Follow-up to 544.)
|
| | |
|
| | |
|
| | |
|