about summary refs log tree commit diff stats
path: root/010vm.cc
Commit message (Collapse)AuthorAgeFilesLines
* 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
|
* 2199 - stop printing numbers in scientific notationKartik K. Agaram2015-09-141-1/+47
| | | | | | | | | | | Turns out the default format for printing floating point numbers is neither 'scientific' nor 'fixed' even though those are the only two options offered. Reading the C++ standard I found out that the default (modulo locale changes) is basically the same as the printf "%g" format. And "%g" is basically the shorter of: a) %f with trailing zeros trimmed b) %e So we'll just do %f and trim trailing zeros.
* 2095Kartik K. Agaram2015-08-281-2/+0
| | | | | | | | | | | | Finally terminate the experiment of keeping debug prints around. I'm also going to give up on maintaining counts. What we really need is two kinds of tracing: a) For tests, just the domain-specific facts, organized by labels. b) For debugging, just transient dumps to stdout. b) only works if stdout is clean by default. Hmm, I think this means 'stash' should be the transient kind of trace.
* 2043Kartik K. Agaram2015-08-201-0/+1
| | | | | Traces were changing based on whether I was loading a .mu file with 'main' or not.
* 1994 - new primitive: 'create-array'Kartik K. Agaram2015-08-141-1/+3
| | | | | Not strictly necessary, but it might help me stage the introduction of arrays and 'new'.
* 1945Kartik K. Agaram2015-08-061-1/+4
| | | | | | Turns out it is indeed useful to insert code at multiple duplicate labels within a single (long) recipe. Like handle-keyboard-event in edit.mu.
* 1876Kartik K. Agaram2015-07-281-0/+2
|
* 1842 - get layers building again after 2 weeksKartik K. Agaram2015-07-241-0/+15
| | | | | Also, turns out I haven't been building 999spaces.cc in my default build. Now fixed.
* 1814 - save code in editorKartik K. Agaram2015-07-181-2/+2
| | | | | | | Very rudimentary ability to read/write from file+version control. No control over name. Recipes now saved. But what to do about sandboxes?
* 1783 - stable if sluggish on caleb's 512MB serverKartik K. Agaram2015-07-141-2/+0
| | | | | Profiling shows the bulk of time is spent in read_memory, canonize, absolutize. But I'm not sure how to optimize those places.
* 1762 - numbers without types = literalsKartik K. Agaram2015-07-111-0/+4
| | | | Quick hack for demo at balisp meetup today.