[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: State of Swarm on Mac OS X
From: |
W . Northcott |
Subject: |
Re: State of Swarm on Mac OS X |
Date: |
Fri, 20 Sep 2002 16:30:11 +1000 |
> > Apple say they have done a lot of work on 1..
> This seems to be the compiler flag for the runtime.
I am sorry but I don't understand that comment.
> >> The same is valid for me. So that's perhaps the reason, why I don't
> >> see
> >> yet, why the different message dispatching call is such a huge
> >> problem.
> >> This function should only be called in one object like (Cocoas)
> >> NSInvocation.
> >
> > If this object is compiled with the Next runtime flag (to communicate
> > with
> > Cocoa objects), it would not be possible to invoke its methods from a
> > Swarm library compiled with the GNU runtime flag.
> Of course, but just compile everything with the same runtime flag.
I will say again - this will NOT work. The C call to pass a message to an
object via the Next/Apple library is a different function from that used
by the GNU library. If you compile a program with the -fgnu-runtime flag
it is simply impossible for that code to call a Cocoa object, because it
would be using the wrong 'language'. Conversely, if you compile with the
-fnext-runtime, then the code cannot access a Swarm object.
Scott Christley explained this clearly.
> >
> > That sounds to me like what I would call glue
> Well, you can call it as you wnat of course. But in OpenStep/MOSX, we
> have methods in NSObject (performSelector, superclass, poseAs,...) and
> in separate objects like NSInvocation. Those are all calls to the
> runtime system, but by making it part of an object, you have it just in
> one place.
Every call to an object method is a call to the runtime system. That IS
the problem. You cannot quarantine them in one object.
What is needed is a C library. The object implementation in the Swarm
code could invoke an NSObject method by making a C call to this library
that then makes a C call into the Apple runtime. It has to be done in a
pure C program so that the compiler generates no Objective-C runtime calls
when it is compiled.
It would be similar to the avcall/mframe stuff in Swarm.
> Well if this phased creation and destruction of objects could be solved
> in OpenStep, it's automatically also solvable in Gnustep. Because on
> MOSX I don't even have the sources. But I have to have a closer look.
This problem is administrative not technical. You would need to pursuade
the GNUstep maintainers to include it in the source tree.
Regards
Bill Northcott
==================================
Swarm-Support is for discussion of the technical details of the day
to day usage of Swarm. For list administration needs (esp.
[un]subscribing), please send a message to <address@hidden>
with "help" in the body of the message.
Re: State of Swarm on Mac OS X, Ed Baskerville, 2002/09/24