On 30.03.2011, at 20:18, Mariano Martinez Peck wrote:

On Wed, Mar 30, 2011 at 3:36 PM, Levente Uzonyi leves@elte.hu wrote:

On Wed, 30 Mar 2011, Mariano Martinez Peck wrote:

(no quote :))

See this example:

'foobar' withArgs: #(65) executeMethod: ByteArray >> #atAllPut:

Sorry, I didn't understand. What is 65 and what is 'foobar' ?

ASCII for $A and a ByteString, respectively.

- Bert -

On Wed, Mar 30, 2011 at 8:55 PM, Levente Uzonyi leves@elte.hu wrote:

On Wed, 30 Mar 2011, Mariano Martinez Peck wrote:

(no quotes)

It's pure smalltalk code. 'foobar' is a ByteString and it will execute a

method of ByteArray. The method is called #atAllPut: and it will be evaluated with the argument 65.

Sorry for the late answer. I think you didn't understand what I asked or I didn't understand your answer.

In that example, you are SENDING the message withArgs:executeMethod: to the receiver.

What I need is this...imagine I have Message instance, and I need to do a #sendTo: but WITHOUT using the receiver but instead sending it by parameter. I cannot do: aMessage sendTo: aReceiver because

sendTo: receiver "answer the result of sending this message to receiver"

^ receiver perform: selector withArguments: args

So...as you can see, #sendTo sends a message to the receiver, which I cannot. Instead of delegating to the receiver, I need someting like this:

CompiledMethod >> valueWithReceiver: aReceiver arguments: anArray "Execute compiledMethod against the receiver and args in argArray. The receiver is the CompiledMethod"

<primitive: 666> self primitiveFailed

Where the primitive is send directly, and not a message to the receiver.

Is something like this available or I would need to create a new primitive?

Thanks in advance,

I cannot believe it but it seems to work. I would really appreaciate if someone can take a look, and consider to integrate it. Having no way to execute a method on a receveir WITHOUT sending a message to the object, is really a problem. I am implementing proxies, which understand NOTHING (their class has method dictionary in nil and I use the cannotInterpret trick) and so I CANNOT send a message because I will be in loop. I have a similar problem with primitiveChangeClassTo: but fortunately, Eliot did #adoptInstance: which receiver is the class and not the object.

Anyway, this is the method

CompiledMethod >> executeWithReceiver: aReceiver arguments: anArray "Execute the compiledMethod against the aReceiver and args in argArray."

<primitive: 190> self primitiveFailed

And this is the primitive.

StackInterpreterPrimitives >> primitiveExecuteWithReceiverArguments "method, recevier, and the array of arguments are on top of stack. Execute method against receiver and args. Set primitiveFunctionPointer because no cache lookup has been done for the method, and hence primitiveFunctionPointer is stale." | receiverMethod argCnt argumentArray primitiveIndex receiverObject | receiverMethod := self stackValue: 2. receiverObject := self stackValue: 1. argumentArray := self stackTop. ((objectMemory isOopCompiledMethod: receiverMethod) and: [objectMemory isArray: argumentArray]) ifFalse: [^self primitiveFailFor: PrimErrBadArgument]. argCnt := self argumentCountOf: receiverMethod. argCnt = (objectMemory fetchWordLengthOf: argumentArray) ifFalse: [^self primitiveFailFor: PrimErrBadNumArgs]. self pop: 3. self push: receiverObject. 0 to: argCnt - 1 do: [:i| self push: (objectMemory fetchPointer: i ofObject: argumentArray)]. newMethod := receiverMethod. primitiveIndex := self primitiveIndexOf: newMethod. primitiveFunctionPointer := self functionPointerFor: primitiveIndex inClass: nil. argumentCount := argCnt. "We set the messageSelector for executeMethod below since things like the at cache read messageSelector and so it cannot be left stale." messageSelector := objectMemory nilObject. self executeNewMethod. "Recursive xeq affects primErrorCode" self initPrimCall

Thanks for taking a look and hopefully integrate this or something better,

Mariano

On Wed, Apr 20, 2011 at 2:42 PM, Andreas Raab andreas.raab@gmx.de wrote:

On 4/20/2011 14:29, Mariano Martinez Peck wrote:

...

CompiledMethod >> valueWithReceiver: aReceiver arguments: anArray "Execute compiledMethod against the receiver and args in argArray. The receiver is the CompiledMethod"

<primitive: 666> self primitiveFailed

Where the primitive is send directly, and not a message to the receiver.

Is something like this available or I would need to create a new primitive?

Which by the way, is the primitive that should exist, and Object>>withArgs:executeMethod: should be nuked ASAP. There is no reason to pollute the Object namespace any more than absolutely necessary.

