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
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 -
On 06/02/2008, Bert Freudenberg bert@freudenbergs.de 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.
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?
eliot.miranda@gmail.com 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@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
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
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@rowledge.org; http://www.rowledge.org/tim Useful random insult:- A one-bit brain with a parity error.
vm-dev@lists.squeakfoundation.org
-
Andreas Raab -
Bert Freudenberg -
Igor Stasenko -
John M McIntosh -
Robert Krahn -
tim Rowledge