| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Forgot to run valgrind again. That triggered some trace cleanup as well.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Deduce operation id from name during transform rather than load, so that
earlier transforms have a chance to modify the name.
|
| | |
|
| | |
|
| |
|
|
| |
Forgot to run against valgrind.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
I checked these commands:
$ mu x.mu
$ grep "===" .traces/interactive
$ grep "===\|---" .traces/interactive
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
I've been growing lax on white-box testing when it's one of the three
big thrusts of this whole effort. Perhaps it was because I got too
obsessed with keeping traces stable and didn't notice that stable
doesn't mean "not changing". Or perhaps it's because I still don't have
a zoomable trace browser that can parse traces from disk. Or perhaps
$trace-browser is too clunky and discourages me from using it.
Regardless, I need to make the trace useable again before I work much
more on the next few rewriting transforms.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
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!)
|
| | |
|
| |
|
|
|
| |
I no longer have any null types! That raises confidence that I'm on the
right track.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
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).
|
| | |
|
| | |
|
| |
|
|
|
| |
As we perform type-checking earlier we'll delete these checks. But start
with type-checking at run-time.
|
| |
|
|
| |
Making life too complex at this time.
|
| |
|
|
| |
Bah, sick of CALL and continuations.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now dilated reagent parsing is much simpler.
We still can't parse nested hashes. We may never need that. For now the
syntax model is:
program = collection of top levels
top-level contains a list of lines
lines may be instructions
instructions have reagents
reagents can be in compressed or dilated syntax (or literal strings)
property values inside reagents can be s-expression trees
We balance {} inside top-levels, [] inside strings, and () inside
property values.
|
| |
|
|
|
|
|
| |
Make it easy to skip distracting valgrind errors when debugging more
obvious errors in early layers. Just throw a 'test' at the end of
build_and_test_until commands to not run valgrind (and make it a regular
test run).
|
| |
|
|
|
| |
Now we always consider words to be terminated at () and {}.
We also always skip commas.
|
| | |
|
| |
|
|
| |
Still trying to come up with clean lexing rules.
|