Dgdebug for automation

Authoring Dialog
1

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.

1 Like
2

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.)

1 Like
3

you should expect the answer to your problem here:

https://core.tcl-lang.org/expect/index

(I’ll fess up: actually I have named “inquisition” an expect script of mine (not IF related) albeit it’s a tcl and not a phython extension…)

Best regards from Italy,
dott. Piergiorgio.

4

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?

5

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.

6

I guess that would make sense, but even on Windows, the compiler requires the command line. I’m surprised the debugging tools don’t.

7

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”).

1 Like
8

It would be very useful if there was a debug command to turn the display paging off, for example, to allow someone to turn it off immediately before using @replay to avoid all of the [more] prompts, but then let them turn it back on later to continue playing normally.

Using pipes instead of a TTY gets around it for automation purposes, but that also presumes that the display area is always tall enough to fit the output.

9

In other words, you’d like a way to turn paging on and off interactively, within the console?

10

If there’s a use case for this, it wouldn’t be too difficult to add. This is how it’s currently handled in the Linux version (term_tty.c):

int term_sendlf() {
	fputc('\n', stdout);
	unread_lines++;
	if(term_height > 1 && isatty(1)) {
		if(unread_lines >= term_height - 1) {
			term_effectstyle(0);
			fflush(stdout);
			morefunc();
			unread_lines = 0;
			return 1;
		}
	} else {
		unread_lines = 0;
	}
	return 0;
}

So I could just add a new global, more_disabled or the like, which is also checked in that if-statement. Then a new debugging command would toggle the state of this global.

Alternately, there’s currently a way to force a particular width, overriding what ioctl reports. A similar option could force a particular height, and setting this to 0 would mean “assume everything always fits the screen”.

(The Windows version leaves it entirely up to the Glk library, so unfortunately there’s no way to do it there.)

11

Yes. Beyond trying to automate it I think that would be useful for someone who manually uses @replay too.

Do you mean that there is already a debug command to do that, or just that it is already possible internally?

12

Oops, I forgot to reply to this!

It’s currently possible internally. There would need to be commands added to control it interactively.