| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the process, some extra unit tests as well. The final scenario is newly fixed.
Between the earlier support for '%' escaping C code inside scenarios,
and the previous commit, we now actually have the ability to setup
the Routines data structure just so to simulate different situations.
One unanticipated but happy consequence of ignoring run(""): I can interleave
'+' lines with '-' lines to avoid making any ordering assertions between '+'
lines. So the '+' lines here are checked in order:
+layer1: a
+layer3: c
But here they will pass even if present out of order:
+layer1: a
-layer2: b
+layer3: c
This might be too confusing. In general, relying on run("") is just a temporary
hack. It might well have even worse counter-intuitive effects.
At least I'm not seeing any string-escaping issues so far.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Also our first test of printing to screen.
|
|
|
|
| |
Finally start tracing the actual instructions as they run.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
I've made some tweaks to the arc version. In/out params should be
identical; it was ugly that the in param was a pointer but the out
wasn't.
Still need to check the /same-as-ingredient property.
|
| |
|
|
|
|
| |
I think I have enough now to port channels over.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
Why did I think STL's map wasn't efficient? It has logarithmic
complexity (maintains a tree internally) and is faster than hashing for
small containers. It's the more portable solution and should be what I
turn to by default.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
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 :/
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|