| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
|
| |
|
|
| |
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.)
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I thought I'd need to duplicate scenarios to simulate running some code,
making some checks, running some more code. But I can just keep saving
state to raw locations! I'd still have to manage raw locations myself,
though. And it can be ping-pongy to have to check on the other blocks
then go back to the run block. But what's the alternative? Multiple run
blocks (even excluding the implementation effort) raise questions of
namespace sharing across them.
If it gets too bad I can intersperse recipes inside the scenario. Yes,
that will work. Of course, overly long tests might themselves be a bad
idea. We'll see, this is all terra incognita syntactically speaking.
This might not be enough to check that a routine is waiting on a
channel, but should keep us until then. Wait, even there what you need
is a way to check on the status of your child routines. Yeah, doable.
Even if we're getting ahead of ourselves.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
We have tangled vs regular comments, but they highlight the same. So
we're still at 3 colors for comments. Anything more starts to seem
gratuitous.
|
| | |
|
| | |
|