about summary refs log tree commit diff stats
path: root/091run_interactive.cc
Commit message (Collapse)AuthorAgeFilesLines
* 2712Kartik K. Agaram2016-02-261-4/+4
|
* 2707Kartik K. Agaram2016-02-251-8/+1
|
* 2704 - eradicate all mention of warnings from coreKartik K. Agaram2016-02-251-2/+2
|
* 2703Kartik K. Agaram2016-02-251-6/+4
|
* 2702Kartik K. Agaram2016-02-251-16/+16
|
* 2685Kartik K. Agaram2016-02-191-3/+3
| | | | | | | | | | | | | | | | Stack of plans for cleaning up replace_type_ingredients() and a couple of other things, from main problem to subproblems: include type names in the type_tree rather than in the separate properties vector make type_tree and string_tree real cons cells, with separate leaf nodes redo the vocabulary for dumping various objects: do we really need to_string and debug_string? can we have a version with *all* information? can we have to_string not call debug_string? This commit nibbles at the edges of the final task, switching from member method syntax to global function like almost everything else. I'm mostly using methods just for STL in this project.
* 2628Kartik K. Agaram2016-02-051-0/+1
| | | | | Ran into a crash here while loading Caleb's deck-of-war program. Not bothering debugging it..
* 2576 - distinguish allocated addresses from othersKartik K. Agaram2016-01-191-30/+30
| | | | | | | | | | | | | | | | 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.
* 2562Kartik K. Agaram2016-01-171-1/+1
| | | | | | | | | | | | 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.
* 2553 - keep failed specializations from generating spurious errorsKartik K. Agaram2015-12-281-1/+0
| | | | Thanks Caleb Couch.
* three bugs fixedKartik K. Agaram2015-12-151-4/+70
| | | | | | | | | | | | | | | | | - 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.
* 2622Kartik K. Agaram2015-12-131-10/+10
|
* 2473 - bad idea to use /raw with multiple intentionsKartik K. Agaram2015-11-221-1/+1
| | | | | /raw is to express absolute addresses /unsafe is to sidestep type-checking in test setup
* 2467 - rename 'string' to 'text' everywhereKartik K. Agaram2015-11-211-3/+3
| | | | | | | | 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.
* 2464: edit/: update errors in shape-shifting recipesKartik K. Agaram2015-11-191-0/+17
| | | | | Requires carefully deleting specializations so that they can be reintroduced each time.
* 2458 - edit/: recipe side free of sandbox errorsKartik K. Agaram2015-11-181-2/+8
| | | | | | | | | 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().
* 2440Kartik K. Agaram2015-11-141-2/+1
| | | | | | 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.
* 2430 - make room for more transformsKartik K. Agaram2015-11-131-0/+452