Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000076Core InformTablespublic2010-06-20 00:372010-07-04 16:27
Reportersoukie 
Assigned Tograham 
PrioritynormalSeveritymildReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSWindowsOS Version
Product Version6E59 
Target VersionFixed in Version6E72 
Summary0000076: Self-referential constant lists don't work in tables defining a kind of value
DescriptionThe output is:
Followers: , M: 3. Number of followers: -1

The number of 'followers' should be 2 and the entries should be
accessible to various operations such as "let candidates be followers
corresponding to a subject of .... in the Table of TestSubjects"
Minimal Source Text To Reproduce
Subject is a kind of value. The subjects are defined by the Table of
TestSubjects.

Table of TestSubjects
Subject Followers       Mass
subjA   {subjA, subjB}  3
subjB   {subjB} 5

Testlab is a room.
When play begins, say "Followers: [Followers of subjA], M: [mass of
subjA]. Number of followers: [number of entries of followers of
subjA]".
Additional InformationIn the previous build, submitter used a conversation system based on a table defined in this fashion:

<code>
Subject is a kind of value. The subjects are defined by the Table of
Existing Subjects.

Table of Existing Subjects
Subject Subject Title Followers Quip Availability Discussed
n "n" {n} "none" true true
</code>

With 6E59, submitter was unable to come up with a syntax to interact with the 'Followers' lists defined for the Subject values at all.
TagsNo tags attached.
Effect(serious/mild) Game compiles but misbehaves
Attached Files

- Relationships

-  Notes
(0000064)
jmcgrew (administrator)
2010-06-20 00:44

The code above doesn't seem to work in 5Z71 either.
(0000100)
graham (administrator)
2010-06-20 15:33

In fact the self-reference wasn't the problem here, tricky as it looks; it was to do with how Inform handles literal list constants. These require adaptation from their compiled state to their dynamic state, and Inform was performing this adaptation twice on the entries in the "followers" column - once because it knew they were list constants in a table column; once because it knew they were list constants in a property value. The second and redundant adaptation process corrupted the data and resulted in an empty list. Fixed.

- Issue History
Date Modified Username Field Change
2010-06-20 00:37 jmcgrew New Issue
2010-06-20 00:37 jmcgrew Product Version => 6E59
2010-06-20 00:37 jmcgrew Target Version 6E59 =>
2010-06-20 00:44 jmcgrew Note Added: 0000064
2010-06-20 00:44 jmcgrew Reproducibility have not tried => always
2010-06-20 00:44 jmcgrew Status new => acknowledged
2010-06-20 00:44 jmcgrew OS => Windows
2010-06-20 00:44 jmcgrew Status acknowledged => confirmed
2010-06-20 15:33 graham Note Added: 0000100
2010-06-20 15:33 graham Status confirmed => resolved
2010-06-20 15:33 graham Resolution open => fixed
2010-06-20 15:33 graham Assigned To => graham
2010-06-30 18:07 jmcgrew Fixed in Version => 6E72
2010-07-01 23:07 jmcgrew Status resolved => closed
2010-07-04 16:27 jmcgrew Reporter jmcgrew => soukie


Copyright © 2000 - 2010 MantisBT Group
Powered by Mantis Bugtracker