| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
| |
..now that we support non-integers.
|
| |
|
|
|
|
|
|
| |
Mu allows us to use multiple ingredients/products without commas, but
make sure we don't.
$ grep "<- [^ ]\+ [^#\[,]* [^#\[,]*$" *
$ grep "^[ ]*[^ #,][^#,]* [^#,]* <- " *
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Also a bugfix in break to label, because I noticed the screen wasn't
being cleaned up on quit.
|
| | |
|
| |
|
|
|
|
| |
Lots mixed into this commit:
some off-by-one errors in display.cc
a new transform to translate jump labels that I'd somehow never gotten around to supporting
|
| | |
|
| |
|
|
| |
buffer-lines works, at least.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I tried to bring too much into this commit, and paid the price with some
debugging effort. Still havent't tried to enable line buffering, but
I'll take a snapshot.
Some tests are failing because of the huge hack in the scheduler.
For a while I thought there was a bug in termbox because I kept seeing
segfaults and valgrind complained about out-of-bounds access. But that
was just subsidiary threads trying to print to the screen after I'd
returned to console mode.
Maybe I should add a test for send-keys-to-channel. Or just use a fake
keyboard rather than a channel.
And *then* there's the fact that the interaction is molasses slow.
Slower than the arc version even though the tests run so much faster.
And what's with the long pauses in printing strings to screen?
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Still need a nice syntax for managing the routine under test.
|
| | |
|
| |
|
|
|
| |
I spent a couple of hours debugging this because routine-state only
sometimes writes to its product. This is unacceptable. Fix this first.
|
| |
|
|
|
|
|
|
|
| |
Just to put all our new test primitives through their paces, and iron
out any kinks.
Just the one chessboard scenario is taking 1.5-2.5x all the tests we've
written so far. But we're starting from a faster baseline, that was the
point of the C++ port. I also have -O3 optimizations in my back-pocket.
|
| |
|
|
| |
I've tried to update the Readme, but there are at least a couple of issues.
|
| |
|
|
|
|
|
|
|
| |
Arc version is 15% faster (8.3s vs 9.9s for print-board test) if I use
an intermediate array rather than list. I'm starting to question the
whole tagged-value design, and the current tagged-value implementation
was treating squares as integers in one place anyway, so its benefits
for typing are not great. Might as well create a good baseline for the
Arc vs C++ performance test.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Swap printing generalized objects using arc's infrastructure to be the
$-prefixed debug helper, while the erstwhile $print-key-to-host becomes
the primitive print-character to host.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
I dunno, this may all be a wild goose chase. I haven't been disciplined
in tagging in-out arguments in 'read-move' and its helpers. Maybe I
should just drop those 'nochange' oargs in 'read' and 'write'. Maybe I
should reserve output args only for return values that callers might
actually care about, and use more conventional metadata like 'const' or
'unique' or 'inout' on other args.
|
| |
|
|
|
|
|
|
|
| |
I just did this in 611; what's the point of all this if tests can't stay
passing?
I don't understand why buffered-stdin.mu needs to preempt itself. stdin
and buffered-stdin somehow end up sharing a single circular buffer,
that's probably causing a race condition.
|
| |
|
|
|
|
| |
2 bugs found:
a) Have to slurp the newlines.
b) Have to clear the line-buffer at the start of each line.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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?
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
'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.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
Once we started printing we uncovered that we were storing positions by
rank rather than by file as we'd planned.
Amazing how slow it is. Might be interesting to try to compile it down
to straightforward assembler and see how fast it gets.
|
| | |
|
|
|
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).
|