| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |
|
|
|
| |
Deduce operation id from name during transform rather than load, so that
earlier transforms have a chance to modify the name.
|
| | |
|
| |
|
|
|
|
|
|
| |
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!)
|
| | |
|
| |
|
|
|
| |
Now we always consider words to be terminated at () and {}.
We also always skip commas.
|
| | |
|
| |
|
|
| |
Still trying to come up with clean lexing rules.
|
| | |
|
| |
|
|
|
| |
Switch format for tracing reagents in preparation for trees rather than
arrays of properties.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Current plan:
parsing {x: foo, y: bar} syntax for reagents
parsing s-expr syntax for properties
supporting reverse instructions (<-)
parsing s-expr syntax for recipe headers (recipe number number -> number)
static dispatch
generic functions
type-checking higher-order functions
type of delimited continuations? need more type information
First step is done, and the second partially so.
|
| |
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
| |
Follow-up to 2147, which switched transform_all to only run once, after
loading all layers.
|
| |
|
|
|
| |
This will let me create separate 'main' recipes at each layer so people
can interact with less featureful versions.
|
| | |
|
| |
|
|
|
| |
I ran into this inside 'reload' when I left a trailing comment at the
end of the editor.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Standardize test names.
|
| |
|
|
| |
Should be a little bit more mnemonic.
|
| |
|
|
| |
First step to reducing typing burden. Next step: inferring types.
|
| | |
|
| |
|
|
|
|
| |
A couple of times now I've accidentally named a scenario the same thing
as a recipe inside it that I define using 'run' or something. The
resulting infinite loop is invariably non-trivial to debug.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
| |
All tests passing, but early layers are broken.
|
| |
|
|
|
|
|
| |
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!
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Our new heuristic is: all string literals are the same. If they contain
newline before non-whitespace, we scan for comments assuming there might
be code inside:
foofoofoo [
... # ']' inside comment ignored
]
If they contain non-whitespace first, then we ignore comments assuming
it's just a regular string:
foofoofoo [abc#def] # valid string literal
The big hole in this approach:
foofoofoo [ # what about comments here containing ']'?
... # abc
]
Currently this reads as a 'code comment' and terminates before the
newline or '?' and will probably trigger errors down the line.
Temporary workaround: don't start code strings with a comment on the
same line as the '['. Eventually we'll tighten up the logic.
We're still not using the new heuristic in scenarios, but that's up
next.
|
| |
|
|
|
|
| |
Just figured out why a first keystroke of backspace was sending me out
for a spin: run_interactive needs all early exits that don't actually
run anything to increment the current_step_index(). FML, this is lousy..
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Required fixing two levels of bugs:
a) The hack in tangle to drop initial comments a '%' directive..
b) ..was masking a bug where run_mu_scenario wasn't robust to initial
comments.
Mildly concerned that neither of the sub-issues have their own tests,
but I'm just removing hacks, and writing tests for that throwaway
function like run_mu_scenario seems pointless. Instead I've solved the
problem by disallowing comments before '%' directives.
I've also taken this opportunity to at least try to document the
'scenarios' and '%' directives at the first layer where they appear.
|
| | |
|
| |
|
|
|
|
|
|
| |
Implement warnings for types without definitions without constraining
where type definitions must appear.
We also eliminate the anti-pattern where a change in layer 10 had its
test in layer 11 (commit 1383).
|
| | |
|
| | |
|
| |
|
|
| |
..now that we support non-integers.
|
| |
|
|
|
|
|
|
|
| |
Useful check:
$ grep "[^ '\"]\[[^\"]" *.cc \
|perl -pwe 's/\Wargv\[|\WTests\[|\Wframe\[|\WMemory\[|\WName\[|\WSurrounding_space\[|\WRecipe\[|\WType\[|\WRecipe_number\[|\WType_number\[|\WBefore_fragments\[|\WAfter_fragments\[//g' \
|perl -pwe 's/\Wargv\[|\WTests\[|\Wframe\[|\WMemory\[|\WName\[|\WSurrounding_space\[|\WRecipe\[|\WType\[|\WRecipe_number\[|\WType_number\[|\WBefore_fragments\[|\WAfter_fragments\[//g' \
|grep '[^ ]\['
|
| |
|
|
|
| |
No way to only insert code at a label in a specific recipe. Let's see
how that goes.
|
|
|
I've tried to update the Readme, but there are at least a couple of issues.
|