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 <stephane.ducasse@inria.fr> 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 <stephane.ducasse@inria.fr>:
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