| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Back to checking render performance everywhere.
|
| | |
|
| | |
|
| |
|
|
|
| |
All scenarios should use just numeric locations, and 'run' should
encapsulate the code under test.
|
| |
|
|
|
| |
Standardize on whether screen operations will explicitly write to
'screen' inside scenarios. (Answer: not for setup code, at least.)
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Get all tests passing again. Actually slower now than before, thanks to
double-render when editing the sandbox side. But that is temporary.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
First step: drop the existing optimization of not redrawing after every
character. Gives the editor a jumpy feel. I'm also hoisting the render
into handle-keyboard event as a first step to duplicating it everywhere.
One test temporarily failing: we're gonna sometimes forget to draw the
line below editors.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
| |
I'm starting to optimize screen-drawing. If I get it wrong, this will be
a work-around.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
I think this can never trigger because 'cursor-column' can't be greater
than 'right'.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Now that it's time to optimize we're gonna go over our code for
externalities. Like in this case: not telling mu about what has changed.
|
| | |
|
| |
|
|
| |
Turn off profiling.
|
| | |
|
| |
|
|
| |
Minor issue in building until just layer 32.
|
| |
|
|
|
|
|
|
|
| |
No, 2001 is no good. Phony targets can't early-exit if everything's
built. New approach:
$ CFLAGS=-g make && ./mu test
etc.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Let's stop hackily editing compiler flags in makefile.
I considered modifying the 'mu' script as well, with cases like this:
1. mu test -- don't optimize
2. mu test edit.mu -- optimize
3. mu test edit.mu just-one-test -- don't optimize
4. mu edit.mu -- interactive; optimize
5. mu -- just help message; don't optimize
But that seems brittle for all the added complexity. From now on to
build quickly just do:
$ make dbg && mu test
etc.
|
| | |
|
| |
|
|
|
| |
Still worth trying to optimize, though. Current lowest-hanging fruit:
stop having index/index-address copy entire arrays around.
|
| |
|
|
|
| |
Spent a while trying to understand why editing a slightly larger program
was so much slower. Then realized I'd managed to disable optimizations.
|
| | |
|
| | |
|
| |
|
|
|
| |
The slowness of the environment -- even for code spanning just a couple
hundred lines -- is the biggest priority right now.
|
| |
|
|
|
| |
Not strictly necessary, but it might help me stage the introduction of
arrays and 'new'.
|
| |
|
|
| |
Thanks Caleb Couch.
|
| | |
|
| | |
|