about summary refs log tree commit diff stats
Commit message (Collapse)AuthorAgeFilesLines
* 3986 - bring back delimited continuationsKartik K. Agaram2017-08-302-1/+189
| | | | | | | | | | | | | | | | They're back after a long hiatus: commit 2295 in Oct 2015. I'm not convinced anymore that this is actually a correct implementation of continuations. Issues on at least two fronts: a) These aren't safe yet. Since continuations can be called multiple times, we need to disable reclamation of locals inside a continuation. There may be other type- or memory-safety issues. However, delimited continuations at least seem possible to make safe. Undelimited continuations (call/cc) though are permanently out. b) They may not actually be as powerful as delimited continuations. Let's see if I can build 'yield' out of these primitives.
* 3985Kartik K. Agaram2017-08-302-120/+116
|
* 3984 - bugfix: display errors when scrolling recipe sideKartik K. Agaram2017-08-252-733/+809
| | | | This regression was (also) introduced by commit 3902 in June.
* 3983Kartik K. Agaram2017-08-2212-1823/+1885
|
* 3982 - bugfix: clear old recipe errors on F4Kartik K. Agaram2017-08-222-0/+60
| | | | | | This regression was introduced by commit 3902 in June. Making this commit clean took the last 4 commits of reorganizing.
* 3981Kartik K. Agaram2017-08-222-7/+4
| | | | | It's always been ugly that I referred to a later layer/feature in a label name.
* 3980Kartik K. Agaram2017-08-2212-123/+123
|
* 3979Kartik K. Agaram2017-08-221-4/+4
|
* 3978Kartik K. Agaram2017-08-221-13/+18
|
* 3977Kartik K. Agaram2017-08-222-2/+2
|
* 3976Kartik K. Agaram2017-08-204-91/+1
|
* 3975Kartik K. Agaram2017-08-201-6/+1
|
* 3974Kartik K. Agaram2017-08-203-11/+11
|
* 3973Kartik K. Agaram2017-08-201-149/+0
|
* 3972 - drop ancient experiment for global variablesKartik K. Agaram2017-08-201-82/+0
| | | | | | | | | | | | | We never ended up using this, and all it has provided is a hole in the type system. Java's lesson is that globals are not essential. Any program that uses globals can be rewritten to do without them. Just thread a world object through the program, saving global state in it, and extracting relevant bits of global state to pass into functions lower down the call chain. Thanks Andrew Owen for the conversation that led me to focus on this issue.
* 3971Kartik K. Agaram2017-08-1937-2663/+2653
|
* 3970Kartik K. Agaram2017-08-191-2/+1
|
* 3969Kartik K. Agaram2017-07-131-1/+1
|
* 3968Kartik K. Agaram2017-07-112-0/+68
|
* 3967Kartik K. Agaram2017-07-101-2/+3
|
* 3966Kartik K. Agaram2017-07-0915-19/+19
|
* 3965 - get rid of the teardown() functionKartik K. Agaram2017-07-097-25/+16
| | | | | | Instead of setup() and teardown() we'll just use a reset() function from now on, which will bring the machine back to a good state before each test or run, and also before exit (to avoid memory leaks).
* 3964 - eliminate one global from the test harnessKartik K. Agaram2017-07-092-8/+8
| | | | | I'm in the process of making it more self-contained so I can use it in another project.
* 3963Kartik K. Agaram2017-07-085-177/+199
| | | | | | | | Narrow the scope of implicit type conversions. Now only numbers can be freely converted to from other scalars (booleans, characters). We want in particular to make this an error: x:character <- new [abc]
* 3962Kartik K. Agaram2017-06-277-3005/+3025
| | | | | Yet another regression, this time cascading from commit 3953. My scenario wasn't actually testing what I thought it was testing.
* 3961Kartik K. Agaram2017-06-251-28/+39
| | | | | | | | | Expand the steps in `update_html` and try to process each set of files separately so we can see commonality. The eventual goal is a script that can selectively process a subset of files. But this is a good first step: I can at least easily comment out different subsets.
* 3960Kartik K. Agaram2017-06-253-193/+265
| | | | | Don't refresh entire sandbox side when toggling the expected result for a single sandbox.
* 3959Kartik K. Agaram2017-06-259-1031/+1065
| | | | | | | Don't unnecessarily write sandboxes to disk on F4. This seems to save almost 20% time when processing a large lesson directory with 36 sandboxes.
* 3958Kartik K. Agaram2017-06-2511-1011/+1029
| | | | | | | | Improvement on fix 3957: rather than put a band-aid over a slow operation, eliminate the slowdown entirely. In this case it turns out we're unnecessarily saving files to disk when they could never be modified. Are we doing this on F4 as well?!
* 3957Kartik K. Agaram2017-06-253-76/+82
| | | | | Marking sandbox responses as expected can take a long time if there are many sandboxes. Indicate when a click is being worked on.
* 3956Kartik K. Agaram2017-06-256-4996/+4947
|
* 3955Kartik K. Agaram2017-06-252-36/+32
| | | | | Move a scenario which is after commit 3954 applicable to both editors, not just the recipe side.
* 3954Kartik K. Agaram2017-06-254-131/+65
| | | | | | | | | | | | | | | | | | | | | | | | | | | As a blanket rule, down-arrow now stops scrolling once the bottom margin comes on screen. Now that we have page-wise scrolling with ctrl-f/b and line-wise scrolling with ctrl-s/x, we don't need to conflate scroll positioning with the arrow keys. And as a result, early students no longer have to struggle with accidentally scrolling part of the sandbox off the screen when there's tons of empty space available. `move-to-next-line` is still super messy and will need further rethinking, but this commit simplifies the codebase as a whole by eliminating a couple of historical accidents: a) We only introduced scrolling past the bottom of the screen to allow more sandboxes to come into view before we had scrolling for the sandbox side. b) We undid scrolling past the bottom in just the recipe side to allow errors to come into view. Since these historical details are now irrelevant, we no longer need separate logic for the recipe and sandbox sides, and we don't need to keep track of the recipe-bottom separate from the bottom margin of arbitrary editors.
* 3953Kartik K. Agaram2017-06-241-24/+51
| | | | | | | | | Redo cursor-down to fix a bug. This should be the final bug I find as part of my audit of everywhere we compare characters to newlines in layer 3 of the edit/ app. Pretty messy implementation, but we'll clean it up now.
* 3952Kartik K. Agaram2017-06-241-11/+10
|
* 3951Kartik K. Agaram2017-06-2422-6407/+6556
|
* 3950Kartik K. Agaram2017-06-242-4/+86
| | | | | | Fix a regression caused by commit 3919. Thanks Juan Crispin Hernandez for running into this.
* 3949Kartik K. Agaram2017-06-241-0/+9
|
* 3948Kartik K. Agaram2017-06-242-0/+13
|
* 3947Kartik K. Agaram2017-06-241-3/+5
| | | | Fix CI.
* 3946Kartik K. Agaram2017-06-232-6/+6
| | | | Fix the failing scenario of commit 3944.
* 3945Kartik K. Agaram2017-06-231-33/+51
| | | | | Fix a discrepancy between fake screen and real terminal behavior. (See recent commits.)
* 3944Kartik K. Agaram2017-06-232-2/+50
| | | | | | | Reintroduce the failing test of commit 3938. It has two problems: a) it's failing, and b) it's not failing the same way as with a real screen.
* 3943Kartik K. Agaram2017-06-236-153/+6
| | | | Undo commit 3938 and almost everything after. Let's do this right.
* 3942Kartik K. Agaram2017-06-235-38/+106
| | | | | | | | No, my conclusion in the previous commit was wrong. When you print a character on the right margin, the cursor coordinates always wrap around to the left margin on the next row. It's just that if you're at the bottom of the screen, scrolling gives the impression that the row didn't change.
* 3941Kartik K. Agaram2017-06-235-14/+49
| | | | | | | | | | | | | | | | | Even though the bug of commit 3938 is now fixed, I'm still trying to track down why the failure looked different on the fake screen than on the real one. Snapshot as I try to track down the difference. One key lesson is that the approach of commit 3860 -- updating the cursor before rather than after printing each character -- turns out to be untenable. A sequence of `print` followed by `cursor-position` needs to behave the same as the real screen. But it's still not clear how the real screen. When you get to the end of a line the cursor position wraps after print to the left margin (column 0) on the next row. When you get to the bottom right the cursor position wraps to the *bottom left* margin. How the heck does it know to scroll on the next print, then? Is there some hidden state in the terminal?
* 3940Kartik K. Agaram2017-06-221-1/+1
|
* 3939Kartik K. Agaram2017-06-224-6/+16
|
* 3938Kartik K. Agaram2017-06-222-4/+64
| | | | | | | Fix an out-of-bounds write to the screen when sandboxes aligned just right. Thanks Ella Couch for reporting this issue.
* 3937Kartik K. Agaram2017-06-222-4/+23
| | | | | Fix screen-checking functions to handle fake screen after scrolling. I can't believe I forgot about this during commit 3882.