| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
A long-standing problem has been that I couldn't spread code across
'run' blocks because they were separate scopes, so I've ended up making
them effectively comments. Running code inside a 'run' block is
identical in every way to simply running the code directly. The 'run'
block is merely a visual aid to separate setup from the component under
test.
In the process I've also standardized all Mu scenarios to always run in
a local scope, and only use (raw) numeric addresses for values they want
to check later.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Can't use type abbreviations inside 'memory-should-contain'.
|
| | |
|
| | |
|
| |
|
|
| |
It wasn't a phase-ordering issue after all..
|
| |
|
|
|
|
|
|
| |
We still can't check ingredient types, and even this is still a run-time
check. We'll need to start tracking recipe signatures at some point.
I've had to introduce a hack called /skiptypecheck. Time to get generics
working.
|
| |
|
|
|
| |
Now duplex-list is fully non-generic and only works with characters. But
we'll fix that in a bit..
|
| |
|
|
| |
Already I'm finding type errors in the programming environment.
|
| | |
|
| |
|
|
| |
Still to go: ctrl-k and ctrl-u.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Finally terminate the experiment of keeping debug prints around. I'm
also going to give up on maintaining counts.
What we really need is two kinds of tracing:
a) For tests, just the domain-specific facts, organized by labels.
b) For debugging, just transient dumps to stdout.
b) only works if stdout is clean by default.
Hmm, I think this means 'stash' should be the transient kind of trace.
|
| |
|
|
|
| |
Not yet useable, because we never ever stop coalescing operations. That
will happen when we introduce a second type of operation.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Should be a little bit more mnemonic.
|
| |
|
|
| |
First step to reducing typing burden. Next step: inferring types.
|
| |
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
| |
I forgot to check for nulls before writing prev pointers in doubly
linked lists. Tests were accidentally passing.
|
| |
|
|
|
|
|
|
|
|
| |
This uncovers an issue with this interface to duplex lists: the caller
needs to check the result and invalidate any other pointers if it's null
(i.e. the list is now empty)
We *could* try to encapsulate the list in a header to help the caller
manage header pointers. But heck, let's see if writing tests helps
call-sites stay on the straight and narrow.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|