| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Other options considered for 'retro':
'teletype': perhaps most accurate, but arcane
'chat': captures that you have to hit 'enter', but not the rendering
'wrap': captures the auto-wrap when printing text but not that you have
to hit 'enter' when typing
'text': useful as a synonym of 'chat' while conveying more information
in other meanings, but too generic, nobody will get it
Why do the input and output options have to be entangled like this?
|
| |
|
|
| |
Tests for terminating when there's just helpers left.
|
| | |
|
| | |
|
| |
|
|
| |
Simpler to just always sleep, whether or not a character was received.
|
| | |
|
| | |
|
| |
|
|
| |
When all you have left to run are helper routines, end the simulation.
|
| |
|
|
|
|
|
|
| |
The problem is that once main exits it takes two characters at minimum
to truly quit: one to fill the buffer and another to overflow it and
trigger the deadlock detector.
Not the cleanest way to exit in the world either, death by deadlock.
|
| |
|
|
| |
Time to write some tests for the chessboard app.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Fork syntax is now: fork <function> [global space] [max cycle limit] args*
|
| | |
|
| |
|
|
| |
Cleaner trace for 'convert-braces'.
|
| |
|
|
| |
Cleanup trace a little.
|
| |
|
|
|
| |
Disquieting that I can't make each of these five tests fail in
isolation. We have to fix them all at once.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
I could swear there was an issue earlier where tagged-values had to
contain pointers for some core function. But I can't find it anymore.
Ok, assume we can store primitives in it and pointers only for
aggregates (and-records and arrays).
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Dog slow, though. Drawing the sprite for a single piece takes 12s or
30ms/pixel for 400 pixels. A third of that is the actual racket overhead
of drawing pixel by pixel, which would in itself be too much. We need
bitblts.
(Black queen pixels derived from http://www.wpclipart.com/recreation/games/chess/chess_set_1,
after scaling down to 40x40 and replacing external white pixels with
transparent ones in Gimp.)
|
| |
|
|
| |
Just prints an empty board so far.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
'default-scope' is now 'default-space'
'closure-generator' is now 'next-space-generator'
The connection to high-level syntax for closures is now tenuous, so
we'll call the 'outer scope' the 'next space'.
So, let's try to create a few sentences with all these related ideas:
Names map to addresses offset from a default-space when it's provided.
Spaces can be strung together. The zeroth variable points to the next
space, the one that is accessed when a variable has /space:1.
To map a name to an address in the next space, you need to know what
function generated that space. A corollary is that the space passed in
to a function should always be generated by a single function.
Spaces can be used to construct lexical scopes and objects.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Amazing how quickly we need tests or manual QA.
|
| | |
|
| | |
|
| |
|
|
|
| |
Now chessboard is faster than in my super-late-bound language
(https://gist.github.com/akkartik/1291243). Reassuring.
|
| | |
|
| |
|
|
|
|
| |
Computing length of a 32-long list takes 2x a 16-long list.
But 64-long takes 3x 32-long.
Why? No idea yet. No insights from counting calls.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This took a couple of hours to track down. I had to shrink down to a 2x2
chessboard, isolate a half-move (just a square to clear) that triggered
an error, then hard-code the half-move to make it non-interactive, then
copy my changes over to the non-cursor version in chessboard.mu, then
start debugging trace. And then I found I was using an 'index-address'
rather than 'index' to go from a board to a file-address inside
'make-move'. And that was corrupting the array of file pointers.
Things I wish I had to help me here:
a) a type checker.
b) more speed. Are lists slowing down super-linearly? need an arc
profiler.
c) a side channel for traces even when the program is in cursor mode.
I do have that (hence the 'new-trace' before calling main), but for
some reason it wasn't convenient. Just had to buckle down, I think.
d) the right '#ifdef's to switch between hard-coded move and
interactive move, text vs cursor mode, etc.
e) just in general better curation of traces to easily see what's
going on. But that's just a pipe dream.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
No tests. Let's have some fun.
As a first step, a 'list-length' function. Iterative version is 25% faster
than recursive (60 vs 45 seconds).
|