On Aug 23, 2011, at 10:01 PM, Nicolas Cellier wrote:

> Hi Michael, I did in recent past and can renew help with 4) which is
> an immediate cheap solution compared to 5), but as you have seen in 2)
> the solution is not universal.

But Squeak has exactly the same problem that pharo to this respect
I tried in 43-11481

Attachment: Screen shot 2011-08-23 at 10.07.21 PM.pdf
Description: Adobe PDF document







> On thing to remember with Decompiler, is that it sounds like a visitor
> pattern, but some very important features are sometimes implemented on
> the node side!
> This does not help understanding the too much complicated code (simple
> browsing is void, you often need debugging).
> 
> Nicolas
> 
> 2011/8/23 Michael Roberts <[email protected]>:
>> I think for the debugger, we all live with the bugs. I mean, we (I)
>> unfortunately made the situation worse with the introduction of the
>> closures around 1.0/1.1 and it has never been fixed. It is hard to fix
>> too, this stuff is not simple.  I contacted a few people quietly maybe
>> a year ago to see if we all lived with it, because a few times i
>> posted about the debugger and there was not a lot of response.  I
>> wondered if no one *actually* programmed in pharo. but no, we become
>> masters of interpreting the debugger highlight...
>> 
>> What can we do-
>> 1) I have contacted Eliot (again). Historically he said it was fixed
>> (or better) in teleplace images but I need him to send us any patches.
>> He has also been helpful and highlighted the areas that need work like
>> the decompiler and how we could write some tests to protect against
>> unintended change
>> 
>> 2) I have checked a recent Squeak, and it is bust there too.
>> 
>> 3) I am writing some test cases. So that we can regression test the
>> debugger highlighting, and building an analyser class (@esug) to make
>> it easier to dig into the debugger.
>> 
>> 4) carefully check Squeak class versions for merging changes into
>> Pharo. this is not easy.



>> 
>> 5) We have to rebuild the debugger model based on the new compiler /
>> decompiler machinery. (This is a long term Pharo goal)
>> 
>> I am just chipping away at the analysis, and i will share my code when
>> i have something on the tracker.
>> 
>> Also would be great in a separate thread if someone could explain to
>> me the simulation guard primitive. i.e you can not step over process
>> creation, but you can halt after it e.g.
>> 
>> cheers,
>> Mike
>> 
>> 
> 

Reply via email to