Klaus D. Witzel a écrit :
> Hi Mathieu,
> 
> on Mon, 09 Oct 2006 12:43:58 +0200, you wrote:
>> Klaus D. Witzel a écrit :
>>> On Sun, 08 Oct 2006 13:59:05 +0200, stephane ducasse wrote:
>>> ...
>>>> If people wants to help we need the decompiler also working well.
>>>
>>> Can I have a specification (sufficient, please) that describes what
>>> source construct emits what bytecode(s). I cannot promise that I will
>>> then be able to work on the decompiler but I promise to give it a try.
>>>
>>
>> Forgot to tell if you want to see exacly what happen
> 
> Yes I want to see, but must look into the opposite direction :| Let me
> ask further: which component of the framework (the slides in
> 11Bytecode.pdf are excellent, thank you!) is responsible for pretty
> print? The latter is what the browser usually requests from the decompiler.

Normaly it's RBFormatter who suppose to pretty print it(you can install other pretty printer like
gutenberg).
And the compilation stop at the AST representation so you don't need to compile it completly.

see: Compiler>>format:in:notifying:decorated:

You also have to understand the Visitor but this one it's a bit strange beceause when
visitMethodNode is expected you will see acceptMethodNode... (HTH)

	Math

> 
> /Klaus
> 
>> you can use #>> and see the bytecode
> 
> Yes, thank you :)
> 
>> Object>>#haltIf:
>>
>> ->
>> 45 <10> pushTemp: 0
>> 46 <D0> send: isSymbol
>> 47 <AC 17> jumpFalse: 72
>> 49 <89> pushThisContext:
>> 50 <69> popIntoTemp: 1
>> 51 <11> pushTemp: 1
>> 52 <D1> send: sender
>> 53 <D2> send: isNil
>> 54 <A8 0F> jumpTrue: 71
>> 56 <11> pushTemp: 1
>> 57 <D1> send: sender
>> 58 <81 41> storeIntoTemp: 1
>> 60 <D3> send: selector
>> 61 <10> pushTemp: 0
>> 62 <B6> send: =
>> ...
>>
>>>> Mathieu also worked on fixing the way comments are attached in the
>>>> tree (before this was kind of random).
>>>
>>> Can't wait to see this in action :)
>>>
>>> /Klaus
>>>
>>>> Stef
>>>
>>>
>>>
>>
>>
>>
> 
> 
> 
>