| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
The at-head-of-list? is a really ugly hack, though.
|
|
|
|
| |
We're now down to 4 failing tests. But these will require surgery.
|
| |
|
| |
|
|
|
|
|
| |
Still a couple of failing tests before I switch gears to breaking down
symbols containing infix.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Like parenthesize, I'm copying tests over from https://github.com/akkartik/wart
Unlike parenthesize, though, I can't just transliterate the code itself.
Wart was operating on an intermediate AST representation. Here I'm all
the way down to cells. That seemed like a good idea when I embarked, but
now I'm not so sure. Operating with the right AST data structure allowed
me to more easily iterate over the elements of a list. The natural recursion
for cells is not a good fit.
This patch and the next couple is an interesting case study in what makes
Unix so effective. Yes, you have to play computer, and yes it gets verbose
and ugly. But just diff and patch go surprisingly far in helping build a
picture of the state space in my brain.
Then again, there's a steep gradient of skills here. There are people who
can visualize state spaces using diff and patch far better than me, and
people who can't do it as well as me. Nature, nurture, having different
priorities, whatever the reason. Giving some people just the right crutch
excludes others.
|
| |
|
|
|
|
| |
First step: undo operator support in tokenization.
|
| |
|
| |
|
|
|
|
| |
The only remaining long lines now are in 'pair' and 'with'.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
http://arclanguage.org/item?id=11068
|
| |
|
| |
|
|
|
|
|
| |
This is going better than expected; just 3 failing tests among the new
ones.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
General plan:
stop skipping newlines during tokenization
introduce a new indent token, initially skip it transparently
start doing cleverer things
|
| |
|
| |
|
|
|
|
| |
Thanks Sumeet Agarwal for the suggestion.
|
| |
|
| |
|
| |
|
|
|
|
| |
This is an old 'optimization' that turns out to not actually matter.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Refreshing the fake screen is still a heavyweight operation. Double-buffering
makes it less obvious but doesn't actually reduce the amount of work. We
need to ensure that we do enough work between refreshes to make them economic.
|
|
|
|
|
| |
Before I only separately counted calls at each stack depth. I don't remember
if that seemed good enough or was just an oversight.
|
|
|
|
|
|
|
|
| |
Font rendering now happens off the real screen, which provides the effect
of double-buffering.
Apps can now also use convert-graphemes-to-pixels for more traditional
double-buffering.
|
|
|
|
|
| |
I should really stop using /disp8 jumps at the top-level given how inconvenient
it is to check for overly large offsets.
|
|
|
|
|
| |
Roll back to commit 70919b45f0. Recent commits add lots of extra function
args for dubious benefit.
|
|
|
|
| |
Looks like what's slowing down screen rendering is in fact _font_ rendering.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Two interesting things:
- We don't really need double-buffering for rendering the screen on the
sandbox as a progress indicator. Everything else is untouched, and render-screen
should be doing that as well.
- Rendering just pixels of the fake screen is buttery smooth. It's the
_graphemes_ that are slowing things down. Even though there's so many
fewer of them!
As a result, drawing the fake screen less frequently in `evaluate` doesn't
actually help with flicker. Even though it'll make the debug cycle shorter.
So my current plan is to attack flicker in isolation before I mess with
the render frequency.
In this commit I optimized away the cursor handling. Still doesn't seem
to be helping. In fact it actually seems _worse_.
|
| |
|
|
|
|
|
|
| |
Rename cells containing screens to screen vars because of the ambiguity
that each grapheme in fake screens is represented by a type screen-cell.
While we're at it, we also analogously rename keyboard vars.
|
| |
|
| |
|
| |
|