I am tantalizingly close to compiling Kerkerkruip; there’s just one error in the Inform 6 stage left. However, it has me stumped.
I guess that this has something to do with what I’m seeing just below that in the error console:
But how do you increase the number of attributes? I’ve opened up auto.inf, which starts with a big list of all the memory settings; but I don’t see any setting pertaining to attributes.
Not entirely sure how accurate or useful this info is, but ifwiki.org/index.php/Attributes_in_Inform_6 says you can change the number of attributes available by the $NUM_ATTR_BYTES setting? Is this what you need? No idea at all about global variables.
Increasing the number of attributes ($NUM_ATTR_BYTES) is not recommended at this time. There is a bug in Glulxe which will crash if you try it. I fixed this bug only a couple of months ago (see thread https://intfiction.org/t/glulx-accelerated-functions-and-num-attr-bytes/6499/1) so most people won’t have a fixed interpreter yet.
I7 should never create this many attributes, anyhow. It’s supposed to switch over to individual (I6) properties when it approaches the limit of 48. Are you creating new attributes in I6 code?
Same with global variables, actually. If you create an I7 global variable by saying “Foo is a number that varies”, that is not an I6 global variable. You can’t hit a limit by doing that.
If you’re creating I6 globals directly, the limit is $MAX_GLOBAL_VARIABLES. Which is 512 by default, actually. That “233” number there is a total lie. Ignore it.
Here are all the lines in auto.inf starting with “attributed_property_offsets”.
attributed_property_offsets-->pluralname = 437;
attributed_property_offsets-->proper = 447;
attributed_property_offsets-->ambigpluralname = 457;
attributed_property_offsets-->privately_named = 467;
attributed_property_offsets-->light = 473;
attributed_property_offsets-->visited = 477;
attributed_property_offsets-->light = 480;
attributed_property_offsets-->edible = 484;
attributed_property_offsets-->static = 487;
attributed_property_offsets-->scenery = 490;
attributed_property_offsets-->clothing = 493;
attributed_property_offsets-->pushable = 496;
attributed_property_offsets-->moved = 499;
attributed_property_offsets-->concealed = 502;
attributed_property_offsets-->workflag = 505;
attributed_property_offsets-->mentioned = 509;
attributed_property_offsets-->enterable = 512;
attributed_property_offsets-->transparent = 516;
attributed_property_offsets-->open = 519;
attributed_property_offsets-->openable = 523;
attributed_property_offsets-->lockable = 527;
attributed_property_offsets-->locked = 531;
attributed_property_offsets-->female = 535;
attributed_property_offsets-->neuter = 538;
attributed_property_offsets-->on = 541;
attributed_property_offsets-->g_present = 546;
attributed_property_offsets-->p173_g_required = 549;
attributed_property_offsets-->p180_readied = 564;
attributed_property_offsets-->p181_at_parry = 567;
attributed_property_offsets-->p182_at_dodge = 570;
attributed_property_offsets-->p183_at_roll = 573;
attributed_property_offsets-->p184_at_block = 576;
attributed_property_offsets-->p185_at_expose = 579;
attributed_property_offsets-->p187_cardinal = 584;
attributed_property_offsets-->p188_placed = 587;
attributed_property_offsets-->p190_normal_concentrating = 592;
attributed_property_offsets-->p193_super_undead = 598;
attributed_property_offsets-->absent = 996;
attributed_property_offsets-->mark_as_room = 1004;
attributed_property_offsets-->mark_as_thing = 1006;
The first 25 are obviously from the Standard Library. I think “g_present” and “g_required” are from Flexible Windows. Then we have a bunch from Inform ATTACK and other Kerkerkruip extensions, and three more that I don’t recognise but could try to look up if that seems useful are also from Inform 7 itself. None of the Kerkerkruip ones are created by I6 code, I’m certain of that.
I also notice that these total up to 40, not to 49.
It also seems that other either/or properties are (correctly) turned into valued_property_offsets, e.g.:
All right, I managed to track the error down to Flexible Windows. Here’s a minimal program that reproduces the compilation failure:
[code]“Attributes” by Victor Gijsbers
Universe is a room. The player is here.
A person can be asjl.
A person can be ashkdj.
A person can be asdhk.
A person can be ndfk.
A person can be adl.
A person can be jdlmkm.
A person can be nemf.
A person can be smflk.
A person can be wjn.
A person can be dnal.
A person can be asjlx.
A person can be ashkdjx.
A person can be asdhkx.
Include (-
Attribute g_present;
-) after “Definitions.i6t”. [/code]
As you can see, it is creating a new attribute with that Inform 6 code (which is in Flexible Windows) that makes things go awry.
I think it’s possible to do an I7 inclusion for the properties in the I6 code, but it’s a lot more messy. It that’s what it takes to fix FW then that’s what I’ll do, but I’ll change it again if it gets fixed.
The wossname, attributed_property_offsets array, is supposed to describe all the attributes in order – that is, in the order that I7 creates them. If you define your own attribute that I7 doesn’t know about, it throws off the ordering; all the attribute values that I7 creates after that are higher than I7 thinks they are.
The solution is to do all your attribute-creation after I7 is finished with its.
I don’t think I can figure out any more of this situation. I’m not very clear on how I7 handles I6 attributes internally.
We know that 6L02 defines one I6 attribute (“ambigpluralname”). It’s possible that it failed to adjust some internal accounting by one to account for this. It’s also possible that including new attributes “after “Definitions.i6t”” was always wrong, although then it’s not obvious why it used to work.