Bug with Flexible Windows--or Quixe?

Authoring Inform 7
1

The following I7 code causes an init error in Quixe (“glk_window_clear: invalid window”):

[code]Include Flexible Windows by Jon Ingold.

The back-colour of the main-window is g-lavender.

There is a Room.[/code]

I haven’t found any other interpreter that has difficulty with this–all the rest . I believe that the code that causes the crash is Flexible Window’s InitGlkWindow, pasted below, which calls glk_window_clear. Possibly it is being called before the window exists (I can’t remember how that works) and is therefore truly invalid; but if so, why do GarGlk, CocoaGlk, and WinGlk not also choke on what would be a fundamental error…?

On the other hand, I also can’t figure out any reason why one would call glk_window_clear at that point, and removing the call does prevent the crash. So there’s a simple fix, but I thought I’d post about this in case there might be an obscure bug with the interpreter that might prove more troublesome in a later case.

–Erik

InitGlkWindow code:

[code]
Include
(-
[ InitGlkWindow winrock i col;
switch(winrock){
GG_MAINWIN_ROCK:
if ((+main-window+).back_colour ~= (+g-placenullcol+))
{ col = ColVal((+main-window+).back_colour);
for (i = 0: i < style_NUMSTYLES : i++)
glk_stylehint_set(wintype_TextBuffer, i, stylehint_BackColor, col);
glk_window_clear((+main-window+).ref_number);
glk_stylehint_set(wintype_TextBuffer, style_Emphasized, stylehint_Oblique, 1);
glk_stylehint_set(wintype_TextBuffer, style_Emphasized, stylehint_weight, 0);

				rfalse;
			}
		GG_STATUSWIN_ROCK: 
			if (USE_NO_STATUS_LINE == 1) rtrue;		! - Aaron Reed
	}
	
	rfalse;

];

-) after “Definitions.i6t”. [/code]

2

An unfortunate adherence to Postel’s Mistake?

I suspect that that clear_window should not be removed, but should instead be wrapped in an “if the window actually exists right now” test. This may be “if ((+main-window+).ref_number) …” but I’m not exactly sure what the library semantics are.

3

FYI, since you run Gargoyle under OS X, you can see some of these errors by launching it from the Terminal.

If you have it installed in Applications, you would start Terminal and enter this as the command:

/Applications/Gargoyle.app/Contents/MacOS/Gargoyle

It will print any warnings to the Terminal window.

I’m fairly sure garglk doesn’t turn anything into a fatal error; for any given Glk call, you can find at least one Glulx game that is careless about its use of the API.

Failing to cancel line events is the most typical problem; I have a “strict” mode in garglk that enforces it, but it’s disabled by default since nearly every game that uses hyperlinks doesn’t properly cancel line events before writing output.

4

Thanks, guys. I’ll email Jon with the suggestion to test the existence of the window before clearing it, which does seem wiser than simply deleting the call (he very probably had some reason for putting there, after all!).

Ben, thanks for the tip about starting Gargoyle from the command line; that will be very useful. The issue of different levels of permissiveness from different interpreters definitely causes issues, if only because folks aren’t always able to test on the whole variety of terps available. It would be nice if the built-in IDE interpreters were either highly intolerant of errors, or (maybe better) if they spat out warning messages to a log in the IDE. It would also be useful if you could put the IDE terp in a minimal mode, where only the core Glk library was supported and any unprotected calls to optional functions would error out. (I sometimes use Quixe as a semi-minimal terp, but that won’t be an option forever.)

–Erik

5

If you don’t mind using a development snapshot, you might try Floyd Mode.

6

I agree. Actually, it should be two separate features. The IDE should always be strict about erroneous calls (such as glk_window_clear(0)), and it should have a switch for various minimal-feature regimes (floyd=one window; terminal=multiple text windows but no graphics).

The latter is already up as a uservoice suggestion: inform7.uservoice.com/forums/573 … tions-for-

I’ll add the former now.

7

Thanks, zarf–I’m all out of votes :wink:

Emacs, thanks for introducing me to Floyd Mode! I7grip more generally looks interesting too.

–Erik