I’ve been working on a feature for the I6 compiler which will allow better debugging in the future. It’s not useful right now; it may not become useful for the foreseeable future. But I don’t want it to remain completely unnoticed either, so I’ll describe it here.
(Inform issue tracker URL: inform7.com/mantis/view.php?id=1779 )
The idea is that the I7 compiler might generate directives in the I6 code like
#origsource "game.inform/Source/story.ni" 100 20;
This means that the following I6 code is generated from the I7 code in story.ni, line 100, character 20. This applies to all I6 code until the next #origsource directive.
Or it might add a directive like
#origsource "Extensions/Person Name/Rocks.i7x" 50;
…indicating that the following I6 code is generated from that extension, line 50.
The character and line number are optional, so we have three forms:
#origsource FILE;
#origsource FILE LINE;
#origsource FILE LINE CHAR;
Or you can just say
#origsource;
…to turn it off again.
The #origsource info does not affect the compiled I6 file, but it turns up in the gameinfo.dbg if you compile with -k. It also appears in I6 error messages. You might see:
Here 5000 is the line number in the I6 .inf file. The parenthesized info comes straight from the (most recent) #origsource directive.
Having this info in the gameinfo.dbg opens up the possibility of better debugging interpreters. To be clear, there is no debugging tool that uses this information right now! To make use of this, I7 will have to be updated to generate these directives, and then we’d need to upgrade an interpreter to make use of the information.
Now the down side: adding this feature required tracking more location information inside the I6 compiler. Because of this, Inform now uses more memory and is slightly slower even when the #origsource directive is not used. My tests indicate that it’s about 4% slower on most compiles. This is not a huge cost – I6 is only a small fraction of the time of an I7 compile anyhow. But it’s enough that I wanted to bring it up here.
Semi-related: at one point we were talking about using a more compact representation of in the gameinfo.dbg file. Is that worth pursuing? We’ve now got concepts like “bundle the gameinfo.dbg into the Blorb file for easier profiling and testing”. The gameinfo.dbg files are kind of enormous, and something like two-thirds of their bulk is tags. (To be sure, they’d still be pretty enormous even at a third their current size.)
I’ve also considered adding a switch to suppress the tags in gameinfo.dbg, since (as I said) nothing uses them right now. Perhaps this is optimizing the wrong thing, however.