I'm trying to work with the latest Inform -- what is the status of version 10.2 (or beyond)?

Authoring Inform 7
1

I’ve been relying on the following github repositories:

Graham Nelson’s repository for Inform
David Kinder’s repository for Windows-Inform7
Friend’s of Inform 7 i7/extensions repository

And if those are still the correct place to be looking, it seems as though the latest “stable” release remains 10.1, and that 10.2 is still seeing a fair bit of ongoing developement.

I’m asking because I was hoping to play around a bit with some of the techniques found in Graham Nelson’s “The Reliques of Tolti-Aph” (aka ROTA), but those rely a good deal on being able to use tables to create objects and kinds, and that syntax is broken in version 10.1. The bug tracker (Jira) noted that those issues were fixed going forward, so I went ahead and cloned the current master (development) branch of Inform, built the requisite projects (including inter and intest), and even worked out how to get the Windows IDE to use the new tools.

With just a small bit of tweaking (two bits of syntax that work fine in earlier versions but are broken in the 10.2 branch), I can now compile and run ROTA.

BUT …

I also wanted to be able to play around with Tara McGrew’s Dynamic Object Creation. There is a version compatible with 10.1, but that version breaks in the current 10.2 development branch. More specifically, parts of the Dynamic Tables extension on which it depends fail to compile – and while I worked out a way to get around that, too, thus far, the behavior just isn’t right. (At a glance, it looks as though some important bits of Inform 6 functionality on which the extension depends either no longer behave the same, or may even have been entirely removed.)

I’m happy to keep going at this, but I could really use a bit of guidance up front from more experienced members of the community. In particular …

(1) Am I even looking in the right place(s)? If there are better, newer sources and/or 10.2 or later stable releases I’m just not awere of, please let me know!

(2) Is there a way (command line option, for example) to view the intermediate (inter) results generated by the Inform7 compiler?

Inform development after 10.1 appears to have leaned VERY heavily into “inter”, which at once sounds promising IN THEORY, not least of all as a possible way to decouple the natural language processing and rules-based power of Inform from its dependency on Inform 6, etc., as a back-end … but also appears to add a terrifying degree of additional complexity, not to mention verbosity.

In trying to work out just what’s going on with dynamic objects, for example, I feel as though it would be quite helpful if I could actually SEE the intermediate compilation results. But if there is a way to get the compiler to leave that file behind, I haven’t found it yet.

(3) Previously, when tracking down a low-level issue, I could usually find what I was looking for in an Inform 6 template somewhere. But now, I confess I certainly haven’t got a good grasp of exactly how many/most of those bits have been migrated over to use inter instead. I’ve read through what I could find on the topic, but so far, it’s not really clicking. So if anyone has any pointers to share, or links to other documentation that might really help in that regard, I’d appreciate it.

(4) Oh, and while I’m at it, the i7/extensions repository has an 11.0 branch, but I haven’t found anything else related to an 11.0 version of Inform, experiemental or otherwise. Does anyone know what’s up with that?

Thanks!

5 Likes
2

There aren’t righter places and there is no stable release of Inform subsequent to 10.1.2. I keep the Inform 7 Docs and Resources up to date and it would reflect such changes.

Command-line flag: -variable '*tout=output.inter' where “output.inter” is arbitrary, your choice of filename.

No source has been moved to Inter. It’s exclusively a compilation target. See Structure of the Inform 7 Compiler. The Inform 6 .i6t files can now be found within “kits”; see A Guide to Kits.

The next release of Inform (for which there’s still no schedule) will be 11. Current development Inform still uses 10.2 internally.

2 Likes
3

For the moment, my recommendation would be: switch to an older compiler version. There’s a dropdown for this in the Settings pane of the IDE. That way you can use extensions like Dynamic Objects while also running the Tolti-Aph source code as written.

6M62 is generally a safe bet; there’s a whole lot of extensions written for that one in particular.

3 Likes
4

If you do use build 6M62 (aka Inform 9.3) you’ll probably want to include this extension:
6M62 Patches by Friends of I7. It has a few bug fixes that were ultimately incorporated into version 10.

5 Likes
5

Thanks for the quick reply. That’s all very helpful.

I see what you mean about inter – I guess it’s wasn’t “inter”, then, but rather the change from .i6t files to “kits” that got me confused. I’ll give the info you pointed me to on “kits” a look and see if that helps clear up the confusion.

