This weekend's progress in IF tools...

…is not very interesting at all. Just cleanup work. But I’ll mention it anyway.

I have updated three of my IF-related Python scripts to be Py2/Py3 compatible:

regtest.py (eblong.com/zarf/plotex/regtest.html) – IF game regression tester
blorbtool.py (eblong.com/zarf/blorb/blorbtool.py) – Blorb file manipulation
profile-analyze.py (github.com/erkyrath/glulxe/blob … analyze.py) – parse profiling output from Glulxe

I added a couple of features here and there. regtest.py now detects game timeouts (hung games); this is a feature backported from the I6-library-test project. profile-analyze.py now has command-line options to sort its output in different ways.

I also took a small step towards easier Inform profiling and debugging. I’ve declared that you can include Inform’s gameinfo.dbg output in a Blorb file, using the “Dbug” chunk code. (Thanks to Dannii for the suggestion.)

The I7 compiler doesn’t (yet) inject this for you. You can do it manually with the blorbtool.py script:

python blorbtool.py game.gblorb import Dbug gameinfo.dbg

Now, just declaring that you can do this doesn’t make any hay. What can you do with such a Blorb file?

  • In my experimental CheapGlk/Glulxe branches with debugging active, you can do debugging and get symbols from the Dbug chunk.

  • In Quixe, if you add “debug_info_chunk: true” to the game options, the interpreter will show a symbolicated stack dump on any game crash. (In the Javascript console.) That is, you’ll see the names of the VM (I6) functions that were executing when the crash occurred.

  • The profile-analyze.py script, which needs symbols from the gameinfo.dbg file, can now extract them from a Blorb file with this chunk.

As I said, these are baby steps. All these situations are a nuisance to set up, and will rarely be of value to most Inform authors. But occasionally I really want to do it. (When someone reports a particularly hard-to-pinpoint bug…)

1 Like

Thanks Zarf!

I thought detecting hung games was technically an uncomputable problem.

Yes. We apply the realistically cheapass solution of “if a full second has gone by and the game hasn’t responded, assume it’s stuck and give up.”

If your game actually takes a full second to compute its response, change the timeout to five seconds.

Fair enough. I figured that was the kind of solution at play.

Right on. I’ve actually used one of those things so updates are always appreciated!