| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
| |
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.
|