| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
The old approach of ad hoc boosts and penalties based on various
features was repeatedly running into exceptions and bugs. New
organization: multiple tiered scores interleaved with tie-breaks. The
moment one tier yields one or more candidates, we stop scanning further
tiers. Just break ties and return.
|
| |
|
|
| |
More tweaking of traces as I debug recipe specialization.
|
| | |
|
| |
|
|
|
| |
Turns out we don't need to threshold non-shape-shifting and
shape-shifting variants at different levels to keep all tests passing.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When we stash a value, mu does several levels of work for us:
a) First it inserts instructions above the stash to convert the value to
text using to-text-line.
b) to-text-line calls to-text. Both are shape-shifting, so multiple
levels of specialization happen.
To give a good error message, we track the 'stack' of current
specializations at the time of the error, and also check if the
offending instruction at the top-most level looks like it was inserted
while rewriting stash instructions.
Manual example (since booleans can't be stashed at the moment):
x:boolean <- copy 1/true
stash x
|
| |
|
|
| |
Drop yet another source of perturbance in traces.
|
| |
|
|
| |
Pretty hacky fix: we simply suppress static dispatch for main.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
| |
Reorganize layers in preparation for a better, more type-safe
implementation of first-class and higher-order recipes.
|
| |
|
|
|
| |
I still need it in some situations because I have no way to set a
non-zero default for an optional ingredient. Open question..
|
| | |
|
| |
|
|
| |
Thanks Caleb Couch.
|
| |
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Ok, now I'm a little happier about our type checking. Type checking lies
in three layers:
layer 21: checking types, usually at run-time in the VM or just before
layer 57: checking type names
layer 59: checking type names
It's taken me the process of writing this commit to convince myself that
all three layers check mappings for literal values in a consistent
manner. Layer 21 uses sizes, and layers 57/59 have whitelists, but
either way the goal is that number != character != boolean unless
mediated through a literal.
|
| |
|
|
|
| |
'append' also implicitly calls 'to-text' unless there's a better
variant.
|
| |
|
|
| |
Literal '0' ingredients should map to numbers before addresses.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
This turned out to be surprisingly easy: rather than try to specify the
types expected by each operation, just have primitive instructions go
through any other variants and only remain unnamed if no variants pass.
All I had to do was stop using contains_key() anywhere on Recipe_variants,
so that I could use get_or_insert() rather than get().
|
| |
|
|
|
| |
Starting to leave debug prints around once again, just in case one of
them is worth promoting to the trace..
|
| |
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
| |
More evocative, less jargony.
|
| | |
|
| |
|
|
|
| |
One new issue: the traces for all tests are perturbed by the .mu files we
choose to load.
|
| |
|
|
|
| |
Fix that stray issue with a better phase ordering.
Another thing I'm not testing.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Got that idea to work with a special-case for 'new'. Requires parsing
new's first ingredient, performing the replacement, and then turning it
back into a string. I didn't want to replace NEW with ALLOCATE right
here, because then it messes with my invariant that transform should
never see a naked ALLOCATE.
Layer 11 still not working, but everything else is. Let's clean up
before we diagnose the new breakage.
|
| |
|
|
| |
Yup, type ingredients were taking size 1 by default.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
No, my idea was abortive. My new plan was to run no transforms for
generic recipes, and instead only run them on concrete specializations
as they're created.
The trouble with this approach is that new contains a type specification
in its ingredient which apparently needed to be transformed into an
allocate before specialization.
But no, how was that working? How was new computing size based on type
ingredients? It might have been wrong all along.
|
| | |
|
| |
|
|
| |
Layer 1 of edit/ is introducing spurious types, though.
|
| |
|
|
|
| |
I'd not paid any attention to it so far, but I need to do so from now
on.
|
| |
|
|
| |
Starting to leave commented out prints again out of desperation.
|
| |
|
|
|
|
|
|
| |
New assertions still failing during tests.
This whole implementation of generic recipes is like an extended spike.
I don't have nearly enough tests. Ideally I'd have confidence in
generics once layer 59 passed its tests.
|
| |
|
|
|
|
|
| |
Commands run:
$ sed -i 's/\([^. (]*\)\.find(\([^)]*\)) != [^.]*\.end()/contains_key(\1, \2)/g' 0[^0]*cc
$ sed -i 's/\([^. (]*\)\.find(\([^)]*\)) == [^.]*\.end()/!contains_key(\1, \2)/g' 0[^0]*cc
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I'm still seeing all sorts of failures in turning on layer 11 of edit/,
so I'm backing away and nailing down every culprit I run into. First up:
stop accidentally inserting empty objects into maps during lookups.
Commands run:
$ sed -i 's/\(Recipe_ordinal\|Recipe\|Type_ordinal\|Type\|Memory\)\[\([^]]*\)\] = \(.*\);/put(\1, \2, \3);/' 0[1-9]*
$ vi 075scenario_console.cc # manually fix up Memory[Memory[CONSOLE]]
$ sed -i 's/\(Memory\)\[\([^]]*\)\]/get_or_insert(\1, \2)/' 0[1-9]*
$ sed -i 's/\(Recipe_ordinal\|Type_ordinal\)\[\([^]]*\)\]/get(\1, \2)/' 0[1-9]*
$ sed -i 's/\(Recipe\|Type\)\[\([^]]*\)\]/get(\1, \2)/' 0[1-9]*
Now mu dies pretty quickly because of all the places I try to lookup a
missing value.
|
| |
|
|
|
| |
Not only can such recipes not have variants, their bodies too will be
oblivious to multiple variants or generics.
|
| | |
|
| |
|
|
|
|
|
| |
A new externality is starting to make its presence felt.
Until I sort this out it's going to be hard to finish making duplex-list
generic.
|