Debugger is not stable
Locked
 
|
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 <[hidden email]> wrote: Hi |
|
|
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 Le 3/6/16 à 22:01, Andrei Chis a
écrit :
|
|
|
Hi,
> On Jun 4, 2016, at 9:08 AM, stepharo <[hidden email]> 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 <[hidden email]> 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." |
|
|
In reply to this post by stepharo
Hi Stef,
On Sat, Jun 4, 2016 at 9:08 AM, stepharo <[hidden email]> wrote:
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
|
|
|
Hi andrei
it was in one of the tests. I put a halt into the coinFor: into2: Pharo5.0 Latest update: #50759
I will try to reproduce it and send it to you. 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 <[hidden email]> 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 <[hidden email]> 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." |
|
|
In reply to this post by stepharo
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 <[hidden email]> 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." |
|
|
In reply to this post by stepharo
Hi. 2016-06-04 18:01 GMT+02:00 stepharo <[hidden email]>:
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. |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |