I’ve posted an update to the Glulxe interpreter on my web site (eblong.com/zarf/glulx/). This contains the I6 debugger module which has been in “experimental” mode for a while now. It’s still experimental, but now it’s released, at least.
Compiling the debugger into the interpreter is still a nuisance. You need to:
- Uncomment the VM_DEBUGGER line in the glulxe.h header.
- Link in the libxml2 library. (This is a common Unix library which we need to parse Inform’s symbol-table debug file. Macs can get it through MacPorts or Homebrew; Linux can use the usual package manager; I don’t know how Windows works.)
- Compile with a Glk library that supports the debug channel. Right now this means CheapGlk or RemGlk. (Get the latest version off Github of either of these.)
- Compile an Inform game. For I6, use the -k switch to generate the gameinfo.dbg file. For I7, gameinfo.dbg is generated automatically in the project/Build directory when you compile in non-release mode.
The CheapGlk build is the easiest to use. You can type something like
glulxe -D --gameinfo gameinfo.dbg output.ulx
With the -D switch set, any input line which begins with a slash is treated as a debug command. (Which is a terrible UI! CheapGlk is always the easiest way to do Glulx stuff with a terrible UI.) You could type “/bt”, for example, and see the current VM stack. (This will always show the KeyboardPrimitive() routine, because of course what the VM is doing is waiting for line input!) There are a few other debug commands; type “/help” for a list. You can print global variables and set breakpoints. Not much else.
The RemGlk build works the same way, except it doesn’t have the stupid slash-prefix UI! Yay! Debug commands come in through a dedicated channel which can’t be confused with line input! Yay! …Except RemGlk is only for people who enjoy typing JSON data. Sorry.
RemGlk can be used with regtest.py (the testing script) and with my remote-if-demo… both of which have been updated to support the debug channel. I’ll go into more detail if anyone wants. It’s all still proof-of-concept stuff, but now I’ve proved the concept with enough permutations of libraries that I’m willing to call it a release.
I’ve implemented the debug channel in GlkOte 2.2.4 (also just released) (it appears as a floating pane in the HTML). However, there is no debugger in Quixe yet. It’s conceptually just a port of the Glulxe code into Javascript, no big deal; I just haven’t done it yet.
Anyway, this is another step towards built-in debugging in the I7 IDE. What’s still missing?
- The IDE would have to implement the debug channel. This is just a way to get text in and out, so it’s pretty simple as UI goes. It would be a floating pane, I suppose.
- The debugger would have to be made aware of I7 structures (rules, global variables, etc). How to do this is not obvious, I’m afraid. It operates entirely at the level of compiled VM code. We have a spec for how to map I7 source line numbers to I6 addresses, but I7 doesn’t implement it yet.