Cheers,

• Andreas

On Wed, Apr 20, 2011 at 4:08 PM, Henrik Sperre Johansen < henrik.s.johansen@veloxit.no> wrote:

On 20.04.2011 15:52, Mariano Martinez Peck wrote:

I cannot believe it but it seems to work. I would really appreaciate if someone can take a look, and consider to integrate it. Having no way to execute a method on a receveir WITHOUT sending a message to the object, is really a problem. I am implementing proxies, which understand NOTHING (their class has method dictionary in nil and I use the cannotInterpret trick) and so I CANNOT send a message because I will be in loop. I have a similar problem with primitiveChangeClassTo: but fortunately, Eliot did #adoptInstance: which receiver is the class and not the object.

Anyway, this is the method

CompiledMethod >> executeWithReceiver: aReceiver arguments: anArray "Execute the compiledMethod against the aReceiver and args in argArray."

<primitive: 190> self primitiveFailed

And this is the primitive.

StackInterpreterPrimitives >> primitiveExecuteWithReceiverArguments "method, recevier, and the array of arguments are on top of stack. Execute method against receiver and args. Set primitiveFunctionPointer because no cache lookup has been done for the method, and hence primitiveFunctionPointer is stale." | receiverMethod argCnt argumentArray primitiveIndex receiverObject | receiverMethod := self stackValue: 2. receiverObject := self stackValue: 1. argumentArray := self stackTop. ((objectMemory isOopCompiledMethod: receiverMethod) and: [objectMemory isArray: argumentArray]) ifFalse: [^self primitiveFailFor: PrimErrBadArgument]. argCnt := self argumentCountOf: receiverMethod. argCnt = (objectMemory fetchWordLengthOf: argumentArray) ifFalse: [^self primitiveFailFor: PrimErrBadNumArgs]. self pop: 3. self push: receiverObject. 0 to: argCnt - 1 do: [:i| self push: (objectMemory fetchPointer: i ofObject: argumentArray)]. newMethod := receiverMethod. primitiveIndex := self primitiveIndexOf: newMethod. primitiveFunctionPointer := self functionPointerFor: primitiveIndex inClass: nil. argumentCount := argCnt. "We set the messageSelector for executeMethod below since things like the at cache read messageSelector and so it cannot be left stale." messageSelector := objectMemory nilObject. self executeNewMethod. "Recursive xeq affects primErrorCode" self initPrimCall

Thanks for taking a look and hopefully integrate this or something better,

Mariano

Wouldn't you want to do a class check on the object vs installed class of the CompiledMethod as part of PrimErrBadArgument checks? Otherwise you'd probably end up insilly situations with CompiledMethods which accesses/stores to instvars :)

Sorry Henry, I couldn't follow you :( I based such implementation in this one: primitiveExecuteMethodArgsArray

primitiveExecuteMethodArgsArray "receiver, argsArray, then method are on top of stack. Execute method against receiver and args. Set primitiveFunctionPointer because no cache lookup has been done for the method, and hence primitiveFunctionPointer is stale." | methodArgument argCnt argumentArray primitiveIndex | methodArgument := self stackTop. argumentArray := self stackValue: 1. ((objectMemory isOopCompiledMethod: methodArgument) and: [objectMemory isArray: argumentArray]) ifFalse: [^self primitiveFailFor: PrimErrBadArgument]. argCnt := self argumentCountOf: methodArgument. argCnt = (objectMemory fetchWordLengthOf: argumentArray) ifFalse: [^self primitiveFailFor: PrimErrBadNumArgs]. self pop: 2. 0 to: argCnt - 1 do: [:i| self push: (objectMemory fetchPointer: i ofObject: argumentArray)]. newMethod := methodArgument. primitiveIndex := self primitiveIndexOf: newMethod. primitiveFunctionPointer := self functionPointerFor: primitiveIndex inClass: nil. argumentCount := argCnt. "We set the messageSelector for executeMethod below since things like the at cache read messageSelector and so it cannot be left stale." messageSelector := objectMemory nilObject. self executeNewMethod. "Recursive xeq affects primErrorCode" self initPrimCall

Thanks!

Cheers, Henry

On Tue, Apr 26, 2011 at 12:50 PM, Henrik Sperre Johansen < henrik.s.johansen@veloxit.no> wrote:

Say you have Class A: inst vars : one two three

and method compiled on it: foo ^one

Then you also have Class B: inst vars: three two one

Then you do methodFoo := A >> #foo methodFoo executeWithReceiver: B new one: 1; three: 3; yourself arguments: #()

It'll return 3, which'll probably confuse those not very familiar with the bytecodes.

