On 18 Dec 2012, at 00:03, Tudor Girba <tu...@tudorgirba.com> wrote: > It essentially depends on Glamour. Andrei and Damien looked at this issue, > and it is essentially working with a few glitches. It will likely be > available early in the new year.
Great, looking forward to it, and to Glamour/Moose coming to 2.0 as well. > Cheers, > Doru > > > On 17 Dec 2012, at 23:54, Sven Van Caekenberghe <s...@stfx.eu> wrote: > >> 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." >>> >>> >>> >>> >> >> > > -- > www.tudorgirba.com > > "Problem solving should be focused on describing > the problem in a way that makes the solution obvious." > > > > >
