[gambit-list] Problem with interactive development using remote REPL of iOS Sim.
mevins at me.com
Wed Feb 27 10:50:09 EST 2013
On Feb 27, 2013, at 9:29 AM, Marc Feeley <feeley at iro.umontreal.ca> wrote:
> On 2013-02-27, at 10:19 AM, Jason Felice <jason.m.felice at gmail.com> wrote:
>> I'd be happy to unblackhole mine if it gets more people involved.
>> 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.
>> 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).
> 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).
> I wonder if there are some ideas we can steal from the Python Objective-C bridge:
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:
(defclass converter (ns:ns-object)
(objc:defmethod (#/convertCurrency:atRate: :float)
((self converter) (currency :float) (rate :float))
(* currency rate))
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.
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.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gambit-list