If you could compare your two installations of I7, file by file, it might be helpful. If not, could you zip them up and upload them somewhere?
The compiler and built-in extensions should not have changed between 2012 and 2013.
If you know where I can get the march 2012 version, I’ll run a diff on everything.
I meant nutso’s versions, since those are the ones that actually demonstrate the difference.
Okay, found something that I think can help narrow things down.
In the March 2012 version of Inform 7, the glulxe.exe file under Interpreters has a date of 2/25/2012 and is 553 kb in size. The glulxe.exe file from the April 2013 version of inform has a date of 3/28/2013 and is 561 kb in size.
I tested both of these files in both the March 2012 and April 2013 copies of the Inform IDE and the error occurred in both versions when I used the glulxe.exe file dated 3/28/2013. The error did not occur when I used the glulxe.exe file dated 2/25/2012.
It must be related to the latest glulxe.exe interpreter dated 3/28/2013.
If you don’t have at least version 13/130911 of Flexible Windows, you’ll want to download the update from raw.github.com/i7/extensions/ma … indows.i7x
I haven’t sent this update to the extensions site because I’m planning more changes soon, but perhaps I should just do it.
I actually have been using the latest version of Flexible Windows (130925) since you announced it here a few weeks ago. Unfortunately, it does not resolve the issue that I had.
The problem occurs with both versions of the glulxe.exe interpreters with the latest version of Flexible Windows that you linked.
This is not the root of the problem, I think. I have changed the interpreter in the Windows front-end to be stricter about errors in the game: it’s simply that the newer Glulxe.exe is complaining about the fault in the game, while the older one is silently ignoring it.
I hadn’t noticed Nutso’s earlier example code that causes the problem: I can reproduce the problem here on the last released version of Windows Inform 7,though it doesn’t seem to show up on my latest development version. I will investigate further (in a while - I’m currently on holiday).
Actually, this isn’t quite correct - I was testing on a machine with a slightly out-of-date Flexible Windows, which still had the problem that caused the run-time error. I have improved the handling of this in the front-end so that now such cases don’t result in a blank game window, but it doesn’t explain the problem, as if I use the latest Flexible Windows (from https://raw.github.com/i7/extensions/master/Jon%20Ingold/Flexible%20Windows.i7x) then I don’t see any problem.
Nutso, are you sure you’ve got the exact Flexible Windows version linked to above?
I can confirm I have that version of Flexible Windows and have the error in the April 2013 version of Inform7.
The error from Quixe made me think that Flexible Windows was trying to write to some sort of stream before the stream was created… is it possible that, in improving the error handling, you’ve actually caused the stream to be created sooner and thus fixed the problem? (I’ve also assumed that Glux and Quixe are designed similarly internally since they were both written by Andrew Plotkin, so they might exhibit similar errors.)
This is when I wish I knew how to use GRIP!
Yes, I have double checked that I have that version (shows Version 13/130925 of Flexible Windows (for Glulx only) by Jon Ingold begins here.).
I will attempt to zip the files of both my installations tomorrow for anyone that wants them to compare further.
I’ve managed to get a bit further, and I’ve realised that I was looking at slightly the wrong problem - in fact the problem with Nutso’s example is that the game file calls glk_set_window(0) at some point, which isn’t valid. This is silently ignored in the 2012 Windows I7 release, which is why it seems okay, even though the game is wrong. In the 2013 release, this gets checked, but you don’t see an error as it occurs before the game has opened a window. In my latest development version, I’ve had to relax that check to allow early Run-time problem messages to come through, making this all a bit of a complicated mess. Sigh.
I think I’ll release a new version of the Windows front-end soon to address all this, but first I want to work out why the glk_set_window(0) call is occurring, as that seems to be the root of the problem.
Thanks, but I think I understand why the two installs are different - it’s just a question of the stricter error checking in the 2013 build. The error itself is present with either build, but only the later one actually shows it up. When I build the next version this will be further improved so that you actually get to see an error, (or a Run-time problem warning).
I haven’t actually tested this myself recently, but are you saying there’s a bug with the latest I7Windows and the latest FW? I’ll take a look at it then. The IDE being non-strict in the past has obscured some problems!
I think it’s a problem with the latest FW. I haven’t had time to examine this enough to be absolutely certain, but it looks like Nutso’s very simple example fails with the latest FW because somewhere a call to glk_set_window(0) is made. Previously this would have been silently ignored, but the most recently released Windows front-end fails with an error because of this - unfortunately since there isn’t a window open the error isn’t shown.
glk_set_window(0) is explicitly legal and equivalent to glk_stream_set_current(0).
(The result – of either form – that there is no “current stream”. Until this is set back to a valid window/stream, printing to “the current stream” is illegal and can throw an error.)
(This was not clear in the original spec, but I added a statement to that effect in 2009-ish.)
Hmmm, I clearly did know this once, since Windows Glk follows this, but I appear to have forgotten it by the time the Glulx interpreter logic for the Windows front-end was written. I will correct the front-end and push out a new version of it.
Thanks.
This doesn’t address the error message in Quixe, though, which does accept glk_set_window(null). There may be more going on here.