[squeak-dev] Re: Bug with valueWithReceiver:arguments:

Klaus D. Witzel klaus.witzel at cobss.com
Sun Nov 23 18:39:24 UTC 2008


On Sun, 23 Nov 2008 17:51:42 +0100, Antoine Marot wrote:

>>> Does anyone know approximately when this fix should be added to an  
>>> official release ? This bug seriously makes it hard for me to share my  
>>> code...

Further to the below I checked http://bugs.squeak.org and there was not  
report? I think you (or Frederic) have to report the bug before it  
officially is one ...

>> I understand that what you need is "... method  
>> valueWithReceiver:arguments: is used hugely with method wrappers" and  
>> you need it without VM bug when a primitive fails.
>>
>> Perhaps a stupid question (I don't know any other your requirements)  
>> but instead of wrapping methods one could easily #perform: a selector  
>> on the receiver. What would be the reason that you depend on  
>> #valueWithReceiver:arguments: ? it cannot be performance since  
>> #perform: needs some time as well.
>>
>> /Klaus
>
> The goal of my wrappers is to choose (depending on the context) between  
> the original method and an instrumented one.
>
> The calling code is similar to this :
>
> receiver
> 	withArgs: args
> 	executeMethod:
> 		(context-condition
> 			ifTrue: [transformedMethod]
> 			ifFalse: [originalMethod] )
>
> Note that I don't use #valueWithReceiver:, but the bug also appears with  
> that method.
>
> Since #perform: goes through the method lookup process, it will loop  
> unless I use two new selectors. This solution has several disadvantages  
> like implying a second lookup process or not being invisible (the new  
> method dictionary entries appear in browsers and are editable which is  
> problematic).

Okay, understood (I think so ;) Perhaps there is a workaround (namely: the  
Smalltalk simulator) for Squeak, which you can give a try:

The debugger apparently knows how to perform a primitive by number, look  
at #tryPrimitive:withArgs: its implementor and sender.

If you do that and it returns (ContextPart primitiveFailToken) then do the  
"primitiveFailed" part, using #withArgs:executeMethod: as above *but* on a  
*clone* of the originalMethod into which you put primitive number 0  
(repeat: the clone!).

HTH.

/Klaus

>
> Antoine
>

-- 
"If at first, the idea is not absurd, then there is no hope for it".  
Albert Einstein




More information about the Squeak-dev mailing list