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