On Mon, Sep 5, 2011 at 8:02 AM, 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. > Right. Basically the two levels, source and bytecode are all one needs and a fixation with ASs doesn't really help. The bytecode is quite tractible, and look at the different performance/quality of Smalltalk vs Ruby for what bytecode vs AST architectures get you. > 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, Eliot
