Smalltalk › Squeak › Squeak VM

Method executing but not sent to the receiver

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

18 messages Options

Mariano Martinez Peck

Method executing but not sent to the receiver

Hi folks. I need to be able to execute a method with an object but not sending a message to that object. So for example, I've checked Message>>sendTo:   or CompiledMethod>>valueWithReceiver:arguments:
and both of them are finally sent to the receiver. I need to do something like: (MyClass >>#foo) valueWith: anObject args: args.
but I don't want that the primitive is sent to anObject.

I would like to be able to send such message to the compiled method, and being the receiver. For example, something 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

Do you think this is doable ? If true, can you give me any hint ?

I took a look to #primitiveExecuteMethod but I cannot figure out how to adapt it.

Thanks in advance,

Mariano

Mariano Martinez Peck

Re: Method executing but not sent to the receiver

On Wed, Mar 30, 2011 at 8:55 PM, Levente Uzonyi <[hidden email]> 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,

--
Mariano
http://marianopeck.wordpress.com

Andreas.Raab

Re: Method executing but not sent to the receiver

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

Mariano Martinez Peck

Re: Method executing but not sent to the receiver

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 <[hidden email]> 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

--
Mariano
http://marianopeck.wordpress.com

Henrik Sperre Johansen

Re: Method executing but not sent to the receiver

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

Cheers,
Henry

Mariano Martinez Peck

Re: Method executing but not sent to the receiver

On Wed, Apr 20, 2011 at 4:08 PM, Henrik Sperre Johansen <[hidden email]> 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

--
Mariano
http://marianopeck.wordpress.com

Levente Uzonyi-2

Re: Method executing but not sent to the receiver

In reply to this post by Andreas.Raab

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

Henrik Sperre Johansen

Re: Method executing but not sent to the receiver

In reply to this post by Mariano Martinez Peck

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

Mariano Martinez Peck

Re: Method executing but not sent to the receiver

On Tue, Apr 26, 2011 at 12:50 PM, Henrik Sperre Johansen <[hidden email]> 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-tp3417511p3475162.html
Sent from the Squeak VM mailing list archive at Nabble.com.

--
Mariano
http://marianopeck.wordpress.com

Igor Stasenko

Re: Method executing but not sent to the receiver

On 26 April 2011 16:31, Mariano Martinez Peck <[hidden email]> wrote:

>
>
>
> On Tue, Apr 26, 2011 at 12:50 PM, Henrik Sperre Johansen <[hidden email]> 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?
>

I have one for you:
- eliminate this bogus and unsafe primitive from VM.

I don't really understood why you need this primitive, but as to me it
is an awful hack and can compromise the system safety easily.
You can break encapsulation, expose unwanted state with given
primitive and so-on so-on.
So, instead of fixing it , my proposal is to remove it completely.
Or provide a really strong arguments why such behavior should exist in VM?

> 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-tp3417511p3475162.html
>> Sent from the Squeak VM mailing list archive at Nabble.com.
>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>
>
>

--
Best regards,
Igor Stasenko AKA sig.

Henrik Sperre Johansen

Re: Method executing but not sent to the receiver

In reply to this post by Mariano Martinez Peck

On 26.04.2011 16:31, Mariano Martinez Peck wrote:

 
On Tue, Apr 26, 2011 at 12:50 PM, Henrik Sperre Johansen <[hidden email]> 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

Igor Stasenko

Re: Method executing but not sent to the receiver

On 26 April 2011 18:18, Henrik Sperre Johansen
<[hidden email]> wrote:

>
> On 26.04.2011 16:31, Mariano Martinez Peck wrote:
>
>
>
>
>
> On Tue, Apr 26, 2011 at 12:50 PM, Henrik Sperre Johansen <[hidden email]> 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.
>

For good or bad, but all methods in system are bound to specific class.
After installing a method to class, they can be executed only for
(sub)instances of that class.
For rest of the cases we have closures, which can be evaluated at any
point , based on whatever criteria you may need.

I think that most of the tools will be seriously confused when they
will find out some context which has a method
which are not belong to one of the (super)class of receiver. This is
on top of security issues , which you have to deal with,
when using such primitive.

> I love disagreeing with myself :D
>
> Cheers,
> Henry
>

--
Best regards,
Igor Stasenko AKA sig.

Levente Uzonyi-2

Re: Method executing but not sent to the receiver

In reply to this post by Andreas.Raab

On Wed, 20 Apr 2011, Andreas Raab wrote:

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

>
> Cheers,
> - Andreas
>
>

Eliot Miranda-2

Re: Method executing but not sent to the receiver

Hi Levente, Hi David,

On Tue, Jun 7, 2011 at 1:57 PM, Levente Uzonyi <[hidden email]> 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

Levente Uzonyi-2

Re: Method executing but not sent to the receiver

On Tue, 7 Jun 2011, Eliot Miranda wrote:

> Hi Levente, Hi David,
>
> On Tue, Jun 7, 2011 at 1:57 PM, Levente Uzonyi <[hidden email]> 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

Great, thanks!

Levente

> package contains a putative fix for Interpreter. Feel free to integrate it
> into the interpreter.
>
> best,
> Eliot
>
>
>>
>> Levente
>>
>>
>>> Cheers,
>>> - Andreas
>>>
>>>
>>>
>

David T. Lewis

Re: Method executing but not sent to the receiver

In reply to this post by Eliot Miranda-2

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 <[hidden email]> 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

David T. Lewis

Re: Method executing but not sent to the receiver

In reply to this post by Eliot Miranda-2

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

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

Dave

Levente Uzonyi-2

Re: Method executing but not sent to the receiver

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 <[hidden email]> 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
>
>