Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000153Mac OS X Inform application[IDEs] User Interfacepublic2010-07-01 13:372010-10-29 09:19
Assigned Toahunter 
Platformx86OSMac OS XOS Version10.4
Product Version6E72 
Target VersionFixed in Version6F95 
Summary0000153: Neither game nor index tab is available after successful compile
DescriptionThe story compiles successfully (compiler finished with code 0), but the IDE does enable either the game or the index tab.
Minimal Source Text To Reproduce
There is a room.
Additional Information1. Start Inform
2. Click on ``Start a new project...''
3. Select ``Inform 7 -> New Project''
4. Click on ``Next''
5. Browse to file location
6. Click on ``Create''
7. Enter the source text.
8. Click on ``Go!''

(Relayed from [^])
TagsNo tags attached.
Attached Files

- Relationships
has duplicate 0000154closedahunter Mac OS X Inform application Nothing appears in the release folder. 
has duplicate 0000273closedjmcgrew Mac OS X Inform application Go/Replay does not play the game 
has duplicate 0000275closedjmcgrew Core Inform Won't run when Go or Test Me pushed 
has duplicate 0000449closedjmcgrew Core Inform Doesn't run 
has duplicate 0000640closed Core Inform No work 

-  Notes
zarf (developer)
2010-07-01 14:32

I see the same thing (MacOS 10.5.8, Intel). If I close the project window and re-open it, the game then compiles and runs normally.
ektemple (reporter)
2010-07-01 18:41

I also see this on MacOS 10.5.8 (Intel). Unlike zarf's report, the problem is consistent rather than intermittent. So far, I've seen no evidence of the issue under 10.6 (Intel).
Ron Newcomb (reporter)
2010-07-01 19:53

I get this behavior on my main home machine, a MacOS 10.4.9 (PPC). Release,
Release Debug Build, Test Me, double-clicking a Skein node, Replay
Last Commands, Replay Blessed Transcript, Rebuild Index... nothing
works. It compiles successfully upon selecting any of those, but
nothing happens afterward. I'm left staring at the graphic with
Translation Successful. It does this on new projects, old projects,
from the splash screen buttons or from the File menu, always and
everywhere. I have no workaround.
jjsonick (reporter)
2010-07-01 20:07

Another note of not seeing this issue in OS X 10.6.4 (Intel).
infovore (reporter)
2010-07-07 01:57

I've got this issue on 10.5.8. When i ran Inform from the shell (rather than the Finder). this error message was logged to my terminal:

2010-07-07 09:51:33.500 Inform[52504:10b] Exception raised during posting of notification. Ignored. exception: '-[NSFileWrapper addFileWrapper:] *** a document must have a preferredFilename before it can be added as the subdocument of another document.' invoked observer method: '*** -[IFProjectController compilerFinished:]' observer: 0x10ddf2c0 notification name: 'IFCompilerFinishedNotification'

...if that's of any help.
endlessrepeat (reporter)
2010-07-14 02:09

I also have this problem on Mac OS 10.5.8 Intel. It won't start the interpreter for new or old projects at all (and so none of the tabs that require the game to have run will open either).
ahunter (developer)
2010-07-18 07:35
edited on: 2010-07-18 07:37

I've gone through all of the calls Inform makes to addFileWrapper, and they're all setting the preferred filename, plus I don't think that any of them have changed for at least 2 years, looking at my subversion repository.

However, that exception could definitely explain the behaviour that people are seeing. The only thing I can think that could possible cause this problem is the new code to fix up the index pages so they survive saving the project: at a guess, the OS X call [NSFileWrapper updateFromPath:] doesn't work at all in versions prior to 10.6. (It wouldn't surprise me if this was the reason for the previous behaviour)

Debugging this is nearly impossible for me as I no longer have access to any machines running 10.5.

ahunter (developer)
2010-07-18 07:45
edited on: 2010-07-18 07:45

Assuming it's what I think it is, this build might work: [^]

