| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
My transform pipeline ignores empty recipes, but when I specialized
shape-shifting ones I forgot that check.
|
| |
|
|
|
| |
I was finding it hard to wrap around the directionality of calls with
'lhs' and 'rhs'. Seems to work better with 'to' and 'from'. Let's see.
|
| |
|
|
|
|
|
|
|
|
| |
Reading http://www.jonathanturner.org/2016/01/rust-and-blub-paradox.html,
I realize there's nothing currently stopping mu programs from taking a
unique (non-shared) address into a shared allocation, abandoning the
allocation and being left with an invalid address. No fix for this yet,
but let's try to minimize its effect by limiting lifetimes of unique
addresses. We really should only be using them to write to array or
container elements.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the one major refinement on the C programming model I'm planning
to introduce in mu. Instead of Rust's menagerie of pointer types and
static checking, I want to introduce just one new type, and use it to
perform ref-counting at runtime.
So far all we're doing is updating new's interface. The actual
ref-counting implementation is next.
One implication: I might sometimes need duplicate implementations for a
recipe with allocated vs vanilla addresses of the same type. So far it
seems I can get away with just always passing in allocated addresses;
the situations when you want to pass an unallocated address to a recipe
should be few and far between.
|
| |
|
|
| |
Thanks Caleb Couch.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- notes
bug in edit/ triggers in immutable but not master branch
bug triggered by changes to layer 059: we're finding an unspecialized call to 'length' in 'append_6'
hard to debug because trace isn't complete
just bring out the big hammer: use a new log file
length_2 from recipes.mu is not being deleted (bug #1)
so reload doesn't switch length to length_2 when variant_already_exists (bug #2)
so we end up saving in Recipe for a primitive ordinal
so no valid specialization is found for 'length' (bug #3)
why doesn't it trigger in a non-interactive scenario?
argh, wasn't checking for an empty line at end. ok, confidence restored.
|
| |
|
|
|
| |
Now I complain before running if a call somewhere doesn't line up with
its ingredients, or if no specialization can be made to match it.
|
| | |
|
| | |
|
| |
|
|
|
| |
More cleanup. Haven't bothered to figure out why the trace for
specialize_with_literal_4 is repeatedly perturbed.
|
| |
|
|
|
| |
Eliminate one of several hacky type-check helpers; they've been
proliferating lately.
|
| |
|
|
|
| |
'append' also implicitly calls 'to-text' unless there's a better
variant.
|
| |
|
|
|
|
|
| |
A long-standing question resolved: why specializations sometimes skipped
some names. Turns out cleanup is incomplete if Recipe_ordinal and Recipe
aren't exactly lined up with each other, and the early exit in
new_variant was breaking that constraint.
|
| | |
|
| | |
|
| |
|
|
|
| |
Requires carefully deleting specializations so that they can be
reintroduced each time.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Starting to leave debug prints around once again, just in case one of
them is worth promoting to the trace..
|
| |
|
|
| |
Yet another bugfix as I trace through the last session with Caleb.
|
| |
|
|
|
| |
Another little bit of polish: if a call doesn't do enough for a complete
specialization, show a decent error message and above all: don't die!
|
| |
|
|
|
|
| |
Fix the drawback in the previous commit: if an ingredient is just a
literal 0 we'll skip its type-checking and hope to map type ingredients
elsewhere.
|
| |
|
|
|
|
|
|
|
| |
I was failing to specialize calls containing literals. And then I had to
deal with whether literals should map to numbers or characters. (Answer:
both.)
One of the issues that still remains: shape-shifting recipes can't be
called with literals for addresses, even if it's 0.
|
| |
|
|
|
|
|
| |
What was I thinking with 2366?
Thanks Caleb Couch. It turned out we couldn't call shape-shifting
recipes inside the edit/ or sandbox/ apps.
|
| |
|
|
|
|
| |
Lessons with Caleb uncovered a problem with type ingredients: I can call
shape-shifting recipes like 'push' from the commandline but not inside
the edit/ or sandbox/ apps.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The rule is, an address ingredient is only modifiable if:
a) it's also a product
b) it's /contained-in some other ingredient+product
Only if an ingredient is a modifiable can you:
a) call get-address or index-address on it (the only way to write to it)
b) call other recipes that also return it in a product
I still don't check copies of the address. That's next.
Core mu passes this check, but none of the example apps do. edit/ and
sandbox/ are known to fail.
|
|
|
More evocative, less jargony.
|