Problems with CocoaGlk on Lion?

Ever since I upgraded to OS X 10.7, whenever I load a gblorb, Gargoyle shows the first screen of text and then locks up and won’t accept any input, and Zoom just shows the cover art and then brings up a message log containing this:

Using git vs. glulxe doesn’t seem to make any difference, though my GlkTerm build of glulxe still works.

I don’t know how to dig deeper than that, but a google search did lead me to this bug report which looks likely to be related.

Anyone know what’s going on, or alternately, anyone running it on Lion with no problems?

I see the same thing on Lion in the Inform IDE (which uses CocoaGlk.) Probably the same bug report you found, yes.

Can you see if the Gargoyle input issues go away in this build?

Yep, that seems to do the trick.

Excellent!

So, er, any idea how to deal with this issue for the Inform IDE? It’s making glulx game development kind of difficult.

Ben, does “that build” contain a bug fix at the CocoaGlk level, or was it recompiled in some useful way, or what?

I filed bug inform7.com/mantis/view.php?id=711 on the I7 bug tracker.

It doesn’t have anything useful for CocoaGlk. It’s a build that fixes all the weird stuff I had going on with NSThread sleep, on the way to supporting the new volume change API.

It looks like this fix will solve the underlying issue in CocoaGlk; just a matter of waiting until a new build is released.

Thanks entirely to Andrew Hunter’s labours, we now have Inform 7 running successfully on Mac OS 10.7, that is, Lion. As far as I’m aware, there are two issues at present:

(a) Apple chose to hide the “Library” subfolder of each user’s home folder in 10.7. It continues to exist, but is now invisible. In all previous versions of OS X, it was best practice for applications to place user-configurable settings inside this folder, and that’s where Inform stores user-installed extensions, and so on. (In ~/Library/Inform.) Apple apparently believes that users should no longer deal with applications in this low-level way, which is a problem for many high-end apps as they stand - BBEdit, Photoshop, and many others. It isn’t yet clear what we should do instead; we may one day have to rethink this when and if we adopt Lion’s sandboxing - as would be necessary if Apple forces all developers onto the App Store, something we are currently opting out of, but which may be a good idea in any case. But that’s a longer-term issue. For now, we’re simply telling people how to access Library despite its invisibility.

If you want to get access to this folder, you now have to use the Finder menu option

Go > Go to folder…

and type “~/Library”; alternatively, there’s a command-line command which will hack the Finder to restore the Library folder to visibility.

(b) For projects with the Glulx virtual machine setting, games would hang rather than play after a successful translation of the source text. This may be due to a bug in Lion’s implementation of NSPortCoding (I’m writing this as though I understood what that meant) - in any case, Andrew has reimplemented this part of the interface to avoid the problem, and we now have a fixed build, which I have uploaded here:

inform7.com/download/

This is still billed as 6G60 because the core of Inform - the compiler, the templates, and so on - remains unchanged. It’s the cleanest replacement I can make it, and people with ongoing Glulx projects should in principle be able just to replace Inform.app and carry on. Do please let us know if that turns out not to be the case.

(Work is indeed ongoing on a major new release of Inform, but this isn’t it.)

Graham

Excellent. Thanks!

Incidentally, the command to permanently restore ~/Library’s visibility is:

chflags nohidden ~/Library

Inform is now working again. Excellent job, thanks! Is there/will there be a similar solution for Zoom?

At the risk of sounding impatient — although I really understand that Zoom is a community service provided in someone’s off-time — any word on a Zoom fix? There aren’t a whole lot of full-featured Glulx players on OS X. (Although the Gargoyle snapshot provided above does seem to work.)

Should I try this re-release to ensure it still works on a PPC Tiger installation?

At the risk of also sounding impatient, I just wanted to bump this thread again. I like Gargoyle, but not being able to make it full-screen is kind of a dealbreaker for me.

Hi all,

I just wanted to clarify a few things, as I’m a Mac/iOS developer. (My company is exploring the possibility of branching out into commercial IF, FWIW.) :slight_smile:

The ~/Library folder for Mac OS X Lion is hidden from the user, but is functionally the same as it always has been. Applications can still store data there, though it should, typically, be data that an end user is not expected to access from outside your app. In general, app data should be stored at:

~/Library/Application Support/AppName/

And application preferences, (i.e. settings), should be stored at:

~/Library/Preferences/

However, the user’s Library folder is still very easily accessed by simply opening the Finder’s Go menu and holding down the Option key. A menu item will appear for the user Library folder, which will make it temporarily visible in your home folder.

Document-type files, such as Inform projects, should be saved to the ~/Documents/ folder by default, generally speaking.

I hope this info is useful to some fellow Mac folks. :slight_smile:

Yes, I didn’t know about the bit with the option key. Thanks, that’s quite useful!

Hi,

I just fired up Zoom to introduce my new class of 9/10 year olds to IF via Toonesia, only to find that it comes up with a blank screen and the error ‘Client crashed with error 11’.

Googling got me here, but has there been a Zoom fix since last September?

John.

No, but Gargoyle has been updated. That’s your best bet: code.google.com/p/garglk/

Gargoyle is what I’m using to demo the game to the students, but it’s by no means a Mac application. Opening the Preferences opens a Unix-style configuration file! I’m not exposing my little ones to that. Maybe in a couple of years’ time, but not now - editing config files is not in the scope of what I want to do with them.

John.

I agree that editing the configuration file is not the most user friendly experience, but why would they need to do it?