dgdebug.exe bugs...

Authoring Dialog
1

I don’t believe either of these issues are recorded on GitHub, so I thought I’d post them here, especially because perhaps there is a better way to do what I am doing!

Spaces in Filenames

The first issue is this: dgdebug.exe on Windows can’t cope with spaces in filenames, even if quoted. I first ran into this in Git Bash, but it seems to apply to the standard Windows terminal also:

Screenshot of dgdebug.exe being run for a file with spaces, then failing to run as it is trying to open a file just named after the first word in the filename.
Screenshot of dgdebug.exe being run for a file with spaces, then failing to run as it is trying to open a file just named after the first word in the filename.507×175 8.99 KB

For the past couple of years I’ve just worked around this by writing a little script to copy my source file to a new name and then run dgdebug.exe against that, but I figured now might be the time to actually bring this up, as I’ve run into another issue…

@restore outside the CWD

For my WIP, I’m testing it by running different transcripts through dgdebug.exe using @restore. Over time I’ve built up a library of different files that will take me to particular characters or scenes so I can test my changes - I guess I’m kind of approximating the Inform 7 skein, and I know someone was working on an equivalent for Dialog - I’m not sure if there’s a better process I could be using?

But assuming there isn’t, I now have a lot of these files, and I decided to move them into a sub-directory. Except…

dgdebug.exe is run for a file called fordebug.dg, which loads, however once @restore is entered, it complains that there is no such file as fordebug.dg
dgdebug.exe is run for a file called fordebug.dg, which loads, however once @restore is entered, it complains that there is no such file as fordebug.dg505×421 14.3 KB

To my ignorant eye, this looks like loading the test transcript from a different directory is changing the current working directory, at which point the debugger chokes. But whatever is causing it… it would be nice to be able to put my test transcripts in their own directory. :slight_smile:

1 Like
2

Set up a separate “(game)-debug” directory with a working copy of your game file and the resulting transcripts?

1 Like
3

Good idea! Since I was already using a script to run the debugger (originally to rename the file without spaces, and now because I’ve divided the source up into multiple files) I tweaked it to do as you suggested…

The following worked in Git Bash (assumes that you’re running in the source directory and that a “tests” directory exists):

#!/bin/bash
#
# Run the game in the debugger.
#
# source files:
SOURCE=(vasily.dg case1.dg common.dg stdlib.dg)
#
# copy them to where our test transcripts are:
#
for i in "${SOURCE[@]}"
do
   cp "$i" tests/
done
#
# run debugger:
#
./dgdebug.exe "${SOURCE[@]}"
#
# now delete the copies:
#
for i in "${SOURCE[@]}"
do
   rm "tests/$i"
done
1 Like
4

Hmm! That’s certainly not ideal.

The problem is that the Dialog programs are designed for a POSIX environment first and foremost, which means they expect their parameters in the standard argc/argv format (and then POSIX getopt is used for further parsing). But Windows doesn’t provide that format; instead, it provides the entire command line as a single string.

This isn’t a problem for programs executed in the terminal—there, whichever terminal provides POSIX support also handles things like quotes in command lines. But the debugger isn’t a terminal program; it’s a graphical program, using WinGlk for the interface. And this means Dialog has to convert the Windows command line into POSIX argc/argv on its own.

So that’s where the first bug comes in. It does this in a very rudimentary way: it doesn’t even use strtok, it just manually steps through the string and breaks at each run of spaces. It looks like MinGW specifically provides extra symbols __argc and __argv that do exactly what’s needed here…but it’s hard for me to test this, since I don’t have any machines with Windows on them.

If I can generate a new build of the debugger that uses these special symbols instead of parsing the arguments manually, would some Windows-users be willing to test it? I’m a bit hesitant to use compiler-specific extensions to the language when Dialog tries to be maximally-portable C, but the Windows support is already very much a hack, with POSIX support being primary.

1 Like
5

The @restore one, unfortunately, may be beyond my ability to fix. Here’s the guts of the @restore command:

	if((lines = fs_readfile(&nline, "input"))) {
		free(dbg->pending_input);
		dbg->pending_input = lines;
		dbg->nalloc_pend = dbg->pending_wpos = nline;
		dbg->status = ESTATUS_RESTART;
	}

In other words, it just delegates to fs_readfile, which is implemented separately for different environments. And on Windows:

	fref = glk_fileref_create_by_prompt(fileusage_InputRecord|fileusage_TextMode, filemode_Read, 0);
	if(!fref) {
		report(LVL_ERR, 0, "Operation cancelled.");
		return 0;
	}

	if((s = glk_stream_open_file(fref, filemode_Read, 0))) {
		while(glk_get_line_stream(s, linebuf, sizeof(linebuf))) {
	// etc...

It just delegates to the Glk file-opening routines. Glk then handles all the problems of locating, opening, and reading the file. So when that’s going wrong, I think the problem is in the Glk library.

Glk, in general, has no concept of directories—it’s the library’s responsibility to find all the files the program asks for (and to avoid malicious programs overwriting system files). And it sounds like WinGlk is messing that up. For now, I’m afraid the best I can recommend is your script that moves the files around before testing.

1 Like
6

If you push the changes to a dev branch, I can certainly give it a whirl (I’ve already been using the ifcomp2025 branch to compile my WIP).

1 Like
7

All right! If you can build it yourself, the windows-argv branch has the experimental changes. I also made this temporary pull request so that the automatic build process would make the release files for me. If I did it right, it should be here.

8

You could pinch PuTTY’s reimplementation of console-mode argv splitting for GUI-mode programs.
(MIT licence; with extensive comments and test suite; bug-compatible in corner cases, because the PuTTY suite wanted consistency between its console-mode and GUI apps.)

1 Like
9

If the MinGW extension doesn’t work, I’ll check on this next! I’m hesitant to do anything too elaborate when I can’t test it myself—sending new builds to someone else every time I adjust something means a very long development cycle—but I’m also always happy to get pull requests from others too!

10

Oh yes, I forgot to say—this build also prints the resulting argc and argv values to the terminal before launching the window, for debugging purposes. Please send those to me along with any reports!

11

Appears to work…

Screenshot of dgdebug.exe correctly handling a space in a filename.
Screenshot of dgdebug.exe correctly handling a space in a filename.912×263 15.9 KB

In copy-pasteable form:

PS D:\deleteme> .\dgdebug.exe "Forsaken Denizen.dg" stdlib.dg
cmdline ""Forsaken Denizen.dg" stdlib.dg"
 0: "D:\deleteme\dgdebug.exe"
 1: "Forsaken Denizen.dg"
 2: "stdlib.dg"
12

Excellent! Since the Windows version is (currently) only meant to be built with one specific compiler toolchain, I think the nonstandardness isn’t worth worrying about. I’ll remove the debugging output and pull this into the ifcomp2025 branch, and then see about getting it into main.

1 Like