Dan, and all squeakers

>However, execute...
>	3 perform: #zork: with: 4
>and look at the debugger state.  The message is fairly nicely packaged up
>...snip...
when #zork: is sent to 3; the VM build aMessage (a Message with selector: zork:
  and arguments: (4 )) as a side effect for handling the 
#doesNotUnderstand: exeption.
Then the debugger can show the message (and the receiver handle the exeption
  because this message has been created by the VM);
  but the #perform: does not generates message nor context.
Please note that if you evaluate "3 perform: #zork: with: 4" in a workspace
  you will see the UndefinedObject>>Doit method
  and the SmallInteger(Object)>>doesNotUnderstand: method;
  but the SmallInteger(Object)>>perform: method will be absent!.
The debugger show you the #perform: because he has the message
  built by the VM to handle the #doesNotUnderstand:.

In my problem the message is always implemented in the receiver using
  a litte method that connect to the server and download the real method
  only when needed; then the message does not fail (with #doesNotUnderstand:).

Attached to this mail you will find a little example to see the
  problem I'm trying to solve (in a non-dirty way).
Please fileIn this change set and evaluate the expression:
	SwapperTest new test
The test will fail when a #perform: message is sent.
WARNING: do NOT save your image and reload the changeset
  prior to testing again.

Ale.


----------
De:     	Dan Ingalls[SMTP:DanI at wdi.disney.com]
Enviado: 	Martes 25 de Agosto de 1998 09:58
Para:   	Alejandro F. Reimondo
Cc: 	squeak at cs.uiuc.edu
Asunto:     	Re: RV: "thisContext selector" (the revenge)

Ale -

I'm on the road and can't send a careful answer until later. 
However, execute...

	3 perform: #zork: with: 4

and look at the debugger state.  The message is fairly nicely 
packaged up and will even proceed properly if you define zork: before 
proceeding.  So I would spend a while looking at what the debugger 
does.  It should ultimately answer your need.

	- Dan

>what happens when you send a #perform: message?
>It is solved in a primitive method that sends the message inside the VM;
>  activating a new method context to solve the performed message.
>Then, when I look for the sent message in the context, the message found
>  is #perform:... and the activated method is NOT the #perform implementation
>Ouch!
>The #perform: implementation does not create a MethodContext because
>  it is a primitive method!
>mmm...
>When I search in the contexts (actual and the sender's context)
>I can find the #perform: selector, but the arguments are missing
>( has been absorbed by primitive)
>Provably the problem will be difficult to solve with the contexts 
>information only...
>
>Is there any known (easy) way to solve the #perform: problem?
>
>thanks.
>Ale.





Attachment converted: Cog:SwapOut.zip (pZIP/pZIP) (0000E167)