Or using a class with no instvars, it'll crash in a similar manner to what you get if you currently do: Test methodDictionary at: #foo put: MCPackage >> #packageInfo. Test >> #foo. Test new foo

You see, now I got it :) I am just slow. Thanks Henrik for this example. In fact, it was not even obvious for me until you told me. The "problem" is that the bytecodes to access/set instanceVariables work by position instead of name, no? I mean, 'one' is never put in the literals of A >> #foo

Nevertheless, exactly the same happens with #valueWithReceiver:arguments: so...ok, we have this problem but we also have from before ;) right ?

solutions?

First I would put a nice comment in #valueWithReceiver:arguments: and #valueWithReceiver:arguments:

Second, if I understood you correctly you mean to do in your previous email, you want to validate that the class of the receiver is the same as the class where the CompiledMethod is installed and if it is not, throw an error ?

On the one hand that would limit a bit the usage because that fails only when there is instance var access, doesn't it? On the other hand, it prevents some crashes or weird cases where the results are not the expected ones.

Opinions?

-- View this message in context: http://forum.world.st/Method-executing-but-not-sent-to-the-receiver-tp341751... Sent from the Squeak VM mailing list archive at Nabble.com.

On 26.04.2011 16:31, Mariano Martinez Peck wrote:

On Tue, Apr 26, 2011 at 12:50 PM, Henrik Sperre Johansen <henrik.s.johansen@veloxit.no mailto:henrik.s.johansen@veloxit.no> wrote:

Say you have Class A:
inst vars : one two three

and method compiled on it:
foo
^one

Then you also have Class B:
inst vars: three two one

Then you do
methodFoo := A >> #foo
methodFoo executeWithReceiver: B new one: 1; three: 3; yourself
arguments:
#()

It'll return 3, which'll probably confuse those not very familiar
with the
bytecodes.

Or using a class with no instvars, it'll crash in a similar manner
to what
you get if you currently do:
Test methodDictionary at: #foo put: MCPackage >> #packageInfo.
Test >> #foo.
Test new foo

You see, now I got it :) I am just slow. Thanks Henrik for this example. In fact, it was not even obvious for me until you told me. The "problem" is that the bytecodes to access/set instanceVariables work by position instead of name, no? I mean, 'one' is never put in the literals of A >> #foo

yup, instvar access in byte codes is indexed.

Nevertheless, exactly the same happens with #valueWithReceiver:arguments: so...ok, we have this problem but we also have from before ;) right ?

Dunno, I only commented on the code you posted.

solutions?

First I would put a nice comment in #valueWithReceiver:arguments: and #valueWithReceiver:arguments:

Second, if I understood you correctly you mean to do in your previous email, you want to validate that the class of the receiver is the same as the class where the CompiledMethod is installed and if it is not, throw an error ?

On the one hand that would limit a bit the usage because that fails only when there is instance var access, doesn't it? On the other hand, it prevents some crashes or weird cases where the results are not the expected ones.

Opinions?

Not sure if the overhead of such a check would be worth it. The least restrictive to avoid outright crashing would probably be to check that instvar accessing bytescodes in the method did not exceed that of the receiver, but a class check would probably be simpler.

I'd be ok with just a good comment, one would expect users of this to sort of know what they are doing. On the other hand, you didn't realize it untill I pointed it out specifically ;)

If it should be allowed at all, as per Igor's post.

I love disagreeing with myself :D

Cheers, Henry

On Wed, 20 Apr 2011, Andreas Raab wrote:

On 4/20/2011 14:29, Mariano Martinez Peck wrote:

...

CompiledMethod >> valueWithReceiver: aReceiver arguments: anArray "Execute compiledMethod against the receiver and args in argArray. The receiver is the CompiledMethod"

<primitive: 666> self primitiveFailed

Where the primitive is send directly, and not a message to the receiver.

Is something like this available or I would need to create a new primitive?

Which by the way, is the primitive that should exist, and Object>>withArgs:executeMethod: should be nuked ASAP. There is no reason to pollute the Object namespace any more than absolutely necessary.

Right. AFAIK #withArgs:executeMethod: and friends were part of Marcus' closure implementation, so there's also no need for them anymore.

Levente

Cheers,

• Andreas

Hi Levente, Hi David,

On Tue, Jun 7, 2011 at 1:57 PM, Levente Uzonyi leves@elte.hu wrote:

On Wed, 20 Apr 2011, Andreas Raab wrote:

...

On 4/20/2011 14:29, Mariano Martinez Peck wrote:

...

CompiledMethod >> valueWithReceiver: aReceiver arguments: anArray "Execute compiledMethod against the receiver and args in argArray. The receiver is the CompiledMethod"

