2011/9/5 Nicolas Cellier <[email protected]>: > 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 >
By the way, I would find it cool to have an optional byteCode view parallel to source code view and see the execution of byte codes, and why not, a view of Context stack frames. Also, the debugger might step message by message (AST-based) rather than byteCode by byteCode, is this what you mean by wrong abstraction level ? 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 >>>>> http://code.google.com/p/pharo/issues/detail?id=4685 >>>>> >>>>> 4686: Method category change creates no new version >>>>> http://code.google.com/p/pharo/issues/detail?id=4686 >>>>> >>>>> 4687: Errors during coding (MessageNotUnderstood: receiver of "morph" is >>>>> nil) >>>>> http://code.google.com/p/pharo/issues/detail?id=4687 >>>>> >>>>> 4688: Progress bar disappears on image save >>>>> http://code.google.com/p/pharo/issues/detail?id=4688 >>>>> >>>>> 4689: MessageTally bug >>>>> http://code.google.com/p/pharo/issues/detail?id=4689 >>>>> >>>>> 4690: Progress bar position >>>>> http://code.google.com/p/pharo/issues/detail?id=4690 >>>>> >>>>> 4691: Bad line breaks in code until window is resized (because of bold >>>>> text?) >>>>> http://code.google.com/p/pharo/issues/detail?id=4691 >>>>> >>>>> 4692: Drop downs should select the default entry (topmost) instead of a >>>>> middle one >>>>> http://code.google.com/p/pharo/issues/detail?id=4692 >>>>> >>>>> 4693: Line breaks in tooltips are wrong >>>>> http://code.google.com/p/pharo/issues/detail?id=4693 >>>>> >>>>> 4694: Debugger: stepping over an error can not open a new debugger until >>>>> I hit cmd+. >>>>> http://code.google.com/p/pharo/issues/detail?id=4694 >>>>> >>>>> 4695: Time asString prints nanos unrounded >>>>> http://code.google.com/p/pharo/issues/detail?id=4695 >>>>> >>>>> >>>>> -- >>>>> Andrea Brühlmann >>>>> >>> >>> >>> -- >>> AB | ANDREA BRÜHLMANN · SOFTWARE ENGINEER >>> | NETSTYLE · TERRASSENWEG 18 · CH-3012 BERN >>> | TEL +41 31 356 42 54 · FAX +41 31 356 42 51 >>> | WWW.NETSTYLE.CH · [email protected] >>> >> >> >> >
