Ben, I was thinking the same as you, I think that if I could set the image in development mode, or something like that, it would not do such optimization so that debugger behaves more like expected. If the debugger could undo such optimizations would be fine also. I just assumed it should be hard to accomplish that..... Regards, Vitor On Wed, Oct 12, 2016 at 9:38 AM, Clément Bera <bera.clement@gmail.com> wrote:
The simulation of primitives is done in Context>>#doPrimitive:method: receiver:args:
Basically, specific numbers are simulated in the image while other numbers are run using the VM code.
Quick methods (what you call inlined methods) are encoded with primitive numbers between 256 and 512. If you look at IRBytecodeGenerator>>quickMethodPrim you should be able to find the specification of the quick primitive numbers (256 = quick return self, 257 = quick return true, etc...).
Basically if you change this method to simulate in the image those primitive numbers instead of using the VM code and simulating by creating the context and executing it, it should work. Or something like that.
On Wed, Oct 12, 2016 at 2:18 PM, Ben Coman <btc@openinworld.com> wrote:
On Tue, Oct 11, 2016 at 9:45 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 11 Oct 2016, at 15:43, Vitor Medina Cruz <vitormcruz@gmail.com>
wrote:
Hello,
I was TTDing today with Pharo and some odd thing happened. I had a
method that just returned false and while debugging I could not step into it (i wanted to change the method while debugging), I suppose the method was inlined and so debugging was not available, is that correct?
yes.
The same also happens for accessors that return an instance variable directly. I often find It unsettling, to be expecting one behaviour and something different occurs, even if a moment later I implicitly understand what happened.
Except of course that someone busy would have to do it, how hard would it be for the debugger to un-inline the method so it can step into it? Are there any reasons not to do that?
cheers -ben