Out of curiosity, what was the motivation to make that change, though? At first glance, it looks to me like we’ve taken source that would logically have resided together in a single cohesive file before and spread it out over multiple “web” (or “inweb”?) pages??? And I see now that some fundamental extensions are now coded the same way.

I would have thought that would make things a bit more complicated from a development and maintenance standpoint … Unless there are editing tools that can pull everything together for development purposes and handle the underlying file complexity behind the scenes??

Also – (and again, this may not be quite the place to ask the question, but if I recall correctly, you are pretty intimately familiar with a lot of the internals) – one issue with Dynamic Objects and Tables not quite working appears to have to do with possible changes to the method of storing and/or accessing linked lists of objects of each kind in Inform6. I can poke around some more and try to figure out exactly what’s different, but if that happens to ring a bell, or better yet, if you actually know what might have changed on that front, and can help me narrow down where to look, that would be much appreciated!

Again, many thanks!

6

Thanks for the advice, Daniel.

I keep coming back to Inform every so often, and the last time I played around with it, there were some reasons I had decided to step up to version 10 at the time – but at the moment, I can’t for the life of me remember what those issues were.

I did see the “retrospective” feature supported in the latest IDE, and that should at least make it a little more convenient to try out both paths for a bit and see how things go from there.

Out of curiosity, though, what’s your take on the direction in which 10.2/11 is headed? I won’t claim to have read and digested everything Graham and others have written on the new direction so far. But at first glance, it seems like a fair bit of additional layers and complexity (such as the new inweb style of coding, and the introduction of inter, for example), and, if I’m understanding things correctly, 10.2 is working with what is essentially a new port of Inform6 as well?

I suppose that’s all well and good provided there’s a substantial payoff for making the changeover, but I’m not sure I’ve quite understood what that is supposed to be as yet.

7

More complicated, but less fragile!

It used to be that Inform 7 output plain Inform 6 into a file, and then compiled that file. Inform 6 inclusions weren’t processed by I7 at all but copied verbatim into that file, as were a bunch of I6Ts (then “templates”, now “kits”). This required a whole delicate balancing act where I7 didn’t actually know what was going on in the I6 code, so it just had to hope that all the I7-internal stuff lined up with what the I6Ts were doing.

Now that’s changed. I7 and I6 code are both translated into an intermediate language called “Inter”, where they’re merged together and then compiled into the output; this means that I7 can know when there are mismatches between the two, and give proper error messages instead of “sorry, the I6 compiler failed and I have no earthly idea why”.

And that’s why I7 can now be open-sourced! The whole delicate I7-I6 dance was fragile enough that any little change could make it crash and burn. Now that the connections between them are more robust, other people can work on the project alongside Graham without worrying that everything will collapse.

Funnily enough, inweb isn’t actually new: we have some documents showing that the I7 compiler source was always written that way. What’s new is that now we can see the results for ourselves! The weird formatting of I6Ts, with paragraphs of comments interspersed with paragraphs of code, was always due to inweb; but we only got access to them as raw I6Ts, not as the webbed output.

And now that other people can tinker with the source code, a lot of old bugs are getting fixed, faster than ever before. So I’m all in favor of that. I wish there was a quicker release cadence, certainly, but I think Inter is a definite improvement to the whole system.

3 Likes
8

The most direct advantage of using the Inter layer (this came in with 10.1) is that I7 can manage I6 entities from the kits as first-class objects. So you can replace any individual I6 function, rather than having to replacing blocks of I6 source code at the section level.

This leads to a few sore spots: you now have to replace the big Parser function as a whole, whereas before you could replace smaller pieces of it. (Because its source code was divided up at the section level.) But overall, this is an improvement.

3 Likes
9

Yeah, it would be really nice if specifically Parser__parse and NounDomain could be factored down so individual bits of them could be replaced. I have absolutely no idea how it could be accomplished, though!

10

If anyone is game to compile Inform themselves and use it from the command line, then the current source code is pretty stable. Probably stable enough to use for a competition game even. Of course there are still bugs which might not make it a valid option for all projects, but it’s stable in the sense that it won’t randomly crash on you.

One of the biggest advantages of kits is that it lets you define kinds. Previously adding advanced kinds required you to overwrite some i6t templates, as in my Data Structures extension (so pretty much no extension other than Data Structures ever did so.) Now you can include Neptune files directly in an extension, like in the Inform 11 version of Glulx Text Effects. This also lets us define these enum kinds to use specific values. Normally if you define a kind of value using named options then it starts with 1. Using a kit lets us give the Glk styles the same values as their true values from the Glk spec, so we don’t have to subtract anything. It also lets us have negative values (like for light font weight), or to skip values.

