| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
But still no difference in either memory footprint or in running time.
This will teach me -- for the umpteenth time -- to optimize before
measuring.
|
| |
|
|
|
| |
Turns out to not affect memory utilization or run-time. At all.
But still looks nicer and requires less fudging on our part.
|
| |
|
|
|
|
|
|
| |
chessboard finally passing all its tests. What made this hard was that
for some reason one of the background routines in the main chessboard
test wasn't terminating like it used to. And so it was polluting *later*
tests. Just clean up that source of contamination for now. Later we'll
think about routine termination.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
I still have no idea how it will hook up to the rest. Parsing traces
will be slow. I can't test it like this. Writing the large trace data
structure to mu memory will be slow. But let's at least see the new
algorithm in action. (Not in this commit; so far we just render the
first n lines from the chessboard trace, and wait for a 'q' or 'Q' to
quit.)
|
| | |
|
| |
|
|
| |
It was all going to laboriously writing out 300+ MB to disk.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
After like 40 seconds (because of the 120-column screen), but whatever.
The final bug was that clear-screen wasn't actually working right for
fake screens.
(The trace is too large for github, so I'm going to leave it out for
now.)
|
| |
|
|
| |
Still failing, though.
|
| | |
|
| |
|
|
|
| |
Delete comment-out marker from inside mu strings. Have to do this
manually for now.
|
| |
|
|
|
|
|
| |
CRLF still shows as two newlines, though. Cross that bridge when we get
to it.
The new chessboard test is still hanging, though.
|
| |
|
|
| |
..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.
|
| | |
|
| | |
|
| | |
|