Mac OS X @split_window bug?

Technical Development Interpreters
1

Happy Sunday!

Forgive me for wandering off the path a bit – I hope this is the appropriate place to dive into a Mac interpreter problem.

IFGamePage.h references:

#import <ZoomView/ZoomView.h>
. . .
    ZoomView*        zView

It looks like zView is an actual complete interpreter nested within the IFGamePage. However, I can’t seem to locate the source for Zoom. (Is the Mac source out there somewhere?) From what has been said so far, it seems like the Zoom code may have a bug triggered by the @split_window operation. I would suspect a problem with an NSScrollView or similar, but without the source I’m only guessing.

Although my ultimate build target is the web, I’d like to be able to test within the Mac Inform IDE without using any hacks. Any suggestions how I can continue to track down this bug?

Tom

2

The Mac IDE source code is downloadable at inform7.com/sources/interfaces/.)

The Mac Zoom source code is at logicalshift.co.uk/unix/zoom/.)

3

Thanks!

Something is up with the links or domain – logicalshift.demon.co.uk is the domain I had to use. I couldn’t find the source there, but did end up finding it on ifarchive.org/indexes/if-arc … Xzoom.html.

There were a couple invocations of makeFirstResponder in ZoomView.m, which may explain the behavior if there is some kind of bug or unexpected behavior in the NS libraries. I sent Andrew (the other) a note asking about it.

Anyways, thanks for the help!

Tom

4

FWIW, I suspect the problem is related to the Zoom 1.1.5 code, src/zcode.ops (line 1577 on). From what I gather, zcode.ops seems to be part of Zoom’s precompute strategy for optimizing run time performance. The actual bug itself seems to occur within ZoomView.m, possibly in shouldReceiveCharacters or shouldReceiveText:maxLength. (I suspect these functions because they have calls to makeFirstResponder.)

The above is speculation based on tracing the code from a sample Inform project, Inform, the Inform Mac UI, and into the zView embedded object. When the bug occurs it seems like the textView of Zoom looses input focus, and so keystrokes generate an error sound on the Mac after lockup. Having Zoom invoke the @split_window operation seems to be the trigger. (I’m having trouble getting Xcode to build the Zoom source, so I don’t have an actual trace/instrumentation at this time.)

I see the problem on a 2013 MacBook Pro running Mac OS 10.8.3 (12D78). The laptop does not have a retina display.

I think the bug is exclusively within the Zoom source, and not within any Inform source. Let me know if you think any/all of this should be posted up to the Inform bug ticket.

Tom

5

If it were just the view losing focus, then you could get focus back by clicking on it. Also, if it were a bug in the app’s display logic, it would be consistent for everybody.

I still think this is a wild pointer. But I haven’t looked at the source, so I’m still just guessing.

6

If it would help, I have detailed build instructions written up, which I can PM you later today, once I get my laptop back from the friend who’s borrowing it.

7

I would not mind seeing that.

Or is there a github repository out there that builds under the current version of xcode?

8

So by later today'', I guess that I meanttomorrow’’. Anyway, I’ve posted them here.

9

Fantastic build notes, EmacsUser!

Building with Zoom pulled from git, using the above instructions, Zoom works perfectly for me. However, using Zoom 1.1.5 (Zoom interpreter version 1.1.5, Macintosh interface version 2.1.5, CocoaGlk version 1.0.8, Glulxe version 0.4.7, Git version 1.2.9), I get the lockup every time on the following test case:

Include (-
[ SuperFrob;
VM_StatusLineHeight(5);
];
-)

To DoFrob:
(- SuperFrob(); -).

Frob is an action applying to nothing.
Understand "frob" as frob.
Carry out frob: DoFrob.
Report frob: say "Frob ho!"

So, I would infer that the code used for the 1.1.5 build differs from the code I just built.

(One note - for line 169 I used open zoom/ZoomCocoa.xcodeproj instead of open cocoaglk/CocoaGlk.xcodeproj.)

Tom

10

Huzzah! I will guardedly say I think there is a possibility I might have found the cause of the lockups. From the git log for Zoom,

> git diff 81a709dbe3b21c131f637af5b80ed822eb13f0d4 53bf0d0e6a58bb7ab6055e7b3c9769871a539c54  # (abridged)
. . .
diff --git a/src/zoomCocoa/ZoomView.m b/src/zoomCocoa/ZoomView.m
index 82628ab..5a1f533 100644
--- a/src/zoomCocoa/ZoomView.m
+++ b/src/zoomCocoa/ZoomView.m
@@ -926,7 +926,10 @@ static void finalizeViews(void) {
     [self setShowsMorePrompt: moreOn];
 
     [self setNeedsDisplay: YES];
-    [textView setEditable: NO];
+    
+    if ([textView isEditable] && moreOn) {
+        [textView setEditable: NO];
+    }
 }
 
 - (void) resetMorePrompt {

Andrew’s comment on July 1, 2012, was,

When the diff is applied, everything is happiness and sunshine. When I roll back the diff, I always get the lockup. I am not using Romaji or any other non-English input. However, I do have System Preferences → Dictation & Speech → Dictation normally set to “on.” This enables a “Fn Fn” hotkey that turns on dictation, although I normally do not use it.

For anyone with the lockup bug, do you have dictation enabled? Do you have non-English character input enabled?
 (And can someone sanity check me to be sure I’m not just bleary-eyed and delusional? :confused: )
Tom

11

Oo, good catch. If I turn on that dictation preference, then Zoom 1.1.5 starts locking up on the “Test Case.zblorb” file I built. (Not instantly, but after the first command I try.)

So, not a memory problem after all. Probably that’s a relief for everybody. :slight_smile:

12

Awesome! Thanks for tracking that down, Tom!