14606 Really Important bug - Can't see some variables values while debugging closure
Issue 14606 [1] is tagged "Really Important" where evaluating.... | t1 t2 t3 t4 t5 t6 | t1 := 1. t2 := 2. t3 := 3. t4 := 4. t5 := 5 . t6 := 6. [ t5 := 50. t6 := 60. t3 + t4. 1 halt. ] value => can't see the value of t4, t5, t6. I've just submitted a possible solution for this, but its a bit late before release for such a change - so I'm asking for "all hands in" to help stress test it. You don't need to review code, just please merge latest slice 14606 into your normal working image and report your experience. cheers -ben [1] https://pharo.fogbugz.com/default.asp?14606#124466
Thanks ben Several rmoder are busy with paper deadline for this evening. ... Stef Le 1/4/15 18:56, Ben Coman a écrit :
Issue 14606 [1] is tagged "Really Important" where evaluating....
| t1 t2 t3 t4 t5 t6 | t1 := 1. t2 := 2. t3 := 3. t4 := 4. t5 := 5 . t6 := 6. [ t5 := 50. t6 := 60. t3 + t4. 1 halt. ] value
=> can't see the value of t4, t5, t6.
I've just submitted a possible solution for this, but its a bit late before release for such a change - so I'm asking for "all hands in" to help stress test it. You don't need to review code, just please merge latest slice 14606 into your normal working image and report your experience.
cheers -ben
2015-04-01 18:56 GMT+02:00 Ben Coman <btc@openinworld.com>:
Issue 14606 [1] is tagged "Really Important" where evaluating....
| t1 t2 t3 t4 t5 t6 | t1 := 1. t2 := 2. t3 := 3. t4 := 4. t5 := 5 . t6 := 6. [ t5 := 50. t6 := 60. t3 + t4. 1 halt. ] value
=> can't see the value of t4, t5, t6.
I've just submitted a possible solution for this, but its a bit late before release for such a change - so I'm asking for "all hands in" to help stress test it. You don't need to review code, just please merge latest slice 14606 into your normal working image and report your experience.
cheers -ben
Here is a minimal example that does not work with your fix. (condensed from the failing test case) [ :x :y | (thisContext tempNamed: 'x') inspect. (1 to: 1) do: [ :i | | k l | k := y. l := x. (thisContext tempNamed: 'x') inspect ] ] value: 1 value: 23 Both inspector windows should show the same value for the argument 'x'. But the result is 1. inspector -> 1 2. inspector -> 23
On 02 Apr 2015, at 00:29, Nicolai Hess <nicolaihess@web.de> wrote:
2015-04-01 18:56 GMT+02:00 Ben Coman <btc@openinworld.com <mailto:btc@openinworld.com>>: Issue 14606 [1] is tagged "Really Important" where evaluating....
| t1 t2 t3 t4 t5 t6 | t1 := 1. t2 := 2. t3 := 3. t4 := 4. t5 := 5 . t6 := 6. [ t5 := 50. t6 := 60. t3 + t4. 1 halt. ] value
=> can't see the value of t4, t5, t6.
I've just submitted a possible solution for this, but its a bit late before release for such a change - so I'm asking for "all hands in" to help stress test it. You don't need to review code, just please merge latest slice 14606 into your normal working image and report your experience.
cheers -ben
[1] https://pharo.fogbugz.com/default.asp?14606#124466 <https://pharo.fogbugz.com/default.asp?14606#124466>
Here is a minimal example that does not work with your fix. (condensed from the failing test case)
[ :x :y | (thisContext tempNamed: 'x') inspect. (1 to: 1) do: [ :i | | k l | k := y. l := x. (thisContext tempNamed: 'x') inspect ] ] value: 1 value: 23
Both inspector windows should show the same value for the argument 'x'. But the result is 1. inspector -> 1 2. inspector -> 23
Before loading the slice, both inspectors show â1â. That canât be right either⦠Max
2015-04-02 16:06 GMT+02:00 Max Leske <maxleske@gmail.com>:
On 02 Apr 2015, at 00:29, Nicolai Hess <nicolaihess@web.de> wrote:
2015-04-01 18:56 GMT+02:00 Ben Coman <btc@openinworld.com>:
Issue 14606 [1] is tagged "Really Important" where evaluating....
| t1 t2 t3 t4 t5 t6 | t1 := 1. t2 := 2. t3 := 3. t4 := 4. t5 := 5 . t6 := 6. [ t5 := 50. t6 := 60. t3 + t4. 1 halt. ] value
=> can't see the value of t4, t5, t6.
I've just submitted a possible solution for this, but its a bit late before release for such a change - so I'm asking for "all hands in" to help stress test it. You don't need to review code, just please merge latest slice 14606 into your normal working image and report your experience.
cheers -ben
Here is a minimal example that does not work with your fix. (condensed from the failing test case)
[ :x :y | (thisContext tempNamed: 'x') inspect. (1 to: 1) do: [ :i | | k l | k := y. l := x. (thisContext tempNamed: 'x') inspect ] ] value: 1 value: 23
Both inspector windows should show the same value for the argument 'x'. But the result is 1. inspector -> 1 2. inspector -> 23
Before loading the slice, both inspectors show â1â. That canât be right eitherâ¦
No, that is correct. Both inspector inspect the block argument 'x', it is assigned with value 1 with the message value:1 value:23 and the block argument value can not change, therefore both inspect should show '1'
Max
On 03 Apr 2015, at 14:03, Nicolai Hess <nicolaihess@web.de> wrote:
2015-04-02 16:06 GMT+02:00 Max Leske <maxleske@gmail.com <mailto:maxleske@gmail.com>>:
On 02 Apr 2015, at 00:29, Nicolai Hess <nicolaihess@web.de <mailto:nicolaihess@web.de>> wrote:
2015-04-01 18:56 GMT+02:00 Ben Coman <btc@openinworld.com <mailto:btc@openinworld.com>>: Issue 14606 [1] is tagged "Really Important" where evaluating....
| t1 t2 t3 t4 t5 t6 | t1 := 1. t2 := 2. t3 := 3. t4 := 4. t5 := 5 . t6 := 6. [ t5 := 50. t6 := 60. t3 + t4. 1 halt. ] value
=> can't see the value of t4, t5, t6.
I've just submitted a possible solution for this, but its a bit late before release for such a change - so I'm asking for "all hands in" to help stress test it. You don't need to review code, just please merge latest slice 14606 into your normal working image and report your experience.
cheers -ben
[1] https://pharo.fogbugz.com/default.asp?14606#124466 <https://pharo.fogbugz.com/default.asp?14606#124466>
Here is a minimal example that does not work with your fix. (condensed from the failing test case)
[ :x :y | (thisContext tempNamed: 'x') inspect. (1 to: 1) do: [ :i | | k l | k := y. l := x. (thisContext tempNamed: 'x') inspect ] ] value: 1 value: 23
Both inspector windows should show the same value for the argument 'x'. But the result is 1. inspector -> 1 2. inspector -> 23
Before loading the slice, both inspectors show â1â. That canât be right eitherâ¦
No, that is correct. Both inspector inspect the block argument 'x', it is assigned with value 1 with the message value:1 value:23 and the block argument value can not change, therefore both inspect should show â1'
Oops. i thought that x was being assigned to in the block :)
Max
2015-04-01 18:56 GMT+02:00 Ben Coman <btc@openinworld.com>:
Issue 14606 [1] is tagged "Really Important" where evaluating....
| t1 t2 t3 t4 t5 t6 | t1 := 1. t2 := 2. t3 := 3. t4 := 4. t5 := 5 . t6 := 6. [ t5 := 50. t6 := 60. t3 + t4. 1 halt. ] value
=> can't see the value of t4, t5, t6.
I've just submitted a possible solution for this, but its a bit late before release for such a change - so I'm asking for "all hands in" to help stress test it. You don't need to review code, just please merge latest slice 14606 into your normal working image and report your experience.
cheers -ben
Origins of issue "14606 Can't see some variables values while debugging closure" It starts with issue: 14079 Inconsistent information in debugger (pharo 4) (fixed in 40258) The thisContext inspector in the debugger (sometimes) shows the wrong values for the thisContext temp vars. This was first seen in Method FreeTypeFontProvider>>#updateFromFile: I extracted a minimal example to reproduce this behavior: [ :x | | d c b a | a := 1. b := 2. c := 3. d := 4. [ c:=3. c=0 ] on:Error do:[:ex|]. d halt. [ c:=3. c=0 ] whileTrue:[]] value:23 If you execute this method, it stops at "d halt". Look at the "all temp vars" and the individual temp var entries in the context inspector. It shows the temp vars with the correct values. Now do a step over, int the whileTrue block the temp var name list is unchanged but the values changed their order, now the list of individual temp vars shows the wrong values! Why did this happen? There are two problems, 1. The order of temp vars changes between the method context and the block closure 2. The EyeDebuggerContextInspector compares ContextTempEyeElements without their inst vars (tempName AND tempIndex). In EyeInspector>>#updateList: We step into a new block and the debugger calls updateList, here we check the current list (self list getItems) with the new list (elements) and check if they are equal, they aren't, because the lists contain ContextTempEyeElements with the same tempName but different tempIndex, but the #= selector in AbstractEyeElement doesn't check this. EyeInspector>>#updateList "update the list of elements displayed according to the new object" | elements | " self haltOnce." elements := self generateElements. self list getItems = elements ifTrue: [ ^ self ]. "<<<--- returns event if the elements aren't equal" .... Possible solutions: - Don't reorder tempvars in inner scopes. This needs some deeper knowlegde of opals AST Translator. - Fix the #= for AbstractEyeElement resp. ContextTempEyeElement - in ContextTempEyeElement, access the temp values not by index (they changed) but by name I choosed the latter, because I could not get a working fix for the other, this raised some new issues. Not really new, they exists already, but weren't visible because they were only used in special cases: 13260 inspecting variables in the debugger fails in some cases (fixed in 40354) Minimal example: x := [ :k || b a | b:=[ a:=1. a:=k+1.a]] value:7. x value *Execute* the first line, then debug the second. In the debugger, in the thisContext inspector, you can select the var "k", it shows 7, you can select the var "b" it shows nil (because it *is* nil), you can not show the value for "a", although it should show "1". Why did this happens? With the fix for issue 14079, we now use #tempNamed:aName instead of #namedTempAt: anIndex but in the end, the context only stores the temp vars by index, so we (the debugger) needs to find the index for the named temp. This is done through DebuggerMethodMapOpal namedTempAt:in: resp. tempNamed:in: It looks up the temp index by the variable binding for the *Method* scope (and finally the method context). This is wrong, because in this case, the method context is already dead. I fixed this by changing OCVectorTempVariable>>#readFromContext:scope: to start from the inner scope instead of the scope that defined the method (because it can be already dead). (This wasn't straight forward, I need to change some more because the way the IR class for constructing the closures bytecodes, only searched in its "block sequence" but the copyied tempvector is defined in its "sequence" (I don't really remember what is what). Even if I had choosed a different fix for issue 14079, this still had to be fixed, because indirect variable access through namedTempAt: is used, if we select the temp var in the *code view* and do a inspectIt. Even with this fix, the issue is not fully solved: Unsolved issues: 14606 Can't see some variables values while debugging closure Minimal example: |a b c| a := [ Transcript show: 'test' ]. [ b :=4. c := 5. 1 halt] on: Error do: a. select the b or c value in the thisContext inspector shows "nil" although they actually have a value. And 15174 error when inspecting/printing variables in the debugger this is a minimal example, reproducing this case, the assignment on "a" is alreaday done, after that accessing the value with DebuggerMethodMapOpal should work, but it raises an error | a b | [ ] value. a := 1. b := [ a := 4. (DebuggerMethodMapOpal forMethod: thisContext method) tempNamed: 'a' in: thisContext ] value. ^ a + b -> MessageNotUnderstood: receiver of "indexForVarNamed:" is nil in OCCopyingTempVariable>>indexInTempVectorFromIR: Both issues has to be solved and they have actually two causes: 1. There is a guarding clause in Context>>tempNamed: anIndex If the context stackpointer is below temp index, it returns nil. This is for the case the block closure vars aren't yet fully initialized (context tempvars are pushed on the stack with pushNil, if the stack pointer is below the index, it looks like we access a temp var, for which there isn't yet a place on the stack). But this is wrong! If the closure uses a closure copied or closure indirect tempvars, then multiple vars may be in *one* array that only takes one place on the stack. 2. (This is the reason for the MNU). Reading the temp vector index for "copied" temp vars fails. My proposed solution in "15174 error when inspecting/printing variables in the debugger" Looks like fixing this bug at the wrong place. I think it has something to do with 12887 Fix pc->AST maping. There was another issue, something with optimized blocks and reading and or writing closure temp vars, but I don't remember that, one. Don't know if it had something to do with this issues. Hope this was understandable and it helps (but I doubt we can solve any of this for this release. I was working on them the last 6 month, and issues 12887 is there since one year, still exists). nicolai
I got annoyed since a few times I thought I'd solved everything just the issue looking at the manual examples of one issue, only to find I'd caused the other case to fail. Also keeping track of all cases as I threw away images with partial solutions was awkward. So I turned the examples from all these Cases into tests and uploaded AdditionalTests-14606-13260-15174-BenComan.1 - so solutions can consistently test all cases. These can be integrated once we have a solution for all of them. Can you think of anymore to add? On Sun, Apr 5, 2015 at 8:27 AM, Nicolai Hess <nicolaihess@web.de> wrote:
2015-04-01 18:56 GMT+02:00 Ben Coman <btc@openinworld.com>:
Issue 14606 [1] is tagged "Really Important" where evaluating....
| t1 t2 t3 t4 t5 t6 | t1 := 1. t2 := 2. t3 := 3. t4 := 4. t5 := 5 . t6 := 6. [ t5 := 50. t6 := 60. t3 + t4. 1 halt. ] value
=> can't see the value of t4, t5, t6.
I've just submitted a possible solution for this, but its a bit late before release for such a change - so I'm asking for "all hands in" to help stress test it. You don't need to review code, just please merge latest slice 14606 into your normal working image and report your experience.
cheers -ben
Origins of issue "14606 Can't see some variables values while debugging closure" It starts with issue: 14079 Inconsistent information in debugger (pharo 4) (fixed in 40258) The thisContext inspector in the debugger (sometimes) shows the wrong values for the thisContext temp vars. This was first seen in Method FreeTypeFontProvider>>#updateFromFile: I extracted a minimal example to reproduce this behavior: [ :x | | d c b a | a := 1. b := 2. c := 3. d := 4. [ c:=3. c=0 ] on:Error do:[:ex|]. d halt. [ c:=3. c=0 ] whileTrue:[]] value:23 If you execute this method, it stops at "d halt". Look at the "all temp vars" and the individual temp var entries in the context inspector. It shows the temp vars with the correct values. Now do a step over, int the whileTrue block the temp var name list is unchanged but the values changed their order, now the list of individual temp vars shows the wrong values! Why did this happen? There are two problems, 1. The order of temp vars changes between the method context and the block closure 2. The EyeDebuggerContextInspector compares ContextTempEyeElements without their inst vars (tempName AND tempIndex). In EyeInspector>>#updateList: We step into a new block and the debugger calls updateList, here we check the current list (self list getItems) with the new list (elements) and check if they are equal, they aren't, because the lists contain ContextTempEyeElements with the same tempName but different tempIndex, but the #= selector in AbstractEyeElement doesn't check this. EyeInspector>>#updateList "update the list of elements displayed according to the new object"
| elements | " self haltOnce." elements := self generateElements. self list getItems = elements ifTrue: [ ^ self ]. "<<<--- returns event if the elements aren't equal" ....
Possible solutions: - Don't reorder tempvars in inner scopes. This needs some deeper knowlegde of opals AST Translator. - Fix the #= for AbstractEyeElement resp. ContextTempEyeElement - in ContextTempEyeElement, access the temp values not by index (they changed) but by name I choosed the latter, because I could not get a working fix for the other, this raised some new issues. Not really new, they exists already, but weren't visible because they were only used in special cases:
13260 inspecting variables in the debugger fails in some cases (fixed in 40354) Minimal example: x := [ :k || b a | b:=[ a:=1. a:=k+1.a]] value:7. x value
*Execute* the first line, then debug the second. In the debugger, in the thisContext inspector, you can select the var "k", it shows 7, you can select the var "b" it shows nil (because it *is* nil), you can not show the value for "a", although it should show "1". Why did this happens? With the fix for issue 14079, we now use #tempNamed:aName instead of #namedTempAt: anIndex but in the end, the context only stores the temp vars by index, so we (the debugger) needs to find the index for the named temp. This is done through DebuggerMethodMapOpal namedTempAt:in: resp. tempNamed:in: It looks up the temp index by the variable binding for the *Method* scope (and finally the method context). This is wrong, because in this case, the method context is already dead. I fixed this by changing OCVectorTempVariable>>#readFromContext:scope: to start from the inner scope instead of the scope that defined the method (because it can be already dead). (This wasn't straight forward, I need to change some more because the way the IR class for constructing the closures bytecodes, only searched in its "block sequence" but the copyied tempvector is defined in its "sequence" (I don't really remember what is what). Even if I had choosed a different fix for issue 14079, this still had to be fixed, because indirect variable access through namedTempAt: is used, if we select the temp var in the *code view* and do a inspectIt. Even with this fix, the issue is not fully solved:
Unsolved issues: 14606 Can't see some variables values while debugging closure Minimal example: |a b c| a := [ Transcript show: 'test' ]. [ b :=4. c := 5. 1 halt] on: Error do: a. select the b or c value in the thisContext inspector shows "nil" although they actually have a value. And
15174 error when inspecting/printing variables in the debugger
this is a minimal example, reproducing this case, the assignment on "a" is alreaday done, after that accessing the value with DebuggerMethodMapOpal should work, but it raises an error | a b | [ ] value. a := 1. b := [ a := 4. (DebuggerMethodMapOpal forMethod: thisContext method) tempNamed: 'a' in: thisContext ] value. ^ a + b
-> MessageNotUnderstood: receiver of "indexForVarNamed:" is nil in OCCopyingTempVariable>>indexInTempVectorFromIR:
Both issues has to be solved and they have actually two causes: 1. There is a guarding clause in Context>>tempNamed: anIndex If the context stackpointer is below temp index, it returns nil. This is for the case the block closure vars aren't yet fully initialized (context tempvars are pushed on the stack with pushNil, if the stack pointer is below the index, it looks like we access a temp var, for which there isn't yet a place on the stack). But this is wrong! If the closure uses a closure copied or closure indirect tempvars, then multiple vars may be in *one* array that only takes one place on the stack. 2. (This is the reason for the MNU). Reading the temp vector index for "copied" temp vars fails. My proposed solution in "15174 error when inspecting/printing variables in the debugger" Looks like fixing this bug at the wrong place. I think it has something to do with 12887 Fix pc->AST maping.
There was another issue, something with optimized blocks and reading and or writing closure temp vars, but I don't remember that, one. Don't know if it had something to do with this issues.
Hope this was understandable and it helps (but I doubt we can solve any of this for this release. I was working on them the last 6 month, and issues 12887 is there since one year, still exists).
nicolai
On Sun, Apr 5, 2015 at 1:23 PM, Ben Coman <btc@openinworld.com> wrote:
I got annoyed since a few times I thought I'd solved everything just the issue looking at the manual examples of one issue, only to find I'd caused the other case to fail. Also keeping track of all cases as I threw away images with partial solutions was awkward. So I turned the examples from all these Cases into tests and uploaded AdditionalTests-14606-13260-15174-BenComan.1 - so solutions can consistently test all cases. These can be integrated once we have a solution for all of them. Can you think of anymore to add?
And of course, please advise if you think the tests are correct. cheers -ben
2015-04-05 7:25 GMT+02:00 Ben Coman <btc@openinworld.com>:
On Sun, Apr 5, 2015 at 1:23 PM, Ben Coman <btc@openinworld.com> wrote:
I got annoyed since a few times I thought I'd solved everything just the issue looking at the manual examples of one issue, only to find I'd caused the other case to fail. Also keeping track of all cases as I threw away images with partial solutions was awkward. So I turned the examples from all these Cases into tests and uploaded AdditionalTests-14606-13260-15174-BenComan.1 - so solutions can consistently test all cases. These can be integrated once we have a solution for all of them. Can you think of anymore to add?
And of course, please advise if you think the tests are correct. cheers -ben
They look good. Just for reference, in the slice for fixing issue 13260, I added two testcases MethodMapTest>>#testCopiedVarFromDeadContext and MethodMapTest>>#testExampleTempNamedTempVectorInlinedLoop
Thanks both of you for the energy you put into Pharo. The tam really appreciates. This is because there are guys like you that Pharo is worth being done. Thanks for the tests. Esteban has apparently found the bug on the VM. Stef
On Sun, Apr 5, 2015 at 1:23 PM, Ben Coman <btc@openinworld.com <mailto:btc@openinworld.com>> wrote:
I got annoyed since a few times I thought I'd solved everything just the issue looking at the manual examples of one issue, only to find I'd caused the other case to fail. Also keeping track of all cases as I threw away images with partial solutions was awkward. So I turned the examples from all these Cases into tests and uploaded AdditionalTests-14606-13260-15174-BenComan.1 - so solutions can consistently test all cases. These can be integrated once we have a solution for all of them. Can you think of anymore to add?
And of course, please advise if you think the tests are correct. cheers -ben
They look good.
Just for reference, in the slice for fixing issue 13260, I added two testcases MethodMapTest>>#testCopiedVarFromDeadContext and MethodMapTest>>#testExampleTempNamedTempVectorInlinedLoop
Yes, incredible work, well done. Thank you.
On 05 Apr 2015, at 14:59, stepharo <stepharo@free.fr> wrote:
Thanks both of you for the energy you put into Pharo. The tam really appreciates. This is because there are guys like you that Pharo is worth being done. Thanks for the tests. Esteban has apparently found the bug on the VM.
Stef
On Sun, Apr 5, 2015 at 1:23 PM, Ben Coman <btc@openinworld.com> wrote: I got annoyed since a few times I thought I'd solved everything just the issue looking at the manual examples of one issue, only to find I'd caused the other case to fail. Also keeping track of all cases as I threw away images with partial solutions was awkward. So I turned the examples from all these Cases into tests and uploaded AdditionalTests-14606-13260-15174-BenComan.1 - so solutions can consistently test all cases. These can be integrated once we have a solution for all of them. Can you think of anymore to add?
And of course, please advise if you think the tests are correct. cheers -ben
They look good.
Just for reference, in the slice for fixing issue 13260, I added two testcases MethodMapTest>>#testCopiedVarFromDeadContext and MethodMapTest>>#testExampleTempNamedTempVectorInlinedLoop
On Sun, Apr 5, 2015 at 8:59 PM, stepharo <stepharo@free.fr> wrote:
Thanks both of you for the energy you put into Pharo. The tam really appreciates. This is because there are guys like you that Pharo is worth being done. Thanks for the tests. Esteban has apparently found the bug on the VM.
Stef
Energy breeds energy. For me it was an opportunity to learn more deep stuff(tm) by digging with a goal. It remains a bit beyond me, but I'm happy if I've been able to beat the high grass enough to flush the tiger into the open where the marksman can take a shot at it. Nice to flush out a VM bug (can't be too many of those left ;). Let us know when we can do testing on it. I guess I'll read more about it on [vm-dev]. cheers -ben
2015-04-05 17:38 GMT+02:00 Ben Coman <btc@openinworld.com>:
On Sun, Apr 5, 2015 at 8:59 PM, stepharo <stepharo@free.fr> wrote:
Thanks both of you for the energy you put into Pharo. The tam really appreciates. This is because there are guys like you that Pharo is worth being done. Thanks for the tests. Esteban has apparently found the bug on the VM.
Stef
Energy breeds energy. For me it was an opportunity to learn more deep stuff(tm) by digging with a goal. It remains a bit beyond me, but I'm happy if I've been able to beat the high grass enough to flush the tiger into the open where the marksman can take a shot at it.
Nice to flush out a VM bug (can't be too many of those left ;). Let us know when we can do testing on it. I guess I'll read more about it on [vm-dev].
cheers -ben
If it's a VM bug, the VM folks would be really really interested by a bug report, especially if ever it may affect Eliot's branch. Even if it's a Pharo only bug, it is still very interesting to know, because there's allways something to learn from a bug. So I'm all ears... cheers Nicolas
So the current status of this is "apparent" VM bug. Is it apparent enough that for now should I stop banging my head against it from the image side? Actually I am working 10 hour shifts the next three weeks during the power station's annual maintenance outage, so my time is probably limited anyway. cheers -ben On Mon, Apr 6, 2015 at 4:10 AM, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
2015-04-05 17:38 GMT+02:00 Ben Coman <btc@openinworld.com>:
On Sun, Apr 5, 2015 at 8:59 PM, stepharo <stepharo@free.fr> wrote:
Thanks both of you for the energy you put into Pharo. The tam really appreciates. This is because there are guys like you that Pharo is worth being done. Thanks for the tests. Esteban has apparently found the bug on the VM.
Stef
Energy breeds energy. For me it was an opportunity to learn more deep stuff(tm) by digging with a goal. It remains a bit beyond me, but I'm happy if I've been able to beat the high grass enough to flush the tiger into the open where the marksman can take a shot at it.
Nice to flush out a VM bug (can't be too many of those left ;). Let us know when we can do testing on it. I guess I'll read more about it on [vm-dev].
cheers -ben
If it's a VM bug, the VM folks would be really really interested by a bug report, especially if ever it may affect Eliot's branch. Even if it's a Pharo only bug, it is still very interesting to know, because there's allways something to learn from a bug. So I'm all ears...
cheers
Nicolas
Hi! It took me a while to read this thread before answering. :) With Camille we spent some hours this afternoon to take a look at this bug. We added new test cases and managed to do a hack that solves all the issues we could spot. You can find a slice for it in the inbox Now, we would like to have much more testing on it. SLICE-Issue-14606-Cant-see-some-variables-values-while-debugging-closure-GuillermoPolito.2 Our conclusion looking at the issue is that some parts of Opal (particularly the parts that manage the temp mapping and the temp vector) should be rewritten. By the moment our fix looks more like a hack. Guille El lun., 6 de abr. de 2015 a la(s) 3:43 p. m., Ben Coman < btc@openinworld.com> escribió:
So the current status of this is "apparent" VM bug. Is it apparent enough that for now should I stop banging my head against it from the image side?
Actually I am working 10 hour shifts the next three weeks during the power station's annual maintenance outage, so my time is probably limited anyway. cheers -ben
On Mon, Apr 6, 2015 at 4:10 AM, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
2015-04-05 17:38 GMT+02:00 Ben Coman <btc@openinworld.com>:
On Sun, Apr 5, 2015 at 8:59 PM, stepharo <stepharo@free.fr> wrote:
Thanks both of you for the energy you put into Pharo. The tam really appreciates. This is because there are guys like you that Pharo is worth being done. Thanks for the tests. Esteban has apparently found the bug on the VM.
Stef
Energy breeds energy. For me it was an opportunity to learn more deep stuff(tm) by digging with a goal. It remains a bit beyond me, but I'm happy if I've been able to beat the high grass enough to flush the tiger into the open where the marksman can take a shot at it.
Nice to flush out a VM bug (can't be too many of those left ;). Let us know when we can do testing on it. I guess I'll read more about it on [vm-dev].
cheers -ben
If it's a VM bug, the VM folks would be really really interested by a bug report, especially if ever it may affect Eliot's branch. Even if it's a Pharo only bug, it is still very interesting to know, because there's allways something to learn from a bug. So I'm all ears...
cheers
Nicolas
participants (7)
-
Ben Coman -
Guillermo Polito -
Max Leske -
Nicolai Hess -
Nicolas Cellier -
stepharo -
Sven Van Caekenberghe