I understand why he wants that :) no stack explosion… Stef
On May 4, 2013, at 12:37 PM, Clément Bera <bera.clem...@gmail.com> wrote: > 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
