[Pharo-project] How to Debug :D
Begin forwarded message:
From: Camillo Bruni <camillobruni@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-staff@lists.gforge.inria.fr> Reply-To: RMoD private list <lsehub-staff@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 ;)
This is great news! Are you going to publish the code? it will come in handy for my summer of code :D On 3 May 2013 03:21, stephane ducasse <stephane.ducasse@free.fr> wrote:
Begin forwarded message:
*From: *Camillo Bruni <camillobruni@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-staff@lists.gforge.inria.fr> *Reply-To: *RMoD private list <lsehub-staff@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 ;)
Did i said already that i don't like how ASTInterpreter implemented? :) Nevertheless, it is useful.. and this case clearly demonstrates that. On 4 May 2013 00:14, Clara Allende <clari.allende@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.ducasse@free.fr> wrote:
Begin forwarded message:
From: Camillo Bruni <camillobruni@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-staff@lists.gforge.inria.fr> Reply-To: RMoD private list <lsehub-staff@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.
On May 4, 2013, at 1:04 AM, Igor Stasenko <siguctua@gmail.com> wrote:
Did i said already that i don't like how ASTInterpreter implemented? :)
We will let perfection for later :)
Nevertheless, it is useful.. and this case clearly demonstrates that.
On 4 May 2013 00:14, Clara Allende <clari.allende@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.ducasse@free.fr> wrote:
Begin forwarded message:
From: Camillo Bruni <camillobruni@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-staff@lists.gforge.inria.fr> Reply-To: RMoD private list <lsehub-staff@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.
2013/5/4 stephane ducasse <stephane.ducasse@free.fr>
On May 4, 2013, at 1:04 AM, Igor Stasenko <siguctua@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.allende@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.ducasse@free.fr> wrote:
Begin forwarded message:
From: Camillo Bruni <camillobruni@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-staff@lists.gforge.inria.fr> Reply-To: RMoD private list <lsehub-staff@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*
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.clement@gmail.com>
2013/5/4 stephane ducasse <stephane.ducasse@free.fr>
On May 4, 2013, at 1:04 AM, Igor Stasenko <siguctua@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.allende@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.ducasse@free.fr>
wrote:
Begin forwarded message:
From: Camillo Bruni <camillobruni@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-staff@lists.gforge.inria.fr> Reply-To: RMoD private list <lsehub-staff@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*
I understand why he wants that :) no stack explosion⦠Stef On May 4, 2013, at 12:37 PM, Clément Bera <bera.clement@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.clement@gmail.com> 2013/5/4 stephane ducasse <stephane.ducasse@free.fr>
On May 4, 2013, at 1:04 AM, Igor Stasenko <siguctua@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.allende@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.ducasse@free.fr> wrote:
Begin forwarded message:
From: Camillo Bruni <camillobruni@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-staff@lists.gforge.inria.fr> Reply-To: RMoD private list <lsehub-staff@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
So use a trampoline. Then you can define your recursion naturally, in constant stack space. frank On 04 May 2013, at 16:08, stephane ducasse <stephane.ducasse@free.fr> wrote:
I understand why he wants that :) no stack explosionâ¦
Stef
On May 4, 2013, at 12:37 PM, Clément Bera <bera.clement@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.clement@gmail.com> 2013/5/4 stephane ducasse <stephane.ducasse@free.fr>
On May 4, 2013, at 1:04 AM, Igor Stasenko <siguctua@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.allende@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.ducasse@free.fr> wrote:
Begin forwarded message:
From: Camillo Bruni <camillobruni@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-staff@lists.gforge.inria.fr> Reply-To: RMoD private list <lsehub-staff@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
can you explain? Because I read something like that olong time ago and I forgot On May 4, 2013, at 5:41 PM, Frank Shearar <frank.shearar@gmail.com> wrote:
So use a trampoline. Then you can define your recursion naturally, in constant stack space.
frank
On 04 May 2013, at 16:08, stephane ducasse <stephane.ducasse@free.fr> wrote:
I understand why he wants that :) no stack explosionâ¦
Stef
On May 4, 2013, at 12:37 PM, Clément Bera <bera.clement@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.clement@gmail.com> 2013/5/4 stephane ducasse <stephane.ducasse@free.fr>
On May 4, 2013, at 1:04 AM, Igor Stasenko <siguctua@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.allende@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.ducasse@free.fr> wrote:
Begin forwarded message:
From: Camillo Bruni <camillobruni@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-staff@lists.gforge.inria.fr> Reply-To: RMoD private list <lsehub-staff@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
A trampoline looks like this: Foo >> trampoline: initialValue into: aUnaryBlock | v | v := [initialValue]. [v isBlock] whileTrue: [v := aUnaryBlock value: v value]. ^ v. and then used: | f factorial | factorial := 1. f := Foo new. f trampoline: 10 into: [ :n | n <= 0 ifTrue: [factorial] ifFalse: [factorial := factorial * n. [n - 1]]]. The important thing is that the block returns a value for the base case/cases of the recursion, and a block that, when evaluated, will yield the next value on which to recurse. (So the block replaces the recursive call.) The trampoline thus turns the recursive algorithm into an iteration. frank On 4 May 2013 17:42, stephane ducasse <stephane.ducasse@free.fr> wrote:
can you explain? Because I read something like that olong time ago and I forgot
On May 4, 2013, at 5:41 PM, Frank Shearar <frank.shearar@gmail.com> wrote:
So use a trampoline. Then you can define your recursion naturally, in constant stack space.
frank
On 04 May 2013, at 16:08, stephane ducasse <stephane.ducasse@free.fr> wrote:
I understand why he wants that :) no stack explosionâ¦
Stef
On May 4, 2013, at 12:37 PM, Clément Bera <bera.clement@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.clement@gmail.com>
2013/5/4 stephane ducasse <stephane.ducasse@free.fr>
On May 4, 2013, at 1:04 AM, Igor Stasenko <siguctua@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.allende@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.ducasse@free.fr> wrote:
Begin forwarded message:
From: Camillo Bruni <camillobruni@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-staff@lists.gforge.inria.fr> Reply-To: RMoD private list <lsehub-staff@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
Thanks. This is CSP passing style? I thought it was different. Now going to eat and after I will digest that. Thanks for the snippet. Stef
A trampoline looks like this:
Foo >> trampoline: initialValue into: aUnaryBlock | v | v := [initialValue]. [v isBlock] whileTrue: [v := aUnaryBlock value: v value]. ^ v.
and then used:
| f factorial | factorial := 1. f := Foo new. f trampoline: 10 into: [ :n | n <= 0 ifTrue: [factorial] ifFalse: [factorial := factorial * n. [n - 1]]].
The important thing is that the block returns a value for the base case/cases of the recursion, and a block that, when evaluated, will yield the next value on which to recurse. (So the block replaces the recursive call.)
The trampoline thus turns the recursive algorithm into an iteration.
frank
On 4 May 2013 17:42, stephane ducasse <stephane.ducasse@free.fr> wrote:
can you explain? Because I read something like that olong time ago and I forgot
On May 4, 2013, at 5:41 PM, Frank Shearar <frank.shearar@gmail.com> wrote:
So use a trampoline. Then you can define your recursion naturally, in constant stack space.
frank
On 04 May 2013, at 16:08, stephane ducasse <stephane.ducasse@free.fr> wrote:
I understand why he wants that :) no stack explosionâ¦
Stef
On May 4, 2013, at 12:37 PM, Clément Bera <bera.clement@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.clement@gmail.com>
2013/5/4 stephane ducasse <stephane.ducasse@free.fr>
On May 4, 2013, at 1:04 AM, Igor Stasenko <siguctua@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.allende@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.ducasse@free.fr> wrote:
Begin forwarded message:
From: Camillo Bruni <camillobruni@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-staff@lists.gforge.inria.fr> Reply-To: RMoD private list <lsehub-staff@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
It's not CPS, but it is a bit like a hand-rolled limited tail call elimination. frank On 4 May 2013 19:02, stephane ducasse <stephane.ducasse@free.fr> wrote:
Thanks. This is CSP passing style? I thought it was different. Now going to eat and after I will digest that. Thanks for the snippet.
Stef
A trampoline looks like this:
Foo >> trampoline: initialValue into: aUnaryBlock | v | v := [initialValue]. [v isBlock] whileTrue: [v := aUnaryBlock value: v value]. ^ v.
and then used:
| f factorial | factorial := 1. f := Foo new. f trampoline: 10 into: [ :n | n <= 0 ifTrue: [factorial] ifFalse: [factorial := factorial * n. [n - 1]]].
The important thing is that the block returns a value for the base case/cases of the recursion, and a block that, when evaluated, will yield the next value on which to recurse. (So the block replaces the recursive call.)
The trampoline thus turns the recursive algorithm into an iteration.
frank
On 4 May 2013 17:42, stephane ducasse <stephane.ducasse@free.fr> wrote:
can you explain? Because I read something like that olong time ago and I forgot
On May 4, 2013, at 5:41 PM, Frank Shearar <frank.shearar@gmail.com> wrote:
So use a trampoline. Then you can define your recursion naturally, in constant stack space.
frank
On 04 May 2013, at 16:08, stephane ducasse <stephane.ducasse@free.fr> wrote:
I understand why he wants that :) no stack explosionâ¦
Stef
On May 4, 2013, at 12:37 PM, Clément Bera <bera.clement@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.clement@gmail.com>
2013/5/4 stephane ducasse <stephane.ducasse@free.fr>
On May 4, 2013, at 1:04 AM, Igor Stasenko <siguctua@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.allende@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.ducasse@free.fr> wrote:
Begin forwarded message:
From: Camillo Bruni <camillobruni@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-staff@lists.gforge.inria.fr> Reply-To: RMoD private list <lsehub-staff@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
On 4 May 2013 12:21, Clément Bera <bera.clement@gmail.com> wrote:
2013/5/4 stephane ducasse <stephane.ducasse@free.fr>
On May 4, 2013, at 1:04 AM, Igor Stasenko <siguctua@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 ].
more precisely , something like: | node | node := self initialASTNode. [node notNil ] whileTrue: [ node := self interpretSingleASTNode: node ].
But Camillo and I don't want that because it interprets a flatten AST, not a tree.
Clement, it is not a question of "liking", it is question of how far you can go with it. With current implementation, if you try to interpret 10000 factorial, you will crash the image with stack overflow. And it is not about flattening a tree. Your input is always tree. The only difference is how you walk over it, and what (or how many) state you should keep while doing so. But please, do not take me wrong: having AST Interpreter even in current state is a big progress. -- Best regards, Igor Stasenko.
On 2013-05-04, at 00:14, Clara Allende <clari.allende@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
sure I'll have to polish it a bit then I can put it into the ast interpreter repository.
On 3 May 2013 03:21, stephane ducasse <stephane.ducasse@free.fr> wrote:
Begin forwarded message:
*From: *Camillo Bruni <camillobruni@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-staff@lists.gforge.inria.fr> *Reply-To: *RMoD private list <lsehub-staff@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 ;)
participants (6)
-
Camillo Bruni -
Clara Allende -
Clément Bera -
Frank Shearar -
Igor Stasenko -
stephane ducasse