Internal error reporting as problem with Inform source code itself?

Authoring Inform 7
1

Hello good people of Inform world.

I’m putting (I think) the finishing touches on a fairly massive update to a game I wrote several years ago. When I say massive I mean 300,000 words of source code.

I have been building it one chunk at a time, dropping in several thousand words of code at a time and combing through it to clean it up (for example I learned at some point about the efficiency of “check doing X” versus “instead of doing X.”

I just dropped a big chunk (say 40,000 words for sake of argument) into the source and when compiling it, I’m used to going through and fixing typos or issues related to updated language being used in the compiler. I fix these as they occur and eventually I’m ready to playlets that chunk.

The problem is, when now compiling, I get this:


**Problem.** An internal error has occurred: inter error. The current sentence is 'An object is usually improper-named' [![](blob:https://intfiction.org/39c08fc0-3177-447c-9409-b3b5743d8684)](source:/Applications/Inform.app/Contents/Resources/Internal/Extensions/Graham%20Nelson/Basic%20Inform.i7x#line117); the error was detected at line 272 of "inter/building-module/Chapter 3/Produce.w". This should never happen, and I am now halting in abject failure.

What has happened here is that one of the checks Inform carries out internally, to see if it is working properly, has failed. There must be a bug in this copy of Inform. It may be worth checking whether you have the current, up-to-date version. If so, please report this problem via www.inform7.com/bugs.

![](blob:https://intfiction.org/ac7aeb78-0ee5-4f59-a0b6-e8e86f06e785) As for fixing your source text to avoid this bug, the last thing you changed is probably the cause, if there is a simple cause. Your source text might in fact be wrong, and the problem might be occurring because Inform has failed to find a good way to say so. But even if your source text looks correct, there are probably rephrasings which would achieve the same effect.

The issue here, of course, is that I inserted 40,000 words of code, and then deleted a bunch of other stuff (for example, if the game was referencing an item defined in that 40,000 words, I put a temporary definition in there so it would compile, and now I’ve gone through and removed duplicates, etc. for that 40,000 words). It would be a monumental, terrifying pain to remove all that 40,000 words, and no, I don’t have a recently saved version – I save fastidiously but since the last version compiled no problem, I have been saving as I go. I know, not a good thing…but I didn’t expect this find of fatal error.

The offending line is a vary innocuous bit of Inform related to miscellaneous definitions.


Part Two - Miscellaneous Definitions

An object has a value called variable initial value.

An object has a text called specification.
An object has a text called indefinite appearance text.
An object has a text called printed name.
An object has a text called printed plural name.
An object has a text called an indefinite article.
An object can be plural-named or singular-named. An object is usually singular-named.
An object can be proper-named or improper-named. An object is usually improper-named.
An object can be ambiguously plural.

The indefinite article property translates into Inter as "article".
The printed plural name property translates into Inter as "plural".
The printed name property translates into Inter as "short_name".
The plural-named property translates into Inter as "pluralname".
The ambiguously plural property translates into Inter as "ambigpluralname".
The proper-named property translates into Inter as "proper".

I’m using Version 1.82 (1.82.3)

Any suggestions?

2

The version number that you reported looks like the version number of your IDE – the version number that matters here is the version of the Inform compiler, which I’m guessing is 10.1.2 (the current release) based on the error message.

The sample source code that you’ve included and which seems to be the source of the error should not be necessary. Those same assertions already appear in the Standard Rules. Is there a particular reason that you’ve included them in your own source?

It’s sometimes the case that the line cited by the compiler when issuing a Problem message is far removed from the actual cause. It may take some effort to track down the culprit here. The strategy that I would try first in your situation is commenting out any code that the compiler is complaining about because doing so may (eventually) reveal the actual cause.

I think it’s also possible to increase the verbosity of the I7 compiler’s output when compiling from the command line. That might be worth exploring to get more details about what is causing the compilation error.

1 Like
3

Thank you .

The code snippet that causes the problem is indeed from the inform source code, and not my own (when I click on the link it pulls up a pale yellow window rather than a white one). That’s what I found curious and frightening.

Commenting things out is where I would begin but was hoping to avoid the need to repopulate the non-commented code with the dozens of objects that will now be missing by dint of being commented out. But that’s where I will begin if I must.

Could it be something with memory management due to the size of my file? I have basically just taken the memory parameters (like MAX DEFINITIONS or what have you) and arbitrarily increased them in the past…that’s admittedly imprecise and I’m sure there is a more thoughtful and precise way to do it).

4

The current release of Inform no longer requires the author to manually manage these limits. So you can comment these limit-increase/specifying lines of your source out. You probably don’t want to delete them until you feel totally confident they really aren’t needed. But they’re unlikely to be the source of the current failure to compile.

-Wade

5

I’ve sometimes seen the Inform compiler get badly confused when it mistakes one of its own internal terms with something in the author’s source code. You could try the Use unabbreviated object names. use option as described in WWI 3.2 Rooms and the map.

6

Thanks everyone. I’ll report back for the sake of others that might experience similar issues. Really appreciate the advice!

7

So I tried unabbreviated names. This didn’t help, but it did permit me to go through and correct those instances where I had inadvertently used abbreviated names. :slight_smile:

I then commented out the code bit by bit, even though I had to recreate about 100 rooms and objects, etc. that were momentarily removed by the commenting.

Turns out the offending line was a poorly implemented creation of a door that opens with a key fob rather than a key. In the previous iteration of Inform (several years ago now) it permitted me to create a class of door as scenery. New Inform didn’t like that. So I rebuilt this section and it seems to compile again properly. Now I just have to hope the new implementation works. :slight_smile:

Really appreciate the help of this community – thanks again so much!

2 Likes