about summary refs log tree commit diff stats
path: root/010vm.cc
Commit message (Collapse)AuthorAgeFilesLines
...
* 2686Kartik K. Agaram2016-02-191-2/+2
|
* 2685Kartik K. Agaram2016-02-191-24/+20
| | | | | | | | | | | | | | | | 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.
* 2667 - redo container data structureKartik K. Agaram2016-02-171-7/+3
| | | | I've been gradually Greenspunning reagents. Just go all the way.
* 2637 - save type names for container elementsKartik K. Agaram2016-02-071-1/+3
|
* 2635Kartik K. Agaram2016-02-061-0/+1
|
* 2617 - better error messagesKartik K. Agaram2016-01-301-1/+2
| | | | | | | | | | | | | | | | | | 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
* 2569Kartik K. Agaram2016-01-181-1/+1
|
* 2567Kartik K. Agaram2016-01-181-2/+7
|
* 2562Kartik K. Agaram2016-01-171-2/+2
| | | | | | | | | | | | 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.
* 2614 - still fixing bugs with missing '['Kartik K. Agaram2015-12-021-4/+11
| | | | | | When skipping past some text (usually whitespace, but also commas and comments) I need to always be aware of whether it's ok to switch to the next line or not.
* 2491Kartik K. Agaram2015-11-281-2/+12
|
* 2487Kartik K. Agaram2015-11-271-28/+0
| | | | | | | | | | | | | | | 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.
* 2483 - to-text can now handle listsKartik K. Agaram2015-11-271-2/+5
| | | | | 'append' also implicitly calls 'to-text' unless there's a better variant.
* 2454Kartik K. Agaram2015-11-171-3/+3
| | | | | | 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().
* 2445 - dispatch between shape-shifting variantsKartik K. Agaram2015-11-151-2/+2
| | | | | 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-2/+9
| | | | Yet another bugfix as I trace through the last session with Caleb.
* 2441 - never miss any specializationsKartik K. Agaram2015-11-151-0/+10
| | | | | | | | | 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.
* 2413 - another backfilled test for 2391Kartik K. Agaram2015-11-091-0/+1
| | | | This time for the support for 'new' that was added in 2393.
* 2406Kartik K. Agaram2015-11-081-18/+7
| | | | | One new issue: the traces for all tests are perturbed by the .mu files we choose to load.
* 2405Kartik K. Agaram2015-11-081-0/+24
|
* 2399 - consistent debug_string vocabularyKartik K. Agaram2015-11-081-44/+47
|
* 2397Kartik K. Agaram2015-11-081-0/+17
| | | | | Fix that stray issue with a better phase ordering. Another thing I'm not testing.
* 2396 - edit working again!!Kartik K. Agaram2015-11-081-0/+8
| | | | | | | | | | | Still some spurious warnings. This was an insane experience building out generics. Time to reflect. Where did I go wrong? How did I end up writing no tests? Let's take some time and go over the last 50 commits with a fine-tooth comb. Generics seems to be the feature that has moved mu from a VM project to a compiler project.
* 2394 - clean up outputKartik K. Agaram2015-11-071-3/+1
|
* 2393 - redo 2391Kartik K. Agaram2015-11-071-1/+3
| | | | | | | | | | | 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.
* 2392 - undo 2391Kartik K. Agaram2015-11-071-3/+1
| | | | Yup, type ingredients were taking size 1 by default.
* 2391Kartik K. Agaram2015-11-071-1/+3
| | | | | | | | | | | | | 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.
* 2382Kartik K. Agaram2015-11-061-1/+4
| | | | Starting to leave commented out prints again out of desperation.
* 2381Kartik K. Agaram2015-11-061-0/+2
|
* 2380 - done loading mu codeKartik K. Agaram2015-11-061-8/+4
| | | | | | | | 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.
* 2379 - further improvements to map operationsKartik K. Agaram2015-11-061-2/+2
| | | | | | | 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
* 2378Kartik K. Agaram2015-11-061-5/+5
| | | | | | Now we're starting to run up against the misbehavior introduced by generics: Type tries to insert rows for type ingredients. That is a no-no.
* 2377 - stop using operator[] in mapKartik K. Agaram2015-11-061-20/+20
| | | | | | | | | | | | | | | | 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.
* 2354Kartik K. Agaram2015-11-041-2/+2
|
* 2339 - don't let dump_types modify TypeKartik K. Agaram2015-11-011-2/+9
|
* 2321 - more preparations for static dispatchKartik K. Agaram2015-10-291-2/+3
| | | | | Deduce operation id from name during transform rather than load, so that earlier transforms have a chance to modify the name.
* 2316 - preparing for static dispatchKartik K. Agaram2015-10-291-0/+5
|
* 2306 - recipe headersKartik K. Agaram2015-10-281-0/+2
| | | | | | | | | | Once a student has gotten used to recipes and ingredients using the staged 'next-ingredient' approach there's no reason to avoid conventional function headers. As an added bonus we can now: a) check that all 'reply' instructions in a recipe are consistent b) deduce what to reply without needing to say so everytime c) start thinking about type parameters for recipes (generic functions!)
* 2293Kartik K. Agaram2015-10-271-5/+15
|
* 2292Kartik K. Agaram2015-10-271-2/+2
|
* 2291 - parsing property treesKartik K. Agaram2015-10-271-1/+1
|
* 2284Kartik K. Agaram2015-10-261-4/+4
|
* 2283 - represent each /property as a treeKartik K. Agaram2015-10-261-39/+104
|
* 2282Kartik K. Agaram2015-10-261-6/+14
| | | | | Switch format for tracing reagents in preparation for trees rather than arrays of properties.
* 2281Kartik K. Agaram2015-10-261-0/+24
|
* 2279Kartik K. Agaram2015-10-261-1/+1
|
* 2278Kartik K. Agaram2015-10-261-2/+2
|
* 2277 - reagents now have a tree of typesKartik K. Agaram2015-10-251-10/+72
|
* 2238 - dump recipes after tanglingKartik K. Agaram2015-10-041-0/+9
|
* 2201Kartik K. Agaram2015-09-151-2/+4
|