Method invocation in Slang

[Robert Krahn]

 
Hello!

Is there a way to invoke a "normal" method from an arbitrary object  
in Slang?

If I have an oop:

oop := interpreterProxy instantiateClass: MyClass indexableSize: 0.

Now I would like to send message #m1 to the object behind oop. Can  
the InterpreterProxy do that?

Robert

[Bert Freudenberg]

 

On Feb 6, 2008, at 12:02 , Robert Krahn wrote:

> Hello!
>
> Is there a way to invoke a "normal" method from an arbitrary object  
> in Slang?
>
> If I have an oop:
>
> oop := interpreterProxy instantiateClass: MyClass indexableSize: 0.
>
> Now I would like to send message #m1 to the object behind oop. Can  
> the InterpreterProxy do that?

No, the interpreter is not reentrant.

What are you actually trying to accomplish? Possibly Andreas'  
callback support is what you need.

- Bert -

[Igor Stasenko]

 
On 06/02/2008, Bert Freudenberg <bert@...> wrote:

>
>
> On Feb 6, 2008, at 12:02 , Robert Krahn wrote:
>
> > Hello!
> >
> > Is there a way to invoke a "normal" method from an arbitrary object
> > in Slang?
> >
> > If I have an oop:
> >
> > oop := interpreterProxy instantiateClass: MyClass indexableSize: 0.
> >
> > Now I would like to send message #m1 to the object behind oop. Can
> > the InterpreterProxy do that?
>
> No, the interpreter is not reentrant.
>
> What are you actually trying to accomplish? Possibly Andreas'
> callback support is what you need.
>
> - Bert -
>
>

Invoking methods of object is what actually VM created for.
I might suggest that you need to split primitive on two parts, and
place ST code in between, where you need send message to object.


--
Best regards,
Igor Stasenko AKA sig.

[Robert Krahn]

 
> What are you actually trying to accomplish? Possibly Andreas'  
> callback support is what you need.

We are actually trying to find an easy way to use callbacks. The  
method invocation would be triggered from outside the VM. But since  
the callbacks are probably synchronous we don't have to use callbacks  
into the VM at all. If that will not work, we will follow Andreas'  
proposal and use semaphores. One thing I am interested in concerning  
this is how are parameters normally passed to the callbacks when  
using semaphores? By manipulating the stack?

[John M McIntosh]

 
eliot.miranda@...
had sent a note out last Nov talking about work on FFI and callbacks,  
you might want to contact him for more information.


> Hi All,
>
> .....because I've just complete an initial prototype of a simple FFI  
> for x86 at Cadence.

> The system supports callbacks.  I believe it will be reasonably easy  
> to port across 32-bit processors.  ABI features such as the x86-64  
> ABI's splitting of structure contents across integer and floating-
> point registers is considerably more problematic.  But calls  
> involving integer data should port easily.
>
> Since call-outs use alloca the FFI is considerably simpler than  
> Andreas's, and hence slightly faster.  The use of alloca is feasible  
> on RISC processors also, this based on my experience with  
> VisualWorks.  I can provide a porting guide if you're interested in  
> taking this further.
>
> The current system is implemented as a plugin supported by four new  
> functions on Interpreter all of which support callbacks (these are  
> variants of internalActivateNewMethod and lookupMethodInClass and a  
> couple of methods for creating the activation of a send and  
> reestablishing the callout context on returning from a callback).

On Feb 6, 2008, at 9:26 AM, Robert Krahn wrote:

>> What are you actually trying to accomplish? Possibly Andreas'  
>> callback support is what you need.
>
> We are actually trying to find an easy way to use callbacks. The  
> method invocation would be triggered from outside the VM. But since  
> the callbacks are probably synchronous we don't have to use  
> callbacks into the VM at all. If that will not work, we will follow  
> Andreas' proposal and use semaphores. One thing I am interested in  
> concerning this is how are parameters normally passed to the  
> callbacks when using semaphores? By manipulating the stack?

--
=
=
=
========================================================================
John M. McIntosh <johnmci@...>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
=
=
=
========================================================================

[Andreas Raab]

 
Robert Krahn wrote:

>
>> What are you actually trying to accomplish? Possibly Andreas' callback
>> support is what you need.
>
> We are actually trying to find an easy way to use callbacks. The method
> invocation would be triggered from outside the VM. But since the
> callbacks are probably synchronous we don't have to use callbacks into
> the VM at all. If that will not work, we will follow Andreas' proposal
> and use semaphores. One thing I am interested in concerning this is how
> are parameters normally passed to the callbacks when using semaphores?
> By manipulating the stack?

No, by writing primitives which pick them up. For exampe:

runCallbackProcess
        "Run the callback process"
        [true] whileTrue:[
                CallbackSema wait.
                [self handleCallback] ensure:[self callbackReturn].
        ].

handleCallback
        "Handle a callback from Python"
        | nArgs rcvr selector args result |
        nArgs := self callbackGetArgCount.
        nArgs < 2 ifTrue:[^nil].
        rcvr := self resolveReceiver: (self callbackGetArg: 1).
        selector := self callbackGetArg: 2.
        selector isString ifFalse:[^nil].
        args := (3 to: nArgs) collect:[:i| self callbackGetArg: i].
        "Transcript cr; show: selector; space; show: args."
        result := [rcvr pyCallback: selector asSymbol args: args] on: Error
do:[:ex|
                Transcript cr; show: ex description.
                Transcript cr; show: ex signalerContext longStack.
                ex return: nil.
        ].
        "Transcript show:' ==> '; show: result."
        self callbackResult: result.


callbackGetArgCount
        "Primitive. Answer the number of args for the current callback."
        <primitive: 'primitivePyCallbackGetArgCount' module: 'PyBridge'>
        ^self primitiveFailed

callbackGetArg: index
        "Primitive. Answer the n-th argument of the current callback"
        <primitive: 'primitivePyCallbackGetArg' module: 'PyBridge'>
        ^self primitiveFailed

callbackResult: result
        "Primitive. Set the return value from the callback."
        <primitive: 'primitivePyCallbackSetResult' module: 'PyBridge'>
        ^self primitiveFailed

callbackReturn
        "Primitive. Return from the callback."
        <primitive: 'primitivePyCallbackReturn' module: 'PyBridge'>
        ^self primitiveFailed

[tim Rowledge]

 
Do remember  that Slang is merely a pidjin that makes it relatively  
simple to write C code within Squeak in order that we can
a) simulate the vm to try out new ideas more easily and debug them  
within our favourite debugger
b) transliterate the code to (not terribly good) C code for compilation

If you write
> oop := interpreterProxy instantiateClass: MyClass indexableSize: 0.
oop fooble.

... then it will
a) in simulation it will do exactly what you might expect - send  
#fooble to oop. Since oop is probably an integer standing in as an  
object pointer (haven't done this in ages) you might be surprised at  
the result.
b) when transliterating it will convert the 'oop fooble' to 'sqInt  
fooble(sqInt oop);' - modulo the differences between declaration and  
call.

It doesn't do anything clever at all.

tim
--
tim Rowledge; tim@...; http://www.rowledge.org/tim
Useful random insult:- A one-bit brain with a parity error.