On 5 September 2011 18:02, Lukas Renggli <[email protected]> wrote: > Even if you have a AST debugger you still need at some point a bytecode to > AST (or source) mapping, because otherwise you cannot just break into a > debugger at a random point in the code. I imagine this jump from bytecode to > AST interpretation quite difficult; likely you still need a full bytecode > stepper to find a position where you can jump into the AST interpreter. >
It depends, whether you able (or want to) insert a breakpoint which are inside a single AST node (for AST node which contains multiple bytecode), or allow to halt only at AST nodes boundaries. Consider C debugger - it has to deal with same situation: a single C statement could contain multiple machine code instructions, but when you stepping over that statement, you are not stepping over single machine code instruction(s) at a time, you stepping over single C statement. In some cases, stepping over single machine instruction is useful (especially when you dealing with generated machine code ;) but when you debugging a normal code, you don't need that, which means that if you have an AST -> bytecode ranges mapping you know the ranges and stepping points and don't have to interpret each bytecode separately, but intead just interpret what AST node does. > Lukas > > On Monday, 5 September 2011, Stéphane Ducasse <[email protected]> > wrote: >> We were thinking with marcus that using byte code to go back to sources >> code is >> broken by essence and that using an AST is the way to go. >> Now we would need a good AST-based interpreter to start with. >> >>> 2011/9/5 Stéphane Ducasse <[email protected]>: >>>> BTW mike roberts is building a tool to be able to understand and fix the >>>> code range of the debugger hilighting. >>>> Probably your bug is also related to the closure introduction. >>>> >>>> Now the abstraction used is so low level that this is a pain and >>>> fragile. >>>> Ideally using an AST would be much better but this is for the future. >>>> >>>> Stef >>>> >>> >>> Stef, >>> If you are saying that implementation is not crystal clear, I can only >>> agree with you. >>> Eliot did avoid a full rewrite (I guess he took the shortest path to >>> make the available implementation work with closures), and this design >>> decision can be questioned indeed. >>> >>> But speaking of abstraction level by itself, I don't understand your >>> sentence. >>> To me, the abstraction is at the correct level. >>> The Debugger has to map the low level execution machinery >>> (Context/program counter/CompiledMethod/byteCodes) to high level >>> specification visible to the user (source code). >>> The Debugger does so by mapping bytecodes to source ranges via AST, no >>> more, no less. >>> >>> In case of inlined blocks, there are more instructions on the bytecode >>> side than messages sent on the AST side, just to make the problem a >>> bit more complex, so maybe there are more intelligent way to address >>> the mapping problem (maybe you mean via an intermediate transformation >>> of AST), but you'll have to explain this a bit deeper. >>> >>> Nicolas >>> >>>> >>>> On Sep 5, 2011, at 9:07 AM, Andrea Brühlmann wrote: >>>> >>>>> Hello Stef, >>>>> >>>>> I appreciate the work of the pharo community! We will continue >>>>> reporting bugs and submit fixes that >>>>> we made. Of course I do not expect anyone to fix all reported bugs, but >>>>> there are issues like 4694 >>>>> (debugger) where we really need your help. Other issues like the buggy >>>>> code completion can be >>>>> workarounded by me by disabling code completion ;-) >>>>> >>>>> So thanks for the welcome and I am looking forward to having 4694 >>>>> fixed! >>>>> >>>>> Andrea >>>>> >>>>> >>>>> >>>>> >>>>> Stéphane Ducasse schrieb: >>>>>> Thanks andrea >>>>>> Welcome to the pharo mailing-list and community. Now I think that this >>>>>> is important that inside netstyle you also consider that if pharo is >>>>>> important for you (which I imagine) that you should also contribute. Bug >>>>>> reporting is already a contribution. Pharo is an open-source software >>>>>> mainly supported by the free time of people, people that are often do not >>>>>> earning their money from their pharo work (I thank them for all that). I >>>>>> also understand that people can get frustrated by changes but what can we >>>>>> do? >>>>>> May be people can gather and check the fixes that are important to fix >>>>>> but we do not have the force to maintain. >>>>>> Imagine well that we have one engineer full time since 8 months. Stef >>>>>> On Aug 23, 2011, at 8:54 AM, Andrea Brühlmann wrote: >>>>>>> Hello, >>>>>>> >>>>>>> I reported some bugs on the issue tracker and hope you can help me >>>>>>> with them! >>>>>>> >>>>>>> >>>>>>> 4681: Accepting with the enter key does not work >>>>>>> http://code.google.com/p/pharo/issues/detail?id=4681 >>>>>>> >>>>>>> 4682: Code completion makes strange cursor placements and too many >>>>>>> spaces >>>>>>> http://code.google.com/p/pharo/issues/detail?id=4682 >>>>>>> >>>>>>> 4683: Code completion breaks some search fields (errors during >>>>>>> typing) >>>>>>> http://code.google.com/p/pharo/issues/detail?id=4683 >>>>>>> >>>>>>> 4684: Missing ctrl+w (methodNamesContainingIt:) >>>>>>> http://code.google.com/p/pharo/issues/detail?id=4684 >>>>>>> >>>>>>> 4685: Merge dialog: cannot resolve conflict with removed method >>>>>> > > -- > Lukas Renggli > www.lukas-renggli.ch > -- Best regards, Igor Stasenko.
