Commits
each Token is now constructed/pushed into the vector directly
makes argument intent much clearer
- use slice pattern matching with Ok([]) instead of using r.is_empty()
- removed redundant closures from .map_err
- removed redundant return keyword in parser.rs
no longer considering it for this project
- split DataPointerOutOfBounds into DataPointerOutsideTapeLength and
DataPointerNegative
- split CellOutOfBounds into CellUnderflow and CellOverflow
- split IoError into IoReadError and IoWriteError
- removed a leftover comment
- current token in run loop now gets passed into each vm instruction
function for updated errors to access
- updated tokenizer to produce Token values instead of raw bytes,
storing byte value along with source position
- adjusted parse_brackets and VM::run to destructure the new Token type
for comparison and display
- paves the way for nicer error messages in the future
pairs well with tracing, allows you to watch your brainfuck scripts step
through in real-time
prints the current cell on tape, the value within, the current
instruction the interpreter is on, and where in the instructions the
VM::run function is at*
* although as of right now its just an integer pointing at the tokenized
string, not very useful if you have line breaks and such... still, its
a start!
- updated repeat test to account for new behavior
also bumped version number to 0.4.2
- switched from std::io::Read traits in read_raw & run ->
std::io::BufRead. this allows read_raw to consume any extra digits
from one input and prevent them from automatically being digested in a
subsequent input. thankfully i can just swap in the BufRead trait
without much fuss
- wrapped call to stdin in main in a new BufReader
- fixed test, i forgot about the wrapping behavior...
replaced VM::new with a VMBuilder that makes construction of test VMs
much more readable
additionally:
- rewrote VM call in main to use new builder
- bumped from version 0.3.5 -> 0.4.0
- updated all tests with new builder calls
each expects a different input mode
originally the input check for read_raw wouldnt discard excess bytes,
leading to possible stray bytes being picked up whenever the interpreter
needed to ask for a subsequent input
now once the 3 bytes are read, another loop triggers that drains excess
bytes so that doesn't happen!
the issue with this approach is that now its a bit brittle. it only
chucks one non-ascii digit at a time. so each subsequent input call will
chug on an input like `123AAA`. it still... works? but its ineffecient.
will fix later
- write_raw test also added
- updated ROADMAP
- bumped version number to 0.3.0
- renamed input/output in run -> reader/writer for clarity
- read_raw test added
- changed **numerical input/output** to something clearer, **8-bit i/o**
- added monomorphization goal under 8-bit i/o (seems cool, wanna try it
out)
- args for setting ascii/8-bit input & output individually
- defaults to ascii for both
prints the current cell on tape, the value within, the current
instruction the interpreter is on, and where in the instructions the
VM::run function is at*
* although as of right now its just an integer pointing at the tokenized
string, not very useful if you have line breaks and such... still, its
a start!
- switched from std::io::Read traits in read_raw & run ->
std::io::BufRead. this allows read_raw to consume any extra digits
from one input and prevent them from automatically being digested in a
subsequent input. thankfully i can just swap in the BufRead trait
without much fuss
- wrapped call to stdin in main in a new BufReader
- fixed test, i forgot about the wrapping behavior...
originally the input check for read_raw wouldnt discard excess bytes,
leading to possible stray bytes being picked up whenever the interpreter
needed to ask for a subsequent input
now once the 3 bytes are read, another loop triggers that drains excess
bytes so that doesn't happen!
the issue with this approach is that now its a bit brittle. it only
chucks one non-ascii digit at a time. so each subsequent input call will
chug on an input like `123AAA`. it still... works? but its ineffecient.
will fix later