[Openmcl-devel] Binding to PPC CCL Objective-C objects

Paul Krueger plkrueger at comcast.net
Mon Jan 24 14:40:01 PST 2011


As a result of the problems that Paul Onions reported for my developer tools, I've spent several days narrowing down what's going on using an old mac PPC laptop running OSX 10.5. The bottom line is that whenever I load a nib that specifies a binding between an interface element and any CCL objective-C object, a bus error occurs. I've reconstructed what's happening by getting everything initialized from the NIB without the binding and then manually calling #/bind:toObject:withKeyPath:options: which gets the same bus error. 

Even very simple examples that I know were working on my Intel-based system running 10.5 well over a year ago fail, so I'm beginning to suspect that the problem is architecture-dependent rather than OS version-dependent. If someone has run any of my contrib stuff (especially the new stuff) successfully on a 10.5 Intel system, I would appreciate hearing that.  If someone is willing to run a quick check on a 10.5 Intel Mac running with a relatively recent version of the CCL trunk, you could simply start the CCL IDE and do the following:
	(require :lisp-app-doc)
	After the Dev menu appears, select "New Lisp Application" from the file menu. 
If it shows a window and doesn't crash, then the problem I'm chasing doesn't exist on your system.

I'm not ruling out the possibility that I've done something wrong somewhere, so I want to ask, has anyone anywhere created a NIB that binds some value to a CCL-defined Objective-C instance slot and run that successfully on a PPC system? I checked all of the CCL IDE nibs to see if they ever do a similar binding and they do not.

Can anyone think of how a PPC version version of a Lisp Objective-C object might differ from an Intel version in any way that might affect binding?

Can anyone suggest a way to further track down a bus error that occurs when calling that Objective-C method?

Without a lead somewhere, I'm currently at a bit of a loss for what to try next ...

Paul


More information about the Openmcl-devel mailing list