On 17 Dec 2012, at 23:44, Tudor Girba <tu...@tudorgirba.com> wrote: > 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/
Can you say anything about availability for 2.0 ? I haven't touched or worked in 1.4 for months… > 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." > > > >
