Re: scripting support for swarm ?

[Marcus G. Daniels]

>>>>> "DK" == daniel kottow <address@hidden> writes:

DK> i am very interesting in making my swarm-objects (written in
DK> objective C) accessible through a scripting language. i saw that
DK> there are plans/code to support scheme in future/present releases,
DK> although i couldn't find any looking superficially through the
DK> latest tar-file swarm-2001-12-07.tar.gz :-(

Scheme works now if you use Kawa.  Kawa is a Scheme implementation
written in Java that works on top of Java/Swarm.  The problem with
Kawa isn't so much efficiency, as Java support in Swarm is now fairly
fast and Kawa generates bytecodes, but with the difficulty in
extending classes.  Unfortunately, development on Kawa now has
priorities that I expect will mean that the situation won't improve
soon.

DK> my idea is basically to run my simulations from a command line of
DK> an interpreter, invoking (at least) the methods bound currently to
DK> the control panel plus adding object/parameter
DK> inspection/manipulation for the most important simulation
DK> elements.

JavaScript works now through XPCOM in Mozilla.  It could use some
dusting off, but both COM-based probes (IDL `variable' access through
accessor functions) and raw access to the JavaScript runtime are
implemented in Swarm.  I think this could be a pretty nice prototyping
environment, especially now that Mozilla an integrated JavaScript GUI
debugger.

DK> i thought about using python for this (since i believe
DK> python to have nice numeric capabilities), but it seems like SWIG,
DK> a wrapper library for exposing "low-level" libraries to scripting
DK> languages doesnt support objective C at the moment (and maybe
DK> never will anymore, because of lack of interest, they claim).

Swarm has a SWIG-like system for attaching the Swarm libraries
to language environments.  There is an Emacs program (interface.el) that
parses the protocol declaration files (defobj.h, collections.h), and
builds Lisp data structures describing the different methods that
are available.  Then, different front-end stubbers can write out
interface declarations or stubs for different language environments.
The Java front-end filename is java/java-stub.el and the COM front-end is
COM/COM.el.  The former generates all the .java files, mostly with
methods tagged as `native' and generates C stubs to go with them.
The latter generates IDL together with C++ stubs.  The stubs in both
cases use the Objective C `C API', and known Objective C compiler
naming conventions for calling Swarm things. 

Through the process of implementing the COM and Java front-ends (very
different kinds of systems), I don't think it would be terribly
difficult to write a new front-end for Guile or Python or whatever.
But Python already has a XPCOM front end, so that would probably not
be a good use of time.  Guile, however, might be neat because it
wouldn't necessarily require any compiled code.  Foreign function
calls wrappers could all be generated on the Lisp side all at runtime
(I think -- I'm not up-to-date with Guile development, so I don't know
for sure.  I think there is a good dynamic linking interface and FFI,
now in the development sources.)

FYI, probably the most likely projects for me are to 1) polish up the XPCOM
stuff for Swarm 2.2, and 2) adapt the XPCOM support for Microsoft .NET.

DK> my question is: is my approach similar (or compatible) with the
DK> scripting capabilites planned for swarm ? is there any (realtively
DK> straightforward) way to make a swarm simulation run from a guile
DK> command line ? otherwise, i still could think of wrapping some
DK> methods in C and then calling them from python... or are there any
DK> other people who have used or thought of similar approaches ?

You can always hack together something simple in C if it is just a few
methods you care about.  If you want a systematic interface in a
yet-to-be-supported programming language, then take a look at the Emacs
code in the Swarm source distribution.  The Lisp data structures (assuming you 
know Lisp) are easy to iterate over to load whatever scripting environment
you want with metadata.


                  ==================================
   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.