On Sun, 22 Jun 2008 18:17:45 +0200, Nicolas wrote:

> Klaus D. Witzel wrote:
>> On Sun, 22 Jun 2008 17:16:37 +0200, Nicolas wrote:
>>
>>> So what would you assert about longJumpIfFalseTest?
>>  ;)
>>
>>> We could assert that trying to compile such a method should raise an  
>>> Exception (let's say a ByteCodeLimitException).
>>  No, I wouldn't do that. I'd wrap the instance of CompiledMethod into  
>> an InstructionStream using temps | is msg | and check it on the meta  
>> level, without executing the method and without the possibility that  
>> this crashes the VM, like
>>   (msg := is nextInstruction) selector == #pushConstant: and: [msg  
>> arguments = #(true)].
>>  (msg := is nextInstruction) selector == #jump:if: and:  [msg arguments  
>> = #(offset false)]
>>  where offset is the one expected.
>>  /Klaus
>>
>
> Thanks, that's a nice alternative which is future proof toward Bytecode  
> definition change.
>
> However, i have two objections:
> 1) the test would still not pass if i install a handler that can  
> overcome ByteCodeLimitException

This your ififthenthenelseelse did not parse here :(

> 2) the test won't avoid para-phrasing ByteCodeGenerator job. Because you  
> need to calculate the offset...

You could use a computer, perhaps programmed in Smalltalk, for a loop  
which creates a CompiledMethod which is guaranteed to exhibit the desired  
offset? ;)

> In other words, I would always prefer higher level tests if possible  
> (like asserting the result of execution of ifTrue:ifFalse:).
>
> Nicolas
>