Kits also let us now include run time problem explanations, like in Flexible Windows. So an extension can define its own RTPs, and while testing in the IDE your description page would be shown if they occur.

4 Likes
11

Graham would be best able to speak to motivations. But beyond the big win that Andrew mentions above (with significant drawback in Parser__parse’s case, as noted), there’s more flexibility to replace other things named by Inform 6 symbols as well, not just functions. There are also improved ways to share properties and variables between I6 and I7 (development Inform moreso than 10.1, but I don’t remember off the top of my head what the differences are so I’m not going to try to say).

Kits aren’t just I6 code; they may have neptune files defining new data types. (A predecessor existed in 9.3/6M62’s .i6t files; @Dannii , remarkably, even figured out adding new data types without benefit of documentation). And the I6 in kits gets pre-compiled to Inter binaries, saving some compilation time.

A limitation of 10.1 is that there wasn’t a friendly way to share kits for others’ reuse. A thing that’s new in development Inform is that extensions, the things for which we already have some specification and infrastructure for sharing, are no longer restricted to a single file. Extension-as-directory is now preferred. And extensions can bundle kits. This is a big increase in how much difference installing an extension could make (and it’s a thing that could potentially go a long way toward mitigating Inform’s long release cycle).

I see the way things are split into multiple files as having a lot of benefits in some cases (like extensions’ examples) and drawbacks in other cases, like searching for things. In general, the drawbacks could be mitigated with appropriate tools and indexing… that don’t currently exist.

2 Likes
12

I’d say the first steps would be creating a ginormous test suite and writing a detailed spec of what the parser’s existing behavior is as one went.

4 Likes
13

Ah I see what you’re saying … less fragile is brilliant. It may take a bit of getting used to, and a bit more care, I’d imagine, to make sure things are separated out sensibly, but that’s not a bad thing. In all, sounds completely worth the effort. Thanks for the detailed and helpful reply.

Thanks also to @zarf, @Dannii, and @Zed for the additional replies and points to consider. I really appreciate you all taking the time.

Also, let me just say, I’ve been a long-time fan of interactive fiction and Inform, and have seen your names, and admired a good bit of your work over the years. So it’s quite the pleasure to get a chance to meet some of you here, so-to-speak.

I’ll also be more than happy to contribute to the ongoing effort, assuming I manage to come up with anything useful.

1 Like
14

No, that’s a rat-hole. :) You’ll never finish. The parser wasn’t written to a spec, it was written to do a bunch of things as Graham thought of them. And Graham didn’t believe in unit-testing back then(*), so if there were a spec, the parser wouldn’t reliably stick to it.

(* He got better.)

To refactor Parser__parse(), sketch out the overall code flow, figure out how you’re going to divide it up, and then start in with a whole lot of pinhole refactoring. Just keep making sure that each change doesn’t change the code’s behavior.

Mostly it’ll be turning local variables into global variables. Figure out where they need to be initialized (or cleared), and where they need to be handed from one code block to another.

You’ll write a whole lot of tests along the way, of course, but it’ll have to be an observational project. See what each jump and branch does, and write a test to exercise it. Code coverage approach rather than spec-based.

3 Likes
15

What you’re describing is what I had in mind, but you’re right, I shouldn’t have called the results of documenting the observations a spec.

16

It feels like this should be relatively “simple” in a sense – it was already divided up via inweb notation, the whole point of which is to decouple order of control flow from reading order. So, theoretically, the web could be rearranged so that each section is factored out into a different function, instead of all plopped into the same function.

I guess this doesn’t actually work in practice though – they’re probably all referring to a variety of local variables, so all the references would break if you did this.

17

Yeah, that’s the main issue. There’s also a bunch of goto-spaghetti that doesn’t work if it’s divided into multiple routines. (Quite a lot of the parser variables are actually global already, so the latter might end up being the bigger problem.)

1 Like
18

At one stage Graham had basically indicated that he’d implement function in-lining, which would help a lot. Mega functions are rarely ideal. Having I6/Inter structs would help too (might as well dream..)

2 Likes
19

The additional global variables might blow up z8 support for good.

20

That’s true, but there can’t possibly be more than 15 of them, and I’m sure across all of the I6 code there are at least 15 variables that could be moved to an array without wrecking performance. So many of them are seldom-used flags and such.