Compiler+Decompiler together have a serious 'bad case' bug

Marcus Denker denker at iam.unibe.ch
Mon Jul 24 07:36:14 UTC 2006


On 23.07.2006, at 23:06, Klaus D. Witzel wrote:

> On Sun, 23 Jul 2006 16:52:01 +0200, Marcus Denker  
> <denker at iam.unibe.ch> wrote:
>> On 23.07.2006, at 16:31, Bert Freudenberg wrote:
>>> Am 22.07.2006 um 23:42 schrieb Klaus D. Witzel:
>>>
>>>> Strange, why should Decompiler be involved in a halt situation
>>>
>>> I guess because there is no method source if you evaluate the code
>>> in a workspace.
>
> Good guess but I found the error in a regular .changes file source  
> coded method.
>
>> Printing of blocks for the stack-trace shown in the pre-debug window
>> nees the
>> decompiler...
>
> Strange, all source code is available.

Yes... the block-printing uses the decompiler right now, though...  
but thinking
about it, it should be possible to use the bc->text mapping (of the  
encoder)
to do the printing without decompiling... so printOn: would do
	1) compile the method that the block is in to get the MethodNode.
	2) get startPC / endPC of the blocks bytecode
	3) the MethodNode then has the bc-to-text mapping (MethodNode  
encoder, I think)
              that should return the start / end in the text of the  
method when giving it the bytecode interval
	4) print that text in printOn:

Anyone care to try to implement that?

      Marcus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3938 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20060724/9cb84c74/smime.bin


More information about the Squeak-dev mailing list