You can now call 'def' on a function name multiple times. Each time the
instructions you provide are *prepended* to any existing instructions.
One important use for this is when you define a new type and need to
support it in all your generic methods. Now you can keep all those
extensions in one place, near the definition of the type.
To redefine a function, use 'def!'.
This pollutes our traces with all 'system software'. Too much trouble to
keep it out; just lump it for now. Who knows, might even be useful. Most
of the time convert* labels are easy to grep out when debugging.
Will the 'lightweight tools' really be all that useable if we encourage
people to layer them one atop another and track precisely what inputs
each can accept? Something to keep an eye on.
In the meanwhile, we have a new (but very unrealistic) example
demonstrating the tangling directives.
There's still a big constraint on ordering: before/after clauses have to
come before functions that need them.
This simplifies things a lot and eliminates the race condition.
I think it's practical too, as long as you save a single location and
don't permit sleeping on compound structures. I'm resigned to needing a
lock in the native setting.
Should I be concerned that I fixed a failing test by getting rid of hit?
If I had alternatives, how would I save the old sleep implementation?
Still failing, but worth memorializing for posterity.
Race condition tests are still experimental, even more tied to a very
specific implementation. If I make changes to 'write' the very
'wipe-read' label will go away.
But then you just delete all tests relying on stale labels and try to
think up new race conditions.
Also uncovered a bug in convert-braces, which helps see a simpler
close-offset. Instead of all that crap with first incrementing then
waiting for counter to return to 0, just wait for counter to go to -1.
What have we learned?
a) You can't detect deadlock between running a thread and waking up
sleeping threads -- you may miss threads that are about to become
available.
b) Most of the context-switching code in 'run' shouldn't assume
routine* is correctly set. That's just for 'run-for-time-slice' and
for checking on blocked threads. I was implicitly requiring it when I
shouldn't, and not setting it when checking blocked threads.
Before I fix the next failing test I want to write unit tests for a)
above.
'read' and 'write' pass in the channel by value, so they block on
different *local* variables.
Does this kill my plan to pervasively use call-by-value everywhere? No,
we might be able to salvage it if channels are the only shared pointers.
In trying to share pipes between routines, I realized my scheduler was
actually quite brittle. Changing scheduling-interval* shouldn't be
required in most tests, and shouldn't change the outcome most of the
time.
Current state: all scheduler tests fail, but everything else passes.
No oargs, though. Hopefully we don't need them. Use channels for
passing data back.
Drawback: channels must all be passed in by value, and their direction
isn't obvious. Hard to tell when multiple threads read/write the same
channel. Hopefully it's amenable to static analysis.
This radically overhauls our assumption that args must always be lists,
so we're probably missing things. Where we do, more tests are required.
Only important trace change: .traces/dummy-oarg
I've been using raw locations to make tests easy to read (test checks
the same locations that code modifies). But this means I have to manage
them myself, and I've been shoving variables into the storage for
compounds like tagged-value. Doesn't matter in this case since we don't
look at the contents of the tagged-value, but still unhygienic.
Maybe we need syntax for ignoring some output values?
