December 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Helping the noobs help out - i.e. fixing the debugger

by Sven Van Caekenberghe

On 18 Dec 2012, at 00:03, Tudor Girba <tudor(a)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 <sven(a)stfx.eu> wrote: > >> On 17 Dec 2012, at 23:44, Tudor Girba <tudor(a)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-alph… >> >> 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.ducasse(a)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 <siguctua(a)gmail.com> wrote: >>>>> >>>>>> On 13 December 2012 10:30, StÃ©phane Ducasse <stephane.ducasse(a)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-tp… >>>>>>>> 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." > > > > >

Dec. 18, 2012

Re: [Pharo-project] CI down?

by Ben Coman

The "Pharo 2.0 one-click (unstable)" and "integration server" links on http://www.pharo-project.org/pharo-download and http://www.pharo-project.org/pharo-download/beta-2-0 still refer to ci.lille.inria.fr btw should that be "Pharo 2.0 one-click (beta)" ? cheers -ben Marcus Denker wrote: > On Dec 17, 2012, at 2:04 AM, Jimmie Houchin <jlhouchin(a)gmail.com> wrote: > > >> On 12/16/2012 5:45 PM, Camillo Bruni wrote: >> >>> I repeat: Do not use the CI to download stuff from... >>> >>> Use our static file server: http://pharo.gforge.inria.fr/ci/ >>> >>> ci jobs may change names and jenkins is too brittle to support heavy traffic! >>> >> I think the easiest way to encourage this would be to change the website to point to the latest stable version of each of the images and vms. >> >> > I changed the links on the websiteâ¦ > > Marcus > > > > > >

Dec. 18, 2012

[Pharo-project] New Cog VMs available

by Eliot Miranda

New Cog VMs available at http://www.mirandabanda.org/files/Cog/VM/VM.r2637/. CogVM binaries as per VMMaker.oscog-eem.238/r2637 Restore ThreadedFFIPlugin wanting COGMTVM to be determined on command line. Probably broke in VMMaker.oscog-eem.218 Fix bug in changeClass:from: so that if receiver has long header and class is compact, receiver still gets compact class field set, not cleared. No matter what header an instance has, if its class is compact it should have the compact class index set. -- best, Eliot

Dec. 18, 2012

Re: [Pharo-project] CI down?

by Camillo Bruni

On 2012-12-17, at 20:39, "Sean P. DeNigris" <sean(a)clipperadams.com> wrote: > Camillo Bruni-3 wrote >> Use our static file server: http://pharo.gforge.inria.fr/ci/ > > The copy of 1.4 there looks crazy old (14415 vs. at least 14459)... I will look into it. Could be that I did not push all my 1.4 images, since I had to recreate all of them first ;)

Dec. 18, 2012

[Pharo-project] Persistence Options

by Torsten Bergmann

Dec. 17, 2012

Re: [Pharo-project] CI down?

by Sean P. DeNigris

Camillo Bruni-3 wrote > Use our static file server: http://pharo.gforge.inria.fr/ci/ The copy of 1.4 there looks crazy old (14415 vs. at least 14459)... -- View this message in context: http://forum.world.st/CI-down-tp4659453p4659709.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 17, 2012

Re: [Pharo-project] Helping the noobs help out - i.e. fixing the debugger

by Tudor Girba

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. Cheers, Doru On 17 Dec 2012, at 23:54, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > On 17 Dec 2012, at 23:44, Tudor Girba <tudor(a)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-alph… > > 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.ducasse(a)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 <siguctua(a)gmail.com> wrote: >>>> >>>>> On 13 December 2012 10:30, StÃ©phane Ducasse <stephane.ducasse(a)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-tp… >>>>>>> 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."

Dec. 17, 2012

Re: [Pharo-project] Pharo Icon Revamped

by Camillo Bruni

On 2012-12-17, at 19:26, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > I'm sorry, I don't like it at all :S haha no problem, that's why I say subjective ;) > On Dec 17, 2012, at 7:09 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> I like it. >> Just make beam to go from the middle of the tower, >> because right now it looks like beam comes from left side of it :) >> >> On 17 December 2012 19:48, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> I spent my days reactivating my Illustrator skills and tried my luck >> on the Pharo logo. I still lack the water and some perspective mismatches >> with the stripes :) but for me this looks better than the current one :) >> (as usual a highly subjective opinion). >> >> <pharo6.jpeg> >> >> cheers >> cami >> >> >> >> -- >> Best regards, >> Igor Stasenko. >

Dec. 17, 2012

Re: [Pharo-project] Helping the noobs help out - i.e. fixing the debugger

by Sven Van Caekenberghe

On 17 Dec 2012, at 23:44, Tudor Girba <tudor(a)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-alph… 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.ducasse(a)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 <siguctua(a)gmail.com> wrote: >>> >>>> On 13 December 2012 10:30, StÃ©phane Ducasse <stephane.ducasse(a)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-tp… >>>>>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>>> >>> >> >> > > -- > www.tudorgirba.com > > "Beauty is where we see it." > > > >

Dec. 17, 2012

Re: [Pharo-project] Helping the noobs help out - i.e. fixing the debugger

by Tudor Girba

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-alph… Cheers, Doru On 14 Dec 2012, at 13:31, StÃ©phane Ducasse <stephane.ducasse(a)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 <siguctua(a)gmail.com> wrote: >> >>> On 13 December 2012 10:30, StÃ©phane Ducasse <stephane.ducasse(a)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-tp… >>>>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>>>> >>>> >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> > > -- www.tudorgirba.com "Beauty is where we see it."

Dec. 17, 2012