2013/5/15 Guillermo Polito <[email protected]> > > > > On Wed, May 15, 2013 at 3:40 PM, Clément Bera <[email protected]>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 <[email protected]> >> >>> >>> 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... >>> >> >> 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 <[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* >>>> >>> >>> >> >> >> -- >> 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*