<primitive: 666> self primitiveFailed

Where the primitive is send directly, and not a message to the receiver.

Is something like this available or I would need to create a new primitive?

Which by the way, is the primitive that should exist, and Object>>withArgs:executeMethod: should be nuked ASAP. There is no reason to pollute the Object namespace any more than absolutely necessary.

The solution already exists in Cog: primitive 188 can accept a third argument - the receiver, but it doesn't work if the CompiledMethod is quick. In this case the VM crashes. It does work with "normal" methods.

I prepared an image with a workspace in it demonstrating the bug: http://leves.web.elte.hu/squeak/primitive188bug.zip

If primitive 188 works reliably, then this feature can be added to the interpreter VM too.

Levente, this is fixed in VMMaker.oscog-eem.75 & http://www.mirandabanda.org/files/Cog/VM/VM.r2394/. David, the VMMaker package contains a putative fix for Interpreter. Feel free to integrate it into the interpreter.

best, Eliot

Levente

...

Cheers,

• Andreas

On Tue, Jun 07, 2011 at 05:49:45PM -0700, Eliot Miranda wrote:

Hi Levente, Hi David,

On Tue, Jun 7, 2011 at 1:57 PM, Levente Uzonyi leves@elte.hu wrote:

...

On Wed, 20 Apr 2011, Andreas Raab wrote:

...

On 4/20/2011 14:29, Mariano Martinez Peck wrote:

...

CompiledMethod >> valueWithReceiver: aReceiver arguments: anArray "Execute compiledMethod against the receiver and args in argArray. The receiver is the CompiledMethod"

<primitive: 666> self primitiveFailed

Where the primitive is send directly, and not a message to the receiver.

Is something like this available or I would need to create a new primitive?

Which by the way, is the primitive that should exist, and Object>>withArgs:executeMethod: should be nuked ASAP. There is no reason to pollute the Object namespace any more than absolutely necessary.

The solution already exists in Cog: primitive 188 can accept a third argument - the receiver, but it doesn't work if the CompiledMethod is quick. In this case the VM crashes. It does work with "normal" methods.

I prepared an image with a workspace in it demonstrating the bug: http://leves.web.elte.hu/squeak/primitive188bug.zip

If primitive 188 works reliably, then this feature can be added to the interpreter VM too.

Levente, this is fixed in VMMaker.oscog-eem.75 & http://www.mirandabanda.org/files/Cog/VM/VM.r2394/. David, the VMMaker package contains a putative fix for Interpreter. Feel free to integrate it into the interpreter.

Thank you!

I am traveling and cannot look at it right now, but I'll add this to the interpreter VMMaker as soon as possible if someone else has not gotten to it sooner :)

Dave

On Thu, 9 Jun 2011, David T. Lewis wrote:

On Tue, Jun 07, 2011 at 05:49:45PM -0700, Eliot Miranda wrote:

...

Hi Levente, Hi David,

On Tue, Jun 7, 2011 at 1:57 PM, Levente Uzonyi leves@elte.hu wrote:

...

On Wed, 20 Apr 2011, Andreas Raab wrote:

...

On 4/20/2011 14:29, Mariano Martinez Peck wrote:

...

CompiledMethod >> valueWithReceiver: aReceiver arguments: anArray "Execute compiledMethod against the receiver and args in argArray. The receiver is the CompiledMethod"

<primitive: 666> self primitiveFailed

Where the primitive is send directly, and not a message to the receiver.

Is something like this available or I would need to create a new primitive?

Which by the way, is the primitive that should exist, and Object>>withArgs:executeMethod: should be nuked ASAP. There is no reason to pollute the Object namespace any more than absolutely necessary.

The solution already exists in Cog: primitive 188 can accept a third argument - the receiver, but it doesn't work if the CompiledMethod is quick. In this case the VM crashes. It does work with "normal" methods.

I prepared an image with a workspace in it demonstrating the bug: http://leves.web.elte.hu/squeak/primitive188bug.zip

If primitive 188 works reliably, then this feature can be added to the interpreter VM too.

Levente, this is fixed in VMMaker.oscog-eem.75 & http://www.mirandabanda.org/files/Cog/VM/VM.r2394/. David, the VMMaker package contains a putative fix for Interpreter. Feel free to integrate it into the interpreter.

Thanks Eliot,

The fix from VMMaker.oscog-eem.75 is included in VMMaker-dtl.240 (Minor note, oscog needs an implemention of #stackValue:put: for Interpreter also).

Levente, your test image (primitive188bug.zip) works now on the interpreter VM (workspace example evaluates without VM crash).

Great, thanks!

Levente

Dave