about summary refs log tree commit diff stats
path: root/050scenario.cc
Commit message (Collapse)AuthorAgeFilesLines
* 2606 - handle cycles inside stashKartik K. Agaram2015-11-291-6/+3
| | | | | | | | | The idea is that to-text-line should truncate blindly past some threshold, even if to-text isn't smart enough to avoid infinite loops. Maybe I should define a 'truncating buffer' which stops once it fills up. That would be an easy way to eliminate all infinite loops in to-text-line.
* 2483 - to-text can now handle listsKartik K. Agaram2015-11-271-2/+2
| | | | | 'append' also implicitly calls 'to-text' unless there's a better variant.
* 2466 - eliminate ':string' from scenariosKartik K. Agaram2015-11-211-3/+6
|
* 2458 - edit/: recipe side free of sandbox errorsKartik K. Agaram2015-11-181-0/+4
| | | | | | | | | 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().
* 2454Kartik K. Agaram2015-11-171-1/+1
| | | | | | 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().
* 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
* 2377 - stop using operator[] in mapKartik K. Agaram2015-11-061-17/+17
| | | | | | | | | | | | | | | | 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-3/+3
|
* 2312Kartik K. Agaram2015-10-291-1/+1
|
* 2283 - represent each /property as a treeKartik K. Agaram2015-10-261-1/+1
|
* 2271 - bugfix: traces cross-contaminating errorsKartik K. Agaram2015-10-191-0/+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-48/+48
| | | | | | | 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.
* 2232Kartik K. Agaram2015-10-011-9/+29
|
* 2226 - standardize warning formatKartik K. Agaram2015-10-011-5/+5
| | | | | | | | 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-6/+6
| | | | | | | | | | | 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.
* 2195Kartik K. Agaram2015-09-141-2/+2
|
* 2137Kartik K. Agaram2015-09-031-1/+0
|
* 2095Kartik K. Agaram2015-08-281-15/+2
| | | | | | | | | | | | 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.
* 2088 - warn on duplicate scenario nameKartik K. Agaram2015-08-281-0/+5
|
* 2067Kartik K. Agaram2015-08-241-1/+1
|
* 2029Kartik K. Agaram2015-08-171-1/+1
|
* 1991 - new primitive to count lines in traceKartik K. Agaram2015-08-131-0/+60
|
* 1990 - extra ingredient for 'trace' depthKartik K. Agaram2015-08-131-13/+13
| | | | Now we can make use of all the depths from 1 to 99.
* 1871Kartik K. Agaram2015-07-281-0/+5
|
* 1868 - start using naked literals everywhereKartik K. Agaram2015-07-281-19/+19
| | | | First step to reducing typing burden. Next step: inferring types.
* 1846Kartik K. Agaram2015-07-251-1/+1
|
* 1845 - never ever redefine the scenario's recipeKartik K. Agaram2015-07-251-2/+19
| | | | | | A couple of times now I've accidentally named a scenario the same thing as a recipe inside it that I define using 'run' or something. The resulting infinite loop is invariably non-trivial to debug.
* 1844 - explicitly end each trace lineKartik K. Agaram2015-07-251-13/+13
| | | | | | | | | 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.
* 1796 - temporarily undo 1795Kartik K. Agaram2015-07-161-1/+1
| | | | | 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-1/+1
| | | | I'm writing to location 'screen' somehow that's not the raw location.
* 1793 - rudimentary sandboxing for scenarios in the environmentKartik K. Agaram2015-07-151-1/+1
|
* 1754Kartik K. Agaram2015-07-101-1/+1
|
* 1751 - sluggishness fixedKartik K. Agaram2015-07-101-1/+1
| | | | | | | Ah, I was indeed double-rendering, but somehow it was still hard to see the problem past that preliminary diagnosis. Still two failing tests to fix.
* 1746 - load file and run a single testKartik K. Agaram2015-07-101-7/+6
| | | | $ ./mu test run-instruction-and-print-warnings
* 1745 - hoist warning/response strings out of editor-dataKartik K. Agaram2015-07-101-1/+1
| | | | | | | | | | 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.
* 1743Kartik K. Agaram2015-07-091-1/+1
|
* 1721 - hide warnings inside interactive routinesKartik K. Agaram2015-07-081-10/+20
| | | | | | | | | | 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.
* 1702 - experiment: start using 'ordinal' in namesKartik K. Agaram2015-07-041-9/+9
| | | | | | | 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!
* 1672 - begin support for multiple editors at onceKartik K. Agaram2015-06-281-1/+1
|
* 1671 - better separate setup from code under testKartik K. Agaram2015-06-271-5/+13
| | | | | Requires better support for special variable names in scenarios like 'screen' and 'console'.
* 1668 - there's a bug in CHECK_TRACE_DOESNT_CONTAINKartik K. Agaram2015-06-271-1/+3
| | | | For starters start making the test fail when building until layer 41.
* 1621Kartik K. Agaram2015-06-221-1/+1
| | | | | | | | repl.mu now passing again. But still I have concerns: a) Doubling backslashes in tests. Hard to tell how many levels to add. b) I think the read-key interface needs to go. But then how do we handle send-keys-to-channel and other flows like that in the chessboard app?
* 1620Kartik K. Agaram2015-06-221-1/+3
| | | | | | | | chessboard finally passing all its tests. What made this hard was that for some reason one of the background routines in the main chessboard test wasn't terminating like it used to. And so it was polluting *later* tests. Just clean up that source of contamination for now. Later we'll think about routine termination.
* 1598Kartik K. Agaram2015-06-191-2/+5
| | | | | Some tests weren't actually running for the past 5 days. Performed 5 why's.
* 1569Kartik K. Agaram2015-06-161-0/+1
|
* 1566 - fake mouse clicks in scenariosKartik K. Agaram2015-06-151-1/+1
|
* 1565Kartik K. Agaram2015-06-141-31/+4
|
* 1564 - a better way to support string literalsKartik K. Agaram2015-06-141-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Our new heuristic is: all string literals are the same. If they contain newline before non-whitespace, we scan for comments assuming there might be code inside: foofoofoo [ ... # ']' inside comment ignored ] If they contain non-whitespace first, then we ignore comments assuming it's just a regular string: foofoofoo [abc#def] # valid string literal The big hole in this approach: foofoofoo [ # what about comments here containing ']'? ... # abc ] Currently this reads as a 'code comment' and terminates before the newline or '?' and will probably trigger errors down the line. Temporary workaround: don't start code strings with a comment on the same line as the '['. Eventually we'll tighten up the logic. We're still not using the new heuristic in scenarios, but that's up next.
* 1498Kartik K. Agaram2015-05-281-8/+20
| | | | Cleaner to delegate as much as possible to slurp_quoted.
* 1497 - 2 boneheaded bugs in parsing scenariosKartik K. Agaram2015-05-281-6/+30
|