2011/8/23 Stéphane Ducasse <[email protected]>: > > 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 >
Yes, not universal just means that... > > > > > >> 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 >>> >>> >> > > >
