Still need to add debugging in instruction
execution, and perhaps add a better VM
constructor for debugging, that can still
allow for toggling the debug mode in the
middle of execution.

Later on, swapping over printing to stderr
to logging with and without debugging would
probably be more suitable.
---

Alright, got that fixed.
We're probably going to want to switch to 
logging instead of stderr printing, but 
this will do for now.

 vm/src/main.rs |  7 ++++++-
 vm/src/vm.rs   | 38 +++++++++++++++++++++++++++++++++++---
 2 files changed, 41 insertions(+), 4 deletions(-)

diff --git a/vm/src/main.rs b/vm/src/main.rs
index e4dd0ba..65fd85d 100644
--- a/vm/src/main.rs
+++ b/vm/src/main.rs

 fn main() -> std::io::Result<()> {
@@ -26,7 +30,8 @@ fn main() -> std::io::Result<()> {
     let image_file = args.image;
     let image = Image::from_file(image_file);
 
-    let mut vm = VM::new();
+    let mut vm = VM::new(args.debug);
+
     vm.load_image(&image);
     vm.run()?;
 
diff --git a/vm/src/vm.rs b/vm/src/vm.rs
index e5d7c93..6d33745 100644
--- a/vm/src/vm.rs
+++ b/vm/src/vm.rs
@@ -1,51 +1,83 @@
-impl VM {
-    pub fn new() -> Self {
+impl<'a> VM<'a> {
+    pub fn new(debug: bool) -> Self {
         Self {
             cpu: CPU::new(),
             memory: Memory::new(),
             screen: std::io::stdout(),
+            debug,
+            stderr_lock: std::io::stderr().lock(),
         }
     }
 
+    pub fn with_debug() -> Self {
+        Self::new(true)
+    }
+
+

+    fn debug(&mut self, buf: &[u8]) -> std::io::Result<()> {
+        if self.debug {
+            self.stderr_lock.write_all(buf)
+        } else {
+            Ok(())
+        }
+    }
 }
-- 
2.37.1

> and perhaps add a better VM constructor for debugging

For sure. I'm not very sold on `VM::new(bool)` and `VM::with_debug()`,
because they create some asymmetry. There's an "easy" way to create a VM with
debugging on, but there's none for no debugging. Maybe it's best to simply
not include the latter constructor. What do you think?

> Alright, got that fixed.
> We're probably going to want to switch to 
> logging instead of stderr printing, but 
> this will do for now.

Yeah, agreed.

Also, it seems like something broke with the mailing list's patch
recognition; it doesn't show diff hightlighting nor the usual patch controls.
Did you send the patch by standard means?

I snipped some of the diff's content that was also in the PATCH's first 
version, and that probably screwed it up.

There's a way to that correctly, right? Or should I just send the entire 
diff so that it shows up in each new version of the patch, for context's 
sake?

> There's a way to that correctly, right? Or should I just send the entire 
> diff so that it shows up in each new version of the patch, for context's 
> sake?

Yeah, you should just send the diff in its entirety, afaik. `git send-email`
will put the commit message at the top, then the diff, with the option to put
on a cover letter between the commit message and the diff. I believe that is
the only place you should edit things.