[Pharo-project] Helping the noobs help out - i.e. fixing the debugger
Hi, I'm a Smalltalk newbie and I would like to help fix some simpler issues. For example, I've recently logged some issues surrounding smart character use. I set a breakpoint in NECController>>#smartCharacterWithEvent: and proceeded to debug. Now, I understand that for the old-timers stepping through a selector is straightforward, no matter what help the debugger gives you. For myself, and likely many other Smalltalk noobs who'd like to help, I need all the help I can get. One such support is an accurate indication of where the PC is as you step through a body of code. Currently, in the 2.0 one-click image (build 20431), things seem quite broken wrt getting accurate visual feedback of where you are. First, as you step over message sends, the highlighted selection is shown in a totally incorrect spot. Sometimes, just a bit off from where you expect to be, but sometimes quite a bit off, for example in a block that should not even be entered. In the selector I mentioned above, the highlighted location enters the "editor hasSelection ifTrue: []" block when "editor hasSelection" returns false. Second, the PC location highlight is removed when you click somewhere inside the code. This should never turn off - it's as if you switch the lights off, for people not familiar with some particular code. I know you can use the "Where" button to re-establish the highlight, but other than the fact that you shouldn't have to do this, the highlighted selection is sometimes shown in the wrong place. Third, as you step through code, you would expect that the values of variables as shown in the bottom right panel of the debugger are accurately updated as state changes. I've seen cases, relatively frequent, where this is not so. Current values are shown only after some further advancement through code. There is an old issue tracking debugger selection, http://code.google.com/p/pharo/issues/detail?id=709 <http://code.google.com/p/pharo/issues/detail?id=709> , but fixing the problem seems to have stalled. Additionally, I'm not sure that this particular issue addresses the third point I made about stale variable values being shown. Could I ask that making the debugger work be made a priority? Of course one can muddle through some code even with visually broken indicators, but it should not be so, IMO. The old timers can make the case that there are other more pressing issues to be addressed, but IMO it makes sense to make the actual tool used to fix problems as helpful as possible for everyone so that even non-experts can be productive and lend a helping hand. Cheers, Adrian -- View this message in context: http://forum.world.st/Helping-the-noobs-help-out-i-e-fixing-the-debugger-tp4... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
No, old timers are equally upset by false/wrong visual feedback, especially when they remember this used to work 25 years ago ;) Nicolas 2012/12/9 adrians <nmanole@gmail.com>:
Hi,
I'm a Smalltalk newbie and I would like to help fix some simpler issues. For example, I've recently logged some issues surrounding smart character use. I set a breakpoint in NECController>>#smartCharacterWithEvent: and proceeded to debug.
Now, I understand that for the old-timers stepping through a selector is straightforward, no matter what help the debugger gives you. For myself, and likely many other Smalltalk noobs who'd like to help, I need all the help I can get. One such support is an accurate indication of where the PC is as you step through a body of code. Currently, in the 2.0 one-click image (build 20431), things seem quite broken wrt getting accurate visual feedback of where you are.
First, as you step over message sends, the highlighted selection is shown in a totally incorrect spot. Sometimes, just a bit off from where you expect to be, but sometimes quite a bit off, for example in a block that should not even be entered. In the selector I mentioned above, the highlighted location enters the "editor hasSelection ifTrue: []" block when "editor hasSelection" returns false.
Second, the PC location highlight is removed when you click somewhere inside the code. This should never turn off - it's as if you switch the lights off, for people not familiar with some particular code. I know you can use the "Where" button to re-establish the highlight, but other than the fact that you shouldn't have to do this, the highlighted selection is sometimes shown in the wrong place.
Third, as you step through code, you would expect that the values of variables as shown in the bottom right panel of the debugger are accurately updated as state changes. I've seen cases, relatively frequent, where this is not so. Current values are shown only after some further advancement through code.
There is an old issue tracking debugger selection, http://code.google.com/p/pharo/issues/detail?id=709 <http://code.google.com/p/pharo/issues/detail?id=709> , but fixing the problem seems to have stalled. Additionally, I'm not sure that this particular issue addresses the third point I made about stale variable values being shown.
Could I ask that making the debugger work be made a priority? Of course one can muddle through some code even with visually broken indicators, but it should not be so, IMO. The old timers can make the case that there are other more pressing issues to be addressed, but IMO it makes sense to make the actual tool used to fix problems as helpful as possible for everyone so that even non-experts can be productive and lend a helping hand.
Cheers, Adrian
-- View this message in context: http://forum.world.st/Helping-the-noobs-help-out-i-e-fixing-the-debugger-tp4... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Hi, Yes, we should improve the debugger⦠There are some nice things happening around the debugger -> In Berne, Andrei made a DebuggerModel and a Glamour UI for it. In the current Debugger, Model and View are completely mixed (and the implementation is kind of old style, that is, very low level and complex) Last week He and Ben did an experiment to get a second UI working (Spec). -> Clement and Camillo did an AST Interpreter for the RB AST. We are evaluating if this can not replace the context step simulator based parts⦠-> For later, we would like to integrate the idea of object centric debugging (halt on next ivar change, halt on next messageâ¦) -> ⦠The problem right now is that the debugger infrastructure is far more complicated than it should be, making is hard to change, fix and improve it. Marcus On Dec 9, 2012, at 11:07 PM, adrians <nmanole@gmail.com> wrote:
Hi,
I'm a Smalltalk newbie and I would like to help fix some simpler issues. For example, I've recently logged some issues surrounding smart character use. I set a breakpoint in NECController>>#smartCharacterWithEvent: and proceeded to debug.
Now, I understand that for the old-timers stepping through a selector is straightforward, no matter what help the debugger gives you. For myself, and likely many other Smalltalk noobs who'd like to help, I need all the help I can get. One such support is an accurate indication of where the PC is as you step through a body of code. Currently, in the 2.0 one-click image (build 20431), things seem quite broken wrt getting accurate visual feedback of where you are.
First, as you step over message sends, the highlighted selection is shown in a totally incorrect spot. Sometimes, just a bit off from where you expect to be, but sometimes quite a bit off, for example in a block that should not even be entered. In the selector I mentioned above, the highlighted location enters the "editor hasSelection ifTrue: []" block when "editor hasSelection" returns false.
Second, the PC location highlight is removed when you click somewhere inside the code. This should never turn off - it's as if you switch the lights off, for people not familiar with some particular code. I know you can use the "Where" button to re-establish the highlight, but other than the fact that you shouldn't have to do this, the highlighted selection is sometimes shown in the wrong place.
Third, as you step through code, you would expect that the values of variables as shown in the bottom right panel of the debugger are accurately updated as state changes. I've seen cases, relatively frequent, where this is not so. Current values are shown only after some further advancement through code.
There is an old issue tracking debugger selection, http://code.google.com/p/pharo/issues/detail?id=709 <http://code.google.com/p/pharo/issues/detail?id=709> , but fixing the problem seems to have stalled. Additionally, I'm not sure that this particular issue addresses the third point I made about stale variable values being shown.
Could I ask that making the debugger work be made a priority? Of course one can muddle through some code even with visually broken indicators, but it should not be so, IMO. The old timers can make the case that there are other more pressing issues to be addressed, but IMO it makes sense to make the actual tool used to fix problems as helpful as possible for everyone so that even non-experts can be productive and lend a helping hand.
Cheers, Adrian
-- View this message in context: http://forum.world.st/Helping-the-noobs-help-out-i-e-fixing-the-debugger-tp4... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On 11 December 2012 09:32, Marcus Denker <marcus.denker@inria.fr> wrote:
Hi,
The problem right now is that the debugger infrastructure is far more complicated than it should be, making is hard to change, fix and improve it.
some things are inherently complex. of course, proper (re)factoring helps.. but not much :)
Marcus
-- Best regards, Igor Stasenko.
Just out of curiosity.. How does the cutting edge of LISP compare to what we have in Pharo at the moment? I've read somewhere that smalltalk has the best refactoring/debugging tools. Would you agree with that? Are there object centric lisp debuggers? If someone asked you 'why are you working on a smalltalk implementation and not some lisp?', what would your answer be? I suppose nicer syntax might be the first thing that comes to mind, but I don't see that as being super important. Of course, I realise lispers might use a more functional style, but you could be writing smalltalk style code in CLOS or something, right? Feel free to ignore these questions if you're not interested. I'm just musing. On Tue, Dec 11, 2012 at 8:32 AM, Marcus Denker <marcus.denker@inria.fr> wrote:
Hi,
Yes, we should improve the debuggerâ¦
There are some nice things happening around the debugger -> In Berne, Andrei made a DebuggerModel and a Glamour UI for it. In the current Debugger, Model and View are completely mixed (and the implementation is kind of old style, that is, very low level and complex) Last week He and Ben did an experiment to get a second UI working (Spec).
-> Clement and Camillo did an AST Interpreter for the RB AST. We are evaluating if this can not replace the context step simulator based partsâ¦
-> For later, we would like to integrate the idea of object centric debugging (halt on next ivar change, halt on next messageâ¦)
-> â¦
The problem right now is that the debugger infrastructure is far more complicated than it should be, making is hard to change, fix and improve it.
Marcus
On Dec 9, 2012, at 11:07 PM, adrians <nmanole@gmail.com> wrote:
Hi,
I'm a Smalltalk newbie and I would like to help fix some simpler issues. For example, I've recently logged some issues surrounding smart character use. I set a breakpoint in NECController>>#smartCharacterWithEvent: and proceeded to debug.
Now, I understand that for the old-timers stepping through a selector is straightforward, no matter what help the debugger gives you. For myself, and likely many other Smalltalk noobs who'd like to help, I need all the help I can get. One such support is an accurate indication of where the PC is as you step through a body of code. Currently, in the 2.0 one-click image (build 20431), things seem quite broken wrt getting accurate visual feedback of where you are.
First, as you step over message sends, the highlighted selection is shown in a totally incorrect spot. Sometimes, just a bit off from where you expect to be, but sometimes quite a bit off, for example in a block that should not even be entered. In the selector I mentioned above, the highlighted location enters the "editor hasSelection ifTrue: []" block when "editor hasSelection" returns false.
Second, the PC location highlight is removed when you click somewhere inside the code. This should never turn off - it's as if you switch the lights off, for people not familiar with some particular code. I know you can use the "Where" button to re-establish the highlight, but other than the fact that you shouldn't have to do this, the highlighted selection is sometimes shown in the wrong place.
Third, as you step through code, you would expect that the values of variables as shown in the bottom right panel of the debugger are accurately updated as state changes. I've seen cases, relatively frequent, where this is not so. Current values are shown only after some further advancement through code.
There is an old issue tracking debugger selection, http://code.google.com/p/pharo/issues/detail?id=709 <http://code.google.com/p/pharo/issues/detail?id=709> , but fixing the problem seems to have stalled. Additionally, I'm not sure that this particular issue addresses the third point I made about stale variable values being shown.
Could I ask that making the debugger work be made a priority? Of course one can muddle through some code even with visually broken indicators, but it should not be so, IMO. The old timers can make the case that there are other more pressing issues to be addressed, but IMO it makes sense to make the actual tool used to fix problems as helpful as possible for everyone so that even non-experts can be productive and lend a helping hand.
Cheers, Adrian
-- View this message in context: http://forum.world.st/Helping-the-noobs-help-out-i-e-fixing-the-debugger-tp4... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On Dec 11, 2012, at 4:38 PM, Peter H. Meadows <peter.h.meadows@googlemail.com> wrote:
Just out of curiosity.. How does the cutting edge of LISP compare to what we have in Pharo at the moment? I've read somewhere that smalltalk has the best refactoring/debugging tools. Would you agree with that? Are there object centric lisp debuggers? If someone asked you 'why are you working on a smalltalk implementation and not some lisp?', what would your answer be? I suppose nicer syntax might be the first thing that comes to mind, but I don't see that as being super important. Of course, I realise lispers might use a more functional style, but you could be writing smalltalk style code in CLOS or something, right?
Feel free to ignore these questions if you're not interested. I'm just musing.
my problem is timeâ¦
On Tue, Dec 11, 2012 at 8:32 AM, Marcus Denker <marcus.denker@inria.fr> wrote:
Hi,
Yes, we should improve the debuggerâ¦
There are some nice things happening around the debugger -> In Berne, Andrei made a DebuggerModel and a Glamour UI for it. In the current Debugger, Model and View are completely mixed (and the implementation is kind of old style, that is, very low level and complex) Last week He and Ben did an experiment to get a second UI working (Spec).
-> Clement and Camillo did an AST Interpreter for the RB AST. We are evaluating if this can not replace the context step simulator based partsâ¦
-> For later, we would like to integrate the idea of object centric debugging (halt on next ivar change, halt on next messageâ¦)
-> â¦
The problem right now is that the debugger infrastructure is far more complicated than it should be, making is hard to change, fix and improve it.
Marcus
On Dec 9, 2012, at 11:07 PM, adrians <nmanole@gmail.com> wrote:
Hi,
I'm a Smalltalk newbie and I would like to help fix some simpler issues. For example, I've recently logged some issues surrounding smart character use. I set a breakpoint in NECController>>#smartCharacterWithEvent: and proceeded to debug.
Now, I understand that for the old-timers stepping through a selector is straightforward, no matter what help the debugger gives you. For myself, and likely many other Smalltalk noobs who'd like to help, I need all the help I can get. One such support is an accurate indication of where the PC is as you step through a body of code. Currently, in the 2.0 one-click image (build 20431), things seem quite broken wrt getting accurate visual feedback of where you are.
First, as you step over message sends, the highlighted selection is shown in a totally incorrect spot. Sometimes, just a bit off from where you expect to be, but sometimes quite a bit off, for example in a block that should not even be entered. In the selector I mentioned above, the highlighted location enters the "editor hasSelection ifTrue: []" block when "editor hasSelection" returns false.
Second, the PC location highlight is removed when you click somewhere inside the code. This should never turn off - it's as if you switch the lights off, for people not familiar with some particular code. I know you can use the "Where" button to re-establish the highlight, but other than the fact that you shouldn't have to do this, the highlighted selection is sometimes shown in the wrong place.
Third, as you step through code, you would expect that the values of variables as shown in the bottom right panel of the debugger are accurately updated as state changes. I've seen cases, relatively frequent, where this is not so. Current values are shown only after some further advancement through code.
There is an old issue tracking debugger selection, http://code.google.com/p/pharo/issues/detail?id=709 <http://code.google.com/p/pharo/issues/detail?id=709> , but fixing the problem seems to have stalled. Additionally, I'm not sure that this particular issue addresses the third point I made about stale variable values being shown.
Could I ask that making the debugger work be made a priority? Of course one can muddle through some code even with visually broken indicators, but it should not be so, IMO. The old timers can make the case that there are other more pressing issues to be addressed, but IMO it makes sense to make the actual tool used to fix problems as helpful as possible for everyone so that even non-experts can be productive and lend a helping hand.
Cheers, Adrian
-- View this message in context: http://forum.world.st/Helping-the-noobs-help-out-i-e-fixing-the-debugger-tp4... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On 11 December 2012 15:37, Peter H. Meadows <peter.h.meadows@googlemail.com> wrote:
Just out of curiosity.. How does the cutting edge of LISP compare to what we have in Pharo at the moment? I've read somewhere that smalltalk has the best refactoring/debugging tools. Would you agree with that? Are there object centric lisp debuggers? If someone asked you 'why are you working on a smalltalk implementation and not some lisp?', what would your answer be? I suppose nicer syntax might be the first thing that comes to mind, but I don't see that as being super important. Of course, I realise lispers might use a more functional style, but you could be writing smalltalk style code in CLOS or something, right?
The state of the art in debugging etc. in Clojure at least, is abominable. Mainly, I guess, because of a lack of time. Regarding style, there doesn't have to be that big a difference between the Lisps and Smalltalk. As a probable example of Smalltalk in Clojure, take a look at https://github.com/frankshearar/clj-derp. I didn't really _intend_ to write Smalltalk-like code, but that's how it happened. I don't really have a good example of Clojure written in Smalltalk, partly because I'm quite new to Clojure. http://ss3.gemstone.com/ss/ParsingDerivatives.html might come close, if you look in methods like DerivingParser class >> deriverBlock. Of course, both the above examples might be firmly in the class of "don't do that". frank
Feel free to ignore these questions if you're not interested. I'm just musing.
On Tue, Dec 11, 2012 at 8:32 AM, Marcus Denker <marcus.denker@inria.fr> wrote:
Hi,
Yes, we should improve the debuggerâ¦
There are some nice things happening around the debugger -> In Berne, Andrei made a DebuggerModel and a Glamour UI for it. In the current Debugger, Model and View are completely mixed (and the implementation is kind of old style, that is, very low level and complex) Last week He and Ben did an experiment to get a second UI working (Spec).
-> Clement and Camillo did an AST Interpreter for the RB AST. We are evaluating if this can not replace the context step simulator based partsâ¦
-> For later, we would like to integrate the idea of object centric debugging (halt on next ivar change, halt on next messageâ¦)
-> â¦
The problem right now is that the debugger infrastructure is far more complicated than it should be, making is hard to change, fix and improve it.
Marcus
On Dec 9, 2012, at 11:07 PM, adrians <nmanole@gmail.com> wrote:
Hi,
I'm a Smalltalk newbie and I would like to help fix some simpler issues. For example, I've recently logged some issues surrounding smart character use. I set a breakpoint in NECController>>#smartCharacterWithEvent: and proceeded to debug.
Now, I understand that for the old-timers stepping through a selector is straightforward, no matter what help the debugger gives you. For myself, and likely many other Smalltalk noobs who'd like to help, I need all the help I can get. One such support is an accurate indication of where the PC is as you step through a body of code. Currently, in the 2.0 one-click image (build 20431), things seem quite broken wrt getting accurate visual feedback of where you are.
First, as you step over message sends, the highlighted selection is shown in a totally incorrect spot. Sometimes, just a bit off from where you expect to be, but sometimes quite a bit off, for example in a block that should not even be entered. In the selector I mentioned above, the highlighted location enters the "editor hasSelection ifTrue: []" block when "editor hasSelection" returns false.
Second, the PC location highlight is removed when you click somewhere inside the code. This should never turn off - it's as if you switch the lights off, for people not familiar with some particular code. I know you can use the "Where" button to re-establish the highlight, but other than the fact that you shouldn't have to do this, the highlighted selection is sometimes shown in the wrong place.
Third, as you step through code, you would expect that the values of variables as shown in the bottom right panel of the debugger are accurately updated as state changes. I've seen cases, relatively frequent, where this is not so. Current values are shown only after some further advancement through code.
There is an old issue tracking debugger selection, http://code.google.com/p/pharo/issues/detail?id=709 <http://code.google.com/p/pharo/issues/detail?id=709> , but fixing the problem seems to have stalled. Additionally, I'm not sure that this particular issue addresses the third point I made about stale variable values being shown.
Could I ask that making the debugger work be made a priority? Of course one can muddle through some code even with visually broken indicators, but it should not be so, IMO. The old timers can make the case that there are other more pressing issues to be addressed, but IMO it makes sense to make the actual tool used to fix problems as helpful as possible for everyone so that even non-experts can be productive and lend a helping hand.
Cheers, Adrian
-- View this message in context: http://forum.world.st/Helping-the-noobs-help-out-i-e-fixing-the-debugger-tp4... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Hi Marcus, I figured it must be the complexity of fixing the debugger that's keeping it in the broken state that it is for this long. Mainly I wanted to get a sense of how important is fixing this relative to the other things that need fixing. It would seem to me that fixing the tool that you use to fix things in general would be right up there, but maybe, possibly because the people capable of fixing this aren't significantly handicapped by the issues, this is not as much a priority as it could be. Would you know if there is any chance some of these problems will be fixed for 2.0? Regards, Adrian -- View this message in context: http://forum.world.st/Helping-the-noobs-help-out-i-e-fixing-the-debugger-tp4... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On Dec 11, 2012, at 5:10 PM, adrians <nmanole@gmail.com> wrote:
Hi Marcus,
I figured it must be the complexity of fixing the debugger that's keeping it in the broken state that it is for this long. Mainly I wanted to get a sense of how important is fixing this relative to the other things that need fixing. It would seem to me that fixing the tool that you use to fix things in general would be right up there, but maybe, possibly because the people capable of fixing this aren't significantly handicapped by the issues, this is not as much a priority as it could be.
A lot of things are important, yet the day has just 24 hours.
Would you know if there is any chance some of these problems will be fixed for 2.0?
I they are fixed they are fixed, if not then not. :-) Marcus
Marcus, I guess you answered my question regarding priority - i.e. it's not right at the top. For myself, if I used one tool in everything I did, and it was broken, fixing it would have to be close to the number one thing to address, otherwise every job would take longer than it has to. This, unfortunately, seems to happen often in any domain as the experts are good enough not to be slowed down significantly even with problem tools. This seems to be shortsighted since the complaint is that there is not enough time for everything that needs fixing, but probably a good number of things that need looking at could be corrected by less expert people if only the tools were more solid. What can you do when you live in a shoe? Wait... -- Adrian -- View this message in context: http://forum.world.st/Helping-the-noobs-help-out-i-e-fixing-the-debugger-tp4... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On Dec 11, 2012, at 5:39 PM, adrians <nmanole@gmail.com> wrote:
Marcus,
I guess you answered my question regarding priority - i.e. it's not right at the top. For myself, if I used one tool in everything I did, and it was broken, fixing it would have to be close to the number one thing to address, otherwise every job would take longer than it has to. This, unfortunately, seems to happen often in any domain as the experts are good enough not to be slowed down significantly even with problem tools.
But isn't that true for everything we use? That is, the whole of Pharo?
This seems to be shortsighted since the complaint is that there is not enough time for everything that needs fixing, but probably a good number of things that need looking at could be corrected by less expert people if only the tools were more solid.
Nevertheless, there are only 24 hours in a day. I am full, I can not do more. Marcus
Of course not all of what needs to be done in Pharo should be of at same priority. It makes sense to first fix the tools one uses for fixing everything else, so that one can speed up one's own work and at the same time open up the possibility for others (less skilled) to help out. In any case I'm sorry if it seems that I'm demanding you or anyone else should make this a higher priority. The thinking was that maybe there is someone (Stephane D?) who, to some degree, can prioritize certain things over others and if so, wouldn't it make sense to fix the most basic tool that is used to help fix everything else? Who knows though, maybe the debugger is not often used by the experts. -- Adrian -- View this message in context: http://forum.world.st/Helping-the-noobs-help-out-i-e-fixing-the-debugger-tp4... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On Tue, Dec 11, 2012 at 8:58 AM, adrians <nmanole@gmail.com> wrote:
Of course not all of what needs to be done in Pharo should be of at same priority. It makes sense to first fix the tools one uses for fixing everything else, so that one can speed up one's own work and at the same time open up the possibility for others (less skilled) to help out.
In any case I'm sorry if it seems that I'm demanding you or anyone else should make this a higher priority. The thinking was that maybe there is someone (Stephane D?) who, to some degree, can prioritize certain things over others and if so, wouldn't it make sense to fix the most basic tool that is used to help fix everything else?
Who knows though, maybe the debugger is not often used by the experts.
On the contrary. Many experts program in the debugger (one defines a method when one gets a doesNotUnderstand:). Many experts use the debugger to explore code (running code is a powerful aid to understanding). Some experts use the simulation machinery that underlies the debugger to do things like partial evaluation for type analysis etc.
-- Adrian
-- View this message in context: http://forum.world.st/Helping-the-noobs-help-out-i-e-fixing-the-debugger-tp4... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- best, Eliot
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-tp4... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
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.
Your analysis is right. No this is not the idea. We never waited for big bang. But frankly I invite to come in our team to see us fully busy. Because we are doing far more than Pharo. Stef
-- Adrian
-- View this message in context: http://forum.world.st/Helping-the-noobs-help-out-i-e-fixing-the-debugger-tp4... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
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. 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-tp4... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On 13 December 2012 10:30, Stéphane Ducasse <stephane.ducasse@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-tp4... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko.
On Thu, Dec 13, 2012 at 10:40 AM, Igor Stasenko <siguctua@gmail.com> wrote:
On 13 December 2012 10:30, Stéphane Ducasse <stephane.ducasse@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.
I looked at it a bit on the train... With the new infrastructure, we create an intermediate representation which is (nearly) a 1:1 mapping to bytecode (some are mapped to multiple bytecode, multiple IR nodes can result in just one BC), but mostly: 1:1 mapping. The nice thing is that the IRnode records the offset of the bytecode when bytecode is emitted. And the IR knows the AST Node it was created from. And the AST node knows everything (down to the Tokens and the offset in the source text). after adding #instructionForPC: to IRMethod (which just searches for the node), the following code just works: | method astNode| method := Integer>>#+. astNode := (method parseTree ir instructionForPC: 58) sourceNode. method sourceCode copyFrom: astNode debugHighlightStart to: astNode debugHighlightStop returns 'ifTrue: [^ (self digitAdd: aNumber) normalize] ifFalse: [^ self digitSubtract: aNumber]' This needs to be tested and enhanced a bit (e.g. for the case that one IR created multiple bytecodes, e.g. block pre-amble and postscript...). But it should not be that hard to do, I think. The good thing is that it does not rely on some table that is created somewhere, but instead you have the data (IR and AST) directly there to look at. Tweaking special cases should be quite easy with that. Marcus -- Marcus Denker -- denker@acm.org http://www.marcusdenker.de
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@gmail.com> wrote:
On 13 December 2012 10:30, Stéphane Ducasse <stephane.ducasse@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-tp4... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko.
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@gmail.com> wrote:
On 13 December 2012 10:30, Stéphane Ducasse <stephane.ducasse@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-tp4... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko.
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.ducasse@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@gmail.com> wrote:
On 13 December 2012 10:30, Stéphane Ducasse <stephane.ducasse@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-tp4... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko.
-- www.tudorgirba.com "Beauty is where we see it."
On 17 Dec 2012, at 23:44, Tudor Girba <tudor@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.ducasse@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@gmail.com> wrote:
On 13 December 2012 10:30, Stéphane Ducasse <stephane.ducasse@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-tp4... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko.
-- www.tudorgirba.com
"Beauty is where we see it."
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@stfx.eu> wrote:
On 17 Dec 2012, at 23:44, Tudor Girba <tudor@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.ducasse@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@gmail.com> wrote:
On 13 December 2012 10:30, Stéphane Ducasse <stephane.ducasse@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-tp4... 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."
On 18 Dec 2012, at 00:03, Tudor Girba <tudor@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@stfx.eu> wrote:
On 17 Dec 2012, at 23:44, Tudor Girba <tudor@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.ducasse@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@gmail.com> wrote:
On 13 December 2012 10:30, Stéphane Ducasse <stephane.ducasse@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-tp4... 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."
Hi adrian this is not that we do not want to fix issues. This is that some are killing us while others are letting us to breath. Now we can argue for hours about priority. The best things to do is to try. And I can tell you that the debugger is important for us - this is our best friend. But it gets a bit old. To me having the UI defined in another class was strange for years. We fixed it. And as marcus said we are working :) and quite busy. Stef
Hi,
I'm a Smalltalk newbie and I would like to help fix some simpler issues. For example, I've recently logged some issues surrounding smart character use. I set a breakpoint in NECController>>#smartCharacterWithEvent: and proceeded to debug.
Now, I understand that for the old-timers stepping through a selector is straightforward, no matter what help the debugger gives you. For myself, and likely many other Smalltalk noobs who'd like to help, I need all the help I can get. One such support is an accurate indication of where the PC is as you step through a body of code. Currently, in the 2.0 one-click image (build 20431), things seem quite broken wrt getting accurate visual feedback of where you are.
First, as you step over message sends, the highlighted selection is shown in a totally incorrect spot. Sometimes, just a bit off from where you expect to be, but sometimes quite a bit off, for example in a block that should not even be entered. In the selector I mentioned above, the highlighted location enters the "editor hasSelection ifTrue: []" block when "editor hasSelection" returns false.
Second, the PC location highlight is removed when you click somewhere inside the code. This should never turn off - it's as if you switch the lights off, for people not familiar with some particular code. I know you can use the "Where" button to re-establish the highlight, but other than the fact that you shouldn't have to do this, the highlighted selection is sometimes shown in the wrong place.
Third, as you step through code, you would expect that the values of variables as shown in the bottom right panel of the debugger are accurately updated as state changes. I've seen cases, relatively frequent, where this is not so. Current values are shown only after some further advancement through code.
There is an old issue tracking debugger selection, http://code.google.com/p/pharo/issues/detail?id=709 <http://code.google.com/p/pharo/issues/detail?id=709> , but fixing the problem seems to have stalled. Additionally, I'm not sure that this particular issue addresses the third point I made about stale variable values being shown.
Could I ask that making the debugger work be made a priority? Of course one can muddle through some code even with visually broken indicators, but it should not be so, IMO. The old timers can make the case that there are other more pressing issues to be addressed, but IMO it makes sense to make the actual tool used to fix problems as helpful as possible for everyone so that even non-experts can be productive and lend a helping hand.
Cheers, Adrian
-- View this message in context: http://forum.world.st/Helping-the-noobs-help-out-i-e-fixing-the-debugger-tp4... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
participants (11)
-
adrians -
Eliot Miranda -
Frank Shearar -
Igor Stasenko -
Marcus Denker -
Michael Roberts -
Nicolas Cellier -
Peter H. Meadows -
Stéphane Ducasse -
Sven Van Caekenberghe -
Tudor Girba