swarm-hackers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[swarm-hackers] Re: Host platform dependence (was Naming conventions)


From: Scott Christley
Subject: [swarm-hackers] Re: Host platform dependence (was Naming conventions)
Date: Wed, 18 Nov 2009 19:03:20 -0800


Okay, so I think I understand your point, and I agree with it to a certain point. Yes, I did a lot of work to separate the underlying scheduling engine, what you are thinking of as the "model source" from the GUI. This has allowed Swarm to be exactly what you are suggesting with R, that is there is a core Swarm model, and then there is an "integration piece" with that Swarm model and the GUI.

But one of your underlying assumptions is false, which is that the "integration piece" required to use the tcl/tk/blt GUI is somehow very similar to the "integration piece" required to use the OpenStep GUI. That just isn't true, in fact they are very different and it necessitates a different interaction between a core Swarm model and the GUI.

Does that mean it prevents the core Swarm model (identical model source code) from having both an OpenStep GUI and a tcl/tk/blt GUI? Absolutely not, it just means you have to write two "integration pieces", one for each GUI.

Now you do make the point about putting Cocoa code in the library which supports standard Heatbugs model and etc. I'm okay with that for some core things like EZGraph, probes and etc. But note that this still requires writing two "integration pieces", they just happen to be provided by Swarm. And this goes back to the point of how the two GUI have very different interaction models, the current design of Swarm is based upon the tcl/tk/blt interaction model, and that just may not be "doable" identically with OpenStep. It requires more study, but when I looked at this more carefully in the past, I'm fairly confident that it would require significant changes, i.e. its not possible to "squeeze" OpenStep into the tcl/tk/blt interaction model. This is why OpenStep Swarm is using multiple threads and a specific interaction between the GUI and the model, etc. That begs the question then of what is the best design that can support multiple GUIs, not an easy question.

As for the point of core Swarm models *not* using Cocoa stuff. Well in my opinion that is purely up to the user. If there is some cool, I need to use API in Cocoa, and you are willing to give up using that model on Windows under tcl/tk/blt or whatever, then go for it. The purpose of Swarm isn't to limit what people can do. If users want to write a highly portable core Swarm model, that can be easily done.

Scott

On Nov 18, 2009, at 6:15 PM, Bill Northcott wrote:

On 19/11/2009, at 12:32 PM, Scott Christley wrote:

Your comments make sense until you dig deeper, what exactly do you mean by "Swarm style"? Of these two messages, which one is "Swarm style" and which one is "Cocoa style"?

[anObject doSomething]

[anObject doSomethingElse]

The answer is neither. If doSomething is a Cocoa(Swarm) method, it is Cocoa(Swarm) style.

If you have Cocoa methods in a model it will not run on Linux or Windows unless we intend to add GNUstep to those Swarm library distributions. Worse still Cocoa methods which are not part of GNUstep will make the model MacOS X only. That would seem to me to go completely against a basic objective of Swarm: that models should be independent of the host. All the host dependence should be in the Swarm library code.

If you are suggesting that tcl/tk/blt Swarm should be source compatible with openstep Swarm, that would be a difficult task.

If by 'source compatible' you mean 'model source compatible', then that is exactly what I am suggesting. Where do you see the big difficulties in this? If you mean 'library source compatible', that would seem to me to be impossible by definition.

The MacOS X Swarm library code could contain a much more sophisticated GUI, using all sort of Cocoa controls, with the ability to control model execution etc. without affecting the model code.

I keep going back to R as the model for this. An R code can run on any R platform even though there are several completely different GUIs.

It seems to me that Nima is writing a MacOS X version of Heatbugs, which seems to me to be a 'bad idea.' What we need is Cocoa code in the library which will support the standard Heatbugs model, and other Swarm gui models. As I see it this needs a Start/Stop/Save widget, a probe widget and an EZGraph implementation etc.

I'm not familiar with the GC hooks in Swarm but it's possible they are compatible. I don't really know much about how Apple's GC works.

So this is an area that needs investigating.

Thanks for the clarification
Bill





reply via email to

[Prev in Thread] Current Thread [Next in Thread]