[gambit-list] Problem with interactive development using remote REPL of iOS Sim.

mikel evins 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:
> 
>  http://pythonhosted.org/pyobjc/

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)
  ()
  (:metaclass 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...
URL: <http://mailman.iro.umontreal.ca/pipermail/gambit-list/attachments/20130227/4804465d/attachment.htm>


More information about the Gambit-list mailing list