Hi, Just in case someone wants to take a look: the GTDebugger is around and it is supposed to be readable and extensible (works in 1.4 for the moment): http://www.humane-assessment.com/blog/glamorous-debugger-for-smalltalk-alpha/
Cheers, Doru On 14 Dec 2012, at 13:31, Stéphane Ducasse <stephane.duca...@inria.fr> wrote: > Hi mike > > last week andrei sat with ben and they got a first sketch of a debugger using > spec and the > model extracted from the debugger. > > Then just after jorge visited us and ported/fixed Bifrost in 1.4 and 2.0 so > we will also have an > object-centric debugger. > > Stef > > On Dec 14, 2012, at 12:48 AM, Michael Roberts wrote: > >> Indeed we spent some time in Edinburgh looking at it :-) that was too long >> ago :-( >> >> The problem i see with the original debugger inherited from Squeak, in the >> Pharo context, is that it is very sensitive to a lot of the core code in the >> image. What this means is that the accelerated changes in Pharo code base >> had unintended side effects on original debugger machinery as it diverged >> from its ancestry. It goes all the way back to pushing Eliot's closure >> implementation in 1.0 which we were desperate and excited for. >> >> Since we relied on taking core compiler/closure/debugger code from Squeak it >> became more and >> more important to track the difference between squeak and Pharo. Anyone who >> has tried looking at the diffs will know how hard that is. I forget which >> class it was but we found this obscure bug in one of the collection classes >> IIRC that threw one tiny but annoying aspect of debugger highlighting off. I >> only found that by single stepping both images through known code snippets >> with this debugger 'oscilloscope' I had hacked up for the purpose. What that >> experience showed was it was really involved how the instruction machinery >> hangs together. As squeak trunk is where most fixes get pushed in this area >> it requires huge resources and diligence to track every change to see if >> Pharo needs it. For ages Stef would post every interesting looking trunk >> change to the pharo bug tracker but there were not many folks looking at >> them all. And also it is not nice work. We didn't have the tools or >> modularity to cherry pick changes in this area. >> >> So the new debugger model in Glamorous showed an interesting direction to go >> in and this comment from Marcus is also interesting on seemingly building a >> new debugger architecture which we have discussed before. I was trying to >> do was to figure out a way you could regression test the debugger by >> recording and replaying examples of it's operation and checking each release >> it hadn't been broken unexpectedly. I think there is still mileage in that >> area if it has not been done already. >> >> Also, historically, I am not convinced it was ever properly working in the >> sapphire build or even in 3.9. The bugs and effects were so subtle that you >> just got used to working around them. I.e. I have 20 mins to do some coding >> do I add a bit more to my cool seaside app or do I struggle with fixing the >> debugger? Last I looked at squeak trunk it was looking pretty good. But the >> code base is hard to track. >> >> What I was last thinking about in this area was trying to live 'trace' in >> some way all the code required by the debugger into a filed out and renamed >> set of classes like :SqDebugger SqArray SqCompiler SqInstructionStream and >> so on and then load them into Pharo. The idea being you would have an >> identical implementation that you would use to operate on all the Pharo code >> but entirely independent from it and maintained in squeak trunk. It is an >> unrealistic idea but the example i was thinking about from the electronic >> world is using one oscilloscope to test or observe the internals of another. >> You could do that image to image over the network of course but I am not >> sure if you just vary the complexity in a different direction. >> >> Anyway just my 2p, I care a lot I about the tooling and look forward to >> seeing what comes out! >> >> Cheers, >> Mike >> >> (a bit absent, but still enjoying the progress) >> >> On 13 Dec 2012, at 09:40, Igor Stasenko <siguc...@gmail.com> wrote: >> >>> On 13 December 2012 10:30, Stéphane Ducasse <stephane.duca...@inria.fr> >>> wrote: >>>> Now adrian I imagine that you saw that people worked on this bug and this >>>> is a rather complex one. >>>> So I would suggest to you to avoid to draw conclusions too fast. >>>> >>> yes, if i remember, we tried to approach it at least once.. >>> but unfortunately it requires a lot deeper knowledge about bytecode >>> and (de)optimizations to fix highlight. >>> >>>> Stef >>>> >>>> On Dec 12, 2012, at 11:28 PM, adrians wrote: >>>> >>>>> >>>>> Well, it just seems that I'm whining here instead of contributing, but if >>>>> the debugger is indeed a very (if not the most) useful tool which is used >>>>> in >>>>> pretty much every bit of fix-up work, fixing it if it is broken would have >>>>> to come before all else, no? Otherwise, any work that needs to be done >>>>> until >>>>> it is looked at is just compounded. >>>>> >>>>> Maybe it would make sense to correct (in the current code) to a small >>>>> degree >>>>> just one of the things that is currently broken. No frills, but just >>>>> getting >>>>> a more accurate indication of where the PC is - at least have it on the >>>>> correct line of code if it can't be pinpointed more accurately without too >>>>> much hassle. I'm curious what derails the location highlighting as half of >>>>> the time it is close, if not correct. Is it blocks that give it a hard >>>>> time? >>>>> It wouldn't be too bad if other things were going to take a while if you >>>>> could at least keep track of where you were. >>>>> >>>>> If the idea is to wait until a whole big refactoring can be done on this, >>>>> I >>>>> fear a fully debugger might be another year away. >>>>> >>>>> -- Adrian >>>>> >>>>> >>>>> >>>>> -- >>>>> View this message in context: >>>>> http://forum.world.st/Helping-the-noobs-help-out-i-e-fixing-the-debugger-tp4658666p4659105.html >>>>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>>>> >>>> >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> > > -- www.tudorgirba.com "Beauty is where we see it."
