I don’t have any insight beyond restating the issue in your terms: your code must be doing something on the first turn or when play begins that short-circuits the ordinary bookkeeping that takes place before a call to glk_request_line_event.
I downloaded the source Cyberspace and it looks like it probably happens in “open up text-window” or “follow the refresh windows rule”.
Yeah, the loop is supposed to run through the file until a ‘]]’ appears and since the file is empty that never happens. I did have the activity check for a minimum file length in a Before rule to abort the process but I didn’t know or forgot that the activity would still be initialized even when the rule fails, another thing I got to fix.
You mean like
File of Cyberspace Layout is called "CyberLayout.glkdata".That doesn’t work since there are no dots allowed, although Inform 7’s interpreter will automatically assume that they are .glkdata, but that doesn’t help the other interpreters, apparently.
That is already more than I could ask for so thanks again 
I was just wondering if you would be aware of any great differences between gargoyle and all the other interpreters that would cause it to crash but not the rest at least for the Windows version.
Sorry, “crash” is just my imprecise way of saying “the interpreter UI ceases to respond, while the interpreter process continues, eating up 100% or so of the CPU, failing to terminate even after closing the window and quitting the application.” I should have said “hang”.
Of course, the extension should show a failure message for files that can’t be read, rather than failing into an infinite loop.
No, the I7 compiler throws up an error if you try to include a period in your filename. Inform believes that the game code must be agnostic about the file extension and that the interpreter will add its own extension if it likes. This works just fine if a game creates the file itself and we always use the same interpreter to play it, but it is a failure of design in these two cases:
So, it looks like rather than changing the spec, we need to get Graham to change Inform’s file-handling so that authors can exercise control over the extension. Does anyone know if Zoom would defer to the user-provided extension in creating a file, or if it would just add another .glkdata at the end, e.g. “CyberLayout.glkdata.glkdata”? (This would mean that, even though Case 1 was solved, Case 2 would still present difficulties.)
–Erik
Invalid pointers are tricky. Sometimes you write to it and get a crash. Sometimes you silently corrupt something else. Sometimes you get lucky.
I don’t get the crash in the Cyberspace import file, just the crash version, if that helps narrow down the scope of code to review.
It would append a second .glkdata extension, based on this code.
This is in my bailiwick, but I don’t think the right answer is to push file-suffix control all the way in to the game file.
I’ve posted a separate thread: Harmonizing Glk file suffixes?
Any interpreter changes will take a long time, however. I’d say the best option for today, if you want to distribute data with your game, is to embed the data in the source code directly, as text.
The crashes had only occurred with 30x30 simple-top-down-displays, which is another oddity. So far, I haven’t found another constellation for gargoyle to crash but I’ll create a test loop and see if there is any pattern to this.
In lieu of a file extension, you could follow up the call to glk_fileref_create_by_name() with a call to glk_fileref_create_by_prompt(), to let the user find the file. Ugly, but at least it gives you a chance of ending up with the data you’re looking for.
I don’t really like Zoom’s behavior - if an author requests a file called “CyberLayout”, and that file exists, it seems wrong for the library to append .glkdata to the filename and then fail to open it for reading.
However, Inform 7 does seem to allow you to have two distinct files with the same name:
The binary File of Binary Data is called "file".
The File of Text Data is called "file". I haven’t tested this, but Zoom should be able to read and write to separate files (file.glkdata and file.txt) where Gargoyle couldn’t.
If so, Gargoyle’s implementation is broken for Inform. What I don’t know is whether it is legal for Glk. The spec has this comment in it:
But this strikes me as descriptive rather than prescriptive - advising authors of what might happen rather than dictating parameters for the implementation. If not, and extensions are required on platforms that support extensions, those extensions should be specified.
EDIT: Oops, missed zarf’s response.
Great, now I can’t find the right configuration to reproduce the bug anymore. Consider this issue solved until I find the problem again 
The Mac IDE interpreter is a modified version of Zoom. I can get this to run in the IDE as well, but the result is the same: none of the graphics show up. They are in the filepath, and they are packaged into the blorb if I build one, but they are never drawn. The text version doesn’t print either–the output is exactly the same as I described above.
The output is the same for both Zoom and Gargoyle, including the two lines between each section.
–Erik
I appreciate that you find the time for some test-runs. Looks like I’ll have to try a step-by-step analysis.
Does this example create the following output?
Copied and pasted out of Gargoyle/git:
[code]Reading the file: File of Cyberspace Layout
[[
.
]]
Starting the loop
Current letter:
Read: line break followed by next line
New current letter:
Current letter: .
New current letter: .
Current letter:
Read: line break followed by next line
Loop done
Map layout: 0/3/1
g_t_border[/code]
–Erik
Thanks!
Hm, crud, looks like the problem comes from those extra line breaks between the period and brackets that are added for no apparent reason. Can’t think of any easy solution for that, other than offering two separate R&D releases which take this into account 
Could you post-process the data to ignore or eliminate line breaks? The file seems to use brackets as the primary semantic marker for sections, so that maybe the line breaks are redundant anyway?
That should work, yeah. Especially now that I found out that you can use ‘next’ and ‘break’ in a while loop. The algorithm just needs to get redone first. I’ll get down to it tonight.
I think I fixed it now. New example here. Should work for every platform (or abort the loop beforehand if it doesn’t). Word of warning though, at least to Windows 7 users: turns out that, if you open a gblorb over ‘Open with’ for either Glulx or Git, it will not call for the current file but some buffered data instead, apparently. In my case, it calls for the old file which prints “First, second,…” etc. although that file is long gone.
@Erik
You were right that again something seems off with the resizing factor. Probably has something to do with the new full-map parameters. Will try to work on that.
This one works! I suspect the problem was line endings in the text editor you used to create the import file…
That’s good to hear!
Windows 7 and Mac OS not playing nice with each other? Who would have thunk it, right? 
Glad that this is out of the way though.
I’ve got just one more general question: It recently came to my attention that arrays will probably get included in a later Inform 7 release. Would it be a good idea to switch over to those instead of lists? (For faster performance or other advantages)
Uhm, another question just popped up. There seems to be a limit to the amount of text an indexed text can actually store. I just tried to create a very large map in a text file, but the indexed text will only store about half of it. Would there be a possibility to extend this limit somehow?
There shouldn’t be a limit, but you might be running into Inform Bug 587. What happens if you apply the fix in the bug report’s comments to IndexedText.i6t, which is in your Inform install? (While you’re at it, you might as well apply the fix for Bug 593 too.)