Re: [Swarm-Support] development priorities (was Re: Membership in Swarm Developmen Group)

[glen e. p. ropella]

Marcus G. Daniels wrote:
>> There is no such thing as a Swarm model written in Java.  A Swarm model
>> uses the Swarm scheduler, which is written in Objective-C.
>
> You have a program written in Java.  It imports some Swarm things that
> happen to be implemented using compiled code.  Nothing is stopping you
> from using network protocol enable tools in the usual Java ways.

Yes, what's stopping me is the inability to load a dll over http.

>> "Feasible" is not synonymous with "possible".  It is certainly
>> _possible_ to embed Swarm in all sorts of things.  But, it is not
>> feasible for most projects because a) they lack the technical expertise
>> and/or   
>
> Let me take another tack.

What tack?  Do you mean telling the _whole_ truth rather than just
saying whatever is convenient in an attempt to claim that my statements
are wrong?  Gee, thanks.

> It is easier to embed Swarm in an general
> object-oriented way in another framework because Swarm has a lot of
> ready infrastructure to facilitate it.   That you just feign ignorance
> of this does not to justice to the *relative* ease with which the
> capability could be adapted for direct use by users.   True, it hasn't
> been and thus it isn't obvious how to do it.   If you want to have a
> real technical discussion about how to embed a simulator and the general
> issues involved, you might want to at least not revise history so much.

Hmm.  Yes, it is easier to embed the current (hard to embed) Swarm than
it would be to embed a hypothetical Swarm that does not have as much
infrastructure to facilitate it.

I'm not feigning ignorance of Swarm's features.  I'm making the truthful
claim that Swarm is difficult to embed in other applications.

And it was _you_ who digressed into embedding Swarm into R.  All I
wanted to do was give my opinion of the 4 development projects Steve
mentioned.  I've done that.  So, as soon as you stop posting
misinformation, I'll end my part of the discussion.

>> 2) other requirements (like running simulations in a jvm started
>> from a web browser) conflict with Swarm's architecture.
>
> There is nothing magic about running code in a JVM.  As a practical
> matter, embedding in a .NET sandbox will get you faster startup and a
> larger user base.   Or using Flash.    Yes, it would require a new way
> to express models in order to run them in a browser plugin. 

I know there's nothing magic about it.  We weren't discussing that.  As
a practical matter, Swarm's architecture conflicts with many projects'
other requirements.

>>> Swarm runs fine
>>> inside a Java virtual machine -- it's a DLL and a jar file.
>>>     
>>
>> DLLs don't run inside the jvm.  Saying so won't make it true.
>>
>
> DLLs run in the system allocated address process space of the JVM. 
> Along with other DLLs that the JVM may load for its own functioning. 

That doesn't mean that they run "inside the jvm".  DLLs are native code,
not virtual machine code.  They don't run inside a virtual machine.

-- 
glen e. p. ropella, 971-219-3846, http://tempusdictum.com
Cynics regarded everybody as equally corrupt... Idealists regarded
everybody as equally corrupt, except themselves. -- Robert Anton Wilson