Objective-C and runtime type inspection

[Bob Ippolito]

On 8/17/06, Joel Reymont <joelr1@REDACTED> wrote:
>
> On Aug 17, 2006, at 8:38 PM, Bob Ippolito wrote:
>
> > We use libffi for that. The version in the PyObjC repository is
> > patched to work on Mac OS X Intel (I don't think the official one
> > supports that yet).
>
> I'll take a look when I get to this.
>
> > What about a pointer to a structure, output structures, input/
> > output structures?
>
> Don't know yet. Output and input/output structures are a chunk of
> memory, a binary. There's of course no way in Erlang to know the size
> of the chunk before making it.
>
> I'm open to suggestions.

What we do in PyObjC is use the RTTI to determine the size of the
chunk to allocate, and return a tuple of (rval, output1, ...).

> > The networking overhead is going to be irrelevant for the most part.
> > None of the messages in a typical Cocoa app are big unless they're
> > creating NSBitmapImageRep from memory or something. I'd make it a
> > C-node personally.
>
> Ok, I'll go with that. It can be made a driver later on, if needed.
> Question, though...
>
> How do you make this work as a bundled app? Run erlang like Wings3D
> does and then fork off the c-node?

That's a little stumbling block. Perhaps it's possible to structure
the c-node such that it's the primary executable and it launches the
erlang runtime and tells it which pid to talk to. LaunchServices wants
the application bundle's executable to be the one that talks to
WindowServer.

It's possible to launch Erlang first via LaunchServices, but then you
end up with a bit of funny business with the way the application
launches (e.g. it may be allowed to launch more than once) or with the
dock (two dock icons or some such).

On the other hand there's probably more fundamental problems to doing
it with a driver, because you need to really do a lot of messaging
from the main thread, and also the Erlang runtime really shouldn't be
doing much in the main thread because that's going to be controlled by
the NSRunLoop. I think it would be very difficult to write a driver
that works correctly and doesn't screw up Erlang, but a c-node
shouldn't have those sorts of issues.

-bob