Re: A newbie question

Oh, I'm very happy to hear that the functionality I describe is a major goal
for the next breve release.
In the case of almost every Smalltalk the external api access is necessarely
done through dynamic link libraries.

For example in VisualSmalltalk I have a wrapper class called UserDLL that
wraps the user32.dll from Windows OS.
It implements a class method called filename which indicates the name of the
dll to load:

fileName
        "Answer the receiver's file name."
    ^'user32'

And it implements several methods to call the exported functions in the dll,
for example the method
charLower which turns a string into lowercase via user32.dll

charLower: aString
    <api: CharLowerA ulong ulongReturn>
    ^self invalidArgument

Note the following elements in the method:

a) <>    This indicates an "abnormal" external call within the method (api
call or primitive call)
b) api:     Means this is an api call following the _declspec(dllexport)
calling convention (other posibilities are ole: stdcall: pascal: and some
more)
c) CharLowerA    is the actual name of the exported function within the dll
d) ulong    indicates that the function takes one parameter which is an
ulong, in this case the String object is recognized and is automatically
passed as something that the dll can handle (char *), for more complex
parameters an explicit conversion to c pointer for passing the argument may
be needed or you may indicate a struct parameter (other possibilities are
long int uint short ushort boolean double struct)
e) ulongReturn    The last word between <> indicates the return value for
the call, in this case the function returns an ulong that is a pointer to a
char array (char *). An explicit conversion to String in Smalltalk from this
pointer is needed to obtain a String object from that return value.
f) ^self invalidArgument    The method returns an invalid argument error if
the external call fails

Notice that this scheme handles well external memory (read/write) and
supports callbacks via a callback facility (you may create a c pointer in
Smalltalk and pass it to an external c function, then call it from c code
(within the dll) to cause a callback into Smalltalk which results in a
method activation), this facility is handled by the ST virtual machine.

If somehow breve could offer a dll with exported c functions that
communicate with the breve engine almost any Smalltalk user (and those with
external api access via dlls in other languages) could use and map the
objects in the simulation thrugh it and build whatever intermediate layer
neccessary.

I'm willing to help in achieving this scheme if you think it's possible (I
know little about breve right know) and if you give me some pointers =) I
have an intermediate level of c and c++ knowledge (I'm mostly an Smalltalk
programmer) but have done many projects that interfaced c dynamic link
libraries with Smalltalk (including having to build the dlls myself, using
VC++).

Thanks again for breve.

GV

PS: right know I'll be taking a look at the code you mentioned in the
previous e-mail and try to figure out how the breve plugin system works
(thanks!)
PS2: it is much more difficult to interface from Smalltalk to dlls where the
exported functions are in c++ rather than c (because of name mangling and
other issues)

----- Original Message ----- 
From: "jon klein" <[email protected]>
To: <[email protected]>
Sent: Monday, May 31, 2004 5:27 PM
Subject: Re: [breve] A newbie question


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


_______________________________________________
breve mailing list
[email protected]
http://www.spiderland.org/mailman/listinfo/breve