| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
| |
In the process we now support unicode in all mu strings!
|
| |
|
|
| |
Aaalmost there..
|
| |
|
|
| |
Fix messages on failed screen tests.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
Unclear if filtering by color is the best interface.
Adding the color attribute into the screen contents seems ugly.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
After like 40 seconds (because of the 120-column screen), but whatever.
The final bug was that clear-screen wasn't actually working right for
fake screens.
(The trace is too large for github, so I'm going to leave it out for
now.)
|
| | |
|
| |
|
|
| |
Drop the #$%# 'encapsulated' stack ADT.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I added one test to check that divide can return a float, then hacked at
the rippling failures across the entire entire codebase until all tests
pass. Now I need to look at the changes I made and see if there's a
system to them, identify other places that I missed, and figure out the
best way to cover all cases. I also need to show real rather than
encoded values in the traces, but I can't use value() inside reagent
methods because of the name clash with the member variable. So let's
take a snapshot before we attempt any refactoring. This was non-trivial
to get right.
Even if I convince myself that I've gotten it right, I might back this
all out if I can't easily *persuade others* that I've gotten it right.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
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 '[^ ]\['
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
All primitives now always write to all their products. If a product is
not used that's fine, but if an instruction seems to expect too many
products mu will complain.
In the process, many primitives can operate on more than two ingredients
where it seems intuitive. You can add or divide more than two numbers
together, copy or negate multiple corresponding locations, etc.
There's one remaining bit of ugliness. Some instructions like
get/get-address, index/index-address, wait-for-location, these can
unnecessarily load values from memory when they don't need to.
Useful vim commands:
%s/ingredients\[\([^\]]*\)\]/ingredients.at(\1)/gc
%s/products\[\([^\]]*\)\]/products.at(\1)/gc
.,$s/\[\(.\)]/.at(\1)/gc
|
| |
|
|
|
|
|
|
|
| |
Just to put all our new test primitives through their paces, and iron
out any kinks.
Just the one chessboard scenario is taking 1.5-2.5x all the tests we've
written so far. But we're starting from a faster baseline, that was the
point of the C++ port. I also have -O3 optimizations in my back-pocket.
|
|
|
I've tried to update the Readme, but there are at least a couple of issues.
|