about summary refs log tree commit diff stats
path: root/010vm.cc
Commit message (Collapse)AuthorAgeFilesLines
...
* 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.
* 1703Kartik K. Agaram2015-07-041-6/+13
|
* 1702 - experiment: start using 'ordinal' in namesKartik K. Agaram2015-07-041-30/+30
| | | | | | | It comes up pretty early in the codebase, but hopefully won't come up in the mu level until we get to higher-order recipes. Potentially intimidating name, but such prime real estate with no confusing overloadings in other projects!
* 1560Kartik K. Agaram2015-06-131-17/+0
|
* 1559Kartik K. Agaram2015-06-131-0/+2
|
* 1558Kartik K. Agaram2015-06-131-0/+10
| | | | Make it possible to check multi-line string literals in the trace.
* 1557Kartik K. Agaram2015-06-131-0/+8
| | | | More concise traces for literal strings.
* 1416Kartik K. Agaram2015-05-211-0/+2
|
* 1414 - traces now robust to new recipes/typesKartik K. Agaram2015-05-211-9/+6
|
* 1407Kartik K. Agaram2015-05-191-1/+1
|
* 1399 - better 'unknown type' warningsKartik K. Agaram2015-05-181-2/+4
| | | | | | | | Implement warnings for types without definitions without constraining where type definitions must appear. We also eliminate the anti-pattern where a change in layer 10 had its test in layer 11 (commit 1383).
* 1391 - avoid unsigned integersKartik K. Agaram2015-05-171-14/+14
|
* 1390 - support non-integer literalsKartik K. Agaram2015-05-171-2/+2
| | | | | | | | | | | | | | | | | | | | Since '3.14159:literal' looks ugly, we'll just say '3.14159'. It's not like non-integers can be confused for anything but literals. Once I tried to turn reagent values into doubles, I uncovered a bug: arithmetic using signed integers is busted; if either operand of subtraction is unsigned the result is unsigned as well. If it needs to be negative: ka-boom. It was only masked because I was eventually storing the result in a long long int, where it was out of range, and so overflowing into the correct signed value. Once I switched to doubles the unsigned value would indeed fit without overflowing. Ka-boom. Yet another reminder that unsigned integers suck. I started using them mostly to avoid warnings in loops when comparing with .size(), which is usually a size_t. Who knows what other crap lurks here. Just use signed integers everywhere. (And avoid bitwise operators.)
* 1383 - warn on unknown typeKartik K. Agaram2015-05-161-1/+4
| | | | | | | | | | | | | This bit me in the last commit for the first time. Layer 010vm.cc is starting to look weird. It has references to stuff that gets implemented much later, like containers and exclusive containers. Its helpers are getting an increasing amount of logic. And it has no tests. I'm still inclined to think it's useful to have major data structures in one place, even if they aren't used for a bit. But those helpers should perhaps move out somehow or get some tests in the same layer.
* 1363 - rename 'integer' to 'number'Kartik K. Agaram2015-05-131-5/+5
| | | | ..now that we support non-integers.