<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Feb 27, 2013, at 9:29 AM, Marc Feeley <<a href="mailto:feeley@iro.umontreal.ca">feeley@iro.umontreal.ca</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><br>On 2013-02-27, at 10:19 AM, Jason Felice <<a href="mailto:jason.m.felice@gmail.com">jason.m.felice@gmail.com</a>> wrote:<br><br><blockquote type="cite">I'd be happy to unblackhole mine if it gets more people involved.<br><br>The x86_64 part is because ObjC doesn't provide a completely machine-abstract way to invoke dynamically.  Each way has some icky flaws.  My first goal was actually iOS, but I went down the x86_64 path because Mikael had a need for that first.  I'd like the package to have x86_64/i386/arm.<br><br>I did discover that a LOT more machinery is needed for x86_64 than for i386 or arm.  Calling conventions on 64-bit are crazy insane (though I now have the worst of it solved).<br></blockquote><br>I agree that there are issues with all approaches.  If possible I'd like to avoid using assembly language which is compiler and operating system dependent (Objective-C runs on other platforms than iOS and OS X).<br><br>I wonder if there are some ideas we can steal from the Python Objective-C bridge:<br><br>  <a href="http://pythonhosted.org/pyobjc/">http://pythonhosted.org/pyobjc/</a></blockquote><br></div><div>For a Lispier version, you could look at CCL's FFI, which is quite comprehensive, and which provides a lot of very nice conveniences for writing code that talks to Cocoa. For example:</div><div><br></div><div><div><font face="Monaco">(defclass converter (ns:ns-object)</font></div><div><font face="Monaco">  ()</font></div><div><font face="Monaco">  (:metaclass ns:+ns-object))</font></div><div><font face="Monaco"><br></font></div><div><font face="Monaco">(objc:defmethod (#/convertCurrency:atRate: :float) </font></div><div><font face="Monaco">    ((self converter) (currency :float) (rate :float))</font></div><div><font face="Monaco">  (* currency rate))</font></div><div><br></div></div><br><div>Building CCL's FFI is largely automated using Gary Byers' ffigen, which is more or less a customized version of the gcc frontend. ffigen is freely available. It takes some googling to find it and discover how to use it, but I've done that before a few times; it's not too bad.</div><div><br></div><div>Alternatively, you could always make a tool to parse Apple's BridgeSupport files. Automating the generation of these interfaces is probably a good idea. You can pretty easily make a bridge that talks directly to the C API of the Objective-C runtime, and that gets you the power to do pretty much anything, but you're working at a very low level and have to do a lot of gritty stuff by hand. Building reasonable APIs at that level can be pretty time-consuming, and Cocoa is huge and growing. </div><div><br></div><div>When working with OSX and iOS from Gambit I've generally hand-built the interfaces I needed as I needed them. The disadvantage of that approach is that every nontrivial project requires me to hand-build some new Cocoa interfaces. The advantage is that the cost of doing that is no more than it has to be. Making a general Cocoa interface is a large task.</div><div><br></div><div><br></div></body></html>