|
From: | moetteli |
Subject: | Re: State of Swarm on Mac OS X |
Date: | Thu, 19 Sep 2002 00:21:19 +0200 |
Am Mittwoch, 18.09.02 um 17:05 Uhr schrieb Ed Baskerville:
On Wednesday, September 18, 2002, at 02:12 AM, address@hidden wrote:Scott Christley wrote a good summary of the problem on this list someweeks back. Basically the GNU ObjC and Next/Apple Objc have a different message passing mechanism. The compiler can be instructed to use eithermethod with the -fgnu-runtime or -fnext-runtime flags. The problem isthat this flag acts on a per file basis. so you can't compile a programwhich uses both methods. The solution is to write a bit of C glue toallow 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.
Seems like there might be a couple ways to use the Cocoa runtimeexclusively, 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 Idon't have ObjC experience outside Cocoa):
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 fonction should only be called in one object like (Cocoas) NSInvocation. 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.
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.
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.
Are there any cluster/distributed versions of Swarm out there?
That's comes close to something I also gonna need: A thread-save version.
Re Phil ================================== 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.
[Prev in Thread] | Current Thread | [Next in Thread] |