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.
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
