Re: State of Swarm on Mac OS X

[W . Northcott]

Bill Northcott wrote:
> >> Scott Christley wrote a good summary of the problem on this list some
> >> weeks back.  Basically the GNU ObjC and Next/Apple Objc have a
> >> different
> >> message passing mechanism.  The compiler can be instructed to use
> >> either
> >> method with the -fgnu-runtime or -fnext-runtime flags.  The problem 
is
> >> that this flag acts on a per file basis.  so you can't compile a
> >> program
> >> which uses both methods.  The solution is to write a bit of C glue to
> >> allow passing messages using the method of choice on a per message
> >> basis.
> >
> > Glue code is all well and good...but as a Cocoa/Swarm programmer I
> > wouldn't want to deal with that.
> I do agree on that.

Once it was written, you would not need to deal with it.

> > Seems like there might be a couple ways to use the Cocoa runtime
> > exclusively, but both would be a lot of work, and one would
> > significantly
> > split the source tree (if this doesn't make sense, it's probably
> > because I
> > don't have ObjC experience outside Cocoa):

As I understand it (I'm not a programmer by training) there are two basic 
reasons that Swarm uses a patched runtime and compiler. 
1.  An alternative, syntactically different and faster method invocation 
mechanism.
2.  To enable the splitting of object creation and destruction into 
phases, which introduces runtime flexibility important to the modellers.

Apple say they have done a lot of work on 1..  So this may not be needed 
with their runtime.  However, the alternative syntax is written into the 
Swarm code all over the place.
2.  Is regarded as rather important for the users.

> 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.  The messages would 
never reach it, because they are different C functions in the runtimes.  I 
really recommend Scott Christley's summary.  He knows much more about this 
stuff than me.

>Or differently said, as long as you encapsulate all the
> tinkering with the runtime system into a separate object (what OO
> actually demands you), you could only make a few precompiler directives
> to solve the problem.

That sounds to me like what I would call glue and it would need to be in C 
not ObjC.

> And there's another thing, that bathers me/I would like to propose: Why
> keep and maintain Swarm's own foundation classes, when you could go
> GNUstep? And by doing that you gonna have some more programmers for
> free working indirectly for Swarm AND you get MOSX compatibility? Apart
> from that, Swarm could use additional stuff like Distributed Objects
> and thelike.

It could be great, but you would need to get the GNUstep people to accept 
the mods mentioned above.

> I know, that both propositions include probably a lot of work and even
> a complete clean up. But I would probably do a  lot of that myself, if
> the Swarm community does agree with that. I can't yet promise it
> though. But those are the plans I have for my dissertation.

With the current Swarm resource it would seem to be too much work. 
However, if you really could do it, that is another matter.
 
> > Are there any cluster/distributed versions of Swarm out there?

Russell Standish from my University UNSW did some work on this.  He may be 
reading this list.

Finally, we need to get the code running under X11 on MacOS X avoiding all 
Cocoa stuff, before we can really consider this type of rewrite.   Sort of 
walk before we run.

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.