MantisBT - Core Inform
View Issue Details
0000149Core InformIndexingpublic2010-06-30 23:122010-10-28 00:30
Ron Newcomb 
graham 
normalcosmeticalways
closedfixed 
PPCMac OS X10.4
6E59 
6F95 
(cosmetic) Index is created incorrectly
0000149: When a relation appears in Contents Index "#/bytes", with garbled characters instead of a name
The code produces the following at the bottom of the Contents index:
---------------------
table static ideas 148 bytes
object each room 140 bytes
object each direction 124 bytes
object each region 124 bytes
relation L,0{ 52 bytes <--------GARBLED
action each 48 bytes
scene each 21 bytes
--------------------

The behavior changes if I removed the subclass "virtue", and, the garbage produced is different on each compilation. This may indicate a deeper problem?

"bugtest" by Ron Newcomb

spot is room.

A concept is a kind of thing.
An idea is a kind of concept.
A virtue is a kind of idea.

Knowing-about relates various people to various concepts. The verb to know-about (he knows-about, they know-about, he knew-about, it is knowing-about, he is knowing-about) implies the knowing-about relation.

Mary Sue is a person.


Some ideas are defined by the table of static ideas.

Table of Static Ideas
idea
aa
bb
cc
dd
ee
ff
gg
hh
ii
jj
kk
ll
mm
nn
oo
pp
qq
rr
ss
tt
uu
vv
ww
xx
yy
zz
ab
cd
ef
gh
hi
jk
lm

No tags attached.
has duplicate 0000256closed  Incorrect contents index for relations over a certain size. 
Issue History
2010-06-30 23:12Ron NewcombNew Issue
2010-06-30 23:49jmcgrewSeveritymild => cosmetic
2010-06-30 23:49jmcgrewStatusnew => acknowledged
2010-07-01 15:34EmacsUserNote Added: 0000214
2010-07-01 18:29Ron NewcombNote Added: 0000215
2010-07-01 21:07jmcgrewNote Added: 0000221
2010-07-01 21:08jmcgrewStatusacknowledged => confirmed
2010-08-19 21:09EmacsUserRelationship addedhas duplicate 0000256
2010-08-19 21:12EmacsUserNote Added: 0000400
2010-08-20 03:03dchapesIssue Monitored: dchapes
2010-08-20 03:40dchapesNote Added: 0000403
2010-08-20 03:41dchapesNote Edited: 0000403bug_revision_view_page.php?bugnote_id=0000403#r193
2010-08-31 15:16grahamNote Added: 0000473
2010-08-31 15:16grahamStatusconfirmed => resolved
2010-08-31 15:16grahamResolutionopen => fixed
2010-08-31 15:16grahamAssigned To => graham
2010-10-25 21:14jmcgrewFixed in Version => 6F95
2010-10-28 00:30jmcgrewStatusresolved => closed

Notes
(0000214)
EmacsUser   
2010-07-01 15:34   
Hmm. I cannot confirm by pasting the given source into a new project. I am using x86 though; perhaps this bug is only exposed under PPC?
(0000215)
Ron Newcomb   
2010-07-01 18:29   
Oh-ho! It is specific to Glulx! How interesting.
(0000221)
jmcgrew   
2010-07-01 21:07   
On Windows, when compiling to Glulx, I see:

relation WearerOf(noun) 52 bytes

Next to "WearerOf(noun)" is an orange arrow that links to the definition of knowing-about.

This line is missing when compiling to Z-code.
(0000400)
EmacsUser   
2010-08-19 21:12   
The test case in 0000256 is simpler, in case that's of any help.
(0000403)
dchapes   
2010-08-20 03:40   
(edited on: 2010-08-20 03:41)
As EmacsUser mentioned, there is a smaller test case in the duplicate issue that I'd recommending using instead of the above.

I failed to mention in that report that it was reproducible in all story file formats (Z5, Z8, and Glulx) so it is definitively not Glulx specific (nor PPC/Mac specific).

I checked it again and found that if the number of things and people are dropped from 20 to 10 each then the problem only persists with Glulx. Also, the text "WearerOf(noun)" first changes to garbage with this simple test when the values are changed as follows:

Knowing about relates various people to various things.
The Lab is a room.
A block is a kind of thing.
99 blocks are here.
99 women are here.
98 men are here.

(These values noticeably slow down compilation and exceed the readable memory limit of Z8). For what it's worth, my Z8 project that produces garbage text currently has only 9 rooms and 87 things.

(0000473)
graham   
2010-08-31 15:16   
Fixed. An intermittent bug due to using text left on a discarded stack frame, so it only sometimes kicked in, and was sometimes platform-dependent, and also depended on what else was in the usage table, etc., etc.