Inform 7 v10.1.0 is now open-source

While I’m submitting patches, I’m noticing that three separate extensions have been written to deal with the same bug in the core Inform library:

Article Bug Fix by Daniel Stelzer
Indefinite Article Substitution Fix by Matt Weiner (for Glulx only)
Print Stage Detection by Taryn Michelle

The bug is still present in the current version of the WorldModelKit. I am inclined to submit a permanent patch to fix this once and for all. The most flexible and least invasive patch is Print Stage Detection by Taryn Michelle, though I’m not sure where to move the extensive and excellent associated documentation by Taryn Michelle. However, I would welcome comments.


I must have been the author of this confusion, but can’t remember it at all. Looking at the code now, though, “untouchable_silence” simply suppresses response messages explaining that the player can’t reach through some barrier. The variable is set only temporarily and only when checking scope. I can’t imagine circumstances where QUIT_THE_GAME_R could sensibly run when this is set, and therefore the condition (untouchable_silence == false) just looks redundant to me, and should be taken out.

Maybe this was an accident with cut and paste? Anyway, the Z version looks right to me.


That was my guess.

Thank you Mr. Nelson. Pull request made.

1 Like

I think it’s worth checking through the “6M62 Patches.i7x” file and seeing which ones are still needed, to try to get them into v10.1 before release. On a quick check of the current Inform source code, it looks like most of them are still needed, but I haven’t gone through them all in detail (and I don’t fully understand the errors being fixed by some of them, so I’m not quite sure how to test). Any assistance would be appreciated.


Of the contents of 6M62 patches, I was unable to reproduce


in v10. They seemed to have already been fixed before the initial release.

The following had already been an old mantis bug: I7-1746 and has been fixed. (I tried it.)

The following have not yet been reported.


I’m feeling pretty good. I fixed the presentation of extension documentation, which has been broken since 6M62. When-and-if Graham Nelson merges it (now done), it should be all spiffy again, like it was before 6M62.

Also fixed the ability of examples in extensions to have a “by Somebody” phrase.

This is one of the great advantages of being open source: other people can (and will) fix your bugs. These could have been fixed years ago had Inform been open-source earlier, but better late than never. Hooray for open source!


Just to note that I’ve pushed a change to the inform repository to incorporate everything from the “6M62 Patches” extension - a collection of useful fixes to misbehaving functions in (what is now) BasicInformKit. Several of these issues had already been addressed, but others had not.

Note in particular that although a different solution had already been found for the issue with rulebooks returning lists, I agreed with “6M62 Patches” that it was correct to use the strong kind ID and not the weak kind ID in the implementation of “rule succeeds”.

I’m hoping that this change will cause no problems for anybody; “6M62 Patches” should now no longer be needed.


…And I’ve now made a small fix having missed out one change; thanks to otistdog for finding this and pointing this out.


Absolutely astounding. Reading your announcement was like standing in the path of some avalanche.

Thanks Mr. Nelson!


I just looked at what a “Kit” is and I’d agree that the FyreVM Core extension would be best served as a Kit. It’s all I6 replacement code. Who’s interested in helping? The current code is here: fyrevmweb-react/extensions/David Cornelson at main · ChicagoDave/fyrevmweb-react · GitHub

It’s a misnomer that the repo is named “-react” since that’s just the implementation of a UI using fyrevm-web, but the extensions are there.


1 Like

There are some significant changes in the beta today for how to describe a new kit, though the functionality remains the same - you can adapt to these changes quite quickly and easily.

Not everybody will be following this now rather long thread, so I’ve started a page of brief notes about recent changes, and placed it here:


Thanks again for absorbing our long collection of bugfixes.

I am currently trying to figure out the best way to handle the nest of bugs related to the way the kits pick “a” or “an” for an object name, bugs for which there have been three separate extensions written over the years (Article Bug Fix, Indefinite Article Substitution Fix, and Print Stage Detection). I really would like to get this fixed properly in Core Inform.

It has become clear to me that a proper fix requires the ability to dynamically allocate a buffer in a function defined in I6, print to that buffer, and then turn the buffer into a text (all of which can be disposed of at the end of the function – so it could be allocated on the stack).

The problems are that a proper implementation requires that PrefaceArticleBy must be reentrant, which means it cannot use a global buffer (which it currently does); and it should be able to call out to player-defined I7 code, which means I need a way to convert a buffer into text; and that it must not call PSN__ twice (which is easy enough).

