I7: Request for help with two peculiar compiler errors

Authoring Inform 7
1

When I compile my work in progress, I’m receiving the following error sporadically:

Can’t open index file
Offending filename: <C:…\Inform\Projects\Five and Five.inform\Index\Details\0_A.html>

Compiler finished with code 2

After receiving this error, when I try to compile the project a second time, it works just fine.

I’m also observing a failure of “say”, which is causing me some serious debug headaches. The chunk of code in question is as follows:

(I’m not sure how to get the tabs to work here. My apologies. I hope it’s legible anyway.)

Z1 is a room.

An contextual memory is a kind of thing.

50 contextual memories are in Z1.

When play begins:
prepare contextual memories.

To prepare contextual memories:
say “Preparing contextual memories.”;
say “Step 1”;
say “Step 2”;
repeat with target memory running through the contextual memories:
say “Step 3”;
let M be 1;
while M is 1:
say “Step 4”;
say “Step 5.”

This is word for word from my current work in progress. When I run it outside my work in progress, it prints

Preparing contextual memories.
Step 1Step 2Step 3Step 4Step 4Step 4Step 4Step 4Step 4Step 4…

just as I would expect.

In my current work in progress, this outputs “Preparing contextual memories.” and stops there without printing Step 1, Step 2, Step 3, or Step 4… Trying to hack down the source code to the point where I can get this exact behavior is proving very difficult - I think the error has something to do with the size of the source code. I suspect I have a MAX_SOMETHINGOROTHER too low, but without an error message to tell me what to increase, I’m stuck.

Does anyone have recommendations for how I could fix (or at least better debug) these two behaviors?

2

If it’s a memory problem, switching your target to glulx should help. But the missing index file sounds more serious. It it possible there are problems with your computer’s filesystem, or have any of the files in your project been moved around by something other than Inform?

3

I’m already compiling to Glulx, so unfortunately that won’t help.

I won’t rule out problems with my file system (I run a rather crabby 4-year-old Vista machine), but it’s an on-again off-again problem, rather than a consistent one. I do remember having a similar problem a few times near the end of One Eye Open, where I could run the compiler twice in a row and have it mysteriously fail once and then pass the next time, but it seems to be getting worse.

4

I get transient failures like that a lot on my laptop when the machine is overheating, and/or a memory module is going bad. So it might be a hardware issue with you too. The inform compiler (not the IDE) seems unusually sensitive to CPU/memory unhappiness. Since my issue is usually overheating, playing YouTube videos in a web browser frequently causes the browser to crash. It’s very rare though for any other program on my machine to be affected in any way whatsoever. Weird.

5

Do you actually have an infinite loop in your code sample? The loss of indenting makes it unclear what’s going on.

6

By the way, you can wrap code in [code] blocks to preserve spacing.

7

ChrisC - Ah-hah! I did not know about the code block. I don’t know why, since it’s staring me in the face at the top of this list (oops.) Let’s try that again!

To prepare contextual memories: say "Preparing contextual memories."; say "Step 1"; say "Step 2"; repeat with target memory running through the contextual memories: say "Step 3"; let M be 1; while M is 1: say "Step 4"; say "Step 5."

Zarf - Yes, I have an infinite loop. The reason why I have an infinite loop here is that I was trying to debug a supposedly-not-infinite loop (that was apparently going infinite, and I didn’t know why.) I tried adding debugging messaging to my original loop, but even debugging messaging that should have showed up wasn’t showing up. I started cutting code out of the loop in an effort to figure out why the debugging messaging wasn’t working, and this was the result.

8

The behavior of interpreters in infinite loops is poorly defined – to be polite about it.

The text-generating code may overrun the text-displaying code and starve it out. Or the text-displaying code may simply be buffering all output until the next input event, in which case you’re guaranteed to not see anything. (I write my interpreters with the latter setup – I find it gives much better printing performance for games that aren’t infinite loops, which are, you know, most of them.)

Anyhow, that’s probably what’s going on. You can work around it by waiting for a keystroke inside your loop (“wait for any key” in Basic Screen Effects). Or run your game in CheapGlk, which does no buffering (although it prints through the stdio library, which does a little bit).

9

Awww. But “Pick Up The Phone Booth Over And Over And Over And Over And Over…” was going to be such a hit.

Thanks for the recommendations! I’ll try the ‘wait for any key’ trick the next time I’m trying to debug an infinite loop.