Do I need to worry about this? [** Programming error: tried to read from -->-1 in the array "parse", which has entries 0 up to 60 **]

[bg]

I noticed when I turned on rules that this type of error message shows up in response to a command like “Marie, hi”:

[answering Marie that "
[** Programming error: tried to read from -->-1 in the array "parse", which has entries 0 up to 60 **]
 marie , hi" - ended without result]

I’ve spent a little time trying to figure out which code is causing the problem, but have not been successful so far.

On the other hand, if I hadn’t turned on RULES, I wouldn’t have known there was a problem. The game is still responding the way I want, as far as I can tell so far. Is this the kind of thing that has the potential to cause problems if I don’t fix it?

To be more specific, I have a rule similar to this:

Instead of answering something that:
	say "In this game, please use TALK TO."

And that rule does run, and prints the response I want. But the error still shows up (when I turn RULES on).

[bg]

Ok, I pasted in this code from another thread

@drpeterbatesuk

Chapter - Fix (Inform 6_34)

Section - Fix for incorrect snippet generation when UnknownVerb() returns 'no.verb' and command of form 'Darcy, splendid coat' is diverted to ##Answer, by correct reset of verb_wordnum

Include (- Replace UnknownVerb; -) after "Definitions.i6t". [run our new routine instead]
Include (- [UnknownVerb; verb_wordnum--; return 'no.verb'; ]; -) [move verb_wordnum back to 0 if still searching for verb as first word of command, or back to the comma if a command like 'Darcy, ....'] after "Output.i6t". [make sure it comes after the original UnknownVerb in the output I6. (- Replace MyFunction [OldMyFunction]; -) must precede any declaration of MyFunction() but may be followed by any number of subsequent declarations of MyFunction(). The MyFunction chosen to compile will be the last-defined version, except that definitions in normal files are always preferred over definitions in System_file files or the veneer. With the two-parameter form (introduced in 6.33), the declaration chosen to be renamed and compiled as OldMyFunction will be the first-declared version of the function.]

Section - Fix for comma being erased from chained commands to NPC following a 'no.verb' command (eg test case [11]) by nudging verb_wordnum forward by 1, past the comma

Include (-
if ((held_back_mode) && (verb_wordnum ~=0)){
	wn = verb_wordnum;
	if (NextWordStopped() == comma_word) verb_wordnum++;
};
-) before "Parser Letter A" in "Parser.i6t".	  

Section - Fix for failure to consider 'no.verb' grammar lines when no grammar lines match for a detected verb

[if we've reached this point all grammar lines for the recognised verb have failed, so if we haven't tried 'no.verb' and UnknownVerb() returns 'no.verb'- indicating at least some 'no.verb' grammar lines, try those]

Include (- if ((verb_word ~= 'no.verb') && (verb_word =UnknownVerb(verb_word))) jump VerbAccepted; -) after "Parser Letter G" in "Parser.i6t".

Section - Bonus Fix  Inappropriate RTP error generated by 'when the topic understood includes __' when the topic understood is "" eg after 'Darcy,' which generates ##Answer action with parsed_number 300

Include (- Replace SnippetIncludes; -) after "Definitions.i6t".

Include (- 

[ SnippetIncludes test snippet w1 w2 wlen i j;
	w1 = snippet/100; w2 = w1 + (snippet%100) - 1;
	if ((w2<w1) || (w1<1)) {
		if ((w1 == 1) && (w2 == 0)) rfalse; ! #### pre-existing special-case for snippet of 100
		! ##### Insertion
		!print "w1=",w1," w2=",w2,"^";
		if ((snippet%100) == 0) rfalse;  ! 100, 200, 300 etc. i.e. snippet is ""
		! ##### Insertion ends
		return RunTimeProblem(RTP_INCLUDEINVALIDSNIPPET, w1, w2);
	}
	if (metaclass(test) == Routine) {
		wlen = snippet%100;
		for (i=w1, j=wlen: j>0: i++, j-- ) {
			if (((test)(i, 0)) ~= GPR_FAIL) return i*100+wn-i;
		}
	}
	rfalse;
];
-) after "Output.i6t".

and the error went away.

I don’t really understand it, though. Or if I’m doing something extra risky by adding in I6 code that I don’t understand what it does.

Edit:

I’ve now discovered that adding this code makes something else happen that I don’t want to happen. Trying to listen to something that is not present results in “I didn’t understand that sentence” instead of “You can’t see any such thing.”

I tried pasting the code into a new project with just “Lab is a room,” and when I tried listening to something not present, I then got “Glulxe fatal error: Memory access out of range (D0720).”

So…how big of a deal would it be to just leave the original error in there? This one:

[answering Marie that "
[** Programming error: tried to read from -->-1 in the array "parse", which has entries 0 up to 60 **]
 marie , hi" - ended without result]

[Piergiorgio_d_errico]

on the bug in itself, don’t worry, looks like the classical fencepost error in calculating a pointer (-1 instead of 0 is a big clue)

but I can’t explain well the other question, perhaps a bubbling beaker award laureate can explain much better than me…

Best regards from Italy,
dott. Piergiorgio.

[otistdog]

If I’m not mistaken, in general this run-time error is seen when template code attempts to print a snippet that is invalid. Based on where and how it is appearing, that’s what seems to be happening here.

I’m not sure why it would be happening in this case, however. If I had to guess blindly without seeing source code, I would suggest that you might have some after reading a command... rule that is parsing a number or a custom kind of value, which is redefining an internal variable called parsed_number. I’m not looking at template code right now, though, so I could be wrong.

If you would like a more specific diagnosis, try to work out the minimal code that produces the error and post it here.

Also: Is it only when >RULES is active that you see it? Based on the symptom, I would expect it to be happening due to >ACTIONS.

Also: The code that you pasted in is for dealing with “verbless” grammar (i.e. grammar lines that allow the player to just type in an object name or the like) when giving orders to NPCs. Is that something that you’re trying to enable?

[bg]

Here is some very minimal code to demonstrate the issue:

Lab is a room.

Marie is a woman in Lab.

Homing is an action applying to nothing.

Understand "house" and "home" as "[home]".

Understand "[home]" as homing.

Test me with "Actions / Marie, hi"

(The actual code has multiple actions like this with tokens, which I would rather not take out, because of the number of permutations I am dealing with.)

@otistdog

Also: Is it only when >RULES is active that you see it? Based on the symptom, I would expect it to be happening due to >ACTIONS.

You’re right–it’s ACTIONS. I think I may have had both actions and rules turned on.

@otistdog

Also: The code that you pasted in is for dealing with “verbless” grammar (i.e. grammar lines that allow the player to just type in an object name or the like) when giving orders to NPCs. Is that something that you’re trying to enable?

I have “Understand” lines that begin with a token, but I’m not using them for anything related to NPCs. I don’t have any need for giving orders to NPCs. I’d be happy to turn off order-giving (and directly addressing NPCs at all) if that would help, but I don’t know how.

[otistdog]

OK. The cause isn’t what I guessed, but the reason for the run-time error is basically the same. The line

Understand "[home]" as homing.

is used to try to understand any command in which the first word is not a recognized verb word as an instance of that token. For the command, >MARIE, HI, the grammar for your homing action tries and fails to match the player input “hi” with the known words 'house' and 'home'. Unable to resolve any action, the parser is trying to convert the command to an answering it that action, but it’s not setting the value of parsed_number correctly in the process.

The error is solely a side effect of trying to print out the topic understood. This is done automatically when >ACTIONS is on. Your code may never do it, and if that is the case, you can probably just ignore this bug.

However, as explained by @drpeterbatesuk in the post that you referenced, the compiler is not expecting grammar lines to be declared in this way. Since you say you aren’t dealing with NPCs but do want to keep using token-based “verbless” grammars, some tinkering with template code would be required to work around the bug.

Are you using 6M62 or 10.1.2?

[bg]

Thanks!

I’m using 6M62.

@otistdog

The error is solely a side effect of trying to print out the topic understood. This is done automatically when >ACTIONS is on. Your code may never do it, and if that is the case, you can probably just ignore this bug.

I don’t know whether “topic understood” is printed out. So I think I’ll just opt to rewrite the “Understand” lines instead. It’s not as many as I thought it would be, once I realized I don’t have to get rid of all the tokens in the understand lines–just the ones that come first. So I can still say things like

Understand "whatever [token] [token]" as homing.

Just not

Understand "[token] [token] [token]" as homing.

Thank you!