Debugging a Programming Error

Hello community.

During the Spring Thing, it was discovered that when trying to examine a particular object I get ~30 of the following error:

[** Programming error: tried to read (something) **]

It then prompts for disambiguation of ~20 objects.

I have NO idea how to debug this. Any thoughts?

d.

You can start with getting the rules output. Just type

>rules

while playing a test build (in IDE for instance), then try the command.

You can see what rule is firing it, then have a look at that.

1 Like

Are you using something in a place it shouldn’t be used? You can say before eating something but not check eating something; you want to use check eating instead.

1 Like
Summary

Ah yeah, I remember now. I have gotten this when I try to do things with properties that aren’t possible. Some make it through compile but break at runtime. Here’s one:

lab is a room.

instead of jumping:
	now the lab is closed.

test me with "jump".

A room can’t have the “openable” property, so this happens. Unless I’m mistaken.

EDIT I managed to recreate the message. In my case, it did have to do with properties and objects after all. And printed names.


a frob is in lab.

an object can be tall or wide.

after printing the name of an object:
	if the object is tall, say "(tall)";
	if the object is wide, say "(wide)";

Output:

[Rule "you-can-also-see rule" applies.]
You can see a frob
[** Programming error: tried to read (something) **]

[** Programming error: tried to read (something) **]

[** Programming error: tried to read (something) **]

[** Programming error: tried to read (something) **]

[** Programming error: tried to read (something) **]
(wide) here.

So maybe something pertaining to printed names of things, since a disambiguation message prints a list of names.

1 Like

Is there anything special about the object in terms of examining? Like an instead of examining the donut rule or something?

Do you have any does the player mean rules around that or a similarly-named object?

Edit: Now that I think about it, it seems like your problem is in parsing, since it pops up with disambiguation after the programming error messages. Which means examining rules are unlikely.

This doesn’t happen if you compile with 6M62.

I was able to prevent those errors by changing your code to this:

after printing the name of an object:
	if the item described is tall, say "(tall)";
	if the item described is wide, say "(wide)";

Thanks! But to be clear, I’m not looking for a way to avoid the error. I’m trying to recreate it.

I think Drew’s got it. This error shows up when you use a general description where a specific thing is needed. For example, this is wrong:

After printing the name of a thing:
    if the thing is purple:

Inform doesn’t read “the thing” here as meaning “the parameter of this rule”, even if that’s how we’d read it in English. The proper way to do this is:

After printing the name of a thing (called the item):
    if the item is purple:

What’s happening under the hood is that “the thing” is read as equivalent to “a thing”. If you then access a property that not all things can have (like “purple” here), it tries to access that property on every thing in the game, and crashes because many of those things lack the property.

2 Likes

Understood. I was trying to point out that this:

looked as if it was being too vague (using “the object” when it should really be more specific about which object is being referenced), so I wondered whether that was also the reason for those programming errors in the original post.

It is. That’s what Drew was saying earlier.

As a guide in Inform, never put the word “the” before a kind name. “The object”, “the thing”, “the person”, “the door” are all insta-bugs.

(“The item described” is okay, as that’s not a kind name. It’s a variable and refers to a specific object at any given time.)

3 Likes

the noun is also fine, because it’s also a variable (e.g. check pushing a button: try switching on the noun instead.).

Thank you all for your suggestions and tips. I managed to solve the problem. In a DTPM i was referencing an item specifically rather than referencing it as part of the item it belongs to. In other words:

does the player mean doing something with the aqua button: it is likely.
vs.
does the player mean doing something with control panel one’s button: it is likely.

Having fixed that, the disambiguation is still crazy in ways i don’t understand and that don’t seem to be fixed by DTPM.

back at it.

d.

It’s always okay to refer to an item specifically.