Passing value to external program

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Passing value to external program

Ang BeePeng
Hi,

Many thanks for helps that I get, I'm able to store objects in Squeak.dll and use it with a exteranl program, main.exe.

Now I have Squeak.dll responding to main.exe. Say if I need a line, with startPoint, endPoint, colour etc.. I will ask Squeak.dll to create an object from Class Line, return the pointer to exe. While in exe, line is a struct that have sqPointer, startPoint, endPoint, etc.

Say if I have a function that ask Squeak to move the line. Squeak object(line) will then move, and instance variable endPoint will be change. There, Squeak should notify exe to update its value.

What should I do to achieve that? Simple variable pass in? or maybe call-back? Event notification?

Thanks for your valuable opinion.

Ang Beepeng
Reply | Threaded
Open this post in threaded view
|

Re: Passing value to external program

Eliot Miranda-2


On Wed, May 19, 2010 at 7:50 AM, Ang BeePeng <[hidden email]> wrote:

Hi,

Many thanks for helps that I get, I'm able to store objects in Squeak.dll
and use it with a exteranl program, main.exe.

Now I have Squeak.dll responding to main.exe. Say if I need a line, with
startPoint, endPoint, colour etc.. I will ask Squeak.dll to create an object
from Class Line, return the pointer to exe. While in exe, line is a struct
that have sqPointer, startPoint, endPoint, etc.

Say if I have a function that ask Squeak to move the line. Squeak
object(line) will then move, and instance variable endPoint will be change.
There, Squeak should notify exe to update its value.

What should I do to achieve that? Simple variable pass in? or maybe
call-back? Event notification?

Use "sendbacks".  When I did this for VisualWorks I had an interface that comprised a small set of external handles for Smalltalk objects and a send message entry-point.  Given a handle on Smalltalk Symbol nil and #findInterned: and a mapping from C strings to Smalltalk strings one can access any class or selector in the system.  e.g. to evaluate
    MyClass doSomething
you can say
    myClassName = vmSendMessage1(vmSymbolClass, vmFindInternedColonSelector, vmAsSmalltalkString("MyClass"));
    doSomethingSelector = vmSendMessage1(vmSymbolClass, vmFindInternedColonSelector, vmAsSmalltalkString("doSomethingSelector"));
    if (myClassName == vmNil || doSomethingSelector == vmNil) abort();
    atSelector = vmSendMessage1(vmSymbolClass, vmFindInternedColonSelector, vmAsSmalltalkString("at:"));
    myClass = vmSendMessage1(vmSmalltalk, atSelector, myClassName);
    vmSendMessage0(myClass, doSomethingSelector);
etc.

You can make things easier by providing a slightly broader interface (I included handles for at: and includesKey:) and by providing utility wrappers, e.g. lookupSelector or (as the VW interface already does) vmSendCMessage which looks like:

   myClassName = vmSendCMessage1(vmSymbolClass, "findInterned:", vmAsSmalltalkString("MyClass"));
    if (myClassName == vmNil) abort();
    myClass = vmSendCMessage1(vmSmalltalk, "at:", myClassName);
    vmSendCMessage0(myClass, "doSomething");

You can implement sendbacks above callbacks.  For callbacks look at the Alien code or Igor's recent code.

In the above in my VisualWors prototype the VM managed a handle table such that the handles handed out to C did not move and are looked up by the mapping machinery in the VM to map them to Smalltalk objects.  Much more convenient than addGCRoot: but slower.  The table was reference counted to manage lifetimes.  The handle of an immediate (Character or SmallInteger) was the immediate itself so only non-immediates actually appeared in the external oop table.

HTH
Eliot


Thanks for your valuable opinion.

Ang Beepeng
--
View this message in context: http://forum.world.st/Passing-value-to-external-program-tp2222974p2222974.html
Sent from the Squeak - Dev mailing list archive at Nabble.com.