Announcing: Dialog 1a/01!

Ladies, gentlemen, and miscellaneous! It’s been a full year in the making, but at last:

Dialog 1a/01 is released!

If you go to https://github.com/Dialog-IF/dialog/, you should see a new entry in the “Releases” section on the right.

That leads to Release release-1a01-1.1.0 · Dialog-IF/dialog · GitHub, where you can download the whole thing as a big ZIP file: the compiler source, prebuilt binaries for Windows, Mac, and Linux, and the new standard library version 1.1.0.

Changelog

This is the first release handled by the community, and per Linus’s wishes, we’re bumping the major version for the first time! We’re also taking this opportunity to unify the version numbers between the compiler, library, and manual.

Backend: color and background-color properties are now supported on Z-machine backend.

Backend: display:none is now tentatively supported on Z-machine backend, though spacing it properly can be difficult.

Backend: styles can be stacked on Z-machine backend, allowing for (for example) bold italics, or monospace reverse-video. Spans are also allowed inside status bars as a result.

Backend: fixed a bug that would crash the Z-machine if too many dictionary words were included in a wordmap, pushing the wordmap datatables past address $8000.

Backend: lists containing punctuation marks will now print with proper spacing on Z-machine during tracing.

Backend: Unicode characters are now allowed in dictionary words on Z-machine backend.

Backend: generated Å-machine files now include the names of style classes instead of only the numbers, which interpreters may use to improve their output.

Backend: resources can no include option strings on Å-machine backend; the meaning of these is left to the interpreter.

Backend: the Z-machine backend can more effectively calculate the screen dimensions, even in certain buggy interpreters.

Debugger: a new --numbered option shows the depth of the call stack with numbers instead of graphics during tracing. This makes the output significantly easier to understand with a screen reader.

Language: fixed a bug when unifying a list containing multiple instances of a new variable, like ($Y = [$X $X]).

Language: inline style predicates like (bold) are now deprecated. They’re still supported for now, but may be removed in a future release.

Language: new (current div width), (current div height), and (status bar $ with height $) predicates allow better control of status bar layout on Z-machine.

Compiler: the compiler now shows how close a project is to various limits, both backend-specific (like addressable memory on the Z-machine) and universal (the compiler architecture imposes a limit of $1e00 objects on any backend).

Compiler: the compiler now accepts JPEG files as well as PNG files for cover art.

Compiler: in projects that include a library, objects used in rules but never declared as topics (the * syntax) will produce a warning. This can be disabled on the command line.

Library: a new (gender-neutral $) trait will use the pronoun “they”, but without forcing plural verb endings as (plural $) does.

Library: serial commas in phrases like GET X, Y, AND Z are now properly understood. Previously, this would be parsed as GET X followed by TELL Y TO AND Z, which would generally produce an error.

Library: “meta” text (that is, text like “enabling score notifications” that comes from the program itself, rather than from the game) is now always wrapped in a (div @meta), which the author is free to style as they like.

Library: the program will backtrack to free heap memory before the final question, so that complicated parsing or status bars will no longer cause an overflow.

Library: a new (startup) predicate is exhausted before printing the (intro). Library extensions can use this for computations that need to run at the start of play.

Library: a default (appearance $) rule for pristine objects delegates to (initial appearance $), if defined.

The manual is included in the download, but you can also read it online. Check the version in the bottom left corner to make sure you’re looking at 1a/01; this site will maintain a separate copy of the manual for each significant release, so you can always check the right documentation for your copy.

Highlights:

  • Use large numbers of synonyms on Z-machine without your game crashing!
  • Use foreground and background colors, and format your text even in the status bar!
  • Control and measure the exact size of the status bar, letting you draw fancy centered automaps!
  • Put Unicode characters in closures without crashing the compiler!
  • See how close your game comes to the backend’s limits, even before you exceed them!
  • Parse serial commas in commands like TAKE X, Y, AND Z!
  • Include gender-neutral characters who will display as “X is…” but “they are…”!

And more! Most projects should be able to get all the benefits of this new compiler with no changes to their code, but be careful when upgrading the library if you’ve made any local changes.

Have fun! If you find bugs or typos in the docs, or have ideas about how Dialog could be better, let us know and we’ll try and fold them into the next release—plus, we’re always looking for more contributors! Take a look at the issues, and feel free to add more, or try to tackle the ones already there. Or just tell us here, and we’ll take note.

32 Likes

Excited to have this out!

I do encourage everyone here who’s interested in Dialog to get involved, even if it’s just reporting bugs… Dialog 1a/01 already includes contributions from various folks doing everything from stdlib improvements to documentation to project infrastructure, and I think all of us involved are keen to make sure this community-maintained (but Linus-approved!) fork really is built by and for the community here.

That said, it’s impossible to overstate @Draconis’ role in getting Dialog to this point — they’ve been the driving force behind all the major recent language changes, and responsible for a lot of the visibility of Dialog here on the forum as well. Thank you Daniel!

7 Likes

What happened to Linus? Is he no longer involved?

1 Like

Here is where Linus talks about the community maintenance effort.

