| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Thanks Caleb Couch.
|
| |
|
|
|
| |
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().
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Another gotcha uncovered in the process of sorting out the previous
commit: I keep using eof() but forgetting that there are two other
states an istream can get into. Just never use eof().
|
| |
|
|
|
|
|
| |
I ran into this when edit/ couldn't handle spaces after curly brackets,
even though .mu files could. Turns out edit/ loads code using
istringstreams rather than ifstreams, and you can't putback a different
character than you read from an istringstream. Craptastic gotcha..
|
| | |
|
| |
|
|
|
|
|
|
|
| |
I notice that it isn't working perfectly; after maximize/unmaximize the
editor stops wrapping text, like it still thinks the editor is
maximized.
We don't even use this feature anymore, do we? Just delete it rather
than bother debugging.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Great that it just worked after the previous commit.
|
| |
|
|
|
| |
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.
|
| |
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Thanks Caleb Couch. This one's been on my list for 2 weeks.
|
| |
|
|
| |
More evocative, less jargony.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
If a name repeats between ingredients, we raise an error.
If a name repeats across ingredients and products, every call should
share the same name across the corresponding ingredients and products.
|
| | |
|
| |
|
|
| |
This is the last one I can think of.
|