Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000982I6 LibraryGeneralpublic2012-08-08 16:272015-05-10 17:47
Assigned ToDavidG 
PlatformOSOS Version
Product Version6/11 
Target Version6/12Fixed in Version6/12 
Summary0000982: parser_inflection requires common properties in Glulx
DescriptionOriginally reported by Roger Firth as Issue L61126

Exercise 109 in the DM4 defines a 'swedishnoun' token to make nouns and adjectives agree with the article (definite or indefinite) applied to them.

When targetting Glulx, this works only if 'swedish_definite_form' and 'swedish_indefinite_form' are defined as common properties; the Glulxe interpreter crashes if they're defined as individual properties. Both forms are accepted by the Z-machine.
Minimal Source Text To Reproduce
  [ swedishnoun;
      parser_inflection = swedish_indefinite_form;
      if (NextWord() == 'den' or 'det') parser_inflection = swedish_definite_form;
      else                              wn--;
      return ParseToken(ELEMENTARY_TT, NOUN_TOKEN);

  Object  -> "brown Swedish dog"
    with  swedish_definite_form   'bruna' 'hunden',
          swedish_indefinite_form 'brun' 'hund';
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
zarf (developer)
2012-08-09 14:39

I believe this is the fault of the Refer() function, which tests "(parser_inflection >= 256)" to distinguish property values from function values. In Glulx, individual property constants start at 256 (and could conceivably start even higher in a future release).

You could test against a higher value under Glulx, but this is risky. There's no guarantee that the range of valid function addresses won't overlap the range of valid property constants. You really want to store a separate flag to indicate whether parser_inflection is a property or a function.

(Note that INDIV_PROP_START is defined as an I6 constant in Z-code, but not in Glulx.)
DavidG (developer)
2012-08-09 20:48

How is swedishnoun() supposed to be executed? Trying to come up with a test game.
jmcgrew (administrator)
2012-08-09 23:13

Could you use ZRegion/metaclass to check whether parser_inflection is a routine?
zarf (developer)
2012-08-10 09:48

For values between the end of the header and the end of memory, ZRegion/metaclass looks at the tag byte (val->0) to decide whether something is a function. If you throw in property constants, you'll get false positives, which will translate to crashes.

As I said, the ranges can overlap. It is easy to create a large Glulx game where 60 is both the address of a function and a valid common property constant. (Admittedly, 60 is usually the address of Main__(), which can safely be ignored for this purpose. Functions that might legitimately be used for grammar parsing would appear quite a bit later in memory, so you can probably approximate your way out of this. It's just not guaranteed to be correct.)
DavidG (developer)
2014-05-19 05:31

I'm starting to suspect a Glulx interpreter bug.
zarf (developer)
2014-06-03 10:13

The problem is the library wants the "parser_inflection" global to store either a property value and a function value, and distinguish them solely by the value. This is impossible in Glulx.

The easiest fix is to have two globals, "parser_inflection" and "parser_inflection_func". Set the latter to false when "parser_inflection" is a property value, true when "parser_inflection" is a function.
DavidG (developer)
2014-06-04 16:17
edited on: 2014-06-04 16:52

Can I get from you a complete test game that would tickle this bug? How can one tell, in Glulx, if "parser_inflection" is a property value or a function? It sounds like I can't use metaclass().

zarf (developer)
2014-06-05 07:15

I don't have an example beyond the one that's reported above.

It is impossible in Glulx to distinguish a property value from a function based solely on the value. You would have to set "parser_inflection_func" correctly at the same time that you set "parser_inflection".
DavidG (developer)
2014-06-05 18:37
edited on: 2014-06-05 21:09

I see... It should be up to the programmer to correctly set parser_inflection_func to true. I see where to add the check for this. I suppose it should be initialized at the beginning of Parser__parse(). Where should it be reset back to false?

zarf (developer)
2014-06-06 09:12

Every time parser_inflection is set to a property value.
DavidG (developer)
2014-06-06 11:05

How does this look? [^]
zarf (developer)
2014-06-07 07:08

if (parser_inflection_func || parser_inflection >= 256) 

should be

if (parser_inflection_func) 

A property number can be greater than 256 in Glulx, and a function address can be less than 256 (although that's unlikely.)
jmcgrew (administrator)
2015-05-10 17:47

Closing all resolved issues from 2014 and earlier.

- Issue History
Date Modified Username Field Change
2012-08-08 16:27 DavidG New Issue
2012-08-09 14:39 zarf Note Added: 0001783
2012-08-09 20:48 DavidG Note Added: 0001785
2012-08-09 20:48 DavidG Assigned To => DavidG
2012-08-09 20:48 DavidG Status new => feedback
2012-08-09 23:13 jmcgrew Note Added: 0001787
2012-08-10 09:48 zarf Note Added: 0001788
2014-05-19 05:31 DavidG Note Added: 0002797
2014-05-19 05:31 DavidG Status feedback => assigned
2014-06-03 10:13 zarf Note Added: 0002866
2014-06-04 16:17 DavidG Note Added: 0002867
2014-06-04 16:32 DavidG Note Edited: 0002867 View Revisions
2014-06-04 16:52 DavidG Note Edited: 0002867 View Revisions
2014-06-05 07:15 zarf Note Added: 0002868
2014-06-05 18:37 DavidG Note Added: 0002869
2014-06-05 21:09 DavidG Note Edited: 0002869 View Revisions
2014-06-06 09:12 zarf Note Added: 0002870
2014-06-06 10:43 DavidG Note Added: 0002871
2014-06-06 10:56 DavidG Note Deleted: 0002871
2014-06-06 11:05 DavidG Note Added: 0002872
2014-06-07 07:08 zarf Note Added: 0002873
2014-06-07 17:06 DavidG Status assigned => resolved
2014-06-07 17:06 DavidG Fixed in Version => 6/12
2014-06-07 17:06 DavidG Resolution open => fixed
2015-05-10 17:47 jmcgrew Note Added: 0003610
2015-05-10 17:47 jmcgrew Status resolved => closed

Copyright © 2000 - 2010 MantisBT Group
Powered by Mantis Bugtracker