Right now, in the image there exist two ways to annotate an AST: - the Opal way - the RB Way We should simplify that by having only one. So far, the only user of the RB bindings is the ASTInterpreter + the RB tests. So, I prepared a slice and issue [1], with the following details - annotate ast using opal annotator - extended OCBindings to read and write from an AST interpreter - not yet made a difference between arg nodes with a different class (just put an if) - i didnt add inst vars into the opal bindings for the binding->node relation as in RB, I send the node as a parameter - I had to adapt the #compile: into ASTInterpreter because - opal does not annotate other than method nodes - undeclared variables raised warnings, not errors There is one problem yet, I have only one failing test: #testEnsureTricky. I don't understand yet why it is failing and debugging it is pretty complex :). So any help is welcome in reviewing the changes. Guille [1] https://pharo.fogbugz.com/f/cases/10610/Make-ASTInterpreter-use-OC-Opal-bind...
Hey Guille, To debug AST-interpreter there is a specific AIContextInspector. What you can do is just to inspect in the debugger the latest AIContext created by the AST-interpreter and you should see the stack of AIContext in the inspector. It is not perfect but it helps a lot. There is also the AST-Debugger but it is just a prototype so you can hardly use it. testEnsureTricky is the one that checks ensure nested in the on:do: works correctly. Basically it checks when you unwind the context up to the exception handler that you executes the ensure blocks code. It's kind of the trickiest one to fix :/. In the exception chapter of Deep into Pharo I added a section somewhere in Exception implementation about that, it might help you to read it. Take care, AST-interpreter tests might not be enough. You should check the console output of the AST-interpreter-regression build too. (here : https://ci.inria.fr/rmod/job/ast-interpreter-regression/89/console) But it is failing since some new updates in Pharo 3.0 ... Are you committing on the AST-interpreter repository or on Pharo directly ? I don't think there are but there might be some fixes already on the dev branch > Smalltalkhub user: dh83 project: ast-interpreter I would like to work on Opal test this afternoon but if you come to lille this week (not today because there is the strike) we can have a look together. For M4te I've also fixed some stuff in Hz on the m4te repo (basically compatibility with the new RB visitor API) it might be nice to commit it on your repo too. See you, 2013/5/14 Guillermo Polito <guillermopolito@gmail.com>
Right now, in the image there exist two ways to annotate an AST: - the Opal way - the RB Way
We should simplify that by having only one. So far, the only user of the RB bindings is the ASTInterpreter + the RB tests.
So, I prepared a slice and issue [1], with the following details
- annotate ast using opal annotator - extended OCBindings to read and write from an AST interpreter - not yet made a difference between arg nodes with a different class (just put an if) - i didnt add inst vars into the opal bindings for the binding->node relation as in RB, I send the node as a parameter - I had to adapt the #compile: into ASTInterpreter because - opal does not annotate other than method nodes - undeclared variables raised warnings, not errors
There is one problem yet, I have only one failing test: #testEnsureTricky. I don't understand yet why it is failing and debugging it is pretty complex :). So any help is welcome in reviewing the changes.
Guille
[1] https://pharo.fogbugz.com/f/cases/10610/Make-ASTInterpreter-use-OC-Opal-bind...
-- Clément Béra Mate Virtual Machine Engineer Bâtiment B 40, avenue Halley 59650 *Villeneuve d'Ascq*
On Tue, May 14, 2013 at 1:03 PM, Clément Bera <bera.clement@gmail.com>wrote:
Hey Guille,
To debug AST-interpreter there is a specific AIContextInspector. What you can do is just to inspect in the debugger the latest AIContext created by the AST-interpreter and you should see the stack of AIContext in the inspector. It is not perfect but it helps a lot. There is also the AST-Debugger but it is just a prototype so you can hardly use it.
Buu, how do I get the ASTDebugger? Maybe I can give it a try...
testEnsureTricky is the one that checks ensure nested in the on:do: works correctly. Basically it checks when you unwind the context up to the exception handler that you executes the ensure blocks code. It's kind of the trickiest one to fix :/. In the exception chapter of Deep into Pharo I added a section somewhere in Exception implementation about that, it might help you to read it.
Take care, AST-interpreter tests might not be enough. You should check the console output of the AST-interpreter-regression build too. (here : https://ci.inria.fr/rmod/job/ast-interpreter-regression/89/console) But it is failing since some new updates in Pharo 3.0 ...
I'm looking at https://ci.inria.fr/rmod/job/ast-interpreter-regression/. What does this job test/do? We can add that to the description :) Anyway, I'm loading the same as the job, so I can test the slice locally in my machine :)
Are you committing on the AST-interpreter repository or on Pharo directly ?
Pharo... Should I commit to the other repo? Don't have grants =^).
I don't think there are but there might be some fixes already on the dev branch > Smalltalkhub user: dh83 project: ast-interpreter
Will check. Actually, I just loaded bleeding edge + merged my slice, and the same test still fails.
I would like to work on Opal test this afternoon but if you come to lille this week (not today because there is the strike) we can have a look together.
Tomorrow!
For M4te I've also fixed some stuff in Hz on the m4te repo (basically compatibility with the new RB visitor API) it might be nice to commit it on your repo too.
cool :)
See you,
2013/5/14 Guillermo Polito <guillermopolito@gmail.com>
Right now, in the image there exist two ways to annotate an AST: - the Opal way - the RB Way
We should simplify that by having only one. So far, the only user of the RB bindings is the ASTInterpreter + the RB tests.
So, I prepared a slice and issue [1], with the following details
- annotate ast using opal annotator - extended OCBindings to read and write from an AST interpreter - not yet made a difference between arg nodes with a different class (just put an if) - i didnt add inst vars into the opal bindings for the binding->node relation as in RB, I send the node as a parameter - I had to adapt the #compile: into ASTInterpreter because - opal does not annotate other than method nodes - undeclared variables raised warnings, not errors
There is one problem yet, I have only one failing test: #testEnsureTricky. I don't understand yet why it is failing and debugging it is pretty complex :). So any help is welcome in reviewing the changes.
Guille
[1] https://pharo.fogbugz.com/f/cases/10610/Make-ASTInterpreter-use-OC-Opal-bind...
-- Clément Béra Mate Virtual Machine Engineer Bâtiment B 40, avenue Halley 59650 *Villeneuve d'Ascq*
On Tue, May 14, 2013 at 2:44 PM, Guillermo Polito <guillermopolito@gmail.com
wrote:
On Tue, May 14, 2013 at 1:03 PM, Clément Bera <bera.clement@gmail.com>wrote:
Hey Guille,
To debug AST-interpreter there is a specific AIContextInspector. What you can do is just to inspect in the debugger the latest AIContext created by the AST-interpreter and you should see the stack of AIContext in the inspector. It is not perfect but it helps a lot. There is also the AST-Debugger but it is just a prototype so you can hardly use it.
Buu, how do I get the ASTDebugger? Maybe I can give it a try...
testEnsureTricky is the one that checks ensure nested in the on:do: works correctly. Basically it checks when you unwind the context up to the exception handler that you executes the ensure blocks code. It's kind of the trickiest one to fix :/. In the exception chapter of Deep into Pharo I added a section somewhere in Exception implementation about that, it might help you to read it.
Take care, AST-interpreter tests might not be enough. You should check the console output of the AST-interpreter-regression build too. (here : https://ci.inria.fr/rmod/job/ast-interpreter-regression/89/console) But it is failing since some new updates in Pharo 3.0 ...
I'm looking at https://ci.inria.fr/rmod/job/ast-interpreter-regression/. What does this job test/do? We can add that to the description :)
Anyway, I'm loading the same as the job, so I can test the slice locally in my machine :)
And I just did: 68 tests run 68 tests were successful 0 tests failed 0 tests were too long to be run Sound like good results, but I have nothing to reflect with :).
Are you committing on the AST-interpreter repository or on Pharo directly ?
Pharo... Should I commit to the other repo? Don't have grants =^).
I don't think there are but there might be some fixes already on the dev branch > Smalltalkhub user: dh83 project: ast-interpreter
Will check. Actually, I just loaded bleeding edge + merged my slice, and the same test still fails.
I would like to work on Opal test this afternoon but if you come to lille this week (not today because there is the strike) we can have a look together.
Tomorrow!
For M4te I've also fixed some stuff in Hz on the m4te repo (basically compatibility with the new RB visitor API) it might be nice to commit it on your repo too.
cool :)
See you,
2013/5/14 Guillermo Polito <guillermopolito@gmail.com>
Right now, in the image there exist two ways to annotate an AST: - the Opal way - the RB Way
We should simplify that by having only one. So far, the only user of the RB bindings is the ASTInterpreter + the RB tests.
So, I prepared a slice and issue [1], with the following details
- annotate ast using opal annotator - extended OCBindings to read and write from an AST interpreter - not yet made a difference between arg nodes with a different class (just put an if) - i didnt add inst vars into the opal bindings for the binding->node relation as in RB, I send the node as a parameter - I had to adapt the #compile: into ASTInterpreter because - opal does not annotate other than method nodes - undeclared variables raised warnings, not errors
There is one problem yet, I have only one failing test: #testEnsureTricky. I don't understand yet why it is failing and debugging it is pretty complex :). So any help is welcome in reviewing the changes.
Guille
[1] https://pharo.fogbugz.com/f/cases/10610/Make-ASTInterpreter-use-OC-Opal-bind...
-- Clément Béra Mate Virtual Machine Engineer Bâtiment B 40, avenue Halley 59650 *Villeneuve d'Ascq*
Clement? Camilo? :D On Tue, May 14, 2013 at 2:46 PM, Guillermo Polito <guillermopolito@gmail.com
wrote:
On Tue, May 14, 2013 at 2:44 PM, Guillermo Polito < guillermopolito@gmail.com> wrote:
On Tue, May 14, 2013 at 1:03 PM, Clément Bera <bera.clement@gmail.com>wrote:
Hey Guille,
To debug AST-interpreter there is a specific AIContextInspector. What you can do is just to inspect in the debugger the latest AIContext created by the AST-interpreter and you should see the stack of AIContext in the inspector. It is not perfect but it helps a lot. There is also the AST-Debugger but it is just a prototype so you can hardly use it.
Buu, how do I get the ASTDebugger? Maybe I can give it a try...
testEnsureTricky is the one that checks ensure nested in the on:do: works correctly. Basically it checks when you unwind the context up to the exception handler that you executes the ensure blocks code. It's kind of the trickiest one to fix :/. In the exception chapter of Deep into Pharo I added a section somewhere in Exception implementation about that, it might help you to read it.
Take care, AST-interpreter tests might not be enough. You should check the console output of the AST-interpreter-regression build too. (here : https://ci.inria.fr/rmod/job/ast-interpreter-regression/89/console) But it is failing since some new updates in Pharo 3.0 ...
I'm looking at https://ci.inria.fr/rmod/job/ast-interpreter-regression/. What does this job test/do? We can add that to the description :)
Anyway, I'm loading the same as the job, so I can test the slice locally in my machine :)
And I just did:
68 tests run 68 tests were successful 0 tests failed 0 tests were too long to be run
Sound like good results, but I have nothing to reflect with :).
Are you committing on the AST-interpreter repository or on Pharo directly ?
Pharo... Should I commit to the other repo? Don't have grants =^).
I don't think there are but there might be some fixes already on the dev branch > Smalltalkhub user: dh83 project: ast-interpreter
Will check. Actually, I just loaded bleeding edge + merged my slice, and the same test still fails.
I would like to work on Opal test this afternoon but if you come to lille this week (not today because there is the strike) we can have a look together.
Tomorrow!
For M4te I've also fixed some stuff in Hz on the m4te repo (basically compatibility with the new RB visitor API) it might be nice to commit it on your repo too.
cool :)
See you,
2013/5/14 Guillermo Polito <guillermopolito@gmail.com>
Right now, in the image there exist two ways to annotate an AST: - the Opal way - the RB Way
We should simplify that by having only one. So far, the only user of the RB bindings is the ASTInterpreter + the RB tests.
So, I prepared a slice and issue [1], with the following details
- annotate ast using opal annotator - extended OCBindings to read and write from an AST interpreter - not yet made a difference between arg nodes with a different class (just put an if) - i didnt add inst vars into the opal bindings for the binding->node relation as in RB, I send the node as a parameter - I had to adapt the #compile: into ASTInterpreter because - opal does not annotate other than method nodes - undeclared variables raised warnings, not errors
There is one problem yet, I have only one failing test: #testEnsureTricky. I don't understand yet why it is failing and debugging it is pretty complex :). So any help is welcome in reviewing the changes.
Guille
[1] https://pharo.fogbugz.com/f/cases/10610/Make-ASTInterpreter-use-OC-Opal-bind...
-- Clément Béra Mate Virtual Machine Engineer Bâtiment B 40, avenue Halley 59650 *Villeneuve d'Ascq*
On May 15, 2013, at 1:58 PM, Guillermo Polito <guillermopolito@gmail.com> wrote:
Clement? Camilo? :D
I will have a look with Clement this afternoon.
On Tue, May 14, 2013 at 2:46 PM, Guillermo Polito <guillermopolito@gmail.com> wrote:
On Tue, May 14, 2013 at 2:44 PM, Guillermo Polito <guillermopolito@gmail.com> wrote:
On Tue, May 14, 2013 at 1:03 PM, Clément Bera <bera.clement@gmail.com> wrote: Hey Guille,
To debug AST-interpreter there is a specific AIContextInspector. What you can do is just to inspect in the debugger the latest AIContext created by the AST-interpreter and you should see the stack of AIContext in the inspector. It is not perfect but it helps a lot. There is also the AST-Debugger but it is just a prototype so you can hardly use it.
Buu, how do I get the ASTDebugger? Maybe I can give it a try...
testEnsureTricky is the one that checks ensure nested in the on:do: works correctly. Basically it checks when you unwind the context up to the exception handler that you executes the ensure blocks code. It's kind of the trickiest one to fix :/. In the exception chapter of Deep into Pharo I added a section somewhere in Exception implementation about that, it might help you to read it.
Take care, AST-interpreter tests might not be enough. You should check the console output of the AST-interpreter-regression build too. (here : https://ci.inria.fr/rmod/job/ast-interpreter-regression/89/console) But it is failing since some new updates in Pharo 3.0 ...
I'm looking at https://ci.inria.fr/rmod/job/ast-interpreter-regression/. What does this job test/do? We can add that to the description :)
Anyway, I'm loading the same as the job, so I can test the slice locally in my machine :)
And I just did:
68 tests run 68 tests were successful 0 tests failed 0 tests were too long to be run
Sound like good results, but I have nothing to reflect with :).
Are you committing on the AST-interpreter repository or on Pharo directly ?
Pharo... Should I commit to the other repo? Don't have grants =^).
I don't think there are but there might be some fixes already on the dev branch > Smalltalkhub user: dh83 project: ast-interpreter
Will check. Actually, I just loaded bleeding edge + merged my slice, and the same test still fails.
I would like to work on Opal test this afternoon but if you come to lille this week (not today because there is the strike) we can have a look together.
Tomorrow!
For M4te I've also fixed some stuff in Hz on the m4te repo (basically compatibility with the new RB visitor API) it might be nice to commit it on your repo too.
cool :)
See you,
2013/5/14 Guillermo Polito <guillermopolito@gmail.com> Right now, in the image there exist two ways to annotate an AST: - the Opal way - the RB Way
We should simplify that by having only one. So far, the only user of the RB bindings is the ASTInterpreter + the RB tests.
So, I prepared a slice and issue [1], with the following details
- annotate ast using opal annotator - extended OCBindings to read and write from an AST interpreter - not yet made a difference between arg nodes with a different class (just put an if) - i didnt add inst vars into the opal bindings for the binding->node relation as in RB, I send the node as a parameter - I had to adapt the #compile: into ASTInterpreter because - opal does not annotate other than method nodes - undeclared variables raised warnings, not errors
There is one problem yet, I have only one failing test: #testEnsureTricky. I don't understand yet why it is failing and debugging it is pretty complex :). So any help is welcome in reviewing the changes.
Guille
[1] https://pharo.fogbugz.com/f/cases/10610/Make-ASTInterpreter-use-OC-Opal-bind...
-- Clément Béra Mate Virtual Machine Engineer Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
Sorry I wasn't very well yesterday so I skipped a couple of mails... If you want we can pair-programm some time on that (and a possible paper?) On 2013-05-15, at 13:57, Guillermo Polito <guillermopolito@gmail.com> wrote:
Clement? Camilo? :D On Tue, May 14, 2013 at 2:46 PM, Guillermo Polito <guillermopolito@gmail.com
wrote: On Tue, May 14, 2013 at 2:44 PM, Guillermo Polito < guillermopolito@gmail.com> wrote:
On Tue, May 14, 2013 at 1:03 PM, Clément Bera <bera.clement@gmail.com>wrote:
Hey Guille,
To debug AST-interpreter there is a specific AIContextInspector. What you can do is just to inspect in the debugger the latest AIContext created by the AST-interpreter and you should see the stack of AIContext in the inspector. It is not perfect but it helps a lot. There is also the AST-Debugger but it is just a prototype so you can hardly use it.
Buu, how do I get the ASTDebugger? Maybe I can give it a try...
testEnsureTricky is the one that checks ensure nested in the on:do: works correctly. Basically it checks when you unwind the context up to the exception handler that you executes the ensure blocks code. It's kind of the trickiest one to fix :/. In the exception chapter of Deep into Pharo I added a section somewhere in Exception implementation about that, it might help you to read it.
Take care, AST-interpreter tests might not be enough. You should check the console output of the AST-interpreter-regression build too. (here : https://ci.inria.fr/rmod/job/ast-interpreter-regression/89/console) But it is failing since some new updates in Pharo 3.0 ...
I'm looking at https://ci.inria.fr/rmod/job/ast-interpreter-regression/. What does this job test/do? We can add that to the description :)
Anyway, I'm loading the same as the job, so I can test the slice locally in my machine :)
And I just did:
68 tests run 68 tests were successful 0 tests failed 0 tests were too long to be run
Sound like good results, but I have nothing to reflect with :).
Are you committing on the AST-interpreter repository or on Pharo directly ?
Pharo... Should I commit to the other repo? Don't have grants =^).
I don't think there are but there might be some fixes already on the dev branch > Smalltalkhub user: dh83 project: ast-interpreter
Will check. Actually, I just loaded bleeding edge + merged my slice, and the same test still fails.
I would like to work on Opal test this afternoon but if you come to lille this week (not today because there is the strike) we can have a look together.
Tomorrow!
For M4te I've also fixed some stuff in Hz on the m4te repo (basically compatibility with the new RB visitor API) it might be nice to commit it on your repo too.
cool :)
See you,
2013/5/14 Guillermo Polito <guillermopolito@gmail.com>
Right now, in the image there exist two ways to annotate an AST: - the Opal way - the RB Way
We should simplify that by having only one. So far, the only user of the RB bindings is the ASTInterpreter + the RB tests.
So, I prepared a slice and issue [1], with the following details
- annotate ast using opal annotator - extended OCBindings to read and write from an AST interpreter - not yet made a difference between arg nodes with a different class (just put an if) - i didnt add inst vars into the opal bindings for the binding->node relation as in RB, I send the node as a parameter - I had to adapt the #compile: into ASTInterpreter because - opal does not annotate other than method nodes - undeclared variables raised warnings, not errors
There is one problem yet, I have only one failing test: #testEnsureTricky. I don't understand yet why it is failing and debugging it is pretty complex :). So any help is welcome in reviewing the changes.
Guille
[1] https://pharo.fogbugz.com/f/cases/10610/Make-ASTInterpreter-use-OC-Opal-bind...
-- Clément Béra Mate Virtual Machine Engineer Bâtiment B 40, avenue Halley 59650 *Villeneuve d'Ascq*
Sorry with the strike and no metro I cannot be at INRIA today. I'm at Marcus right now we will have a look at your slice now :) I don't know why this morning I hadn't received yet your mails from yesterday. 2013/5/14 Guillermo Polito <guillermopolito@gmail.com>
On Tue, May 14, 2013 at 1:03 PM, Clément Bera <bera.clement@gmail.com>wrote:
Hey Guille,
To debug AST-interpreter there is a specific AIContextInspector. What you can do is just to inspect in the debugger the latest AIContext created by the AST-interpreter and you should see the stack of AIContext in the inspector. It is not perfect but it helps a lot. There is also the AST-Debugger but it is just a prototype so you can hardly use it.
Buu, how do I get the ASTDebugger? Maybe I can give it a try...
AST-Debugger is at Smalltalkhub user : dh83 project : ast-interpreter package AST-debugger there is no config. But it's just a quick prototype, there is some work to do. To try you should copy AST-debugger test in workspace (in test it does not works because of problem with test thread / UI thread) and then run. The into button works a little, the other not, but the stack and inspectors works.
testEnsureTricky is the one that checks ensure nested in the on:do: works correctly. Basically it checks when you unwind the context up to the exception handler that you executes the ensure blocks code. It's kind of the trickiest one to fix :/. In the exception chapter of Deep into Pharo I added a section somewhere in Exception implementation about that, it might help you to read it.
Take care, AST-interpreter tests might not be enough. You should check the console output of the AST-interpreter-regression build too. (here : https://ci.inria.fr/rmod/job/ast-interpreter-regression/89/console) But it is failing since some new updates in Pharo 3.0 ...
I'm looking at https://ci.inria.fr/rmod/job/ast-interpreter-regression/. What does this job test/do? We can add that to the description :)
This test runs all the Pharo Kernel tests with the AST-interpreter. Then you can guarantee the AST-interpreter can interpret the whole Pharo Kernel suite, which is much more than just AST-interpreter tests.
Anyway, I'm loading the same as the job, so I can test the slice locally in my machine :)
Are you committing on the AST-interpreter repository or on Pharo directly ?
Pharo... Should I commit to the other repo? Don't have grants =^).
There is currently no dev any more on AST-interpreter but it would be nice to commit to the other repo first for the 2 jenkins jobs to run. Ask Camillo to have the rights to write on it.
I don't think there are but there might be some fixes already on the dev branch > Smalltalkhub user: dh83 project: ast-interpreter
Will check. Actually, I just loaded bleeding edge + merged my slice, and the same test still fails.
I would like to work on Opal test this afternoon but if you come to lille this week (not today because there is the strike) we can have a look together.
Tomorrow!
Not possible there is still the strike... Are you at INRIA ?
For M4te I've also fixed some stuff in Hz on the m4te repo (basically compatibility with the new RB visitor API) it might be nice to commit it on your repo too.
cool :)
See you,
2013/5/14 Guillermo Polito <guillermopolito@gmail.com>
Right now, in the image there exist two ways to annotate an AST: - the Opal way - the RB Way
We should simplify that by having only one. So far, the only user of the RB bindings is the ASTInterpreter + the RB tests.
So, I prepared a slice and issue [1], with the following details
- annotate ast using opal annotator - extended OCBindings to read and write from an AST interpreter - not yet made a difference between arg nodes with a different class (just put an if) - i didnt add inst vars into the opal bindings for the binding->node relation as in RB, I send the node as a parameter - I had to adapt the #compile: into ASTInterpreter because - opal does not annotate other than method nodes - undeclared variables raised warnings, not errors
There is one problem yet, I have only one failing test: #testEnsureTricky. I don't understand yet why it is failing and debugging it is pretty complex :). So any help is welcome in reviewing the changes.
Guille
[1] https://pharo.fogbugz.com/f/cases/10610/Make-ASTInterpreter-use-OC-Opal-bind...
-- Clément Béra Mate Virtual Machine Engineer Bâtiment B 40, avenue Halley 59650 *Villeneuve d'Ascq*
-- Clément Béra Mate Virtual Machine Engineer Bâtiment B 40, avenue Halley 59650 *Villeneuve d'Ascq*
On Wed, May 15, 2013 at 3:40 PM, Clément Bera <clement.bera@inria.fr> wrote:
Sorry with the strike and no metro I cannot be at INRIA today. I'm at Marcus right now we will have a look at your slice now :)
I don't know why this morning I hadn't received yet your mails from yesterday.
2013/5/14 Guillermo Polito <guillermopolito@gmail.com>
On Tue, May 14, 2013 at 1:03 PM, Clément Bera <bera.clement@gmail.com>wrote:
Hey Guille,
To debug AST-interpreter there is a specific AIContextInspector. What you can do is just to inspect in the debugger the latest AIContext created by the AST-interpreter and you should see the stack of AIContext in the inspector. It is not perfect but it helps a lot. There is also the AST-Debugger but it is just a prototype so you can hardly use it.
Buu, how do I get the ASTDebugger? Maybe I can give it a try...
AST-Debugger is at Smalltalkhub user : dh83 project : ast-interpreter package AST-debugger there is no config. But it's just a quick prototype, there is some work to do. To try you should copy AST-debugger test in workspace (in test it does not works because of problem with test thread / UI thread) and then run. The into button works a little, the other not, but the stack and inspectors works.
Will try, tx!
testEnsureTricky is the one that checks ensure nested in the on:do: works correctly. Basically it checks when you unwind the context up to the exception handler that you executes the ensure blocks code. It's kind of the trickiest one to fix :/. In the exception chapter of Deep into Pharo I added a section somewhere in Exception implementation about that, it might help you to read it.
Take care, AST-interpreter tests might not be enough. You should check the console output of the AST-interpreter-regression build too. (here : https://ci.inria.fr/rmod/job/ast-interpreter-regression/89/console) But it is failing since some new updates in Pharo 3.0 ...
I'm looking at https://ci.inria.fr/rmod/job/ast-interpreter-regression/. What does this job test/do? We can add that to the description :)
This test runs all the Pharo Kernel tests with the AST-interpreter. Then you can guarantee the AST-interpreter can interpret the whole Pharo Kernel suite, which is much more than just AST-interpreter tests.
I did, all green :).
Anyway, I'm loading the same as the job, so I can test the slice locally in my machine :)
Are you committing on the AST-interpreter repository or on Pharo directly ?
Pharo... Should I commit to the other repo? Don't have grants =^).
There is currently no dev any more on AST-interpreter but it would be nice to commit to the other repo first for the 2 jenkins jobs to run. Ask Camillo to have the rights to write on it.
Camillo? Can I???
I don't think there are but there might be some fixes already on the dev branch > Smalltalkhub user: dh83 project: ast-interpreter
Will check. Actually, I just loaded bleeding edge + merged my slice, and the same test still fails.
I would like to work on Opal test this afternoon but if you come to lille this week (not today because there is the strike) we can have a look together.
Tomorrow!
Not possible there is still the strike... Are you at INRIA ?
Nope. Douai :(
For M4te I've also fixed some stuff in Hz on the m4te repo (basically compatibility with the new RB visitor API) it might be nice to commit it on your repo too.
cool :)
See you,
2013/5/14 Guillermo Polito <guillermopolito@gmail.com>
Right now, in the image there exist two ways to annotate an AST: - the Opal way - the RB Way
We should simplify that by having only one. So far, the only user of the RB bindings is the ASTInterpreter + the RB tests.
So, I prepared a slice and issue [1], with the following details
- annotate ast using opal annotator - extended OCBindings to read and write from an AST interpreter - not yet made a difference between arg nodes with a different class (just put an if) - i didnt add inst vars into the opal bindings for the binding->node relation as in RB, I send the node as a parameter - I had to adapt the #compile: into ASTInterpreter because - opal does not annotate other than method nodes - undeclared variables raised warnings, not errors
There is one problem yet, I have only one failing test: #testEnsureTricky. I don't understand yet why it is failing and debugging it is pretty complex :). So any help is welcome in reviewing the changes.
Guille
[1] https://pharo.fogbugz.com/f/cases/10610/Make-ASTInterpreter-use-OC-Opal-bind...
-- Clément Béra Mate Virtual Machine Engineer Bâtiment B 40, avenue Halley 59650 *Villeneuve d'Ascq*
-- Clément Béra Mate Virtual Machine Engineer Bâtiment B 40, avenue Halley 59650 *Villeneuve d'Ascq*
2013/5/15 Guillermo Polito <guillermopolito@gmail.com>
On Wed, May 15, 2013 at 3:40 PM, Clément Bera <clement.bera@inria.fr>wrote:
Sorry with the strike and no metro I cannot be at INRIA today. I'm at Marcus right now we will have a look at your slice now :)
I don't know why this morning I hadn't received yet your mails from yesterday.
2013/5/14 Guillermo Polito <guillermopolito@gmail.com>
On Tue, May 14, 2013 at 1:03 PM, Clément Bera <bera.clement@gmail.com>wrote:
Hey Guille,
To debug AST-interpreter there is a specific AIContextInspector. What you can do is just to inspect in the debugger the latest AIContext created by the AST-interpreter and you should see the stack of AIContext in the inspector. It is not perfect but it helps a lot. There is also the AST-Debugger but it is just a prototype so you can hardly use it.
Buu, how do I get the ASTDebugger? Maybe I can give it a try...
AST-Debugger is at Smalltalkhub user : dh83 project : ast-interpreter package AST-debugger there is no config. But it's just a quick prototype, there is some work to do. To try you should copy AST-debugger test in workspace (in test it does not works because of problem with test thread / UI thread) and then run. The into button works a little, the other not, but the stack and inspectors works.
Will try, tx!
testEnsureTricky is the one that checks ensure nested in the on:do: works correctly. Basically it checks when you unwind the context up to the exception handler that you executes the ensure blocks code. It's kind of the trickiest one to fix :/. In the exception chapter of Deep into Pharo I added a section somewhere in Exception implementation about that, it might help you to read it.
Take care, AST-interpreter tests might not be enough. You should check the console output of the AST-interpreter-regression build too. (here : https://ci.inria.fr/rmod/job/ast-interpreter-regression/89/console) But it is failing since some new updates in Pharo 3.0 ...
I'm looking at https://ci.inria.fr/rmod/job/ast-interpreter-regression/. What does this job test/do? We can add that to the description :)
This test runs all the Pharo Kernel tests with the AST-interpreter. Then you can guarantee the AST-interpreter can interpret the whole Pharo Kernel suite, which is much more than just AST-interpreter tests.
I did, all green :).
This is not possible there is primitive:error:code: that fails. The problem is that the result is displayed per package. So you have to click 'full log' then check the 8 blue text, and check there is no [FAIL] before ... But if the build finishes it is already something. Marcus answered for the problem with the binding.
Anyway, I'm loading the same as the job, so I can test the slice locally in my machine :)
Are you committing on the AST-interpreter repository or on Pharo directly ?
Pharo... Should I commit to the other repo? Don't have grants =^).
There is currently no dev any more on AST-interpreter but it would be nice to commit to the other repo first for the 2 jenkins jobs to run. Ask Camillo to have the rights to write on it.
Camillo? Can I???
I don't think there are but there might be some fixes already on the dev branch > Smalltalkhub user: dh83 project: ast-interpreter
Will check. Actually, I just loaded bleeding edge + merged my slice, and the same test still fails.
I would like to work on Opal test this afternoon but if you come to lille this week (not today because there is the strike) we can have a look together.
Tomorrow!
Not possible there is still the strike... Are you at INRIA ?
Nope. Douai :(
For M4te I've also fixed some stuff in Hz on the m4te repo (basically compatibility with the new RB visitor API) it might be nice to commit it on your repo too.
cool :)
See you,
2013/5/14 Guillermo Polito <guillermopolito@gmail.com>
Right now, in the image there exist two ways to annotate an AST: - the Opal way - the RB Way
We should simplify that by having only one. So far, the only user of the RB bindings is the ASTInterpreter + the RB tests.
So, I prepared a slice and issue [1], with the following details
- annotate ast using opal annotator - extended OCBindings to read and write from an AST interpreter - not yet made a difference between arg nodes with a different class (just put an if) - i didnt add inst vars into the opal bindings for the binding->node relation as in RB, I send the node as a parameter - I had to adapt the #compile: into ASTInterpreter because - opal does not annotate other than method nodes - undeclared variables raised warnings, not errors
There is one problem yet, I have only one failing test: #testEnsureTricky. I don't understand yet why it is failing and debugging it is pretty complex :). So any help is welcome in reviewing the changes.
Guille
[1] https://pharo.fogbugz.com/f/cases/10610/Make-ASTInterpreter-use-OC-Opal-bind...
-- Clément Béra Mate Virtual Machine Engineer Bâtiment B 40, avenue Halley 59650 *Villeneuve d'Ascq*
-- Clément Béra Mate Virtual Machine Engineer Bâtiment B 40, avenue Halley 59650 *Villeneuve d'Ascq*
-- Clément Béra Mate Virtual Machine Engineer Bâtiment B 40, avenue Halley 59650 *Villeneuve d'Ascq*
On May 15, 2013, at 3:41 PM, Clément Bera <clement.bera@inria.fr> wrote:
Sorry with the strike and no metro I cannot be at INRIA today. I'm at Marcus right now we will have a look at your slice now :)
So we looked⦠and there is a problem with readWith: anInterpreter inNode: aVariableNode self isArg ifTrue: [ | definingScope argIndex | definingScope := aVariableNode scope lookupScopeForVar: aVariableNode name. argIndex := definingScope node argumentNames indexOf: name. ^ anInterpreter readArgumentAt: argIndex node: aVariableNode ]. "If it is not an arg, it is a normal temporary" ^ anInterpreter readTemporaryAt: -1 named: name When generating byte code with closures the way they are implemented (with escaping variables allocated in Arrays on the heap), we can not assign any meaningful index to temps. (there is an index ivar, but this needs to be cleaned up). Now temps and args are modelled the same, but all kinds indexes that you could calculate are meaningless. Especially argIndex := definingScope node argumentNames indexOf: name. does not need to be consistent with the actual position of the arg⦠in edge cases. So we need to think about this⦠maybe introducing a OCArgVariable (with index) is the only way to do it. Marcus
On May 15, 2013, at 4:42 PM, Marcus Denker <marcus.denker@inria.fr> wrote:
On May 15, 2013, at 3:41 PM, Clément Bera <clement.bera@inria.fr> wrote:
Sorry with the strike and no metro I cannot be at INRIA today. I'm at Marcus right now we will have a look at your slice now :)
So we looked⦠and there is a problem with
No! We found it! The code showing the error (in the testEnsureTricky) it this: (String streamContents: [:s | [ [s nextPutAll: 1 printString. 1/0] ensure: [s nextPutAll: 2 printString] ] on: Error do: [s nextPutAll: 3 printString] ]) asInteger The problem is that the scope of the second "s" is wrong, it should the block with the [:s |, but it is just the block one outer. And the reason is this: The ASTClosureAnalyzer, the visitor that analyses if a variable is to be put in a tempVector or is a copied var, does this: visitVariableNode: aVariableNode "re-lookup the temorary variables..." | var | aVariableNode isTemp ifFalse: [^self]. var := scope lookupVar: aVariableNode name. aVariableNode ocBinding: var. var isTempVectorTemp ifTrue: [scope addCopyingTempToAllScopesUpToDefVector: var vectorName]. var isCopying ifTrue: [scope addCopyingTempToAllScopesUpToDefTemp: var]. If it seems a copying temp, it puts copied vars in all scopes until it finds the definition: addCopyingTempToAllScopesUpToDefTemp: aVar (self hasCopyingTempNamed: aVar name) ifFalse: [self addCopyingTemp: aVar]. tempVars at: aVar name ifPresent: [:v | ^ self]. ^ self outerScope addCopyingTempToAllScopesUpToDefTemp: aVar. Now for the second "s", the visit will call var := scope lookupVar: aVariableNode name. again, but this lookup will find the *copy* in the outer scope and returns this.. so this is clearly wrong. (but for Opal this is not a problem, as it just compiles a local access to the copying temp and does not care that it has a copy...). Now how to fix it... Marcus
On May 14, 2013, at 2:09 PM, Guillermo Polito <guillermopolito@gmail.com> wrote:
Right now, in the image there exist two ways to annotate an AST: - the Opal way - the RB Way
We should simplify that by having only one. So far, the only user of the RB bindings is the ASTInterpreter + the RB tests.
So, I prepared a slice and issue [1], with the following details
- annotate ast using opal annotator - extended OCBindings to read and write from an AST interpreter - not yet made a difference between arg nodes with a different class (just put an if)
I think it might be a good idea to add that⦠what I will do first is to cleanup the OCTemp vars a bit (there is an index variable that is used to sort them at the end, a leftover from back before the closures when there was simple temp=index mapping).
- i didnt add inst vars into the opal bindings for the binding->node relation as in RB, I send the node as a parameter
We need to check this, back pointers are always interesting (but I am not sure if we have a new semantic variable or if we reuse it for multiple nodes?)
- I had to adapt the #compile: into ASTInterpreter because - opal does not annotate other than method nodes Yes, this is because when compiling an expression we transform it do the doIt method before. Expressions can not be compiled standalone.
- undeclared variables raised warnings, not errors
Yes, the idea is that in interactive mode it does user=interaction, while in non-interactive it compiled an Undeclared. (so that the code stays loadable). Maybe the interpreter could do the same an fall back to Undeclared, that it, undeclared vars are just treated as nil. Marcus
We are movin AST-interpreter project from dh83 to mate team so you can write on it Guille. 2013/5/16 Marcus Denker <marcus.denker@inria.fr>
On May 14, 2013, at 2:09 PM, Guillermo Polito <guillermopolito@gmail.com> wrote:
Right now, in the image there exist two ways to annotate an AST: - the Opal way - the RB Way
We should simplify that by having only one. So far, the only user of the RB bindings is the ASTInterpreter + the RB tests.
So, I prepared a slice and issue [1], with the following details
- annotate ast using opal annotator - extended OCBindings to read and write from an AST interpreter - not yet made a difference between arg nodes with a different class (just put an if)
I think it might be a good idea to add that⦠what I will do first is to cleanup the OCTemp vars a bit (there is an index variable that is used to sort them at the end, a leftover from back before the closures when there was simple temp=index mapping).
- i didnt add inst vars into the opal bindings for the binding->node relation as in RB, I send the node as a parameter
We need to check this, back pointers are always interesting (but I am not sure if we have a new semantic variable or if we reuse it for multiple nodes?)
- I had to adapt the #compile: into ASTInterpreter because - opal does not annotate other than method nodes Yes, this is because when compiling an expression we transform it do the doIt method before. Expressions can not be compiled standalone.
- undeclared variables raised warnings, not errors
Yes, the idea is that in interactive mode it does user=interaction, while in non-interactive it compiled an Undeclared. (so that the code stays loadable).
Maybe the interpreter could do the same an fall back to Undeclared, that it, undeclared vars are just treated as nil.
Marcus
-- Clément Béra Mate Virtual Machine Engineer Bâtiment B 40, avenue Halley 59650 *Villeneuve d'Ascq*
participants (5)
-
Camillo Bruni -
Clément Bera -
Clément Bera -
Guillermo Polito -
Marcus Denker