Running out of attributes?

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.

And while I’m asking, I’d also like to know how to increase this:

As you can see, I’ve almost hit the maximum, and I don’t see a memory setting for that either.

Not entirely sure how accurate or useful this info is, but 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 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.:

valued_property_offsets-->p194_emotionless = 601; valued_property_offsets-->p195_non_attacker = 604; valued_property_offsets-->p196_weapon_user = 607; valued_property_offsets-->p197_thrower = 610; valued_property_offsets-->p198_talker = 613; valued_property_offsets-->p199_deathly_resistant = 616; valued_property_offsets-->p200_flyer = 619;

If I get rid of an attribute (I commented out “normal-concentrating”), I get the same error, but with the next either/or property:

[code]auto.inf(11255): Error: Array reference is out-of-bounds

attributed_property_offsets-->p192_emotionless = 598;[/code]

As you can see, that is the first property that got translated into a valued_property before I took out normal-concentrating.

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 thought I might be able to just comment it out, since Flexible Windows also contains:

[code]A g-window can be g-present or g-unpresent. A g-window can be g-required or g-unrequired.

The g-present property translates into I6 as “g_present”.[/code]
But that doesn’t seem to work:

Apparently, the problem is that such a property gets translated into a “Constant”, not into an “Attribute”.

OK, I can get that last error message with a very minimal game:

[code]“Attributes” by Victor Gijsbers

Universe is a room. The player is here.

A person can be g-present or g-unpresent.

The g-present property translates into I6 as “g_present”.[/code]
If anyone knows how I can fix Flexible Windows, I would be very happy.

Unless that’s no longer allowed, it’s pretty important.

It’s also pretty important if it’s no longer allowed! (But perhaps we could rewrite everything using normal properties?)

I probably needed a semi colon there :wink:.

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.

Easy fix:

Include (-
Attribute g_present;
-) after "Properties" in "Output.i6t". 

The maximum number of attributes in Glulx is 56, not 48. Once again, the -s output is lying to you.

Ahh, currently it’s defined ‘after “Definitions.i6t”’. Any idea why it would needs to be moved?

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.

An Inform 7 property is defined for g_present however. 27.22 makes it look like this is still a supported feature.

I don’t know why the old form worked in 6G60 but not in 6L02.

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.