| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
How did this image get corrupted?
|
| | |
|
| |
|
|
|
|
|
| |
No restore. We'll have to do that manually for the first lesson.
The version control is also super ugly; every save creates a new commit.
But that's ok; version control is just the backup of last resort.
|
| | |
|
| |
|
|
|
| |
We want to avoid accidentally mixing lessons into ourselves. Require
users to git-enable it first.
|
| |
|
|
|
|
|
| |
Very rudimentary ability to read/write from file+version control. No
control over name.
Recipes now saved. But what to do about sandboxes?
|
| |
|
|
|
| |
Otherwise can't use colors inside recipes! This will do for now, until
we start distinguishing '[' at end of line.
|
| | |
|
| |
|
|
|
| |
Nice to get a couple of easy wins under my belt after the troubles with
memory corruption.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
The recent session makes me weary of deleting comment counts from inside
strings, and the newlines everywhere take up vertical space. Considered
println like pascal/ruby, but I'd like something I can add/remove at the
end of existing prints. So this hack for $print.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rendering the screen was easy to fix: I'd just never gotten around to
printing anything but spaces.
Rendering the 'screen:' was harder. Turned out I wasn't incrementing
row, and so the screen contents were overwriting the header. Much
fiddling with row ensued. Still unclear if I have a sane policy for
managing row. I don't leave cursor on start of next line after
render-string (relying on run-interactive to return strings terminated
by newlines) but I do so in render-screen.
Never mind, all architecture is illusion and all programs sit on the
edge of chaos. This is just the best way I know how to permit others to
periodically reclaim architecture from chaos by expending energy. But
it'll never be perfect.
Crash-only architecture for the win.
|
| |
|
|
|
|
|
| |
Between it and support for printing screens our tests take twice as long
to run as they did two days ago.
Still the one failing test. Finishing all this cleanup first.
|
| | |
|
| |
|
|
|
| |
Bring back my optimizations for avoiding unnecessary work. But they
shouldn't be needed for correctness, and they aren't.
|
| | |
|
| |
|
|
|
|
| |
Now we can investigate the remaining issues:
print-string to main screen not working to print 'screen:'
print-integer to toy screen not working to print '4'
|
| |
|
|
| |
I was counting locations when I should have been counting elements.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
| |
Doesn't work yet.
|
| |
|
|
|
| |
Debugging simulated-screen support is taking too long, and I suddenly
have a few higher priorities.
|
| |
|
|
| |
I'm writing to location 'screen' somehow that's not the raw location.
|
| | |
|
| | |
|
| |
|
|
| |
More evidence that the choice of 'before-cursor' was inspired.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
We stopped rendering just the widget under focus when we switched away
from the simplistic list of editors. Need to bring that back.
|
| |
|
|
|
| |
Profiling shows the bulk of time is spent in read_memory, canonize,
absolutize. But I'm not sure how to optimize those places.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
I keep forgetting about it. Until, that is, I run gprof. Even if I think
I need a memory profile, a cpu profile is a pretty good proxy.
|
| |
|
|
|
|
| |
But still no difference in either memory footprint or in running time.
This will teach me -- for the umpteenth time -- to optimize before
measuring.
|
| |
|
|
|
|
| |
Now we can reclaim allocated space. But the API's suspect. I still want
to provide some sort of tree of allocations. For now we'll use this only
to reclaim default-spaces. That's next.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Turns out to not affect memory utilization or run-time. At all.
But still looks nicer and requires less fudging on our part.
|
| |
|
|
| |
Let's see how much this helps edit.mu.
|