Debugger is not stable
Hi I'm debugging a simple algo for a first exercises in Pharo future book and I get stepToSendOrReturn DNU when using the debugger. :(((((((((((((((((((((((((((((((((((( You see I would really like in Pharo that we get new tools only when there are better than the old ones. I still could not see how GTDebugger helps me debugging faster my programs. Personally the fact that GT debugger can show bytecodes or can be extended is not in the critical path. My critical path is that I can debug Pharo programs and now I cannot. I also did not see any comments on the multiple complaints about the funky place for the buttons. So to me GTDebugger is a disappointement. Here is the kind of code I'm debugging so this is not that complex nor implying concurrency or whatever complex. coinsFor: aValue into2: accuWallet | accu | self halt. [ accu := accuWallet money. accu < aValue ] whileTrue: [ | big | big := self biggest. [ big > (aValue - accu) ] whileTrue: [ big := self biggestBelow: big ]. self removeCoin: big. accuWallet addCoin: big ]. ^ accuWallet Stef
Hi Stef, Can you provide a way to load or access the entire code of your example? Cheers, Andrei On Fri, Jun 3, 2016 at 9:43 PM, stepharo <stepharo@free.fr> wrote:
Hi
I'm debugging a simple algo for a first exercises in Pharo future book and I get stepToSendOrReturn
DNU when using the debugger. :((((((((((((((((((((((((((((((((((((
You see I would really like in Pharo that we get new tools only when there are better than the old
ones. I still could not see how GTDebugger helps me debugging faster my programs.
Personally the fact that GT debugger can show bytecodes or can be extended is not in the critical path.
My critical path is that I can debug Pharo programs and now I cannot.
I also did not see any comments on the multiple complaints about the funky place for the buttons.
So to me GTDebugger is a disappointement.
Here is the kind of code I'm debugging so this is not that complex nor implying concurrency or whatever complex.
coinsFor: aValue into2: accuWallet
| accu | self halt. [ accu := accuWallet money. accu < aValue ] whileTrue: [ | big | big := self biggest. [ big > (aValue - accu) ] whileTrue: [ big := self biggestBelow: big ]. self removeCoin: big. accuWallet addCoin: big ]. ^ accuWallet
Stef
Hi andrei ThibaultDucasse/Wallet And remove the roundTo: 0.1 in the coinFor:into2: method. The while loop will iterate forever and pressing on into nearly kill you else you get killed by DNU from the debugger. Stef PS: Yes I know I'm the stupider guy in the world because I criticise the wonderful GT tools and I should not because it is not acceptable :) Le 3/6/16 à 22:01, Andrei Chis a écrit :
Hi Stef,
Can you provide a way to load or access the entire code of your example?
Cheers, Andrei
On Fri, Jun 3, 2016 at 9:43 PM, stepharo <stepharo@free.fr <mailto:stepharo@free.fr>> wrote:
Hi
I'm debugging a simple algo for a first exercises in Pharo future book and I get stepToSendOrReturn
DNU when using the debugger. :((((((((((((((((((((((((((((((((((((
You see I would really like in Pharo that we get new tools only when there are better than the old
ones. I still could not see how GTDebugger helps me debugging faster my programs.
Personally the fact that GT debugger can show bytecodes or can be extended is not in the critical path.
My critical path is that I can debug Pharo programs and now I cannot.
I also did not see any comments on the multiple complaints about the funky place for the buttons.
So to me GTDebugger is a disappointement.
Here is the kind of code I'm debugging so this is not that complex nor implying concurrency or whatever complex.
coinsFor: aValue into2: accuWallet
| accu | self halt. [ accu := accuWallet money. accu < aValue ] whileTrue: [ | big | big := self biggest. [ big > (aValue - accu) ] whileTrue: [ big := self biggestBelow: big ]. self removeCoin: big. accuWallet addCoin: big ]. ^ accuWallet
Stef
Hi,
On Jun 4, 2016, at 9:08 AM, stepharo <stepharo@free.fr> wrote:
Hi andrei ThibaultDucasse/Wallet
And remove the roundTo: 0.1 in the coinFor:into2: method. The while loop will iterate forever and pressing on into nearly kill you
else you get killed by DNU from the debugger.
Thanks for the code. Now, how do I trigger the debugger problem? @Andrei: you can load the code like this: Gofer new smalltalkhubUser: 'thibautducasse' project: 'wallet'; package: 'Wallet'; load Cheers, Doru
Stef PS: Yes I know I'm the stupider guy in the world because I criticise the wonderful GT tools and I should not because it is not acceptable :)
Le 3/6/16 à 22:01, Andrei Chis a écrit :
Hi Stef,
Can you provide a way to load or access the entire code of your example?
Cheers, Andrei
On Fri, Jun 3, 2016 at 9:43 PM, stepharo <stepharo@free.fr> wrote: Hi
I'm debugging a simple algo for a first exercises in Pharo future book and I get stepToSendOrReturn
DNU when using the debugger. :((((((((((((((((((((((((((((((((((((
You see I would really like in Pharo that we get new tools only when there are better than the old
ones. I still could not see how GTDebugger helps me debugging faster my programs.
Personally the fact that GT debugger can show bytecodes or can be extended is not in the critical path.
My critical path is that I can debug Pharo programs and now I cannot.
I also did not see any comments on the multiple complaints about the funky place for the buttons.
So to me GTDebugger is a disappointement.
Here is the kind of code I'm debugging so this is not that complex nor implying concurrency or whatever complex.
coinsFor: aValue into2: accuWallet
| accu | self halt. [ accu := accuWallet money. accu < aValue ] whileTrue: [ | big | big := self biggest. [ big > (aValue - accu) ] whileTrue: [ big := self biggestBelow: big ]. self removeCoin: big. accuWallet addCoin: big ]. ^ accuWallet
Stef
-- www.tudorgirba.com www.feenk.com "What we can governs what we wish."
Hi Stef, On Sat, Jun 4, 2016 at 9:08 AM, stepharo <stepharo@free.fr> wrote:
Hi andrei
ThibaultDucasse/Wallet
And remove the roundTo: 0.1 in the coinFor:into2: method.
The while loop will iterate forever and pressing on into nearly kill you
else you get killed by DNU from the debugger.
I loaded the code, removed #roundTo: 0.1 in #coinFor:into2:, and experimented with #testCoinsForPayingWithOtherCoins which seems to trigger the recursion but I cannot reproduce the error. Do you use a particular Wallet object? What image are you using? Can you fuel out and send the stack if you get this error again? Cheers, Andrei Stef
PS: Yes I know I'm the stupider guy in the world because I criticise the wonderful GT tools and I should not because it is not acceptable :)
Le 3/6/16 à 22:01, Andrei Chis a écrit :
Hi Stef,
Can you provide a way to load or access the entire code of your example?
Cheers, Andrei
On Fri, Jun 3, 2016 at 9:43 PM, stepharo <stepharo@free.fr> wrote:
Hi
I'm debugging a simple algo for a first exercises in Pharo future book and I get stepToSendOrReturn
DNU when using the debugger. :((((((((((((((((((((((((((((((((((((
You see I would really like in Pharo that we get new tools only when there are better than the old
ones. I still could not see how GTDebugger helps me debugging faster my programs.
Personally the fact that GT debugger can show bytecodes or can be extended is not in the critical path.
My critical path is that I can debug Pharo programs and now I cannot.
I also did not see any comments on the multiple complaints about the funky place for the buttons.
So to me GTDebugger is a disappointement.
Here is the kind of code I'm debugging so this is not that complex nor implying concurrency or whatever complex.
coinsFor: aValue into2: accuWallet
| accu | self halt. [ accu := accuWallet money. accu < aValue ] whileTrue: [ | big | big := self biggest. [ big > (aValue - accu) ] whileTrue: [ big := self biggestBelow: big ]. self removeCoin: big. accuWallet addCoin: big ]. ^ accuWallet
Stef
Hi andrei
Do you use a particular Wallet object?
it was in one of the tests. I put a halt into the coinFor: into2:
What image are you using? Pharo5.0 Latest update: #50759
Can you fuel out and send the stack if you get this error again?
I will try to reproduce it and send it to you. Stef
Cheers, Andrei
Stef
PS: Yes I know I'm the stupider guy in the world because I criticise the wonderful GT tools and I should not because it is not acceptable :)
Le 3/6/16 à 22:01, Andrei Chis a écrit :
Hi Stef,
Can you provide a way to load or access the entire code of your example?
Cheers, Andrei
On Fri, Jun 3, 2016 at 9:43 PM, stepharo <stepharo@free.fr <mailto:stepharo@free.fr>> wrote:
Hi
I'm debugging a simple algo for a first exercises in Pharo future book and I get stepToSendOrReturn
DNU when using the debugger. :((((((((((((((((((((((((((((((((((((
You see I would really like in Pharo that we get new tools only when there are better than the old
ones. I still could not see how GTDebugger helps me debugging faster my programs.
Personally the fact that GT debugger can show bytecodes or can be extended is not in the critical path.
My critical path is that I can debug Pharo programs and now I cannot.
I also did not see any comments on the multiple complaints about the funky place for the buttons.
So to me GTDebugger is a disappointement.
Here is the kind of code I'm debugging so this is not that complex nor implying concurrency or whatever complex.
coinsFor: aValue into2: accuWallet
| accu | self halt. [ accu := accuWallet money. accu < aValue ] whileTrue: [ | big | big := self biggest. [ big > (aValue - accu) ] whileTrue: [ big := self biggestBelow: big ]. self removeCoin: big. accuWallet addCoin: big ]. ^ accuWallet
Stef
Hi, I tried several times to reproduce this and could not. If you could get an image with the problem it would be the best case scenario. Cheers, Doru
On Jun 4, 2016, at 5:39 PM, stepharo <stepharo@free.fr> wrote:
Hi andrei
Do you use a particular Wallet object?
it was in one of the tests. I put a halt into the coinFor: into2:
What image are you using? Pharo5.0 Latest update: #50759
Can you fuel out and send the stack if you get this error again?
I will try to reproduce it and send it to you.
Stef
Cheers, Andrei
Stef PS: Yes I know I'm the stupider guy in the world because I criticise the wonderful GT tools and I should not because it is not acceptable :)
Le 3/6/16 à 22:01, Andrei Chis a écrit :
Hi Stef,
Can you provide a way to load or access the entire code of your example?
Cheers, Andrei
On Fri, Jun 3, 2016 at 9:43 PM, stepharo <stepharo@free.fr> wrote: Hi
I'm debugging a simple algo for a first exercises in Pharo future book and I get stepToSendOrReturn
DNU when using the debugger. :((((((((((((((((((((((((((((((((((((
You see I would really like in Pharo that we get new tools only when there are better than the old
ones. I still could not see how GTDebugger helps me debugging faster my programs.
Personally the fact that GT debugger can show bytecodes or can be extended is not in the critical path.
My critical path is that I can debug Pharo programs and now I cannot.
I also did not see any comments on the multiple complaints about the funky place for the buttons.
So to me GTDebugger is a disappointement.
Here is the kind of code I'm debugging so this is not that complex nor implying concurrency or whatever complex.
coinsFor: aValue into2: accuWallet
| accu | self halt. [ accu := accuWallet money. accu < aValue ] whileTrue: [ | big | big := self biggest. [ big > (aValue - accu) ] whileTrue: [ big := self biggestBelow: big ]. self removeCoin: big. accuWallet addCoin: big ]. ^ accuWallet
Stef
-- www.tudorgirba.com www.feenk.com "To lead is not to demand things, it is to make them happen."
I will try to reproduce it and send it to you.
I tried and after several tries I could not reproduce the bug but I could totally freeze the image :( Do not ask me how. See screenshot below Now I do not get it but when I put a halt like the following coinsFor: aValue into2: accuWallet | accu | self halt. [ accu := accuWallet money. accu < aValue ] whileTrue: [ | big | big := self biggest. [ big > ((aValue - accu)) ] whileTrue: [ big := self biggestBelow: big ]. self removeCoin: big. accuWallet addCoin: big ]. ^ accuWallet - sometimes I cannot get it stopped there :( when running the test for coinsFor: testCoinsForPayingWithOtherCoins for example. I got it now GTInspector does not open on latest stack frame but the one before and if I scroll I get it So this one should be easy to fix. For the other one I do not know. Having a robust debugger would be priority number one. Stef Stef
Hi, We certainly want to have a bullet proof debugger. However, by looking at the selector you mention, the problem you got with the crashing debugger is almost surely reproducible with the old debugger. It is unlikely related to the GT Debugger (which is essentially a UI). The issue you mention with the stack selection is a GT Debugger issue indeed. @Andrei: let us open an issue for this and let us look again at the selection strategy for the SUnit debugger. Cheers, Doru
On Jun 4, 2016, at 6:01 PM, stepharo <stepharo@free.fr> wrote:
I will try to reproduce it and send it to you.
I tried and after several tries I could not reproduce the bug but I could totally freeze the image :( Do not ask me how. See screenshot below
Now I do not get it but when I put a halt like the following
coinsFor: aValue into2: accuWallet
| accu | self halt. [
accu := accuWallet money. accu < aValue ] whileTrue: [ | big | big := self biggest. [ big > ((aValue - accu)) ] whileTrue: [ big := self biggestBelow: big ]. self removeCoin: big. accuWallet addCoin: big ]. ^ accuWallet
- sometimes I cannot get it stopped there :( when running the test for coinsFor: testCoinsForPayingWithOtherCoins for example.
I got it now GTInspector does not open on latest stack frame but the one before and if I scroll I get it
<ianmjlfcejhofpgl.png> So this one should be easy to fix. For the other one I do not know.
Having a robust debugger would be priority number one.
Stef
<hjelkjfocdmahjhd.png> Stef
-- www.tudorgirba.com www.feenk.com "It's not what we do that matters most, it's how we do it."
Hi. 2016-06-04 18:01 GMT+02:00 stepharo <stepharo@free.fr>:
I got it now GTInspector does not open on latest stack frame but the one before and if I scroll I get it
Yes. And step into not autoscroll stack view. I like GTDebugger. It is step forward for our tools. Now only real issue for me is horribly slow stepping. I guess each "step over" action refreshes all inspector views. I hope proposed solution for fast inspector updating could address it.
participants (4)
-
Andrei Chis -
Denis Kudriashov -
stepharo -
Tudor Girba