about summary refs log tree commit diff stats
path: root/081run_interactive.cc
Commit message (Collapse)AuthorAgeFilesLines
* 2039 - warn on unbalanced '['Kartik K. Agaram2015-08-191-1/+2
|
* 2024 - mu environment now handles infinite loops gracefullyKartik K. Agaram2015-08-161-2/+6
|
* 2022 - run sandboxes in separate routinesKartik K. Agaram2015-08-161-36/+88
|
* 2021Kartik K. Agaram2015-08-161-5/+3
|
* 2020Kartik K. Agaram2015-08-161-11/+2
|
* 2019 - simplify run-interactive furtherKartik K. Agaram2015-08-161-41/+25
| | | | | | | | | | | | | | | | | This time I'm getting rid of all the intricate SCREEN hacking. Now run-interactive is idiomatic: it creates a recipe on the fly, runs it, and returns various results and stats about it. One big consequence of the recipe now running interactively inside a local-scope: you can't just use numeric addresses anymore -- not without using /raw. Fixed one of the tests to reflect this. I realize now that I don't really want my students to be using raw addresses in their sandboxes, even if that was my idiom for lower-level scenarios. Hopefully running sandboxes in separate (synchronous) routines will be easy now.
* 2018Kartik K. Agaram2015-08-151-1/+0
| | | | | Still trying to minimize the work around run-interactive so I can build it with a sandboxed routine rather than a call in editor space.
* 2017Kartik K. Agaram2015-08-151-11/+11
|
* 1993Kartik K. Agaram2015-08-141-1/+4
| | | | Thanks Caleb Couch.
* 1975 - let's start using traces in lessonsKartik K. Agaram2015-08-101-18/+0
| | | | | More friendly way to 'stash' stuff in the trace so that you can toggle lines of code to see their stashed traces.
* 1923Kartik K. Agaram2015-08-021-2/+10
| | | | | | | | | | Still iterating on the right way to handle incorrect number of ingredients. My first idea of creating null results doesn't really work once they're used in later instructions. Just add a warning at one place in the run loop, but otherwise only add products when there's something to save in them. Undoes some work around commit 1886.
* 1921 - show trace by clicking on codeKartik K. Agaram2015-08-021-7/+20
| | | | | | | Region to click on to edit is now reduced to just the menu bar for the sandbox (excluding the 'x' for deleting the sandbox). The symmetry there might be useful, but we'll see if the relative click area is in line with how commonly the actions are performed.
* 1919Kartik K. Agaram2015-08-021-6/+6
| | | | | Generalize a little layer as a first step to providing traces for other layers.
* 1913 - save expected response for each sandboxKartik K. Agaram2015-08-011-2/+2
|
* 1886 - gracefully handle malformed ingredientsKartik K. Agaram2015-07-291-2/+2
| | | | | | | | For example: x:number <- index y:address:array:number, 3 (forgetting to do a lookup) Thanks Caleb Couch.
* 1869 - rename the /deref property to /lookupKartik K. Agaram2015-07-281-3/+3
| | | | Should be a little bit more mnemonic.
* 1868 - start using naked literals everywhereKartik K. Agaram2015-07-281-3/+3
| | | | First step to reducing typing burden. Next step: inferring types.
* 1852Kartik K. Agaram2015-07-251-1/+1
|
* 1849Kartik K. Agaram2015-07-251-1/+1
|
* 1848 - core instructions now check for ingredientsKartik K. Agaram2015-07-251-3/+16
| | | | Also standardized warnings.
* 1846Kartik K. Agaram2015-07-251-2/+2
|
* 1841 - reenable old layersKartik K. Agaram2015-07-241-6/+2
|
* 1826 - edit: start carefully showing all errorsKartik K. Agaram2015-07-211-0/+11
| | | | | | | | | | | | | | | | | | | | | Eventually we might be able to get rid of die entirely. This is just a preliminary stab at a random error. In the process I ran into two issues that have impeded debugging before: a) Naming conflicts within scenarios are a real no-no. I need to warn on them, but the rules are getting complicated: Always print warnings on redefine But not in interactive mode Or in scenarios checking warning behavior Unless the scenario recipe itself is overridden b) Now that we've added collect_layers and a long time can go between traces, debugging is a minefield because trace lines don't print to screen immediately after they're created. Need to do something about that. Maybe explicitly trigger collection by tracing '\n' or something. These are the next two items on my todo list.
* 1822Kartik K. Agaram2015-07-191-7/+7
|
* 1802 - cleanupKartik K. Agaram2015-07-171-7/+3
|
* 1799 - continue to debug memory corruption of 1795Kartik K. Agaram2015-07-171-21/+55
| | | | | | | | | | | | 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-49/+21
| | | | | 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-21/+49
| | | | 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/+10
|
* 1787 - clear warnings between runsKartik K. Agaram2015-07-151-29/+9
|
* 1782 - stop tracing anything but warnings inside editKartik K. Agaram2015-07-141-0/+1
| | | | | | | | | Speeds up edit.mu tests by 10x, and shrinks memory usage by 100x. We need a more efficient implementation of traces, but we can keep going for now. We didn't really need to reclaim memory just yet, after all. Mu is pretty memory-efficient.
* 1764 - editor now updates all sandboxesKartik K. Agaram2015-07-111-0/+14
| | | | Finally, albeit too late for my demo.
* 1759Kartik K. Agaram2015-07-111-0/+4
|
* 1736 - stop refusing to reload code in the editorKartik K. Agaram2015-07-091-0/+6
| | | | All tests passing, but early layers are broken.
* 1733 - load all recipes before running sandboxesKartik K. Agaram2015-07-081-0/+20
| | | | | This is starting to look good! I need to add some tests for render-string, but we'll see.
* 1732Kartik K. Agaram2015-07-081-12/+0
|
* 1727Kartik K. Agaram2015-07-081-2/+34
|
* 1726Kartik K. Agaram2015-07-081-11/+50
|
* 1725Kartik K. Agaram2015-07-081-1/+5
|
* 1724 - first stab at printing interactive resultsKartik K. Agaram2015-07-081-3/+46
|
* 1723Kartik K. Agaram2015-07-081-4/+11
| | | | | Some reorg before we start plumbing 'reply' from 'run-interactive' to return a string containing the results.
* 1722 - drop support for querying locationsKartik K. Agaram2015-07-081-57/+6
| | | | | | | | | | | | Also added another failing test showing what behavior we want in the programming environment. But there's no way to make use of querying locations, since we're not planning any interaction with individual sandboxes at the moment. Instead of interacting with one sandbox at a time, which is the current approach, we want to create dashboards out of multiple sandboxes at once. Start with them non-interactive, that'll demonstrate 80% of the new benefits. We'll add interactivity down the road.
* 1721 - hide warnings inside interactive routinesKartik K. Agaram2015-07-081-0/+9
| | | | | | | | | | 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.
* 1720 - start adding repl supportKartik K. Agaram2015-07-071-7/+8
|
* 1717 - less hacky replKartik K. Agaram2015-07-071-57/+78
| | | | | | | 'run-interactive' now takes a string as input and returns a string as output when it generates a result. As a result we also don't have to worry about manual tests anymore, and it should now be reusable in edit.mu.
* 1702 - experiment: start using 'ordinal' in namesKartik K. Agaram2015-07-041-11/+11
| | | | | | | 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!
* 1553Kartik K. Agaram2015-06-111-0/+122