While we’re talking about software changes, I’d like to talk about changes to dgdebug to better support automation.
In this context, I’m thinking about the dialog-tool, which runs dgdebug in a background process, feeding it inputs, and capturing outputs.
One change that would be useful would be to redirect warnings about reloading of changed code to standard error, rather than standard out. Alternately, ensure that any such output is marked in a way that’s easy to extract.
Also, from a testing perspective, I’m trying to figure out a way to deal with the status bar. It would be great to include status bar content in some way.
I mean, in a perfect world, I would “send a request” to the debugger, and get back a JSON response w/ keys for output, status bar, errors.
I believe there is a further issue with the Windows build because there is no option to run it without the GUI frontend, and so there seems to be no way to send it input or receive any output.
(I was looking at connecting to it as a REPL from Emacs.)
That should be doable. Right now, all this stuff is put in a special style class; I think it should be possible to redirect that style class to stderr, with stdout just being the game’s output. If not, it can definitely be prefixed by whatever you want.
That’s going to be harder, at least if you want full control of positioning and such. Divs in a top status bar are handled fundamentally differently from divs anywhere else, and right now, the debugger just doesn’t even try.
Handling the top status bar like the inline status bar—that is, just showing all the text from it, without any fancy positioning—would be doable, though.
Doable, but very time-consuming, because it’s a fundamental change to how the debugger works. But debugger.c is where you’d want to start.
Hrm. I didn’t realize it couldn’t be built as a simple command-line application on Windows. I wonder why the Linux command-line build doesn’t work for that? Does it rely on ncurses or something?
I haven’t looked at the code, but I imagine it was a decision that the Windows build would only be used by people who wanted a GUI, and so this build has a dependency on Glk while other builds do not.
It has it’s own terminal handing code (term_tty) which would only work on Unixes. There is a neat little line-editor in there, as well as support for printing colored text.
You could make a version of that which works on the Windows consoles, the easiest is something very plain using just stdio.h (no colors, no line editing, no proper “get_key”).