At the moment I do not see how to allocate a function-local buffer on the stack or convert it to a text, though it looks like such things are being done by the internals of Inform 7 so it is perhaps possible. This is essentially bugfix material, but rather difficult bugfix material.

Any assistance would be appreciated.

I’m going to ask for some consideration regarding extending the beta status of Inform 10.1 until some more bugfixes and porting issues are resolved.

The other category of core code for which large amounts of extension material has been written to work around bugs is disambiguation. There are several of these extensions, some of which have been heavily used and used in well-known games (such as Scroll Thief), and they involve invasive parser work.

Two of these are Dismabiguation Control by Jon Ingold and Responsive Disambiguation for 6M62, both of which have to replace multiple Parser Letter sections.

These are two of only three remaining unported extensions which worked for 6M62/9.3 which replace Parser Letter sections: the other one is Unified Glulx Input by Andrew Plotkin, which seems not widely used.

One of the sections replaced in Disambiguation Control is described as “reset cobj_flags on reparsing (the library should do this anyway, I think)”, which makes me suspect it might be a bug fix.

These are heavily-used extensions which require substantial porting. I would like the chance to figure out if there’s a way to give them better hooks in Core Inform – because I really don’t like the idea of replacing the entire monolithic Parser routine – and to see if elements of them are actually bugfixes which should just be pushed up into Core Inform.


Historically, I think the reason that fixed buffers were used for things like PrefaceArticleBy was that the Z-machine had such a heavily constrained memory. But that shouldn’t be driving Inform any longer, since Glulx has for years been the platform used for almost all projects, and the amounts of memory we’re talking about here are fairly trivial.

What I would suggest, in terms of a function-local buffer, would be (a) to continue to use the current fixed buffer on Z but (b) to use VM_AllocateMemory and VM_FreeMemory on Glulx.

Creating a text is fairly easy. I would think a sensible thing would be to use two words at the front of the memory allocated from VM_AllocateMemory to hold the short block - the two words would then be UNPACKED_TEXT_STORAGE followed by the address of a long block which you’d allocate from the heap using FlexAllocate(32, TEXT_TY, TEXT_TY_Storage_Flags). (Basically, imitate what is done by the existing function TEXT_TY_Temporarily_Transmute.) That will give you a valid but initially empty I7 text, and you can then copy in the text from the buffer. When you’re done with it, make sure BlkValueFree is called first, and then use VM_FreeMemory to get rid of the buffer as well. Something like that?

I’m sympathetic on the question of extending the beta a little further to work on these issues, because there’s still plenty of useful work going on. As it happens the Mac app is still not quite done (it works fine on modern versions of MacOS, but we want it to work on versions back to Mojave, and there are some rendering issues there). So we’re not quite ready to declare the official release anyway, but probably that’s not going to hold things up for long.

Beyond that point, it’s going to be a matter of deciding what’s good enough, from the user’s point of view.


(i do not know if this is the right place for this but i could not find a way to inform them of the issue on the github page, so i dont know how to contact them about the issue) i have noticed when build the inform7-ide that when running the forceintegration that the kits folders that get transfer over to the ide are named “BasicInformExtrasKit-v10_1_0-beta+6V20” and such, but when trying to build a project using the ide inform7 say it can not find the kits. i was able to make it find the kits by renaming the folders removing the version number after the name


Your best bet would probably be the Beta release of Inform App for Linux thread. But one can file bugs against the “Gnome Inform Application” component in the I7 bug tracker (account creation with Atlassian required).

I’m not sure whether a process is in place right now for @ptomato to get notified about it, but one can do it.

thanks for the info, i have created a bug report

when looking through the build log of inform i noticed this error when building kits "Build failed at ‘’/home/silver/aur-packages-git/inform-7-ide/src/inform/inter/Tangled/inter’ -architecture 16 -build-kit ‘inform7/Internal/Inter/BasicInformExtrasKit’, it doesn’t seem to cause the build to fail so i don’t know if this is important?(building on linux, in case that info is needed)

The build (that is, the compilation of Inform compiler) is a thing, but the compilation of a story file is the thing whose REALLY matters.

if the build is successfully (that is, there’s an up-to-date inform/Tangled/inform7 binary) try to compile some story file (the customary lab should suffice)

Best regards from Italy,
dott. Piergiorgio.

I think this issue may now be fixed.

1 Like