about summary refs log tree commit diff stats
path: root/036call_reply.cc
Commit message (Collapse)AuthorAgeFilesLines
* 2671 - never use debug_string() in tracesKartik K. Agaram2016-02-191-1/+1
| | | | It's only for transient debugging.
* 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.
* 2661 - warn if a reply doesn't match recipe headerKartik K. Agaram2016-02-151-1/+2
| | | | | | | | Thanks Nicolas Léveillé for running up against this bug: https://news.ycombinator.com/item?id=11094837 (Also noticed and fixed several subsidiary issues. This whole aspect doesn't seem fully baked yet.)
* 2656Kartik K. Agaram2016-02-141-0/+1
|
* 2643Kartik K. Agaram2016-02-101-1/+0
|
* 2601 - fix crashKartik K. Agaram2016-01-241-2/+4
|
* 2624 - fix all layersKartik K. Agaram2015-12-141-1/+1
|
* 2623 - check 'reply' instructions ahead of timeKartik K. Agaram2015-12-131-38/+58
|
* 2620Kartik K. Agaram2015-12-071-1/+4
|
* 2608 - improve errors when static dispatch failsKartik K. Agaram2015-11-291-0/+1
|
* 2475 - allow addresses to be converted to numbersKartik K. Agaram2015-11-271-1/+1
| | | | It's just the other direction we want to avoid.
* 2420Kartik K. Agaram2015-11-101-1/+0
|
* 2417 - support mutable ingredients in headersKartik K. Agaram2015-11-101-2/+2
| | | | | | If a name repeats between ingredients, we raise an error. If a name repeats across ingredients and products, every call should share the same name across the corresponding ingredients and products.
* 2406Kartik K. Agaram2015-11-081-17/+14
| | | | | One new issue: the traces for all tests are perturbed by the .mu files we choose to load.
* 2399 - consistent debug_string vocabularyKartik K. Agaram2015-11-081-1/+1
|
* 2396 - edit working again!!Kartik K. Agaram2015-11-081-13/+19
| | | | | | | | | | | 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.
* 2395 - type ingredients can map to trees of typesKartik K. Agaram2015-11-071-1/+3
|
* 2377 - stop using operator[] in mapKartik K. Agaram2015-11-061-5/+5
| | | | | | | | | | | | | | | | 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.
* 2313Kartik K. Agaram2015-10-291-1/+1
|
* 2311Kartik K. Agaram2015-10-291-1/+1
|
* 2306 - recipe headersKartik K. Agaram2015-10-281-1/+1
| | | | | | | | | | 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!)
* 2299 - check types of ingredients in callsKartik K. Agaram2015-10-281-3/+3
| | | | | | | | | | Still very incomplete: a) we perform the check at runtime b) tests for edit and sandbox apps no longer work; we can't fix them until we get type parameters in both containers and recipes (because list and list operations need to become generic).
* 2283 - represent each /property as a treeKartik K. Agaram2015-10-261-3/+3
|
* 2271 - bugfix: traces cross-contaminating errorsKartik K. Agaram2015-10-191-1/+5
| | | | | | | | | | | | | | | | | | There were several places where we push a call on to a routine without incrementing call-stack depth, which was used to compute the depth at which to trace an instruction. So sometimes you ended up one depth lower than you started a call with. Do this enough times and instructions that should be traced at level 100 end up at level 0 and pop up as errors. Solution: since call-stack depth is only used for tracing, include it in the trace stream and make sure we reset it along with the trace stream. Then catch all places where we forget to increment call-stack depth and make sure we catch such places in the future. When I first ran into this with Caleb I thought there must be some way that we're writing some output into the warnings result. I didn't recognize that the spurious output as part of the trace, just at the wrong level.
* 2258 - separate warnings from errorsKartik K. Agaram2015-10-061-13/+13
| | | | | | | At the lowest level I'm reluctantly starting to see the need for errors that stop the program in its tracks. Only way to avoid memory corruption and security issues. But beyond that core I still want to be as lenient as possible at higher levels of abstraction.
* 2247 - type-check products of non-primitive recipesKartik K. Agaram2015-10-051-5/+28
| | | | | | | | We still can't check ingredient types, and even this is still a run-time check. We'll need to start tracking recipe signatures at some point. I've had to introduce a hack called /skiptypecheck. Time to get generics working.
* 2232Kartik K. Agaram2015-10-011-0/+4
|
* 2226 - standardize warning formatKartik K. Agaram2015-10-011-3/+3
| | | | | | | | Always show recipe name where error occurred. But don't show internal 'interactive' name for sandboxes, that's just confusing. What started out as warnings are now ossifying into errors that halt all execution. Is this how things went with C and Unix as well?
* 2199 - stop printing numbers in scientific notationKartik K. Agaram2015-09-141-2/+2
| | | | | | | | | | | 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.
* 2050Kartik K. Agaram2015-08-211-2/+2
|
* 1962Kartik K. Agaram2015-08-091-1/+1
| | | | Standardize test names.
* 1868 - start using naked literals everywhereKartik K. Agaram2015-07-281-10/+10
| | | | First step to reducing typing burden. Next step: inferring types.
* 1848 - core instructions now check for ingredientsKartik K. Agaram2015-07-251-32/+37
| | | | Also standardized warnings.
* 1844 - explicitly end each trace lineKartik K. Agaram2015-07-251-4/+4
| | | | | | | | | More verbose, but it saves trouble when debugging; there's never something you thought should be traced but just never came out the other end. Also got rid of fatal errors entirely. Everything's a warning now, and code after a warning isn't guaranteed to run.
* 1799 - continue to debug memory corruption of 1795Kartik K. Agaram2015-07-171-0/+1
| | | | | | | | | | | | Things I figured out: - 'row' in render-screen doesn't perfectly track cursor-row in screen - proximal cause was forgetting to add left:number to stop-printing - trying to print to screen outside bounds was silently succeeding and corrupting simulated memory - if we silently ignore prints outside bounds things are fine But why are prints outside screen bounds working? We should be accessing screen data using 'index', and that's checking its bounds.
* 1796 - temporarily undo 1795Kartik K. Agaram2015-07-161-1/+0
| | | | | Debugging simulated-screen support is taking too long, and I suddenly have a few higher priorities.
* 1795 - still debugging screen-in-screen renderingKartik K. Agaram2015-07-161-0/+1
| | | | I'm writing to location 'screen' somehow that's not the raw location.
* 1777 - consistent terminology: 'product'Kartik K. Agaram2015-07-131-2/+2
|
* 1754Kartik K. Agaram2015-07-101-0/+2
|
* 1745 - hoist warning/response strings out of editor-dataKartik K. Agaram2015-07-101-1/+17
| | | | | | | | | | Still ugly as hell. Some tests failing, but they're most likely wrong. We need to test cursor positioning at the level of the environment and take it away from the responsibilities of individual editors. Also bring back the line at the bottom of each editor. The non-test run ('main' in edit.mu) is completely borked. Sluggish as hell, and I can't seem to switch focus to the sandbox editor.
* 1723Kartik K. Agaram2015-07-081-4/+1
| | | | | Some reorg before we start plumbing 'reply' from 'run-interactive' to return a string containing the results.
* 1721 - hide warnings inside interactive routinesKartik K. Agaram2015-07-081-2/+4
| | | | | | | | | | We will need many other forms of isolation for these. For starters we're going to have to replace most asserts with warnings that can be traced so that the environment doesn't crash because of illegal code typed into it. New test is still failing. Just getting it to fail right was hard enough.
* 1716Kartik K. Agaram2015-07-071-0/+2
|
* 1702 - experiment: start using 'ordinal' in namesKartik K. Agaram2015-07-041-5/+5
| | | | | | | 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!
* 1698Kartik K. Agaram2015-07-031-0/+158