Oh, never mind. Github wasn’t showing me all the commits.
Unfortunately, no disassembler I’ve tried has been able to handle a “hello world” program. Even UnZ, with explicit Dialog support, chokes on such a small program.
So I’m working with a program that includes the standard library, which is less ideal.
Well, this seems to be where it broke.
Now to figure out what about this went wrong…
Inform’s -a argument, which displays every opcode as it’s compiled, is immeasurably helpful when finding compiler regressions. Adding such a feature to Dialog would probably repay the effort.
Well, some progress. This crash happens specifically when Dialog compiles a header extension table and Unicode translation table. For some reason, Frotz and Gargoyle accept the tables it generates, but ZVM (so Parchment and Lectrote) doesn’t. This is true even when the Unicode translation table contains no entries!
UnZ has no problem with it:
***** HEADER EXTENSION TABLE (01C9B-01CA2, 8 bytes) *****
01C9B 00 03 Number of further words: 3
01C9D 00 00 MSLOCX X-coord of mouse after a click: 0x0000
01C9F 00 00 MSLOCX Y-coord of mouse after a click: 0x0000
01CA1 1C A3 Unicode translation table address: 0x1CA3
***** UNICODE TRANSLATION TABLE (01CA3-01CA3, 1 byte) *****
01CA3 00 Number of entries: 0
***** UNIDENTIFIED DATA (01CA4-01CA7, 4 bytes) *****
01CA0 00 00 00 00 ....
(The “unidentified data” is padding so that the start of the routine data afterward is aligned to an eight-byte boundary.)
Looking at the ZVM code, it seems like it should handle Unicode translation tables just fine. So it’s not like it’s doing anything fundamentally unsupported. There’s just something about Dialog’s implementation that it doesn’t like.
(Why has this been showing up in hello world examples? There’s a bug that makes it always try to compile a Unicode translation table, even when no Unicode characters are used. I’ll fix that once I’ve figured this out.)
Is there some way to see a more detailed trace, where exactly in ZVM’s internals something is crashing? The Lectrote console just shows:
RangeError: Offset is outside the bounds of the DataView
at DataView.prototype.getUint16 (<anonymous>)
at t.restart (/home/daniel/Programs/Lectrote-linux-x64/resources/app/ifvms/zvm.min.js:2:34633)
at t.start (/home/daniel/Programs/Lectrote-linux-x64/resources/app/ifvms/zvm.min.js:2:9642)
at Object.accept_ui_event [as accept] (/home/daniel/Programs/Lectrote-linux-x64/resources/app/quixe/lib/elkote.min.js:633:133)
at send_response (/home/daniel/Programs/Lectrote-linux-x64/resources/app/quixe/lib/elkote.min.js:315:16)
at /home/daniel/Programs/Lectrote-linux-x64/resources/app/quixe/lib/elkote.min.js:43:90
And since everything is minified, this isn’t very helpful.
It seems like it’s the header extension table that’s the problem, rather than the Unicode table; if I have an empty header extension table (3 words, Unicode translation table not supplied; or 0 words, or 4 words, all zeroes), that still crashes. The presence of the extension table at all is the problem.
OH THERE WE GO. I FOUND IT.
ZVM assumes the header extension table is always in RAM, and immediately crashes if it isn’t. Dialog by default puts the header extension table in ROM instead.
Personally I think this is a bug in ZVM and Dialog has it right; as far as I can tell, nothing in the spec requires the extension table to be in RAM, and indeed, Frotz and Bocfel don’t require that. But it’s also possible to change in the Dialog compiler if necessary.
That sounded a bit more sanctimonious than the situation really merits. There are plenty of tweaks in the Dialog compiler to handle particular interpreters’ quirks. For example, Frotz requires there to be enough RAM for 240 globals even if fewer than that are used, and some versions crash if you @undo before the first @saveundo, so the Dialog compiler includes workarounds for both. So there’s no reason not to adjust it to put the header extension table in RAM for ZVM.
I’m committing a fix now, and it’ll be merged as soon as it gets approval!
Yes I think so too.
BTW, I noticed this little bug in the Cloak of Darkness port:
> read message
There's nothing written on the scrawled message.
Yes this looks like a bug in ZVM, and it will be very easy to fix. But considering how long it would take for everyone to update their copy of Lectrote and stop using a buggy version of ZVM, you should probably still consider changing Dialog’s output. Sorry!
That seems like the best solution, yeah. Moving a handful of bytes from ROM into RAM shouldn’t cause any problems, especially when they already had to be in addressable memory anyway.
This is currently implemented on the zvm-compat branch, and will be merged in asap! For now, if you’re building from source, switch to that branch and you should be good.
works beautifully now, thx.
i really should spend more time testing in interpreters - i’d pick up errors faster that way. but the stupid debugger is SO good and has me SO spoiled that i wind up spending 99% of my time there instead.
Honestly the Dialog debugger and Inky have spoiled me on so many other IF systems. The ability to tweak my code mid-test and just keep testing is helpful in so many different ways!
I still haven’t managed to get the Node Å-machine interpreter running properly on my machine, so for each of my projects I have a test script that runs a full playthrough on dumbfrotz and the debugger and checks the output. Then I check in Gargoyle and the web Å-machine interpreter by hand to make sure nothing’s graphically weird. I’ve been vaguely assuming if dumbfrotz accepts it, everything should.
I’ve fixed the bug in ZVM and sent a patch in for Lectrote.
Since this is a thread about compiling Dialog, I hope it’s not too off-topic to ask if there are any out-of-the-box instructions for compiling on Windows? The instructions in the documentation assume that you’re building the Windows compiler by cross-compiling from Linux.
I managed to build dialogc under MSYS2 by tweaking the makefile, but I don’t know enough about what I’m doing to successfully build dgdebug.
Unfortunately we don’t have any right now—our build process creates Windows binaries, but since we haven’t done an official release yet, they’re not posted anywhere easily accessible. And both Linus and the current team develops mostly on Linux.
It’s all written in portable C, so it should be straightforward to compile on Windows too, but I’m not sure how exactly one would do it. Let me see if I can get the artifacts from the most recent build and put them somewhere.
Currently, if you go to a pull request, like this one, you can scroll down to where it shows the automated tests:
The one labelled build-release builds binaries for every platform. So if you click the “…” and then “View details” on that one, you’ll see a list of the steps in the test. The one you want is “upload artifact”, and at the bottom of that section, you’ll see a URL, like https://github.com/Dialog-IF/dialog/actions/runs/16183909596/artifacts/3500505576 . That’ll include current Windows binaries.
This is an annoying hassle right now, but hopefully soon we’ll have an official release up, with an easy download link.
Aaand you have to be logged into GitHub or you get a different view that doesn’t have all the details.
Blah. Does it work if you’re logged in but not a member of the organization, at least? Or do you have to be a part of the organization to do it?
Yeah, it worked fine for me once I logged in. 
But it looks like if you’re not, then even that direct link to the artifacts gives you a 404 not found error.
Well, that’s something at least. I’m really hoping we can get an official release out in the next week or so so that people have an official version to use for IFComp, without needing to build the dev binaries by hand.
