| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
Once a student has gotten used to recipes and ingredients using the
staged 'next-ingredient' approach there's no reason to avoid
conventional function headers. As an added bonus we can now:
a) check that all 'reply' instructions in a recipe are consistent
b) deduce what to reply without needing to say so everytime
c) start thinking about type parameters for recipes (generic functions!)
|
| |
|
|
|
|
|
|
|
|
| |
Still very incomplete:
a) we perform the check at runtime
b) tests for edit and sandbox apps no longer work; we can't fix them
until we get type parameters in both containers and recipes (because
list and list operations need to become generic).
|
| | |
|
| |
|
|
|
|
|
| |
At the lowest level I'm reluctantly starting to see the need for errors
that stop the program in its tracks. Only way to avoid memory corruption
and security issues. But beyond that core I still want to be as lenient
as possible at higher levels of abstraction.
|
| |
|
|
|
| |
Now duplex-list is fully non-generic and only works with characters. But
we'll fix that in a bit..
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
I'm sick of using the 'replace-in-console' hack.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Finally terminate the experiment of keeping debug prints around. I'm
also going to give up on maintaining counts.
What we really need is two kinds of tracing:
a) For tests, just the domain-specific facts, organized by labels.
b) For debugging, just transient dumps to stdout.
b) only works if stdout is clean by default.
Hmm, I think this means 'stash' should be the transient kind of trace.
|
| |
|
|
|
|
|
|
|
| |
More verbose, but it saves trouble when debugging; there's never
something you thought should be traced but just never came out the other
end.
Also got rid of fatal errors entirely. Everything's a warning now, and
code after a warning isn't guaranteed to run.
|
| |
|
|
|
|
|
| |
It comes up pretty early in the codebase, but hopefully won't come up
in the mu level until we get to higher-order recipes. Potentially
intimidating name, but such prime real estate with no confusing
overloadings in other projects!
|
| |
|
|
|
| |
Requires better support for special variable names in scenarios like
'screen' and 'console'.
|
| |
|
|
|
|
|
|
| |
This takes away the need for multi-level escaping in scenario setup.
Post-conditions like screen-should-contain are still an issue, though.
Maybe each string literal should be able to specify escapes inside its
syntax? Or at a per-instruction granularity?
|
| | |
|
| |
|
|
|
|
| |
First, undo our existing hacky pseudo-support.
Some repl tests currently breaking.
|
| | |
|
| |
|
|
|
|
|
|
| |
repl.mu now passing again. But still I have concerns:
a) Doubling backslashes in tests. Hard to tell how many levels to add.
b) I think the read-key interface needs to go. But then how do we handle
send-keys-to-channel and other flows like that in the chessboard app?
|
|
|
Only core layers currently passing. Console apps are probably still
broken.
|