Inform 7 v10.1.0 is now open-source

Apparently the new I7 really wants you to put a space after the function-opener [. Doing that yields an “unexpected node type in Inter tree” internal error instead.

There does seem to be interest in using the (+ … +) notation, inside Include… text, to perform function calls to phrases defined by source text (rather than by further Inform 6 syntax); and also to be able to call functions indirectly by their addresses within inclusions, i.e., to store a function value in a variable and then call the function identified by that variable. (In I6, this has an identical syntax, but is really semantically not the same thing.)

In general, use of even “Include (- … -)” is probably best minimised, and use of “(+ … +)” within that really isn’t something we want to encourage. (This is no longer a world in which this code is just being cut-and-pasted into I6 output: we could have to compile this to C, for example. “(+ … +)” is probably the feature of I7 I most wish I’d never introduced.) Still, I’ve pushed an update which should improve things for people who need to, and particularly to help people getting old extensions to work with 10.1.

The following Basic Inform project:

To begin:
	perform the test.

To perform the test: (- beta(); -)

To expostulate mildly about (N - a number) (this is the irked function):
	say "I do think this is a pity, given [N]."

To expostulate firmly (this is the riled function):
	say "Oh really! This is too much!"

Include (-
[ alpha;
print "alpha called^";

[beta n plugh;
print "beta called^";
plugh = alpha;

((+ irked function +)-->1)(7);
((+ irked function +)-->1)(22);
((+ riled function +)-->1)();

now compiles, and produces:

beta called
alpha called
alpha called
I do think this is a pity, given 7.
I do think this is a pity, given 22.
Oh really! This is too much!

(This is the new test case “IndirectCallsInInclusions”.)

It was also noticed in this thread that the parser used when compiling inclusions did not like I6 syntax with routine names jammed up against the opening square bracket, “[like_this”. It seemed harmless to allow this, so I’ve done so.


is the documentation that can be built in the resources directory accurate to the current version?

Dr. Nelson may provide a much more comprehensive answer, but from what I’ve seen:

  • the discussion of extension version numbers hasn’t been updated vis-a-vis semantic version numbers
  • the section on Inform 6 inclusions at the very end needs updating
  • I just noticed there’s still a reference to downloading extensions from the website, and there are probably still odd little specific bits that are off – but many others have been updated
  • We haven’t seen the IDEs yet, but I’d guess some specific stuff about using them will have to change, and there will be some discussion of the new toolchain and concepts like “nests”… or at least a pointer to the existing inform7 10.1.0 docs on the subject.

But the language itself seems to be vanishingly close to unchanged, so regarding the language I don’t think you would do yourself any harm by reading it as is.


A short heads up about Beta release of Inform App for Linux!


There seems to be some more sensitivity to ambiguity in property names. This, from Bulk Limiter by Eric Eve won’t compile in v10:

A thing has a number called bulk.
The bulk of a thing is normally 1.

A container has a number called bulk capacity.
The bulk capacity of a container is normally 10.

A person has a number called bulk capacity.
The bulk capacity of a person is normally 100.


I am reading the sentence ‘The bulk capacity of a container is normally 10’ (Extensions/Eric Eve/Bulk Limiter.i7x, line 9) as saying that a thing called ‘bulk capacity of a container’ is a value, but this makes no sense to me - it would be like saying ‘the chair is 10’.

I am reading the sentence ‘The bulk capacity of a person is normally 100’ (Extensions/Eric Eve/Bulk Limiter.i7x, line 12) as saying that a thing called ‘bulk capacity of a person’ is a value, but this makes no sense to me - it would be like saying ‘the chair is 10’.

6M62 is ok with it. Both 6M62 and v10 are okay with defining bulk capacity first and then bulk:

A container has a number called bulk capacity.
The bulk capacity of a container is normally 10.

A person has a number called bulk capacity.
The bulk capacity of a person is normally 100.

A thing has a number called bulk.
The bulk of a thing is normally 1.

A Windows / Cygwin user report.

To handle the building on Windows using Cygwin, here’s an experience report. TL;DR - so far only one part of the process doesn’t work for me.

When installing Cygwin, I chose:

  • clang
  • dos2unix
  • libclang-devel
  • libclang8
  • make
  • mingw64-i686-clang
  • mingw64x86_64-clang

Building inweb

  • git clone
  • dos2unix inweb/scripts/
  • bash inweb/scripts/ linux
  • inweb/Tangled/inweb -help

Everything works. :white_check_mark:

Building intest

  • git clone
  • dos2unix intest/scripts/
  • bash intest/scripts/
  • intest/Tangled/intest -help

Everything works. :white_check_mark:

Building Inform

  • git clone
  • cd inform
  • dos2unix scripts/
  • bash scripts/
  • inblorb/Tangled/inblorb -help
  • ../intest/Tangled/intest inform7 -show Acidity

Everything works. :white_check_mark:

Running Full Tests

  • make check

That does not work in Cygwin for me. :stop_sign:

The following occurs:

$ make check
make -f inform6/ test
make[1]: Entering directory '/home/jeffn/i7/inform'
../intest/Tangled/intest -from inform6 all
shell: cd '/home/jeffn/i7/intest/Workspace/T0' ; rm -f *.txt
intest: fatal error: internal error (Execution of the shell failed)
make[1]: *** [inform6/ test] Error 2
make[1]: Leaving directory '/home/jeffn/i7/inform'
make: *** [makefile:431: check] Error 2

This looks to be happening with the following line:

$(MAKE) -f $(INFORM6WEB)/ test

Given that says it’s leaving the inform directory, I wonder if I don’t have something else set up. My current directory structure is:

  --> inform
  --> intest
  --> inweb

Here my i7 is equivalent to the work directory mentioned in the documentation. Specifically, there is in fact an intest\Workspace\T0 directory, which seems to be where the logic is going.

Looking at the line from that seems to be problematic, it looks to be this:

test: $(INTERPRETERS)/dumb-frotz/dumb-frotz $(INTERPRETERS)/dumb-glulx/glulxe/glulxe 
	$(INTEST) -from $(ME) all

I’m not sure if this means there’s some other step I should have taken to set up the interpreters. Although I do see a dumb-frotz directory in: inform\inform6\Tests\Assistants.

Nice one.

FWIW, i tried make check here with mingw and get this;

# make check
make -f inform6/ test
make[1]: Entering directory '/v/jkj/inform/inform'
../intest/Tangled/intest -from inform6 all
inform6 -> cases: [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40] [41] [42] [43] [44] [45] [46] [47] [48] [49] [50] [51] [52] [53] [54] [55] [56] [57] [58] [59] [60] [61] [62] [63] [64] [65] [66] [67] [68] [69] [70] [71] [72] [73] [74] [75] [76] [77] [78] [79] [80] [81] [82] [83] [84] [85] [86] [87] [88] [89] [90] [91] [92] [93] [94] [95] [96] [97] [98] [99] [100] [101] [102] [103] [104] [105] [106] [107] [108] [109] [110] [111] [112] [113] [114] [115] [116] [117] [118] [119] [120] [121] [122] [123] [124] [125] [126] [127] [128] [129] [130] [131] [132] [133] [134] [135] [136] [137] [138] [139] [140] [141] [142] [143] [144] [145] [146] [147] [148] [149] [150] [151] [152] [153] [154] [155] [156] [157] [158] [159] [160] [161] [162] [163] [164] [165] [166] [167] [168] [169] [170] [171] [172] [173] [174] [175] [176] [177] [178] [179] [180] [181] [182] [183] [184] [185] [186] [187] [188] [189] [190] [191] [192] [193] [194] [195] [196] [197] [198] [199] [200] [201] [202] [203] [204] [205] [206] [207] [208] [209] [210] [211] [212] [213] [214] [215] [216] [217] [218] [219] [220] [221] [222] [223] [224] [225] [226] [227] [228] [229] [230] [231] [232] [233] [234] [235] [236] [237] [238] [239] [240] [241] [242] [243] [244] [245] [246] [247] [248] [249] [250]
inform6 -> problems: [251] [252] [253] [254] [255] [256] [257] [258] [259] [260] [261] [262] [263] [264] [265] [266] [267] [268] [269] [270] [271] [272] [273] [274] [275] [276] [277] [278] [279] [280] [281] [282] [283] [284] [285] [286] [287] [288] [289] [290] [291] [292] [293] [294] [295] [296] [297] [298] [299] [300] [301] [302] [303] [304] [305] [306] [307]
  All 307 tests succeeded (time taken 0:53, 11 simultaneous threads)
make[1]: Leaving directory '/v/jkj/inform/inform'
inpolicy/Tangled/inpolicy -silence -check-problems
1026 problem name(s) have been observed:
    Problems actually existing (the source code refers to them):
        922 problem(s) are named and in principle testable
        77 problem(s) are 'BelievedImpossible', that is, no known source text causes them
        19 problem(s) are 'Untestable', that is, not mechanically testable
        7 problem(s) are '...', that is, they need to be give a name and a test case
    Problems which should have test cases:
        915 problem(s) have test cases
        7 problem(s) have no test case yet:
        1 problem(s) are spurious test cases, since no such problems exist:
    Problems which are cross-referenced in 'Writing with Inform':
        475 problem(s) are cross-referenced
This needs attention.

The 307 tests succeed as you can see, but i don’t know whether the observed problems after are also correct.

A Windows / MinGW-w64 user report.

Use the MinGW-w64 with the UCRT runtime.

Specifically I used GCC 11.3.0 + LLVM/Clang/LLD/LLDB 14.0.3 + MinGW-w64 10.0.0 (UCRT) - release 3. I also copied mingw32-make.exe to make.exe.

I also use Git Bash.

Building inweb

  • git clone
  • bash inweb/scripts/ windows

Right away some failures. :stop_sign:

make (e=2): The system cannot find the file specified.
make: *** [inweb/ initial] Error 2
(Okay, so that failed. Maybe your environment doesn't have the compilers anticipated?)

jkj yuio already noted this issue in his post. So I just copied clang.exe to x86_64-w64-mingw32-clang.exe. That appears to be due to an MinGW oddity. It doesn’t provide that alternate executable for clang while it does for just about all other C/C++ implementations. So try again:

  • bash inweb/scripts/ windows
  • inweb/Tangled/inweb -help

Everything works. :white_check_mark:

Building intest

  • git clone
  • bash intest/scripts/
  • intest/Tangled/intest -help

Everything works. :white_check_mark:

Building Inform

  • git clone
  • cd inform
  • bash scripts/

Got some issues. :stop_sign:

cd inform6/Tests/Assistants/dumb-glulx/cheapglk; make
make[1]: Entering directory 'E:/appDev/Projects/i7/inform/inform6/Tests/Assistants/dumb-glulx/cheapglk'
cc -g -Wall    -c -o cgfref.o cgfref.c
process_begin: CreateProcess(NULL, cc -g -Wall -c -o cgfref.o cgfref.c, ...) failed.
make (e=2): The system cannot find the file specified.
make[1]: *** [<builtin>: cgfref.o] Error 2
make[1]: Leaving directory 'E:/appDev/Projects/i7/inform/inform6/Tests/Assistants/dumb-glulx/cheapglk'
make: *** [inform6/ inform6/Tests/Assistants/dumb-glulx/glulxe/glulxe] Error 2

No idea what’s going on there so still investigating. I can say the the path (inform\inform6\Tests\Assistants\dumb-glulx\cheapglk) is accurate and present and the file cgfref.c is present as well.

But I do notice that last entry. It’s looking for:

  • inform6/Tests/Assistants/dumb-glulx/glulxe/glulxe

Notice the two “glulxe”? But I don’t have that. My build has:

  • inform\inform6\Tests\Assistants\dumb-glulx\glulxe

Per something jkj yuio also mentioned earlier, I did look at the Makefile in that directory. You’ll see this line:

OPTIONS = -g -Wall -Wmissing-prototypes -Wstrict-prototypes -Wno-unused -DOS_UNIX

I tried removing the -DOS_UNIX part but that results in the same error.

Still not sure how to resolve this one; investigating.

try my “suggested hacks” to the source here;

and run the build inside the mingw msys2 shell

after the hacks, rebuild inweb and intest first.

I did make those changes and it doesn’t seem to work for me. Same error. Specifically, I did the following:

In the inweb\Materials\platforms\windows.mkscript file, added:

SHELL = bash

Then my inweb\Chapter 6\Makefiles.w has been updated for the pathname_slashed function as follows:

void Makefiles::pathname_slashed(OUTPUT_STREAM, pathname *P) {
	WRITE_TO(PT, "%p", P);
		wchar_t c = Str::get(pos);
		if (c == '\\') c = '/';
		if (c == ' ') WRITE("\\ ");
		else PUT(c);

Then I rebuilt inweb and intest. Both compiled successfully as before.

However, running the compilation for Inform produces the same issue.

But you mention an interesting point: I’m not running msys2 at all. I just have the MinGW-64 installation on my path but I’m using Git Bash as the shell.

I wonder if that’s part of the issue. Is there something in the shell itself that would make this viable?

The end result of all this so far:

  • In a MinGW context, I can’t (yet) build Inform.
  • In a Cygwin context, I can build everything (but can’t run the make check).
  • On my MacOS, I have no issues whatsoever (for obvious POSIX reasons!)

It’s possible the msys shell makes no difference. I ran it because the build didn’t initially work and that can sometimes be the problem. I’ll dig out my list of pacman modules later so you can check.

However, there’s one thing you could check;

IIRC, you have to force rebuild inweb after the changes, or they do not work. have a look in to see if SHELL=bash is there. if not, then inweb didn’t really rebuild.

It’s worth pointing out that I’m using Cygwin (with mingw64-x86_64-clang installed) on Windows to build Inform, so that is the only way that is likely to work without hacking. It would be nice to support other systems, such as MinGW64, not least since that would provide a newer version of clang, but that’s not the priority right now.

It seems to me that the line that is not working is

shell: cd '/home/jeffn/i7/intest/Workspace/T0' ; rm -f *.txt

Does this directory actually exist? At one point there was a problem with workspace directories not being created. I thought that it had been addressed, but possibly not.

I finally cleaned up the extension smoketester output to the point where I feel okay about sharing it, so here’s the results of compiling the Friends extensions with v10; probably of most interest is which extensions have errors under v10. These pages subject to change or deletion without warning…

There are a few things that aren’t true to life because they reflect some trivial fixes I’ve made locally to make things compile, so you’d see a few more errors if you did it yourself. But it should be the case that there’s nothing on the errors page here that does compile in v10 using the Friends repo as External/Extensions.

(And note that many things on the Errors page never worked in 6M62 either.)

Edited: ah, pits. Some of the compiler error output gets mangled while rewriting it to link to the right line in the source code. But lunch is over and fixing it’ll have to wait.

1 Like

I did double-check just to be sure and I have confirmed that /home/jeffn/i7/intest/Workspace/T0 does exist. It has a series of directories in it:

  • Example.inform
  • Example.materials
  • Transient

It doesn’t haven’t any .txt files in it so, at the very least, it looks like the rm command did its job. Or, alternatively, is that what’s failing on? The fact that there are no .txt files? None of the other workspace directories (which number from T0 to T15) have text files in them either.

Although i understand Cygwin is the recommended way. I can also attest that is does work with mingw (after some hacks).

FYI, here are the msys2 pacman packages I’m using:

//Update the package database and core system packages with:
pacman -Syu

// toolchain
pacman -S --needed base-devel mingw-w64-x86_64-toolchain
pacman -S git bison make

// clang
pacman -S mingw-w64-clang-x86_64-toolchain

Looking over your notes in more detail, this is wrong

`bash inweb/scripts/ linux`

This needs to be “windows”, not “linux”. We’re using Cygwin as the environment, but we’re building Windows executables (using MinGW’s clang). You’ll need to rebuild everything.

At some point I’ll want to update the FyreVM extensions to work with the new Inform X.

It looks like the following will need to need to be updated:
-) instead of “Starting Up” in “Glulx.i6t”.
-) instead of “Keyboard Input” in “Glulx.i6t”.
-) instead of “Audiovisual Resources” in “Glulx.i6t”.
-) instead of “Typography” in “Glulx.i6t”.
-) instead of “Character Casing” in “Glulx.i6t”.
-) instead of “Glulx-Only Printing Routines” in “Glulx.i6t”.
-) instead of “The Screen” in “Glulx.i6t”.
-) instead of “Window Colours” in “Glulx.i6t”.
-) instead of “Main Window” in “Glulx.i6t”.
-) instead of “Status Line” in “Glulx.i6t”.
-) instead of “Quotation Boxes” in “Glulx.i6t”.
-) instead of “GlkList Command” in “Glulx.i6t”.
-) instead of “Quit The Game Rule” in “Glulx.i6t”.
-) instead of “Restart The Game Rule” in “Glulx.i6t”.
-) instead of “Restore The Game Rule” in “Glulx.i6t”.
-) instead of “Save The Game Rule” in “Glulx.i6t”.
-) instead of “Switch Transcript On Rule” in “Glulx.i6t”.
-) instead of “Switch Transcript Off Rule” in “Glulx.i6t”.
-) instead of “Prompt” in “Printing.i6t”.
-) instead of “Status Line” in “Printing.i6t”.
-) instead of “Yes/No Questions” in “Parser.i6t”.
-) instead of “Glulx Version” in “Text.i6t”.
-) instead of “Print Obituary Headline Rule” in “OrderOfPlay.i6t”.
-) instead of “Virtual Machine Startup Rule” in “OrderOfPlay.i6t”.
-) instead of “Score Notification” in “Printing.i6t”.

Given everything I’m seeing in this thread, this sounds like it will not be trivial. What I’d like to know is if will be impossible.



It won’t be impossible, though there may be bugs that prevent it currently. FyreVM might even suit being made into a kit.

OK, I’ve updated the smoketester results: here’s what Friends of I7 repo extensions don’t compile under v10 now with segfaults explicitly identified.

As noted previously, more than a hundred of these didn’t work on 6M62 either; some of those may never have worked in any version.

Edited to add: oh yeah, my rubric detection is broken, that’s why everything has “I see no description here.”