Re: A newbie question

jon klein <[email protected]>
Newsgroups gmane.comp.breve
Message-ID <[email protected]>
On May 29, 2004, at 2:06 AM, German Viscuso wrote:

> Hello everybody.
>
> I just saw breve, I'm amazed!
> I see that breve uses a c like language called steve for the 
> experiments. I
> was wondering if it's possible to utilize Smalltalk (abreviated ST)(for
> example Squeak) to interact with objects in the simulation. In most
> Smalltalks there's an external api access facility which is mostly 
> used to
> access c functions in external libraries (such as dlls) and also 
> there's
> full support for berkeley type sockets and several higher level network
> protocols. Is this enough to interface with breve?
> (I cannot generate c code so I cannot build a breve plugin) I find the
> plugin system rather strange because with it breve calls my c code 
> while I
> would prefer to call/use the breve engine myself from my ST 
> environment.
> Is it possible to *fully* use the breve engine from outside (via api 
> calls
> or via network) for my experiments?
> The usual way in ST for interacting with simulations or engines not 
> built
> with ST itself is to make wrappers for the objects in the simulation 
> (the
> later exposed via an api). That way I can see a representation of the 
> engine
> objects in my ST environment which forward any message received in my
> environment to the actual objects in the simulation and viceversa.

The functionality you describe is one of the biggest goals for the next
release (2.0).  People have been asking for ways to interface the breve
engine with all sorts of languages: Java, Smalltalk, Lisp, etc, and I'd
really like to provide an interface that can allow simulations to be
written in *any* of these languages.

Even though the plugin API only describes how breve is used to call 
external
code (and not vice-versa), it is in fact the same interface that is used
for the steve language to interface with the breve engine.  If you 
understand
the plugin interface, then you will understand the interface that 
objects
use to interact with the breve engine.  You can see this in action if 
you
open up some of the included breve class files.  For example, if you 
edit
the class file Mobile.tz, and look at the code for the method "move", 
you
will find that the object interfaces with the breve engine via a C-style
function call: setLocation(realWorldPointer, newLocation).

Here's some horrible ascii-art to illustrate the connection.  The breve
engine calls the "iterate" method (which is written in steve).  The 
steve
code calls C-style function calls, and those calls interface with the
engine.

      "steve" code       <------------
- - - - - - - - - - - - -          |
  C-style function calls        "iterate"
- - - - - - - - - - - - -          |
      breve engine      -------------

SO -- what does this all mean?  It means that if there is an API
available to call C-style function calls, one could "port" the included
class files (currently written in steve) to any other language.  Most
of the method calls in the built-in class files are simple wrappers
for C-style function calls, so this should be very easy.

I can add this functionality to the plugin API very easily.  If you
want to see how it's done right now, you can download the breve
source and have a look at the function stEvalCallFunc() in
steve/evaluation.c.  This shows how internal C-style methods are
executed from the parsed steve code.

If people are interested in helping to interface with the API and
porting the class files to another language, please contact me
off-list and we can discuss the details.  I suspect that each language
will have different constraints for how they interface with the API,
so if possible, please let me know how the language you're interested
in accesses external code.

- jon klein

_______________________________________________
breve mailing list
[email protected]
http://www.spiderland.org/mailman/listinfo/breve
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.