Being able to specify the order of compilation of your files is important; it affects which rule gets matched first.
I’d also love to be able to have my unit tests run as part of the workflow, ideally before compiling or delegating off to the skein. dgdebug will exit with status 1 if a test fails, or status 2 if there’s a fatal error. There’ll need to be a way to specify what needs to be included for each test file; a really simple way would be to read the comment at the beginning of the test file, which by convention contains the exact string to invoke the debugger. Whether test files live in src, or whether a test directory is introduced, is a choice to make.
Speaking of which, having a --flat option at project creation (and in the .edn file) would be nice. I don’t actually use dgt in my daily development because I’m not willing to split my project up among mutiple subdirectories, and this would be an easy fix for that. An option to initialize an existing directory full of already-written .dg files would be nice, too.
If dgt is setting itself up to be the centre of an author’s workflow, having it invoke aambundle to build targets for vintage hardware (currently just the C64) would be nice in response to something like dgt build --format c64, building the .aastory file and then the .d64 file to export to diskette or flash media. For that matter, having it run ozmoo on a .z5 or .z8 (or .zblorb) to produce output for systems that the Å-machine doesn’t currently support would be nice, too.
…which then makes having everything as an output type to specify a nice-to-have, too. And maybe vintage as well, for just the microcomputer stuff if you normally develop just for modern interpreters or the web?
The unit testing framework is currently checked in to the head of the Dialog source tree, along with some examples of its use, and I have a PR open for writing a testing chapter covering it. I was going to include coverage of using dgt for skein testing, if you think it’s mature enough to include at this point.
The ability to compile for multiple platforms without editing the EDN every time
The ability to specify slightly different files for each platform without editing the EDN every time
I currently have a platform/ directory full of platform-specific code, because what looks good on the web doesn’t necessarily look good on a Commodore 64.
Good news: looks like it works - I can get to a prompt, enter queries and have them evaluated, etc.
Unfortunately, I can’t work out how to get it to work with dialog-tool; previously, running java --enable-native-access=ALL-UNNAMED --class-path .\dialog-tool-2.0-rc-1.jar clojure.main -m dialog-tool.main skein new would start the GUI debugger, then when that was closed, open a web browser with the skein interface (non-functioning, of course). After renaming dgdebug_tty.exe to dgdebug.exe and pointing my dialog.edn at it, the same java command now just hangs indefinitely. I’m guessing this is a problem with the difference in how Windows handles piping input/output to/from a process, but I don’t have the knowledge or capacity to investigate in detail right now.
Possibly I spoke too soon here; I think that starting it inside Emacs on Windows may actually fall back to using pipes instead of a pseudo-terminal. So it is technically still working with no obivous issues, but I probably haven’t seen it working on a Windows based pseudo-terminal.
I’ve not had any issues running it in a cmd shell though, and the “modern” Windows terminal (the one that comes with Windows 11 and is optional for Windows 10) seems to be handling the ANSI escape codes. You get command history from the shell rather than the program, so the most obvious difference that I’ve noticed compared to running it on Linux is the lack of output paging.
If the shell is able to handle command history on its own, that’s great! And removes one of my main objections to recommending that people use the console version.
The lack of [more] is definitely unfortunate, though. I’m not aware of any way that a command-line program can get its terminal window size in C on Windows. If anyone does, please let me know!
So it should be possible to port the entire terminal version of dgdebug to Windows, but it’s going to require messing with a lot of things that I can’t really test. I’m going to put together a basic implementation, but after that, I’d like to hand over the debugging to someone who has both a Windows machine (to test it) and a Linux machine (to build it), because otherwise the testing loop is going to be glacially slow. Ideally this person can also test the integration with dgt.
If anyone is up for the challenge, I’ll make a new branch with the Windows version at some point this week.
dgt is a tiny, specialized, highly opinionated command line tool used to build, debug, and test interactive fiction created using Dialog.
Note: I’ve dropped this down from an RC (release candidate) to a beta because of the number of last minute changes. Which is great … people are using (or trying to use) dialog-tool! This may complicate things slightly if upgrading from 2.0-rc-1 to 2.0-beta-10.
What’s new in 2.0-beta-10?
In dialog.edn, renamed :format to :target, and it can now be multiple targets
dgt build and dgt bundle will compile for multiple targets
Now adds .exe extension when invoking external tools on Windows
You must have a recent version of Java installed. You must have the Dialog commands installed (see the full instructions for details).
Unpack the archive, and copy the dgt and dialog-tool-<version>.jar file onto your executable search path. You can also symlink dgt into a directory already on the search path.
┌──────────┬──────────────────┬─────────┐
│ Date │ Tag │Downloads│
├──────────┼──────────────────┼─────────┤
│2026-01-19│release-1a01-1.1.0│ 80│
└──────────┴──────────────────┴─────────┘
At some point, I’ll borrow at Windows machine and see what I can do to make things work. I believe there may be virtual machines I can run from my Mac as well. It’s a matter of time and enthusiasm … I’ll let you guess which I have less of!
Yeah, if the problem ends up being on the dgdebug side, I’d love to fix it! But I don’t have a Windows machine, nor any real understanding of how Windows pipes differ from POSIX ones.
Packaging for Windows isn’t the obstacle. I’ve just been downloading the .jar itself and running the same command the dgt script does. But it doesn’t appear to work and I don’t really know how to diagnose why not.
The next beta of Dialog Tool will be based on the new Dialog 1b/01 release and take advantage of some new dgdebug features. Primarily, it sets the output width to -1 (that is, no automatic word wrapping) and lets the browser do any word wrapping dynamically, rather than using a fixed 80 column width. This make the Skein more usable on smaller screens. The navbar is now more responsive when spacing gets tight.
Also, when opening an existing skein file, it will now immediately run a Replay All.
Hopefully I’ll find some time this weekend to release it.