Re: [Swarm-Modelling] Something Glen said

[Marcus G. Daniels]

glen e. p. ropella wrote:

> The reason I'm not improving or writing a new Swarm is two-fold:  1) the
> SDG is not an open organization that takes direction from the community
> and 2) because the SDG continues to waste it's meager resources, it
> demonstrates that my investment would be more fruitful if I apply it
> somewhere else.
>   
If you had an idea specific and important enough to implement, and your 
view was that the SDG was incapable or unwilling to help you, and you 
felt it was unethical or inappropriate to have the SDG fund you as an 
insider or outsider, then the clear and responsible path is to stop 
complaining about it and start programming.   This will give you maximum 
autonomy and keep you on the moral high road.  
> My argument is that the SDG should become a more open organization that
> serves the community. 
I believe it does that with SwarmFests.  This is by far the largest 
component of cash flow at the SDG.   I personally don't care about these 
meetings, but others like them and find reason to organize them.  (i.e. 
I'm not the SDG.)
> The problem is that it contradicts other messages that indicate the SDG
> is considering porting Swarm to other architectures _without_ doing any
> of the refactoring that is needed to make Swarm relevant and useful.
>   
I'd be happy to try to make this argument to the SDG.   I always tried 
to do these things behind the scenes as a part of other visible software 
efforts projects.   The multilanguage (e.g. Java layer) work went a long 
way to improve the modularity of Swarm.  Factoring doesn't benefit users 
in an obvious way and it's hard to quantify for advisers that aren't 
interested in such issues.  It is, you know, more "geek hermeneutics", 
at least whenever you find it convenient to call it that.  

A first step would be to separate the packaging of GUI and non-GUI 
Swarm.  Scott did some of this internally for GNUstep, it just needs to 
be broken into physically separate code bases. Another step would be to 
rehost Swarm on the Apple Objective C system.    That would drop two 
libraries from Swarm as dependencies and some very nasty technical 
issues (that would be handed off to Apple, at least in part).  This 
means careful coordination with the Apple Objective C people to get 
hooks for the features Swarm needs (for phases). 

The GUI features (Tcl/Tk-based) should be isolated, because it has no 
real design.   It's been heavily factored from the nasty tangle that was 
1.0.   To replace it, I'd suggest a separate scriptable application that 
could attach via remote procedure calls to a running simulation.   Much 
as one does with an interactive debugger like TotalView or GDB.   This 
amounts to exposing simtoolsgui, tclobjc and tkobjc interfaces as web 
services (remote procedure calls over http) in a separate application, 
such as a web browser plugin.  space and analysis need to be reworked to 
keep make measurement and visualization  concerns separate. 

Next to factor out is the random library.  It's a fine library that gets 
the job done, but there's no reason to have it be part of the core.  
Others might find it easy to write a new module with high performance 
parallel random number generators or prefer to use a stock set of 
generators they have used elsewhere. 

Now we are down to the core of Swarm.   defobj, which provides an 
enhanced way to describe the lifetimes of objects, and handles all 
inter-language object coordination and then collections & activity which 
are necessarily intertwined in complicated way.   I would suggest 
separating defobj from the latter two.   One idea would be to merge 
collections and activity into a single library and encourage users to 
use their favorite collections library instead.   Using list proxies as 
needed to get info into the scheduler (as was done with Java/Swarm). 

Restated:

A) A clean factoring of the GUI features to a standalone library, such 
that existing Swarm simulations could still work.

With more work, a simulation monitoring application that works over 
remote procedure calls (RPC) either within the machine or over the 
internet.  If it were implemented as a web browser plugin or a .NET or 
Java application it could include existing native code components 
(current Swarm code).   

B) a core library for representing object lifetimes and dynamic messages 
in a language independent way.
Thus A) is really not that hard to do because the basic RPC approach is 
in place, and because Swarm can already generatesIDL for itself that 
could be handed of to a COM stubber (e.g. Firefox's cross platform COM 
or the Sony/IBM stubber for the PS3).

C) a discrete event simulator module that has a collections library with 
it.  The collections library is needed for the scheduler and for legacy 
simulations. 

D) simtools and analysis, possibly merged but stripped of any direct 
reference

E) the space library

With this organization, one could write lightweight batch simulations 
for large scale parameter sweeps without bothering with installing 
libraries for GUI instrumentation.    One could write or replace 
components for Swarm in any number of languages crossing language and 
machine boundaries.   A web-based monitoring application could equally 
well setup up simulations in the browser itself (e.g. with JavaScript 
agents), or it could initialize native objects on a Playstation 3 or 
clusters or supercomputers (either real or byte code streamed to it's 
processors or precompiled classes advertised as a standard web service 
on those machines).  

A new library I'd like to see would be a JIT native code generator for 
simulations described by higher level model descriptions, such as in 
XML.   Such code could be deployed in browser plugins or on cluster 
nodes.  Perhaps the best way to do this is via a JVM or CLR but I'd be 
happier to know (one way or another) that CPUs receiving code really 
were running at full tilt, i.e. take some time to study how a potential 
package like JIMT executes its code in the JVM and make any needed 
enhancements to optimize it for the hardware.