To be more precise, for the method :

foo
        ^ 1 + 2

AST will be :
     ^
       \
        +
       /  \
      1   2

AST Interpreter, to interpret ^, will do something like :
start interpret ^
      interpret subnode of ^
      start interpret +
            interpret subnodes of +
                  interpret 1
                  interpret 2
            interpret + with subnodes interpretation result
      end interpret +
      interpret ^ with subnode interpretation result
end interpret ^

Igor would like to have a flatten AST that would be in an array like :
#( 1  2  +  ^ )
Then you can interpret it with a loop
[currentASTNode hasNextNode] whileTrue: [ self interpret: currentASTNode
nextNode ].
And interpretation looks like :
interpret 2
interpret 1
interpret + with two precedent results on stack
interpret ^ with precedent result on stack

2013/5/4 Clément Bera <bera.clem...@gmail.com>

> 2013/5/4 stephane ducasse <stephane.duca...@free.fr>
>
>>
>> On May 4, 2013, at 1:04 AM, Igor Stasenko <siguc...@gmail.com> wrote:
>>
>> > Did i said already that i don't like how ASTInterpreter implemented? :)
>>
>>
>> We will let perfection for later :)
>>
>
> It is not a question of perfection or so.
>
> Igor does not like that we interpret recursively the AST instead of with a
> loop (ASTInterpreter>>interpret: calls itself again and again). He would
> like to have a flatten-AST-interpreter, with a loop like:
>
> [currentASTNode hasNextNode] whileTrue: [ self interpret: currentASTNode
> nextNode ].
>
>  But Camillo and I don't want that because it interprets a flatten AST,
> not a tree.
>
>
>> >
>> > Nevertheless, it is useful.. and this case clearly demonstrates that.
>> >
>> > On 4 May 2013 00:14, Clara Allende <clari.alle...@gmail.com> wrote:
>> >> This is great news! Are you going to publish the code? it will come in
>> handy
>> >> for my summer of code :D
>> >>
>> >
>> > Camillo has the image
>> >
>> >>
>> >> On 3 May 2013 03:21, stephane ducasse <stephane.duca...@free.fr>
>> wrote:
>> >>>
>> >>>
>> >>>
>> >>> Begin forwarded message:
>> >>>
>> >>> From: Camillo Bruni <camillobr...@gmail.com>
>> >>> Subject: [Lsehub-staff] How to Debug :D
>> >>> Date: May 2, 2013 6:22:06 PM GMT+02:00
>> >>> To: RMoD private list <lsehub-st...@lists.gforge.inria.fr>
>> >>> Reply-To: RMoD private list <lsehub-st...@lists.gforge.inria.fr>
>> >>>
>> >>> Igor: Camillo can you help me debugging this strange athens rendering
>> bug
>> >>> Cami: sure
>> >>>
>> >>> Igor: where do you think the bug is? The green path jumps if I change
>> the
>> >>> Y coordinate and it shouldn't...
>> >>> Cami: no clue...
>> >>>
>> >>> Igor: Any clue how to get to the bug?
>> >>> Cami: let's use the ASTInterpreter to interpret two methods with
>> different
>> >>> transformation matrices and see when they diverge.
>> >>>
>> >>> Result:
>> >>> -------
>> >>> - after 1h comparing AST Debugger is ready
>> >>> - we run the two traces, they do NOT diverge => ????
>> >>>
>> >>> Conclusion:
>> >>> -----------
>> >>> Cairo, which was chosen as reference, did not properly draw the
>> path!!!
>> >>>
>> >>> So we should publish the code of the ComparingInterpreter a bit and we
>> >>> can use it for a few more tasks in Pharo ;)
>> >>>
>> >>>
>> >>>
>> >>
>> >
>> >
>> >
>> > --
>> > Best regards,
>> > Igor Stasenko.
>> >
>>
>>
>>
>
>


-- 
Clément Béra
Mate Virtual Machine Engineer
Bâtiment B 40, avenue Halley 59650 *Villeneuve d'Ascq*

Reply via email to