| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
More tweaking; edit/ still taking too long to test on Travis CI.
|
| |
|
|
|
|
|
|
|
| |
2943 almost worked; just a couple of tweaks:
a) Divide up the work a little more finely since we still timed out on
some jobs.
b) Use clang and valgrind when running apps as well.
|
| |
|
|
|
| |
I misunderstood what constitutes a job in Travis CI. Let's try this
again..
|
| |
|
|
|
| |
I'm already using grep and perl, bash is no worse, and it's *much* nicer
to work in than plain Bourne sh.
|
| |
|
|
| |
It easily exceeded the 50-minute timeout.
|
| | |
|
| | |
|
| |
|
|
| |
https://travis-ci.org/akkartik/mu
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Since I switched to a Mac laptop (commit 2725) I've been lax in running
test_all_layers because I have to ssh into a server and whatnot. I
should just get CI setup somewhere..
|
| |
|
|
| |
Can't believe I didn't run tests after 2932.
|
| |
|
|
|
|
|
| |
More consistent labeling of waypoints. Use types only when you need to
distinguish between function overloadings. Otherwise just use variable
names unless it's truly not apparent what they are (like that the result
is a recipe in "End Rewrite Instruction").
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Thanks Caleb for finding this. We'd been using sandboxes for so long, I
hadn't tried a null/0 screen/console in a while and somewhere down the
road Mu stopped matching 0 against concrete addresses.
|
| |
|
|
|
| |
This had been broken ever since 2854, because we can't write tests for
restore-snapshots at the moment.
|
| | |
|
| |
|
|
| |
Typo introduced in 2854.
|
| |
|
|
| |
Thanks Caleb Couch for showing the need for this check.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
A better primitive: manage refcounts for an assignment without actually
doing the assignment itself. This way we can add refcounts as a new,
independent bit of bookkeeping without littering early returns and
duplicate code paths.
(OCD: commit number.)
|
| | |
|
| |
|
|
|
|
|
| |
This commit covers instructions 'put', 'put-index' and 'maybe-convert'.
Next up are the harder ones: 'copy' and 'merge'. In these cases there's
a non-scalar being copied, and we need to figure out which locations
within it need to update their refcount.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Reorganize the 'address' layer and split it up before we start greatly
expanding them to manage refcounts in nested objects.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
It's a bit of a trade-off because we need to store copies of
container metadata in each reagent (to support shape-shifting
containers), and metadata is not lightweight and will get heavier. But
it'll become more unambiguously useful when we switch to a compiler.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
All code to be tangled at a label should be defined between two calls to
transform_all(). This property is trivially satisfied if a production
run only ever has one call to transform_all().
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This continues a line of thought sparked in commit 2831. I spent a while
trying to avoid calling size_of() at transform-time, but there's no
getting around the fact that translating names to addresses requires
knowing how much space they need.
This raised the question of what happens if the size of a container
changes after a recipe using it is already transformed. I could go down
the road of trying to detect such situations and redoing work, but that
massively goes against the grain of my original design, which assumed
that recipes don't get repeatedly transformed. Even though we call
transform_all() in every test, in a non-testing run we should be loading
all code and calling transform_all() just once to 'freeze-dry'
everything.
But even if we don't want to support multiple transforms it's worth
checking that they don't occur. This commit does so in just one
situation. There are likely others.
|
| |
|
|
|
|
|
| |
If you accidentally use a recipe name in an ingredient you usually get
an error because types don't match. But jumps need to be flexible enough
to support both addresses and booleans, so they were accepting recipe
literals as well. Now a useful error results.
|
| |
|
|
|
|
|
|
|
|
|
| |
Turns out we don't need a primitive to return an empty value of
arbitrary type. Just create it on the heap using 'new'.
But this uncovered *yet* another bug, sigh. When I specialize generic
functions I was running all transforms on the generated functions after
specialization completed. But there's one transform that includes code
from elsewhere. If such code included type-ingredients -- kaboom. Now
fixed and there's a test, so I've got that going for me which is nice.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Be more consistent that 'return' is the name of the instruction, and
'reply' just a synonym. Maybe I should take it out. It wouldn't affect
the recipe/ingredient terminology while I teach..
|