a question. where is the 1a/01 compiler? i thought it was here:
but the version there is still 0m/03.
when i ‘make’, a bunch of text goes by that SAYS 1a/01.
but --version still says 0m/03
That’s the one, I’m just waiting for review on some pull requests that’ll bump the version number!
1 Like
but the fix for the nasty heap-space bug is already in this version? i’m assuming ‘yes’ because i haven’t seen the ‘heap space’ error in forever.
Yep! Along with a bunch of other bugfixes, like the ($Y = [$X $X]) one and some obscure C errors, and improvements like a custom Unicode translation table and style stacking on Z-machine. The big thing I’m waiting on now before we make the official 1a/01 release is enhanced status bar controls for Z-machine, and option strings and style class names for Å-machine. Once someone approves those, we’ll be good to go!
It should print 1a/01-dev for the version already, though; I may have messed something up in the config.
EDIT: Yeah, just rebuilt from source, and dialogc --version says “Dialog compiler 1a/01-dev”. Are you sure you’re running the binary from the /src folder and not an old binary that’s somewhere in your $PATH?
i am downloading and unzipping the source to my desktop. then i am doing this:
charlesmoorejr@Mac-mini ~ % cd Desk*
charlesmoorejr@Mac-mini Desktop % cd dialog*
charlesmoorejr@Mac-mini dialog-main % cd src
charlesmoorejr@Mac-mini src % make
gcc -c -O3 -Wall -Wno-unused-result -Wno-format-truncation -DVERSION="1a/01-dev" -o frontend.o frontend.c
gcc -c -O3 -Wall -Wno-unused-result -Wno-format-truncation -DVERSION="1a/01-dev" -o backend_z.o backend_z.c
backend_z.c:266:26: warning: unused variable ‘j’ [-Wunused-variable]
266 | uint8_t i = n_extended, j;
| ^
1 warning generated.
gcc -c -O3 -Wall -Wno-unused-result -Wno-format-truncation -DVERSION="1a/01-dev" -o runtime_z.o runtime_z.c
gcc -c -O3 -Wall -Wno-unused-result -Wno-format-truncation -DVERSION="1a/01-dev" -o blorb.o blorb.c
gcc -c -O3 -Wall -Wno-unused-result -Wno-format-truncation -DVERSION="1a/01-dev" -o dumb_output.o dumb_output.c
gcc -c -O3 -Wall -Wno-unused-result -Wno-format-truncation -DVERSION="1a/01-dev" -o dumb_report.o dumb_report.c
gcc -c -O3 -Wall -Wno-unused-result -Wno-format-truncation -DVERSION="1a/01-dev" -o arena.o arena.c
gcc -c -O3 -Wall -Wno-unused-result -Wno-format-truncation -DVERSION="1a/01-dev" -o ast.o ast.c
gcc -c -O3 -Wall -Wno-unused-result -Wno-format-truncation -DVERSION="1a/01-dev" -o parse.o parse.c
gcc -c -O3 -Wall -Wno-unused-result -Wno-format-truncation -DVERSION="1a/01-dev" -o compile.o compile.c
gcc -c -O3 -Wall -Wno-unused-result -Wno-format-truncation -DVERSION="1a/01-dev" -o eval.o eval.c
gcc -c -O3 -Wall -Wno-unused-result -Wno-format-truncation -DVERSION="1a/01-dev" -o accesspred.o accesspred.c
gcc -c -O3 -Wall -Wno-unused-result -Wno-format-truncation -DVERSION="1a/01-dev" -o unicode.o unicode.c
gcc -c -O3 -Wall -Wno-unused-result -Wno-format-truncation -DVERSION="1a/01-dev" -o backend.o backend.c
gcc -c -O3 -Wall -Wno-unused-result -Wno-format-truncation -DVERSION="1a/01-dev" -o aavm.o aavm.c
gcc -c -O3 -Wall -Wno-unused-result -Wno-format-truncation -DVERSION="1a/01-dev" -o backend_aa.o backend_aa.c
gcc -c -O3 -Wall -Wno-unused-result -Wno-format-truncation -DVERSION="1a/01-dev" -o crc32.o crc32.c
gcc -o dialogc frontend.o backend_z.o runtime_z.o blorb.o dumb_output.o dumb_report.o arena.o ast.o parse.o compile.o eval.o accesspred.o unicode.o backend.o aavm.o backend_aa.o crc32.o
gcc -c -O3 -Wall -Wno-unused-result -Wno-format-truncation -DVERSION="1a/01-dev" -o debugger.o debugger.c
gcc -c -O3 -Wall -Wno-unused-result -Wno-format-truncation -DVERSION="1a/01-dev" -o report.o report.c
gcc -c -O3 -Wall -Wno-unused-result -Wno-format-truncation -DVERSION="1a/01-dev" -o term_tty.o term_tty.c
gcc -c -O3 -Wall -Wno-unused-result -Wno-format-truncation -DVERSION="1a/01-dev" -o output.o output.c
gcc -c -O3 -Wall -Wno-unused-result -Wno-format-truncation -DVERSION="1a/01-dev" -o fs_tty.o fs_tty.c
gcc -o dgdebug debugger.o frontend.o report.o arena.o ast.o parse.o compile.o eval.o term_tty.o accesspred.o output.o unicode.o fs_tty.o
charlesmoorejr@Mac-mini src % ls
aavm.c backend.c dumb_output.o parse.h
aavm.h backend.o dumb_report.c parse.o
aavm.o blorb.c dumb_report.o report.c
accesspred.c blorb.h eval.c report.h
accesspred.h blorb.o eval.h report.o
accesspred.o common.h eval.o runtime_z.c
arena.c compile.c frontend.c runtime_z.o
arena.h compile.h frontend.h term_tty.c
arena.o compile.o frontend.o term_tty.o
ast.c crc32.c fs_tty.c term_winglk.c
ast.h crc32.h fs_tty.o terminal.h
ast.o crc32.o fs_winglk.c unicode.c
backend_aa.c debugger.c fs.h unicode.h
backend_aa.h debugger.h Makefile unicode.o
backend_aa.o debugger.o output.c winglk
backend_z.c dgdebug output.h winglk-res.manifest
backend_z.h dialogc output.o winglk-res.rc
backend_z.o dumb_output.c parse.c zcode.h
charlesmoorejr@Mac-mini src % dialogc --version
Dialog compiler 0m/03
and it still says 0m/03
Try ./dialogc --version. I’m not sure how it works on Mac, but on Linux, you need to use ./ to specify the version in the current directory instead of the one in your $PATH.
that works. i have never touched my $PATH that i know of. i’m not smart or brave enough to do such linux-y things… i don’t even know where to find it.
thx!
If you do make install after make, it should put the newly-compiled executable into your $PATH automatically. Though be aware that will overwrite your existing 0m/03 compiler!
ok, another issue. now using the 1a/01 compiler the game immediately crashes using lectrote with the error: RangeError: Offset is outside the bounds of the DataView.
works fine with yasmin, gargoyle, and frotz.
is there anything in the new compiler that lectrote may not like?
Now there’s a great question! I haven’t tested this on Lectrote at all; I figured if it worked in Frotz and Gargoyle, the Z-code was probably good.
But it seems Lectrote gives that error when the call stack overflows. So somewhere in the Z-machine runtime, the recursion is going one level deeper now, and that’s pushing it past a limit.
Does this happen with anything compiled with 1a/01-dev? Or is it specific to your game file?
actually, i spoke too soon. it loads on gargoyle but immediately locks up.
i just compiled a different project (my parsercomp entry) and same result. crash on open with lectrote, opens but lock up on gargoyle.
if it makes any difference, one of these is z5 and one is Z8
and for thoroughness i just compiled the ‘cloak of darkness’ example code and same result
Hmm. This is very odd. We run tests on Windows, Mac, and Linux with every merge, including Cloak of Darkness, and those have been passing just fine. And I can confirm Cloak of Darkness works in Gargoyle for me.
Could you attach the Cloak of Darkness Z5? Then I can see if the compiler on my machine is producing the same thing or not.
cloak.z5 (85.7 KB)
I tested the beta version from the github, and in this Linux box I got another warning, which is potentially interesting, because I feel that perhaps is related to the well-known heap issues:
gcc -c -O3 -Wall -Wno-unused-result -Wno-format-truncation -DVERSION=\"1a/01-dev\" -o compile.o compile.c
In function ‘optimize_choice_frames’,
inlined from ‘comp_predicate’ at compile.c:4571:11:
compile.c:3381:9: warning: ‘memset’ specified size between 18446744071562067969 and 18446744073709551615 exceeds maximum object size 9223372036854775807 [-Wstringop-overflow=]
3381 | memset(visited, 0, nroutine);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dunno if is useful. For the record, I got the warning about the unused variable j, for a total of exactly two warnings.
oh, and on Linux, for running a binary in the current directory, overriding the binary in the path is ./name, e.g. ./dialogc, but dunno about macOS.
HTH, and
Best regards from Italy,
dott. Piergiorgio.
Hmm. So this file runs fine for me on Gargoyle; what version are you using? I have 2023.1.
The two files aren’t exactly identical, but they both seem to play just fine.
ok problem solved on gargoyle, anyway. i was using an older version and it runs fine with an update.
i also updated lectrote (i was using an older version of that too) but it still crashes on startup.
lectrote uses zvm which, i think, parchment uses too. i uploaded the test cloak.z5 to borogrove and it crashes there too. so it looks this may be an interpreter issue with ZVM?
Hmm. I suppose that would make sense, if ZVM has a smaller stack limit than Bocfel. I didn’t think Dialog was coming anywhere close to hitting it, though.
I’m going to ping in @Dannii as (if I remember right) the maintainer of ZVM—is there a way to see what routines are currently on the stack when it overflows? If so, I could compare those addresses with a dump from TXD to find what parts of the Z-machine runtime are involved.
I’ve definitely made some changes to the runtime that would increase the stack depth (e.g. in the status bar handling), but it should only be by one or two calls, so I wouldn’t expect it to have hit a limit.
1 Like
if this isn’t quickly fixable would it be possible before IFComp to revert to a version that just fixes that one ‘show stopper’ heap bug (assuming that’s not causing the problem)?
or a way to point to that version in the repository since it’s probably already there anyway?
Yeah, the next step will be figuring out what commit introduced the problem so we can roll back to it. I’ve downloaded Lectrote and confirmed that this crash happens even with a “hello world” program on the main branch, but doesn’t happen at all on the statusbar branch, so the problem arose somewhere in between those.
Just gotta do a binary search and figure out which one it is!
1 Like
The problem does not arise in this commit, but does arise in this one, and does arise in this one…
It looks like this one is the first one where it stops working. But I’m utterly baffled as to how that could cause the problem. This is purely a change to the command-line options for the compiler. It should have no impact whatsoever on the generated Z-code.
Time to break out TXD I guess!