This disables the behaviour that was stopping the index from getting overwritten before, so it's no good for releasing, unfortunately.

zarf (developer)
2010-07-18 08:22

This build works on my home machine (PPC, 10.5.8). But so does the released 6E72, as I test it this morning. So that's not useful information.

I will test it tomorrow on my work laptop (Intel, 10.5.8).
EmacsUser (manager)
2010-07-18 10:41

The link in 0000153:0000291 eliminates bugs 0000153 and 0000154 for me on machines back to Tiger, including machines where the download for 6E72 did not work before.
Ron Newcomb (reporter)
2010-07-18 13:50

The above link also works on my Tiger machine.

(But the created game's banner text says it's build 6E58, not 6E72. This bug never existed on 6E58/59. Just thought I'd mention that in case it's relevant.)
ahunter (developer)
2010-07-18 14:39

From the description, the version of the compiler in use shouldn't make any difference to this bug. 6E58 happens to be the version I have to use at the moment in my own builds of the IDE.

If you want to verify it, [^] should be a build with both 6E58 of the compiler and this particular issue.
ektemple (reporter)
2010-07-18 14:42

My experience is the same as Ron's: the version of the IDE-compiler package that was released as 6E59 does not have this issue, while the 6E72 version does.
zarf (developer)
2010-07-19 08:35

Sigh. Now I'm unable to replicate the problem, at all, on any computer, with 6E72. Sorry. I wish I knew why my experience is different.
infovore (reporter)
2010-07-19 09:37

The build ahunter supplies in message 0000291 does work on my 10.5.8 machine (where, previously, the distributed 6E72 build had failed).
eeeejay (reporter)
2010-07-22 19:22

Hey. Got a solution. It was an permission issue.

Set the "" file permissions from READ ONLY to READ&WRITE to the "Everyone" User. Sometimes you will need to give it to the "Admin" user too. Remember: to do so you must select the afore mentioned file and press COMMAND-I to show up the Get Info dialog window and carry on the adjustments.

Now, everything should work flawless. It worked like a blessing for me. Hope it helped.
Ron Newcomb (reporter)
2010-07-22 19:45

eeeejay: that does not work for me.
eeeejay (reporter)
2010-07-23 08:30


In your case, try to set those permissions to every file inside the file, just to be sure.

I don't know exactly why, but MAC OS X gets really confused setting the best permissions to applications.

I'll describle what happened to me:

. Downloaded the latest version of Inform7 (6E72);
. Dragged it to my Applications Folder;
. Created an alias on my desktop to use it;
. Verified that it compiled my experiments, but the GAME and INDEX buttons stopped working right after that, so no PLAY/REPLAY;

