I have a large v10 project which depends on some complex extensions. Tonight I started getting
[** Programming error: tried to read (something) **]
every time the game executed a particular rulebook. After some investigation I found that eliminating some either/or properties eliminated the problem, no matter which I eliminated. Once I got it working, I tried adding junk either/or properties and the problem reoccurred.
How can I approach this problem (other than eliminating properties)?
So far as I knew, the compilerâs supposed to automatically start representing either-or properties the same way it would a truth state property when it runs out of I6 attributes and keep the difference invisible to you.
Manually switching to explicit I7 properties might get around it.
Latecomer-attribute is a truth state that varies.
thing1 has a latecomer-attribute.
or if you still want adjectives,
Latecomer is a kind of value. The latecomers are hot and cold.
thing2 has a latecomer.
Not sure, though⌠like I said, I thought this wasnât supposed to happen.
It may be one of the extensions thatâs failing to keep up, rather than the compiler.
If Zarf is right, then one of the book sections I just read mentioned how extensions can have special arrays defined that can run out of room, and how to extend them:
https://ganelson.github.io/inform-website/book/WI_27_18.html
Actually I was thinking that an extension might (wrongly) assume that every either/or property is an attribute.
This is just a guess though.
Moving extension A into the main text made the problem disappear. Which is great, but Iâd like to keep this as an extension, since I wrote it and I find it useful.
Incidentally, it has no I6 inclusions in it, and neither does the main text.
Yeah, thinking about it more, this probably doesnât have anything to do with how either/or properties are being represented. Somethingâs going on thatâs making something try to read a property from something thatâs not an object.
Iâd been writing that when you posted. Any possibility you have some ambiguous names in your code and the compiler took something you intended to refer to an object as a reference to something else?
use unabbreviated object names.
and following through with using thingsâ full names would tell you whether the above is the case, but if your programâs long, it would be a real pain.
If you add two dozen more either/or properties, then comment out extensions one by one, is there a particular extension whose removal fixes the issue?
Iâve found the real problem:
Rule for determining statickness of a thing (called T) when T is enclosed
by a static room:
rule succeeds with result true;
Turns out I had defined static for things but not rooms. But for whatever reason this rule never fired (I suppose) until I added this one final extension, even though the extension doesnât add any things or rooms.
So I donât know why that is. But in any case Iâve found the real problem. Thanks.
Hm, reminds me of this thread: Why do "an object can be x" and "repeat with o running through objects" refer to different sets of objects?
I havenât reproduced either case, but I bet this is the deal:
If you say âA thing can be fooâ, and then check for âa foo roomâ, you expect this to silently match nothing (because rooms canât be foo). If you check for âa foo objectâ, you expect this to match things but reject rooms.
But I guess thatâs not guaranteed? If the foo either-or property is implemented as an I6 attribute, thatâs how it works. But if itâs implemented as an I6 property, the rejections arenât silent; they throw âtried to read (something)â runtime errors.
I donât know whether this contradicts the documentation or just our assumptions.
(Also I donât know if Iâve described the previous thread exactly right. Itâs late.)
For those still a little unsure, what Zarf is pointing out here is that when an I7 either-or property is implemented as one of the limited number of I6 Attributes (which are like universal either-or properties), every object is given that universal attribute- itâs just that if you write âa person can be happyâ only people are allowed to have that attribute allocated by code- such as Mr Bingley is happy or now Mr Darcy is happy. * Any object that is not a person is forever frozen in the default state of not being happy. But you can still ask about that status for objects which are not people without throwing an error- e.g. âIf Netherfield Hall is happyâ is a valid condition, but one that can never be true.
*this is possible because although every object has a âhappyâ Attribute, Inform keeps a separate record of which objects are allowed to have the happy Attribute modified and which are not.
If Inform 7 runs out of I6 Attributes to use as either-or properties (there are only a small number that arenât already used up by the compiler and Standard Rules) it starts to implement them instead as normal I6 properties rather than as Attributes. When this is the case, A person can be happy creates an I6 property which is given only to person objects. Unlike the case with Attributes, any object that is not a person does not have that property at all. Now the condition If Netherfield Hall is happy throws a run-time error because not only can Netherfield never be happy, it doesnât even have access to the concept of happiness, because it has been given no âhappyâ property.
The sequence by which either-or properties are implemented- firstly as I6 Attributes then subsequently, when the stock of Attributes runs out, as properties- will be determined by the order that they first appear in the source or are included from extensions. So re-ordering the source code (or transferring an extension into the main source) may cause a property that was previously implemented as a property (and thereby causing a run-time error) to be implemented instead as an Attribute, such that the error disappears.
This error is peculiar to Ver 10 upwards, because Ver 9 and previous had a different method of accessing either-or properties which checked first whether an object provided a property before trying to read it, simply returning false if the property was not provided (which is the same thing that happens for objects which have unmodifiable attributes). Ver 10 skips this check and blunders in trying to read a non-existent property, throwing a run-time error.
This behaviour is easy to reproduce- see the following, which throws an error in Ver 10 but not if compiled for Ver 9.
"Attributes and Properties" by PB
A person can be happy.
A person can be lucky.
A person can be tall.
A person can be short.
A person can be rich.
A person can be poor.
A person can be rude.
A person can be polite.
A person can be famous.
A person can be obscure.
A person can be black. [up to this point, these either-or properties are implemented as I6 Attributes, hereafter as I6 properties]
A person can be white.
A person can be coloured.
A person can be sad.
A person can be unlucky.
Netherfield Hall is a room.
When play begins:
unless the Hall is happy:
say "Netherfield isn't happy.";
unless the Hall is sad:
say "Netherfield isn't sad.".
Thanks everyone for figuring out what was going on! Even though the base problem was that I was careless, itâs nice to understand where the behavior was coming from.
Ah, thanks. I noticed that 9/10 difference in the âobject can be xâ thread but didnât track down the exact cause.