On 5 September 2011 18:02, Lukas Renggli <renggli@gmail.com> 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 <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
-- Best regards, Igor Stasenko.