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