| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Finally, albeit too late for my demo.
|
| |
|
|
| |
No idea why this was wrong, but whatever..
|
| |
|
|
|
|
|
|
|
| |
We're starting to hit the limits of my 8GB RAM, to the point where I'm
starting to economize on the size of the screen. Time to start thinking
about reclaiming memory.
Anyways, test now fails in the right place. I'm failing to propertly
render intermediate lines between sandboxes.
|
| | |
|
| |
|
|
| |
We're ready to start displaying multiple sandboxes.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Cleanup below editors is now all done.
|
| | |
|
| |
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
Current model: you click on something to put it on the editor at the top
of the column. Worth a shot.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
I probably need another test like editor-clears-last-line-on-backspace,
but we aren't testing the boundary, and we're pushing on anyway.
|
| |
|
|
| |
Leaves a line blank after printing result/warnings, for some reason.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Hmm, this is undesirable, that recipes don't need to explicitly reply.
Need to fix. Also need to have run-interactive create scenarios at some
point.
|
| |
|
|
| |
Pushing back some of the weight of repetitive boilerplate.
|
| |
|
|
|
| |
This is starting to look good! I need to add some tests for
render-string, but we'll see.
|
| |
|
|
| |
The trick is to check for more events and not bother rendering if so.
|
| |
|
|
| |
Switch to F10 because F9 is in use under my setup.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Don't render all the editors on every single keystroke, render just the
one that was modified.
This will also be useful for our next step: heterogeneous editor widgets
responsible for their areas of screen and doing their own rendering and
responding to events.
|
| | |
|
| |
|
|
| |
The menu bar needs separate recipes to render and respond to events.
|
| |
|
|
|
| |
Of course, editors might begin below other editors; this is a stopgap
solution. Yagni, yagni, yagni.
|
| |
|
|
|
| |
More sketching out of a bare-bones scenario. What should happen when we
press F9? Print a result somewhere?
|
| |
|
|
|
|
| |
Simpler gradient computation.
But in the end it looks better when the gradient is so subtle as to be
irrelevant. Might as well eliminate the gradient altogether.
|
| |
|
|
| |
But integer division is a fail, as expected.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Key idea: wrap whenever you type at the right margin, don't wait for
line to grow past it. That way you always leave room to acquire the end
of the line, and you never have to worry about wrapping just the cursor
but not the line. Simplifies a lot of logic.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I started fixing scenario editor-inserts-character-at-wrapped-cursor,
but as I work further I notice there's an irreconcilable ambiguity in
the approach of letting the cursor wrap in a non-wrapped line: if a
cursor is at column 0 and the previous line occupies the entire width,
should the next character you insert go before (assuming a wrapped
cursor) or after the newline (assuming you're at the start of the next
line)? No way to distinguish the two cases.
One approach would be to delete the newline and have the cursor replace
it with whatever you type. Then you have to hit a newline again to
separate.
But the simpler way is to simply wrap the moment the line grows to
width-1, always leaving room for the cursor. Yeah, let's switch to that
approach.
|
| |
|
|
| |
Move experimenting with wrapped lines to the right column.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
We'll start out with just boxes on the right. Unlike the left with its
dotted boundaries, the boundaries on the right will be solid lines, to
indicate that they are isolated from each other even as they take from
all the recipes on the left.
As students grow more advanced we'll provide some way to 'pop up' the
pre- and post-condition fields inside each sandbox. Those will also have
dotted boundaries with the rest of their sandbox.
|