On Tue, May 14, 2013 at 2:44 PM, Guillermo Polito <[email protected] > wrote:
> > On Tue, May 14, 2013 at 1:03 PM, Clément Bera <[email protected]>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 <[email protected]> >> >>> 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-bindings-instead-of-RB-bindings >>> >> >> >> >> -- >> Clément Béra >> Mate Virtual Machine Engineer >> Bâtiment B 40, avenue Halley 59650 *Villeneuve d'Ascq* >> > >
