Is there currently an extant replacement for Tara McGrew’s Dynamic Objects for I7 v10? I’ve dug around but haven’t turned anything up; I’ve also considered just attempting to use the extant implementation, but I’m afraid of managing to royally perma-screw something up, since the source digs pretty heavily into the underlying I6 implementation (which was rewritten pretty heavily, I presume, for v10).
I ask whether this is possible chiefly because the Recipe Book (10.3) alludes to this being possible for Glulx; but no extensions appear to provide this ability to the Inform 7 end-user. Thanks!
(Yes, I know, I know: it’s bad practice; I’m more interested in the can than should.)
Dynamic Objects hasn’t been updated since 9.1/6L02 in 2014. It has known problems in 9.3/6M62. Unless some solitary hacker is keeping it to themselves, no one has an up-to-date version.
I still find it very impressive it was ever written, given that there wasn’t documentation on a lot of the underpinnings it makes use of. The good news, such as it is, is that Inform being open source puts one in much better stead to attempt such a thing today.
Details not relating directly to language changes often miss getting updated. It’s been a lot longer since Mistype by Cedric Knight was current.
Same, actually. Drives me crazy when Stack Overflow questions get shut down because “That’s not a strategy you should use”, and yet I keep finding problem spaces where these whacky things are the only solution. Also, information is valuable, even if I don’t intend to use it often.
Sorry that’s completely off-topic. Just something that seems to set me off. The Inform compiler will never cooperate with me. Just poking my head in from the office across the hall.
This seems encouraging, though! I’ll dig around in the guts of the compiler and see if I can find enough I6 hooks to get the job done. (The fact that FlexAllocate still lives in the codebase seems encouraging…)
It would be reasonable to propose this as a feature to be supported by Inform directly now. Some aspects of its implementation might be more straightforward if it was built in.
Minor update on this-- I’ve got a semi-functional port of Dynamic Objects working!
I haven’t tested it extensively, and in particular I’ve not gotten relations, but at the very least I’ve the milestone of getting the attached example code (The Cubbins Effect) functional
Will the new version allow for de-allocating dynamic objects when they’re no longer needed? That’s the thing that kept me from using the extension before: the unavoidable and ever-growing memory leak. (I realize it’s not leaking much memory by modern standards but it’s something I always try to avoid.)
It seems certainly possible to deallocate objects themselves-- that’s the relatively easy part, at least. Unfortunately, relations are another matter… even if the object itself is deallocated, unless we do some very gross hacks with the runtime relation tables, its corresponding row/column in the table won’t shift. (Then again, this is likely to be wasted space on the order of bytes per object.)
Why not just hybridize the system? Instead of destroying allocated objects, send them to nowhere, and before allocating a fresh object, reuse something from the eeby deeby pool if necessary. Best of both worlds, maybe?
To free (B - a ball):
remove B from play.
To decide which ball is make a new ball:
Let B be a random off-stage ball;
Unless B is nothing:
decide on B;
decide on a new Ball; [ Or however dynamic objects work ]
The extension already does something like this to make room in those tables for newly allocated objects.
I think the main reason I didn’t implement deletion in the first place was that references to the object might still live on in other places: other objects’ properties, tables, global variables, etc. In theory, those could be cleaned up as well, if the right sort of reflection data were available at runtime, and I suppose adding that data to the compiler’s output might actually be possible these days.
Right, this tracks, but as far as I understand the new objects get index sizeof(Table), so we don’t need to update extant indices. But if we deallocate, say, object at ix n when we’ve also allocated objects living at n+1, n+2, etc, we end up also having to shift the stored indices for the corresponding objects, which sounds to me like a general Bad Idea…
This makes sense, yeah… seems extremely easy to shoot oneself in the foot. In that case, unless I suddenly see a spark of madness and decide to write a garbage-collector, I’ll probably leave the deallocation problem be for now.
