I don’t know if that rewrite covers optimizations.
I haven’t looked at the current indexed text code re optimizations, either. HL doesn’t use 'em.
If you’re using any kind of heap using kinds Zarf you might like to. Well, if it is excessively slow.
Nonetheless, the new block value management code (the ``small blocks’’ scheme) should help with some of that. And if multi-block layouts will be left behind, that should also curtail the BlkSize penalty.
Ooh, that’s news to me. If multi block blocks are removed then inlining the function calls will be much easier.
Whoa, clarification: by ``if multi-block layouts will be left behind’’ I mean that I would like to see this happen but am not sure whether the change actually made it into the rework.
My current plan is that HL will continue to use 6G60 even after a new I7 is released. Even with my testing infrastructure, I don’t think I can afford to swap out compilers at this late stage of development.
That being the case, I am avoiding all heap data structures.
(My current game file is just about 1.9 megabytes… which jumps by 100k if I add an indexed text variable.)
(Heck, it jumps by 10k if I add the line “An object has a text called the dfgdfg.” At some point I’m going to have to rip into the Standard Rules and start removing features I don’t need.) (Speaking of which: what the heck are “indefinite appearance text”, “variable initial value”, and “specification”?)
That doesn’t mean indexed text is gone; the system just can decide automatically whether it uses “normal” text or indexed text.
The specification is a bit of text assigned to a kind in the standard rules (“The specification for a room is ‘Represents geographical locations, both indoor and outdoor, which are not necessarily areas in a building…’”), which I imagine is used somewhere in the editor. I don’t know what the other two are for.
The other two are also placeholders for ni, and only declared to ensure that their numbers are distinct from those of non-placeholder properties. ``variable initial value’’ is used to hold the initial values of explicitly initialized global variables, as in
Foo is a person that varies; foo is yourself.
or even
"Story" by Author
which initializes bibliographic globals.
`indefinite appearance text’’ is used whenever quoted text stands on its own in the source and is to be understood as the initial appearance or description of the object under discussion:Kitchen is a room.
"Where tasty meals are prepared."
1 Like
Thanks.
Further testing indicates that even though the Standard Rules say “An object has a text called specification” (etc), the compiler does not generate property table entries for these three properties on each object. So there’s no waste of space to concern me.
This is the text that shows up in the Kinds tab of the index when you click the magnifying glass next to “Room.” Don’t know if it’s used anywhere else.
If this is a property, in some sense, is it possible to change its meaning? For example, could I make it so that a “subject” uses its indefinite appearance text as its description?
Not in any way that I can see. The property only has full-fledged existence during compilation, so one would need a sentence like
The description of a subject is usually the indefinite appearance text of it.
which Inform rejects. I suspect that the kind-based determination of meaning is hard-coded in ni. The internal error if you comment out the property declaration seems to bear this hypothesis out, in particular implicating Chapter 17/Valued Properties.w.
Inform doesn’t accept this either:
However, both of the following compile, though the latter throws a run time error (saying something to the effect (I suppose) that the indefinite appearance text property no longer exists):
The description of a thing is usually "[initial appearance]".
The description of a thing is usually "[indefinite appearance text]".
(The initial appearance is not one of the internal properties elided by the compiler.)