Re: [ANN] LuaCocoa v.0.2 released

[Eric Wing <ewmailing@...>]

On 3/9/11, Dimiter "malkia" Stanev <malkia@gmail.com> wrote:
> Hi Eric,
>
>  From your experience, how easy it would be to plug something like this
> with Cocotron? I guess I would have to recompile some of the objective
> files on Apple, and later transfer the .DLLS
>
> www.cocotron.org
>
> Cocotron uses cross-platform mingw compiler on Mac to compile it's kit.
> It's being used for example from the ClozureCL (Common Lisp) guys to get
> a Cocoa like interface on windows (that is Cocotron).
>
> I was wondering how hard it would be the get the same for Windows and Linux?
>
> There is also GNUStep, but I was looking for more natural feel (not
> detached menus for example).
>
> Thanks,
> Dimiter "malkia" Stanev.
>
> P.S. Thanks for the page where you mention other Cocoa bindings for lua.
>

I don't know much about Cocotron or how it works, but these are my
porting thoughts. I want to port to iOS, so maybe some of this will be
applicable.

To port to iOS, the following needs to be done
- Replace NSXMLDocument (iOS doesn't have this class)
- embed libffi for iOS (it is built-in on Mac)
- Generate BridgeSupport XML metadata for functions, and structs, and
constants, classes etc. and support bundling XML data in the app
bundle

So, I'm still hoping for a knowledgeable volunteer to help rewrite my
XML parsing. I really don't know a thing about XML. I'm surprised
things work as well as they do now. (But I expect to see performance
gains with a better XML parsing engine.)

libffi is cross-platform as far as I know. BridgeSupport is also an
open source project that theoretically is cross-platform. The idea is
that anybody can use it to generate XML metadata for APIs. I read
maybe GNUStep once discussed using it, but I don't think it ever
progressed beyond that. (An aside, I spoke to a Mono engineer at GDC
last week...very impressive work they have done. But it sounds like
they have their own mechanism for parsing APIs to do bindings which
wasn't meant for mainstream external reuse unlike BridgeSupport.)


The JSCocoa project has references to libffi for iOS and I believe
BridgeSupport for iOS. I think they already solved all these problems
so I just need to incorporate everything they have learned.
Ironically, even though they solved all the technical problems,
because they use a private API (JavascriptCore?) on iOS, nobody is
allowed to ship apps on the App Store using JSCocoa right now.
LuaCocoa shouldn't have that problem.


Also, I think I may need to relax a few expectations about
BridgeSupport actually existing. I haven't yet tested the case where
no BridgeSupport is found at all.



My additional thoughts for Cocotron are,

I think LuaCocoa only directly depends on Foundation. I don't think
AppKit is required. (I just noticed I was linking against Cocoa
instead of Foundation which I suppose I should fix.) Though I think
technically I use CoreFoundation for things like CFRetain/CFRelease.
(This is how I handle dual garbage-collection modes on Mac.)


I do use the Obj-C 2.0 API , syntactic features, and runtime, so if
Cocotron is still Obj-C 1.0 based, this might cause some headaches.
The Cocotron webpage makes me think Obj-C 2.0 is not a problem.

I use a few C99 features in a few spots. Not sure if this will also be
a problem or not for Cocotron. (I assume it won't be since you said
mingw)

There are some dlopen's and stuff to load libraries. This probably
needs to be adapted to Windows. This shouldn't be hard to do though.


Finally, kind of an aside, I want to point out that I have a set of
classes called "ParseSupport*" in LuaCocoa. I tried to write these  in
a way that they were detachable from LuaCocoa. My original thought was
that parsing BridgeSupport metadata was tedious and something that was
hard to understand. I was hoping to write one generic implementation
that other language bridges using BridgeSupport might be able to just
rip out my stuff and drop it into their project saving everybody lots
of effort. (I had really hoped to do this from PyObjC, RubyCocoa,
MacRuby, or JSCocoa, but I couldn't make heads or tails of their stuff
and how to decouple it from their language implementations.)
Conversely, this is also the majority of the NSXMLDocument stuff lives
so I was hoping smart volunteers would be able to rewrite this without
needing to get deep into the other ugly internals of LuaCocoa. I'm
sure I mis-designed it, but I'm open to working with anybody who wants
to optimize/rewrite and/or incorporate ParseSupport.

-Eric
-- 
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/