| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Fix a bug in phase ordering discovered while trying to stash cells in
the lambda compiler.
|
| |
|
|
| |
Fix CI.
|
| |
|
|
|
| |
Rewrite ingredients for 'trace' instructions just like 'stash'
instructions.
|
| |
|
|
|
|
|
|
|
| |
Thanks Stephen Malina for helping run into this hole in support for
compound types.
When I created that assert (commit 2381, Nov 2015) I was thinking only
of type ingredients, and didn't realize that compound types could have
internal nodes with zero values.
|
| |
|
|
|
| |
Manual tests for parse errors because scenarios can't handle assertion
failures yet.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Complicated logic to not run core tests. I only want to disable core
tests if:
a) I'm changing CFLAGS on the commandline (usually to disable
optimizations, causing tests to run slower in a debug cycle)
b) I'm not printing a help message (either with just 'mu' or
'mu --help')
c) I'm loading other files besides just the core.
Under these circumstances I only want to run tests in the files
explicitly loaded at the commandline.
This is all pretty hairy, in spite of my attempts to document it in
four different places. I might end up taking it all out the first time I
need to run core tests under all these conditions.
|
| | |
|
| |
|
|
| |
Parsing pairs of atoms.
|
| | |
|
| |
|
|
| |
Don't die if an instruction accidentally has too many products.
|
| | |
|
| |
|
|
|
| |
Reorganize parser to make room for parsing pairs. But first test for
pairs is still failing.
|
| |
|
|
| |
Handle multi-character atoms.
|
| |
|
|
| |
Degenerate 'parser' that handles just atoms of one character.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Reorganize data structure for lambda cells. Create our first real unit
test for the compiler in the process.
|
| |
|
|
|
|
| |
Bugfix: permit dummy product when trying to convert exclusive
containers. The 'status' product is still required, however. Without it
there's no point to calling 'maybe-convert'.
|
| |
|
|
| |
More accurate count of failing tests.
|
| |
|
|
|
| |
Nothing runs yet. Just spewing out code at this point, as a kind of
sketching.
|
| |
|
|
|
|
|
|
| |
Always show instruction before any transforms in error messages.
This is likely going to make some errors unclear because they *need* to
show the original instruction. But if we don't have tests for those
situations did they ever really work?
|
| |
|
|
|
|
|
| |
Warn if 'put' or 'put-index' has a mismatch in the type of the product,
not just the name. It won't do any harm, but could be misleading to a
later reader. In both instructions, the product is just for
documentation.
|
| |
|
|
|
| |
Failures in scenarios should consistently trigger the summary message
showing number of failed tests.
|
| | |
|
| | |
|
| |
|
|
| |
Fix CI.
|
| |
|
|
| |
Better error messages on missing traces in Mu scenarios.
|
| |
|
|
|
| |
$dump-trace had stopped working with an explicit layer. Thanks Jack and
Ella Couch.
|
| |
|
|
|
| |
Fix routine instruction count assignment to handle multi-slice scheduled
routines in the sandbox.
|
| |
|
|
|
| |
Show number of instructions in the editor when a
user clicks on a run instruction in the sandbox.
|
| | |
|
| |
|
|
|
| |
This was long overdue. Thanks Jack, Ella and Caleb Couch for repeatedly
asking for it.
|
| | |
|
| |
|
|
|
| |
In experiments on my laptop it seems to compile a little faster and run
slightly slower. Both might be in the noise.
|
| |
|
|
|
|
| |
Minor tweaks to 3105, primarily using more distinctive locations in the
unit test. 1, 2 and 3 can mean so many different things, they don't
catch the eye as much.
|
| |\
| |
| | |
3105
|
| |/
|
|
| |
Add number-of-instructions recipe to Mu
|