Here is the catch: I noticed that the compile progress bar just kept appearing, even when Inform7 said it was over, signaling that it should be an read/write issue. See, something similar happened to another application I had installed weeks ago. Everytime it tried to access certain parts of my HD, it just stalled. I solved it by just changing their permissions to READ&WRITE all users (recommended by it's own support forum);

. So, I did the same with Inform7. It started to work flawless to me since then.
Ron Newcomb (reporter)
2010-07-23 09:18

Which OSX are you on? Tiger? Leopard? I think I did set all permissions within the .app via a button specifically for the purpose. I even did so on the project I was trying to compile.

I thought Andrew Hunter said the difficulty was a particular method call throwing an exception, that method not being supported on Tiger. Maybe your workaround is only for 10.5?
machtrtl (reporter)
2010-07-23 12:30

Hi all: Long time IF player, first time IF maker. I just downloaded and installed Inform for the first time on my MacBook Pro (Intel, OS 10.5.8) and had the same problem on my very first attempt using the sample code. I'm thrilled to know that this is a real bug, and not just me being dumb. I tried the permissions suggestion, confirming r/w permissions for everyone for all files, and it doesn't seem to be working for me. I've had no success opening and closing windows either as suggested in (0000213).
eeeejay (reporter)
2010-07-23 17:32

Hi Ron and machtrtl,

I'm currently using 10.5.8 (iMac 20, Model iMac8,1, 4Gb RAM). It still works greatly since I applied the permission trick thing. Almost 2 days in a row and counting.

I tried to install it on a white macbook with 10.4 too (a friend of mine allowed me to do it, he's a huge fan of INFOCOM's text adventures), just to confirm the solution. Unfortunatelly adjusting the file's permissions does not worked at first. Tried reinstalling several times again and repeat the adjusts but nothing. Same bug.

 Then I started to research this kind of issue more deeply, using Google, Apple's help system and so on. I researched the web and found that just setting the .app file permissions wasn't enough to make everything work as expected in certain cases. Sometimes you must open the .app package and set the permissions to each and every file inside the .app file. OS X weird stuff area.

To simplify, the app file is a collection of files packed into a single file. Sometimes you must open it (right-clicking the .app and selecting Show Package Contents) and apply the permissions to the highest folder inside it (the one that hold everything related to the program), with this option: Apply to Enclosed Items. Now, those "inner" files inside will get too those adjustments as expected. I warn you that It's tricky to learn at first, especially if you are not an OS X enthusiast. But It can be done in both 10.5.x and 10.4.x. ( I suggest to try this way if my first suggestion not worked for you - search your OS X manuals to get more details on it )

 So, I managed to run once this way on 10.4 on it's full glory, but the bug insisted to appear, now in a random fashion. But I cannot tell if it was my friend's macbook hardware or software fault. Too many applications running in the background and I don't wanted to mess with them. :P

Well, that is it. Hope I could help someone.
machtrtl (reporter)
2010-07-25 12:09

Yep, i had already opened the .app package and changed permissions (actually just did it through the command line with a chmod command). It didn't work. I should also add that I don't see the never-ending compile progress bar you mentioned in (0000334) , so I'm pretty sure that the permissions solution is not the right one for me (or at least not sufficient).

I don't know that I have much to add to this bug, except a willingness to test and report new approaches or builds if it helps, so I'll just keep monitoring and hope for the best.
EmacsUser (manager)
2010-07-26 16:20
edited on: 2010-07-26 17:51

I propose the following:

1. Open a project that exhibits this bug
2. Click on ``Go!'' (the game won't start, because of this bug)
3. Leave Inform open
4. Switch to Finder
5. Navigate to the project and select it (the .inform file, not the materials folder)
6. Copy (don't rename) it to something else
7. Close Inform
8. Delete the original .inform file, the one you copied (or, if you prefer, rename it as a backup file)
9. Rename the copy to the original's name
10. Double-click on the new project file to open it in Inform (Inform may switch to the installed extensions page)
11. Click on ``Go!''

Would anyone mind seeing if this works for them?

machtrtl (reporter)
2010-07-27 07:06

Well how about that? It worked for me, using just the sample "Power of the Keys" example in the Inform Documentation. Copying/renaming/re-opening worked fine. Should I expect that this file will continue to work as it's built out over time?
EmacsUser (manager)
2010-07-27 07:57

I believe so, but I don't claim complete understanding of the bug yet.
Artman (reporter)
2010-08-06 20:05

I had the exact same issue on an Intel iMac 10.5.8. The issue was intermittent, though failed much more than it worked.

Closing and reopening a project didn't resolve the issue for me.

EmacsUser's proposal did work for me (multiple times).

Build attempts resulted in the following console message:
8/6/10 10:51:43 PM Inform[386] Exception raised during posting of notification. Ignored. exception: '-[NSFileWrapper addFileWrapper:] *** a document must have a preferredFilename before it can be added as the subdocument of another document.' invoked observer method: '*** -[IFProjectController compilerFinished:]' observer: 0x167f7540 notification name: 'IFCompilerFinishedNotification'

The old package was considerably smaller than the renamed package as the subdirectories were populated with the indices, plist, and metadata.
ahunter (developer)
2010-08-08 07:10

Assuming I've tracked down the cause, I think this should fix it: it refreshes the index pages in memory in a different way: [^]

However, I have no way to verify this myself.
EmacsUser (manager)
2010-08-08 16:10

Works for me on 10.5.

- Issue History
Date Modified Username Field Change
2010-07-01 13:37 EmacsUser New Issue
2010-07-01 13:44 jmcgrew Status new => confirmed
2010-07-01 13:52 EmacsUser Issue cloned 0000154
2010-07-01 13:58 EmacsUser Severity serious => critical
2010-07-01 14:00 jmcgrew Status confirmed => assigned
2010-07-01 14:00 jmcgrew Assigned To => ahunter
2010-07-01 14:32 zarf Note Added: 0000213
2010-07-01 18:41 ektemple Note Added: 0000216
2010-07-01 18:57 jmcgrew Relationship added related to 0000154
2010-07-01 19:53 Ron Newcomb Note Added: 0000218
2010-07-01 20:07 jjsonick Note Added: 0000220
2010-07-01 23:23 jmcgrew Build => 6E72
2010-07-01 23:24 jmcgrew Build 6E72 =>
2010-07-01 23:24 jmcgrew Product Version => 6E72
2010-07-06 13:43 Ron Newcomb Issue Monitored: Ron Newcomb
2010-07-07 01:57 infovore Note Added: 0000257
2010-07-14 02:09 endlessrepeat Note Added: 0000283
2010-07-14 02:11 endlessrepeat Issue Monitored: endlessrepeat
2010-07-18 07:35 ahunter Note Added: 0000290
2010-07-18 07:37 ahunter Note Edited: 0000290 View Revisions
2010-07-18 07:45 ahunter Note Added: 0000291
2010-07-18 07:45 ahunter Note Edited: 0000291 View Revisions
2010-07-18 08:22 zarf Note Added: 0000293
2010-07-18 10:41 EmacsUser Note Added: 0000295
2010-07-18 13:50 Ron Newcomb Note Added: 0000299
2010-07-18 14:39 ahunter Note Added: 0000301
2010-07-18 14:42 ektemple Note Added: 0000302
2010-07-19 08:35 zarf Note Added: 0000319
2010-07-19 09:37 infovore Note Added: 0000322
2010-07-22 19:22 eeeejay Note Added: 0000332
2010-07-22 19:45 Ron Newcomb Note Added: 0000333
2010-07-23 08:30 eeeejay Note Added: 0000334
2010-07-23 09:18 Ron Newcomb Note Added: 0000335
2010-07-23 12:30 machtrtl Note Added: 0000336
2010-07-23 17:32 eeeejay Note Added: 0000341
2010-07-25 12:09 machtrtl Note Added: 0000350
2010-07-26 16:20 EmacsUser Note Added: 0000352
2010-07-26 17:51 EmacsUser Note Edited: 0000352 View Revisions
2010-07-27 07:06 machtrtl Note Added: 0000353
2010-07-27 07:57 EmacsUser Note Added: 0000354
2010-08-06 20:05 Artman Note Added: 0000385
2010-08-08 07:10 ahunter Note Added: 0000387
2010-08-08 07:10 ahunter Status assigned => resolved
2010-08-08 07:10 ahunter Resolution open => fixed
2010-08-08 07:11 ahunter Relationship replaced has duplicate 0000154
2010-08-08 16:10 EmacsUser Note Added: 0000389
2010-08-27 16:45 docsharmat Issue Monitored: docsharmat
2010-08-29 22:16 jmcgrew Relationship added has duplicate 0000273
2010-08-31 07:58 jmcgrew Relationship added has duplicate 0000275
2010-10-29 09:19 jmcgrew Fixed in Version => 6F95
2010-10-29 09:19 jmcgrew Status resolved => closed
2010-11-30 23:40 jmcgrew Relationship added has duplicate 0000449
2011-04-10 06:51 EmacsUser Relationship added has duplicate 0000640

Copyright © 2000 - 2010 MantisBT Group
Powered by Mantis Bugtracker