I’m abusing Inform 7 to solve an Advent of Code challenge. This involves creating a source file with ~16 000 rooms. My code works fine with a smaller number of rooms, but when I try to compile the full thing, the compiler stops here with no error message:
++ 98% (Generating code)
Am I hitting an internal limit on the number of rooms a story can have?
There’s not supposed to be a limit on that, but my guess is you’re hitting some limitation of the compiler that’s never been discovered before because nobody’s tried to create that many rooms. (Which is why it hangs instead of giving you an error code.)
Does the compiler exit or hang?
There could be some internal inefficiency that takes N^2 memory or N^2 time, but the constant is small enough that you don’t notice until tens of thousands of rooms.
If it’s dumping core you could investigate more, but this would involve running it from the command line.
Really, though, the answer is: “yes, there is some limit. It will not be fixed before Advent of Code is over.”
Thanks! I’ve now tried running it from the command line now and it is indeed core dumping. But it compiles fine if I pass in -no-index, which is fine for my purposes.
The 371186-word source text has successfully been
translated. There were 16083 rooms and 1 thing.
Compiling from Inform 6 to Glulx also worked, producing a 1GB ULX file which crashes some interpreters, but not Gargoyle. Glad to report that this highly inefficient AoC solution is viable after all.
Interesting!
I guess I’ll have to test that case. I’d ask for your game file but I’m sure I can make one just like it in a few minutes. :)
The ulx being 1 GB is both interesting and surprising to me – I didn’t know it’s possible to generate so much Glulx from so little source code, and I’d like to add something like that to my collection of interpreter stress tests. I tried and sort of failed to reproduce one with 16k lines of RoomN is a room. in an otherwise empty project. I can see inform7 (v10.1.2) is struggling to compile it and only finishing with -no-index, but the resulting ulx file is “only” around 500 KB.
@zarf @Hanna Another reason for the size could be the connections between rooms. This is a solution for this challenge, which involves a character navigating a grid. My code generation script reads in the input file, creates a room for each . and gives it north, east, west and south connections to surrounding .s. #s are skipped. Rooms on the edges have all of their edge directions lead to an Endgame room.
It wasn’t the connections, I just forgot to do the I6 → Glulx compilation step (since the IDE does it automatically). When I do that, even just the rooms without any connections give a gigabyte-sized ulx file:
| auto.inf | output.ulx | |
|---|---|---|
| Rooms only | 17181063 | 1039776512 |
| with connections | 18264585 | 1105684736 |
The ulx files are very compressible (down to ca. 2 MB), disproportionally larger than the I6 source, and 99.98% of their size is RAM. All these factors suggest it’s due to huge array(s) with all elements initialized to the same value. A quick search through gameinfo.dbg identifies the sole culprit as FWMatrix, which is from fast route-finding. This makes sense in retrospect: fast route-finding is enabled by default for Glulx and uses n2 x 32 bits of storage for n rooms. This works out to pretty much one gigabyte for n ~= 16 000.
I thought that adding Use slow route-finding. should prevent this and bring the ulx file back to a reasonable size, but it doesn’t, at least in v10.1.2. Apparently that’s a bug which is already fixed for the next release:
- Fix for Jira bug I7-2306 “remaining arbitary ifdefs in kit code”: also fixes an unreported bug in which the use options “Use numbered rules”, “Use manual pronouns”, “Use fast route-finding” and “Use slow route-finding” had ceased to have any effect; all taken care of in the implementation of IE-0018 (commit 95e613c) (see also duplicate report I7-2276)