While debugging, I modify the code of the method, then accept, then restart. But when going back to the method in the browser, it is unchanged. What I am doing wrong or is this something other people do encounter? I didn't had this in 2.0 Phil
Hello, It happens sometimes when you edit a blockClosure code and that the debugger cannot find it on stack. Isn't that your case ? 2014-06-03 13:13 GMT+02:00 phil@highoctane.be <phil@highoctane.be>:
While debugging, I modify the code of the method, then accept, then restart.
But when going back to the method in the browser, it is unchanged.
What I am doing wrong or is this something other people do encounter?
I didn't had this in 2.0
Phil
On 3 juin 2014, at 13:34, Clément Bera <bera.clement@gmail.com> wrote:
Hello,
It happens sometimes when you edit a blockClosure code and that the debugger cannot find it on stack.
Why would the debugger need to find a context for an edited block? The only reason I see would be on-stack replacement, but AFAIK the debugger doesn't do that, does it?
Isn't that your case ?
2014-06-03 13:13 GMT+02:00 phil@highoctane.be <phil@highoctane.be>: While debugging, I modify the code of the method, then accept, then restart.
But when going back to the method in the browser, it is unchanged.
What I am doing wrong or is this something other people do encounter?
I didn't had this in 2.0
Phil
On 03 Jun 2014, at 08:52, Camille Teruel <camille.teruel@gmail.com> wrote:
On 3 juin 2014, at 13:34, Clément Bera <bera.clement@gmail.com> wrote:
Hello,
It happens sometimes when you edit a blockClosure code and that the debugger cannot find it on stack.
Why would the debugger need to find a context for an edited block? The only reason I see would be on-stack replacement, but AFAIK the debugger doesn't do that, does it?
I have spotted this problem too, outside block closures. It is not every time but it happens occasionally. I think is some sort of bug :( Esteban
Isn't that your case ?
2014-06-03 13:13 GMT+02:00 phil@highoctane.be <phil@highoctane.be>: While debugging, I modify the code of the method, then accept, then restart.
But when going back to the method in the browser, it is unchanged.
What I am doing wrong or is this something other people do encounter?
I didn't had this in 2.0
Phil
2014-06-03 14:09 GMT+02:00 Esteban Lorenzano <estebanlm@gmail.com>:
On 03 Jun 2014, at 08:52, Camille Teruel <camille.teruel@gmail.com> wrote:
On 3 juin 2014, at 13:34, Clément Bera <bera.clement@gmail.com> wrote:
Hello,
It happens sometimes when you edit a blockClosure code and that the debugger cannot find it on stack.
Why would the debugger need to find a context for an edited block? The only reason I see would be on-stack replacement, but AFAIK the debugger doesn't do that, does it?
I have spotted this problem too, outside block closures. It is not every time but it happens occasionally. I think is some sort of bug :(
Yeah I also had the problem ... Fortunately, one of the debugger implementor (that I will not name here) is working in our team right now and she may be able to fix it :-)
Esteban
Isn't that your case ?
2014-06-03 13:13 GMT+02:00 phil@highoctane.be <phil@highoctane.be>:
While debugging, I modify the code of the method, then accept, then restart.
But when going back to the method in the browser, it is unchanged.
What I am doing wrong or is this something other people do encounter?
I didn't had this in 2.0
Phil
haha, well, if any of you can provide a way to reproduce the problem, I will take a look. 2014-06-03 14:46 GMT+02:00 Clément Bera <bera.clement@gmail.com>:
2014-06-03 14:09 GMT+02:00 Esteban Lorenzano <estebanlm@gmail.com>:
On 03 Jun 2014, at 08:52, Camille Teruel <camille.teruel@gmail.com> wrote:
On 3 juin 2014, at 13:34, Clément Bera <bera.clement@gmail.com> wrote:
Hello,
It happens sometimes when you edit a blockClosure code and that the debugger cannot find it on stack.
Why would the debugger need to find a context for an edited block? The only reason I see would be on-stack replacement, but AFAIK the debugger doesn't do that, does it?
I have spotted this problem too, outside block closures. It is not every time but it happens occasionally. I think is some sort of bug :(
Yeah I also had the problem ...
Fortunately, one of the debugger implementor (that I will not name here) is working in our team right now and she may be able to fix it :-)
Esteban
Isn't that your case ?
2014-06-03 13:13 GMT+02:00 phil@highoctane.be <phil@highoctane.be>:
While debugging, I modify the code of the method, then accept, then restart.
But when going back to the method in the browser, it is unchanged.
What I am doing wrong or is this something other people do encounter?
I didn't had this in 2.0
Phil
On 3 June 2014 13:46, Clément Bera <bera.clement@gmail.com> wrote:
2014-06-03 14:09 GMT+02:00 Esteban Lorenzano <estebanlm@gmail.com>:
On 03 Jun 2014, at 08:52, Camille Teruel <camille.teruel@gmail.com> wrote:
On 3 juin 2014, at 13:34, Clément Bera <bera.clement@gmail.com> wrote:
Hello,
It happens sometimes when you edit a blockClosure code and that the debugger cannot find it on stack.
Why would the debugger need to find a context for an edited block? The only reason I see would be on-stack replacement, but AFAIK the debugger doesn't do that, does it?
I have spotted this problem too, outside block closures. It is not every time but it happens occasionally. I think is some sort of bug :(
Yeah I also had the problem ...
Fortunately, one of the debugger implementor (that I will not name here) is working in our team right now and she may be able to fix it :-)
I started implementing this for Squeak, and then got snowed under by Real Life :( Had that not happened, you might have been able to spare some cycles. Sorry! frank
Esteban
Isn't that your case ?
2014-06-03 13:13 GMT+02:00 phil@highoctane.be <phil@highoctane.be>:
While debugging, I modify the code of the method, then accept, then restart.
But when going back to the method in the browser, it is unchanged.
What I am doing wrong or is this something other people do encounter?
I didn't had this in 2.0
Phil
On Tue, Jun 3, 2014 at 2:09 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 03 Jun 2014, at 08:52, Camille Teruel <camille.teruel@gmail.com> wrote:
On 3 juin 2014, at 13:34, Clément Bera <bera.clement@gmail.com> wrote:
Hello,
It happens sometimes when you edit a blockClosure code and that the debugger cannot find it on stack.
Why would the debugger need to find a context for an edited block? The only reason I see would be on-stack replacement, but AFAIK the debugger doesn't do that, does it?
I have spotted this problem too, outside block closures. It is not every time but it happens occasionally. I think is some sort of bug :(
I takes away a lot of the fun... Especially when my image gets locked, no matter how much I hit the interrupt key sequence. 'Through', 'Over', 'Restart', ... it is not working nicely. Is that because of the new debugger/compiler chain? Phil
Esteban
Isn't that your case ?
2014-06-03 13:13 GMT+02:00 phil@highoctane.be <phil@highoctane.be>:
While debugging, I modify the code of the method, then accept, then restart.
But when going back to the method in the browser, it is unchanged.
What I am doing wrong or is this something other people do encounter?
I didn't had this in 2.0
Phil
2014-06-03 13:52 GMT+02:00 Camille Teruel <camille.teruel@gmail.com>:
On 3 juin 2014, at 13:34, Clément Bera <bera.clement@gmail.com> wrote:
Hello,
It happens sometimes when you edit a blockClosure code and that the debugger cannot find it on stack.
Why would the debugger need to find a context for an edited block? The only reason I see would be on-stack replacement, but AFAIK the debugger doesn't do that, does it?
I was talking about this case:
DebugContext>>blockNotFoundDialog: aMethod with: aText | browser message result | message := 'Method for block not found on stack, can''t edit and continue'. [ ... ]
Isn't that your case ?
2014-06-03 13:13 GMT+02:00 phil@highoctane.be <phil@highoctane.be>:
While debugging, I modify the code of the method, then accept, then restart.
But when going back to the method in the browser, it is unchanged.
What I am doing wrong or is this something other people do encounter?
I didn't had this in 2.0
Phil
participants (6)
-
Camille Teruel -
Clara Allende -
Clément Bera -
Esteban Lorenzano -
Frank Shearar -
phil＠highoctane.be