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