(I’d not been following this story closely myself, but I’ve tried to summarise on the IFWiki page for Dialog. Apologies if I misunderstood anything.)

4 Likes

Looks accurate to me… thank you for preserving the history!

I am grateful to Daniel and everyone who has contributed to this new release and rekindled my desire to make games using my favorite authoring system. Thank you, everyone!

5 Likes

good to see you back, karona.

4 Likes

We’re also planning to have a more regular release cadence going forward, now that we’ve figured out the logistics of it all! So expect version 1a/02 (or 1b/01?) in much less than a year.

I already have a couple issues I’m working on (simplifying the GO TO and FIND output in the library, making it so ($ is visited) is only set after the initial [look] when entering a room, adding cross-references to the quick syntax reference in the docs, and fixing a couple odd bugs around access predicates), and we’re talking about adding a (nbsp) to the backend’s spacing options…but if we waited until all issues were cleared before release, it was never going to happen!

4 Likes

Oh, good heavens. I hadn’t even considered that the old stdlib didn’t support gender-neutral characters, and the PC of my WIP is one.

Would my testrunner.dg (run unit tests written in Dialog in dgdebug) be of interest for 1a/02? I’m happy to contribute it if it would be useful to anyone not named “Sue.”

1 Like

I have sometimes mused about putting together a directory of reusable code, like the “Friends of Inform” repo that collects Inform extensions. I didn’t suggest it at the time since there weren’t really any such extensions at the time… but I can think of one or two snippets on the forums that might qualify now, and a test runner certainly would.

1 Like

Yeah, we currently have a bunch of unit tests done in different frameworks, and handling some of them in Dialog itself could make a good stress-test! Take a look at the code in /test, and if you think your test harness would make a good addition, we’d be happy to take a PR.

I have seen some pretty convoluted version numbering in my time, but this one takes the cake.

4 Likes

I can’t seem to open the prebuilt binaries on my Mac, because of it thinks that they are malware. What should I do so that I can open them without issues?

It’s weird, but I’d call it less weird than Inform 10.2 being the upcoming version of Inform 7, which compiles to Inter, the new version of Inform 6! :face_with_tongue: Or, for that matter, the previous version of Inform 7 being Inform 7 6M62. We just put a slash in ours for style.

The reason for it comes down to the Z-machine architecture: there are four bytes in the Z-machine header where compilers generally put their name, and another four bytes where they put their version number, as eight ASCII characters. This convention was started by Inform, which will put (e.g.) Info and 6.32 in those eight bytes.

Linus wanted to do Major.Minor.Patch versioning, but that’s hard to fit into four characters. So he made the major version a one-digit number, the minor version a lowercase letter (a-z), and the patch version a two-digit number. The new version will store Dia 1a01 into those eight bytes, fitting three version components into only four characters.

(What about the space before the number? If we ever make a major version past 9, we might end up repurposing it, but by convention, the first four are the compiler name, the last four are the compiler version, and we want to stick to that if possible. We currently store a * in that byte to mark development builds; if the runtime sees a star there, it prints -dev at the end of the version number.)

2 Likes

Yeah, unfortunately Apple really doesn’t like people releasing software without giving them a cut of the profits. And since Dialog doesn’t make any profits, that’s hard for us to do!

You can either build the programs from source (all you need is a standard C compiler; go into the src folder and type make dialogc dgdebug), or trust us and run xattr -d com.apple.quarantine * in the directory with the prebuilt binaries.

7 Likes

Take a look at the code in /test , and if you think your test harness would make a good addition, we’d be happy to take a PR.

I’m tempted to try to write a suite of unit tests for stdlib, but that might need to wait until I’ve actually released my current WIP. (My 1995 IFComp entry is still unfinished because I spent the 90s fiddling with tools rather than actually writing games.)

3 Likes

Another thing that would be very helpful would be including the Å-machine in the automated tests; it shouldn’t be too difficult, we’d just need to add a rule to test/simple/*/Makefile that runs a command-line Å-machine interpreter with stdin and stdout connected to particular files. I’m just not good enough with Node to get the Node interpreter working properly for this.

On Mac, we should see if we can get homebrew-dialog/Formula/dialog-if.rb at master · vickio/homebrew-dialog · GitHub updated (to allow for brew to install it).

I’m doing some work to revise and improve the dialog tool, specifically improvements to the skein. I hope to have a new release out soon.

Testing:

  • Perhaps there’s a way we can have some kind of test driver as part of dgt; there’s already the ability to run a skein “headless” and see any errors, but that’s roughly and integration test, a unit test system would be good.
  • The standard library is great, but I’ve been working on a set of standard extensions (GitHub - hlship/dialog-extensions: Small, useful extensions for the Dialog IF language) – scenes, threaded conversations, and a tutorial mode
  • I’ve been away from Dialog for most of 2025 but I’m finding a little more time to spend on these … and perhaps actually write my game.
2 Likes
  • Perhaps there’s a way we can have some kind of test driver as part of dgt; there’s already the ability to run a skein “headless” and see any errors, but that’s roughly and integration test, a unit test system would be good.

I’ve got one ready to contribute; I just need to sit down and wrap my head around how the project is organized to get it in the right spot to submit a PR.