| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
Pull in a _different_ function than `next-word` (commit 5092) into a shared
file between phases. Let's see how this goes.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Realization: 'next-word' can't be reused in converting string literals,
because it has to understand string literals.
Let's just keep each phase self-contained.
|
| |
|
|
|
|
|
| |
Start using the new newline escape in string literals everywhere.
I could use it more aggressively, but it makes tests harder to read. So
only one line of text per string for now.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Fail early when writing to a fake file runs out of space. Makes debugging
tests easier.
Reads from files, on the other hand, are only buffering to a temporary
stream, so it makes sense to silently stop when they run out of space.
In the process I uncovered a testing bug in pack.subx: I was missing a
trailing space in the expected result, but the test still passed because
the space was getting truncated. Being principled about aborting on overflow
by default will help avoid such issues.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
write-stream-buffered isn't a clean abstraction. Ignoring the 'read' index
of a stream is a hack. It's just saving us the trouble of a rewind-stream.
So make it a helper of pack.subx rather than part of the standard library.
|
| | |
|
| |
|
|
| |
Done with pack.subx?!
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Testing conversion of multiple lines in a data segment.
Bugs fixed:
1. Stack issues in next-token helpers.
2. Needed to teach next-token to avoid newlines.
3. rewind-stream(line) before passing it to convert-code or convert-instruction.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Several bugs found after performing multiple loops through convert-data.
This has been a general pattern: given how unsafe the x86 'language' is,
the regular amount of testing with a single input doesn't really give sufficient
confidence. Ever-present is the possibility that I forgot to pop something
from the stack, either a spilled register or a local. Calling functions
multiple times seems to help detect such bugs. So far I've been doing this
extra level of testing implicitly when I build the next higher abstraction.
But with `convert-data` the buck stopped, and much painful debugging ensued.
One thing that would help is if `write` on streams didn't remain silent
on overflow. But we actually need that sometimes, when streams are used
as buffers.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Add a bounds-check to `next-word`.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Yet another redrawing of responsibilities between convert and its helpers.
In the process I discovered a bug in `write-stream-buffered` which ended
up taking me through a detour to extract `browse_trace` into its own tool.
It turns out just having long buffers is enough to need browse_trace. Simple
operations like clearing a stream swamp a flat view of the trace.
|