Upcoming additions to the Inform 6 compiler

Authoring Inform 6
1

This weekend I knocked over some I6 compiler improvements that have been requested for a while. (Some were implemented a few years ago in a development tree that fell by the wayside.)

I’ve been filing detailed bug reports on the Inform bug site; you can follow them there.

These would come out as an “Inform 6.33” release, not yet scheduled. Currently the patches exist only in my I6 github tree. They have not yet been adopted into David Kinder’s master repository. So now is a good time to comment if I’ve done anything dumb. (Say, used the wrong opcode to implement “font off”. Cough. Oops.)

What it says.

This supports frotz’s effort to have the I6 library support NPC actions. The idea is that an I6 game author can write code like <Take pie, orc> to invoke an action on an NPC rather than the player. (Note that I just implemented the syntax, not the result! If you try to use this with the current I6 library, the actor argument (orc) will be silently ignored.)

(Yeah, it would have been nicer to support <orc, Take pie>. I couldn’t get it to parse reliably. Sorry.)

In Z-code V5 and up, the “font off/on” statement will use the @set_font opcode instead of tweaking bit 2 of the header. (Font 4 for “font off”, 1 for “font on”.) If you stack font and style changes, this change may cause slight difference in display behavior on some interpreters. I caught Mac Zoom behaving differently in one case; not Gargoyle or Parchment, though.

This is an idea I had years ago. If you add a second argument to the Replace directive, the function you’re replacing is preserved under the new name. This lets you replace an I6 library function but still invoke the old functionality. It’s like a simplistic form of I7’s “Before/after foo activity: …” Not sure if it’ll really be useful, but there it is.

After messing with this one, I’m considering throwing it out. The #End directive is pretty useless as it stands (it stops compilation dead, like end-of-file). But it wouldn’t be a lot more useful to be able to jump out of an #include file. I mean, I’ve never wanted to.

It occurred to me that a likely idiom for using this would be

#ifdef WHATEVER;
#end;
#endif;

But to handle that, we’d have to declare that the directive terminates the open #ifdef – otherwise it would stay around until the end of the program, and confuse everything. But that brings up all sorts of other issues about open #ifdefs. (Do they all get resolved at the end of the include file? Can an include file #endif an open #ifdef from the parent?) It turns into a headache. I say if you want to not compile a chunk of code, #ifdef it out, don’t try to make use of this #end thing.

2

I like this. :slight_smile:

What was it for originally? Putting documentation after the #end?

3

Heck if I know.

Oh, add one item to the list: I think I have dead-function stripping working.

4

Sweet! Have you compared the final file sizes of I7 games to see if there’s any savings out-of-the-box? Z-machine lovers will love this.

5

I’ve done some measurements, but this code isn’t final yet. And I’ve only implemented it completely for Glulx. I was about to start on the Z-code side when I ran into a compiler crash… which isn’t my fault… there will be a short delay while that sidetracks me. :slight_smile:

6

It’s great to see that I6 still is supported, especially for a newbie like me who just made I6 his weapon of choice… :wink:

Rock on!

syzygy

7

Inform 6 as a language will be supported for as long as Inform 7 - it’s an essential part of it.

The Inform 6 library was for many years gathering cobwebs, but David Griffith (frotz on the forum) has recently picked it up again.

8

I have added details on the text-stripping feature as an issue entry:

inform7.com/mantis/view.php?id=1024

Remember that this only saves ROM space; it doesn’t touch RAM.

9

Though I’m very much in the minority, I’m firmly convinced that Inform 6 is superior to Inform 7 in several respects. I7 has the nice IDE, to be sure, but when it comes to actually writing a story, I find I7 very much a hodge-podge, far less intuitive, and harder to work with.

10

That’s one reason I prefer Inform6. I’m sure you’ll enjoy playing around with first-person and third-person perspectives when 6/12 comes out.

11

1023 reminds me to ask: Would 6.33 be a good time to introduce a new debug file format? If so, I’d be willing to draft a spec, present it for review, and write up the compiler patches. I’m thinking it’d be nice to at least

  • make it possible to find a record without reading through the entire file,
  • widen all fields to 32 bits (there are already stories exceeding the current widths for line numbers, column numbers, global numbers, and addresses, if not others),
  • include a header record even when the target is Glulx, and
  • record the correspondence between constants’ names and values.
12

That all sounds plausible, although I would rather have the format be easily-parsable rather than randomly-accessible. (Hint: everything can read XML these days. Reading through an entire XML file is not actually slow, and there’s not much advantage to being able to find a single entry “quickly”.)

(Also, with XML the problem of fixed-size integer fields goes away. And it’s way easier to upgrade in the future, by adding more fields, without breaking old code.)

13

My experiences with using XML in the field have not been positive. The redundancy in its format is a pain to deal with at the code level, as well as the whole what to do when the end tag doesn’t match the begin tag scenario.

JSON and Lisp both beat XML for ease of parsing and fewer ways to create invalid files.

I presume the reason for asking is to better support EmacsUser’s Inform 7 debugging extensions, in which case I say that speed of parsing is very important.

14

I’d be fine with either JSON or Lisp-style (S-expression) format, actually, in place of XML. I’ve used all three. Never had any particular problem with XML, but they all work. As long as you test your code for valid output, which we would do anyway, right? Right.

I didn’t say speed of parsing was unimportant; I said that fast random-access is unimportant. If you’re debugging, you’re going to read through the entire debug file.

15

I like JSON, but that’s just me. What I would like is a simple way to ask “what is the name of the function at this address?”

16

As long as we’re brainstorming a new debug format, how about defining a Blorb chunk to hold it? Passing around a single debuggable file would be convenient.

(FWIW, I’d vote for XML over JSON. Attributes make for easy extensibility, which will be handy with multiple tools potentially generating this format. Ease of parsing shouldn’t be much concern when there already so many solid XML parsing libraries.)

17

I have a demo up where the debug data is stored in a DATA chunk, whose chunk number is passed to the interpreter out-of-band. (A config line for Quixe – this could be a command-line argument for a native app.)

This gets the job done without any spec changes.

18

That eliminates the need to deliver two files, but there’d be more benefit if the interpreter could locate that chunk on its own. Imagine getting stack traces with line numbers and routine names from every crash - an IDE could make that happen by passing the chunk number, but it’s a pain to do by hand each time, and a beta tester is unlikely to do it.

19

Even better would be stack traces from every runtime error detected by the library/veneer… but that’s a suggestion for the Z-machine 1.2 thread.

20

Actually, because in any given debugging session a lot of data never gets used, I do get a notable speedup by decoding records lazily. If I could defer both reading and decoding, that could only improve matters. However, the overhead here isn’t at the top of my bottleneck list, and it almost certainly won’t be near the top in a native tool, so I am okay with sacrificing random access for concerns that outweigh it.

(What is near the top is the analogous problem of finding source file positions corresponding to I6 line numbers. I’d be great for me if code locations could be given as both file positions and line/column numbers. I don’t think anyone will object to that?)

Regarding XML, JSON, and S-expressions, I have very little preference unless I’m wearing my extension author hat. In that case, XML looks nicest because I can @linearsearch for ‘<’ or ‘>’ and know that I landed on a tag, not in the middle of a string.

As for the blorb chunk, I agree that some way to avoid the out-of-band communication would be wonderful if we can make that happen.

And I should also ask, where are we documenting things when the Technical Manual no longer describes them accurately? The only other document I know of is Zarf’s addendum for Glulx.