about summary refs log tree commit diff stats
path: root/059shape_shifting_recipe.cc
Commit message (Collapse)AuthorAgeFilesLines
* 2621 - bugfix: empty shape-shifting recipesKartik K. Agaram2016-01-301-6/+17
| | | | | My transform pipeline ignores empty recipes, but when I specialized shape-shifting ones I forgot that check.
* 2620Kartik K. Agaram2016-01-301-20/+20
| | | | | 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.
* 2596 - experiment: no unique addresses in callsKartik K. Agaram2016-01-231-3/+3
| | | | | | | | | | 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.
* 2576 - distinguish allocated addresses from othersKartik K. Agaram2016-01-191-14/+14
| | | | | | | | | | | | | | | | 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.
* 2553 - keep failed specializations from generating spurious errorsKartik K. Agaram2015-12-281-7/+3
| | | | Thanks Caleb Couch.
* 2552Kartik K. Agaram2015-12-281-4/+4
|
* three bugs fixedKartik K. Agaram2015-12-151-5/+26
| | | | | | | | | | | | | | | | | - 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.
* layer 3 of edit/ now workingKartik K. Agaram2015-12-151-0/+12
| | | | | 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.
* 2622Kartik K. Agaram2015-12-131-8/+8
|
* 2489 - another ambiguous specializationKartik K. Agaram2015-11-281-5/+49
|
* 2486Kartik K. Agaram2015-11-271-2/+3
| | | | | More cleanup. Haven't bothered to figure out why the trace for specialize_with_literal_4 is repeatedly perturbed.
* 2484Kartik K. Agaram2015-11-271-2/+1
| | | | | Eliminate one of several hacky type-check helpers; they've been proliferating lately.
* 2483 - to-text can now handle listsKartik K. Agaram2015-11-271-8/+30
| | | | | 'append' also implicitly calls 'to-text' unless there's a better variant.
* 2480Kartik K. Agaram2015-11-271-4/+11
| | | | | | | 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.
* 2479 - bugfix: recursive shape-shifting recipesKartik K. Agaram2015-11-271-6/+24
|
* 2472Kartik K. Agaram2015-11-221-12/+0
|
* 2464: edit/: update errors in shape-shifting recipesKartik K. Agaram2015-11-191-2/+15
| | | | | Requires carefully deleting specializations so that they can be reintroduced each time.
* 2456Kartik K. Agaram2015-11-171-0/+19
|
* 2455 - first fix of another batch of crashesKartik K. Agaram2015-11-171-14/+37
|
* 2449Kartik K. Agaram2015-11-151-0/+1
|
* 2445 - dispatch between shape-shifting variantsKartik K. Agaram2015-11-151-5/+103
| | | | | Starting to leave debug prints around once again, just in case one of them is worth promoting to the trace..
* 2444Kartik K. Agaram2015-11-151-0/+12
| | | | Yet another bugfix as I trace through the last session with Caleb.
* 2443Kartik K. Agaram2015-11-151-12/+28
| | | | | 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!
* 2442Kartik K. Agaram2015-11-151-1/+17
| | | | | | 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.
* 2441 - never miss any specializationsKartik K. Agaram2015-11-151-4/+44
| | | | | | | | | 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.
* 2438 - specialize inside header-less recipesKartik K. Agaram2015-11-141-1/+26
| | | | | | | 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.
* 2433 - temporarily undo 2432Kartik K. Agaram2015-11-131-11/+0
| | | | | | 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.
* 2432 - first stab at making ingredients immutableKartik K. Agaram2015-11-131-0/+11
| | | | | | | | | | | | | | | 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.
* 2421 - 'generic' => 'shape-shifting'Kartik K. Agaram2015-11-101-0/+444
More evocative, less jargony.