[I6] held token causes programming error with no_implicit_actions

Authoring Inform 6
1

There are numerous grammar definitions that use the held token. To my dismay, I have just discovered that if you are using no_implicit_actions and you try to perform any of the actions that use these grammar definitions when you are not holding the relevant object, then you get:

[** Programming error: tried to find the "parent" of nothing **]

[** Programming error: tried to test "has" or "hasnt" of nothing **]
You aren't holding that.

I have tried to find the source of the error in the Inform 6 library (Iā€™m using the latest build downloaded today, 6 September 2020), but the library code is like a dogā€™s breakfast and I canā€™t make sense of it. Iā€™m sure this didnā€™t happen before I upgraded the library, but havenā€™t confirmed this yet.

I canā€™t find anything helpful with debug commands. All I know is that it appears to be in parser.h. The message at the end is from the NOT_HELD error token.

If I donā€™t use no_implicit_actions, it tries an implict take and everything works fine, but I donā€™t want implicit takes.

Does anyone have a fix for this?

2 Likes
2

Minimal code to reproduce the bug:

Include "parser"; Include "verblib";
Object room "Room"
   with description "You are in a room.",
has light;
Object hat "hat" room
   with
      name 'hat',
      description "a hat",
   has clothing;
[ Initialise;
   no_implicit_actions=true;
   location = room;
];
Include "grammar";

>wear hat

[** Programming error: tried to find the ā€œparentā€ of nothing **]

[** Programming error: tried to test ā€œhasā€ or ā€œhasntā€ of nothing **]
You arenā€™t holding that.

1 Like
3

Thatā€™s where the bug comes from:


It is this line that seems to be the problem:
if (parent(noun) has container)
4

Replacing ā€˜nounā€™ by ā€˜not_holdingā€™ seems to solve the problem.

    if (etype == NOTHELD_PE) {
		if (parent(not_holding) has container)
			L__M(##Take, 14, not_holding);
		else
			L__M(##Miscellany, 32, not_holding);
		oops_from=saved_oops;
    }
1 Like
5

Bug written up at https://gitlab.com/DavidGriffith/inform6lib/-/issues/113

Studying the problem and proposed solution now.

6

Fixed. @auraesā€™s fix appears to be correct.

1 Like
7

You guys are life savers. Thank you so much! Iā€™ve downloaded the new parser.h with the fix, done a quick recompile and everything seems to be working as it should. Iā€™ll give it a more thorough test tonight.

8

It is also necessary to replace ā€˜nounā€™ by ā€˜not_holdingā€™ in ā€˜L__M(###Take, 14, noun)ā€™ because ā€˜nounā€™ here is equal to ā€˜nothingā€™.

9

Sorry Garry, but the bug is still there with Drop (it comes from the same lines of code as above.):

Include "parser"; Include "verblib";

Object room "Room"
   with description "You are in a room.",
has light;

Object bag "bag" room
   with name 'bag',
   description "It's a bag",
   has container open;

Object key "key" bag
   with name 'key',
   description "It's a key",
   has;

[ Initialise;
   no_implicit_actions=true;
   move bag to player;
   location = room;
];

Include "grammar";

drop key

[** Programming error: tried to find the ā€œparentā€ of nothing **]

[** Programming error: tried to test ā€œhasā€ or ā€œhasntā€ of nothing **]
You arenā€™t holding that.

1 Like
10

The culprit line is:
if (parent(not_holding) has container)
so I added the following debugging code before it:
print "noun = ", noun, ", not_holding = ", not_holding, "^";
This revealed some interesting results. In the majority of cases that I tested, noun returned 0 and not_holding returned n, where n is an object number. However, in one case, it was the reverse, so there is no way that the test is going to work in all cases. More specifically, I had a key in a glass. GIVE KEY TO MAN returned noun = 0, not_holding = 238110 and DROP KEY returned noun = 238110, not_holding = 0.

I have reverted to the code as it was in version 6.12.3 and everything works fine.

11

Thereā€™s something more complex going on. Could we move this discussion to https://gitlab.com/DavidGriffith/inform6lib/-/issues/113 ?

12

Yeah, sure.