[Pharo-dev] MNU: receiver of stepToCallee: is nil

2014-09-23 Thread Clara Allende
Hi! When debugging tests, if I just close the debugger without finishing the test run, I get this weird message. Has anybody had this problem before?

Re: [Pharo-dev] MNU: receiver of stepToCallee: is nil

2014-09-23 Thread Clément Bera
In the latest Pharo 4, #stepToCallee: is not implemented nor sent. Which version of Pharo are you using ? 2014-09-23 15:59 GMT+02:00 Clara Allende clari.alle...@gmail.com: Hi! When debugging tests, if I just close the debugger without finishing the test run, I get this weird message. Has

Re: [Pharo-dev] MNU: receiver of stepToCallee: is nil

2014-09-23 Thread Clara Allende
pharo 4, but not the latest image 2014-09-23 16:27 GMT+02:00 Clément Bera bera.clem...@gmail.com: In the latest Pharo 4, #stepToCallee: is not implemented nor sent. Which version of Pharo are you using ? 2014-09-23 15:59 GMT+02:00 Clara Allende clari.alle...@gmail.com: Hi! When

Re: [Pharo-dev] MNU: receiver of stepToCallee: is nil

2014-09-23 Thread Clara Allende
Sorry, the message is #stepToCallee (without the colon, my bad). in 40243 I still get it. 2014-09-23 16:30 GMT+02:00 Clara Allende clari.alle...@gmail.com: pharo 4, but not the latest image 2014-09-23 16:27 GMT+02:00 Clément Bera bera.clem...@gmail.com: In the latest Pharo 4,

Re: [Pharo-dev] MNU: receiver of stepToCallee: is nil

2014-09-23 Thread Clément Bera
The theory I've had for a while for this issue is that ensure blocks are sometimes not executed when the process is manipulated / terminated from another process (so topContext was not assigned even if in an ensure block). I've tried to fix it but I failed. Can you give a reproduceable case ? And

Re: [Pharo-dev] MNU: receiver of stepToCallee: is nil

2014-09-23 Thread Clara Allende
https://pharo.fogbugz.com/f/cases/14060/MNU-receiver-of-stepToCallee-is-nil 2014-09-23 17:48 GMT+02:00 Clément Bera bera.clem...@gmail.com: The theory I've had for a while for this issue is that ensure blocks are sometimes not executed when the process is manipulated / terminated from another

Re: [Pharo-dev] MNU: receiver of stepToCallee: is nil

2014-09-23 Thread Martin McClure
On 09/23/2014 08:48 AM, Clément Bera wrote: The theory I've had for a while for this issue is that ensure blocks are sometimes not executed when the process is manipulated / terminated from another process (so topContext was not assigned even if in an ensure block). I've tried to fix it but I

Re: [Pharo-dev] MNU: receiver of stepToCallee: is nil

2014-09-23 Thread Max Leske
On 23.09.2014, at 16:45, Clara Allende clari.alle...@gmail.com wrote: Sorry, the message is #stepToCallee (without the colon, my bad). in 40243 I still get it. You’re right. I just checked the latest image and #stepToCallee is implemented in Context and send in

Re: [Pharo-dev] MNU: receiver of stepToCallee: is nil

2014-09-23 Thread Max Leske
On 23.09.2014, at 15:59, Clara Allende clari.alle...@gmail.com wrote: Hi! When debugging tests, if I just close the debugger without finishing the test run, I get this weird message. Has anybody had this problem before? Yes, just five minutes ago, but I was doing weird stuff with

Re: [Pharo-dev] MNU: receiver of stepToCallee: is nil

2014-09-23 Thread Max Leske
Just for reference, in my case I can reproduce it only because I trick the simulation into thinking that the process I’m working with is not the active process. Here’s a test case that reproduces the problem (the process context will be in the handler at the end):

Re: [Pharo-dev] MNU: receiver of stepToCallee: is nil

2014-09-23 Thread Max Leske
40233 (September 18.) So that probably solves it :) On 23.09.2014, at 16:30, Clara Allende clari.alle...@gmail.com wrote: pharo 4, but not the latest image 2014-09-23 16:27 GMT+02:00 Clément Bera bera.clem...@gmail.com: In the latest Pharo 4, #stepToCallee: is not implemented nor sent.