| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
| |
We want to use the type 'recipe' for recipe *variables*, because it
seems nicer to say `recipe number -> number` rather than recipe-ordinal,
etc. To support this we'll allow recipe names to be mentioned without
any type.
This might make a couple of places in this commit more brittle. I'm
dropping error messages, causing them to not happen in some situations.
Maybe I should just bite the bullet and require an explicit
:recipe-literal. We'll see.
|
| |
|
|
| |
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.
|
| | |
|
| |
|
|
|
| |
/raw is to express absolute addresses
/unsafe is to sidestep type-checking in test setup
|
| |
|
|
|
|
|
|
| |
Not entirely happy with this. Maybe we'll find a better name. But at
least it's an improvement.
One part I *am* happy with is renaming string-replace to replace,
string-append to append, etc. Overdue, now that we have static dispatch.
|
| |
|
|
|
| |
Requires carefully deleting specializations so that they can be
reintroduced each time.
|
| |
|
|
|
|
|
|
|
| |
This is happening because of our recent generic changes, which trigger
some post-processing transforms on all recipes even if we processed them
before. We could clear 'interactive' inside 'reload' to avoid this, but
random 'run' blocks in scenarios can still pick up errors from sandboxes
earlier in a scenario. The right place to clear the 'interactive' recipe
is right after we use it, in run_code_end().
|
| |
|
|
|
|
| |
In debugging 2438, I spent a while going around in circles trying to
decide if there was a stray overload of 'interactive'. Part of the
problem was the hacky delete of a recipe just above. Stop doing that.
|
| |
|