I don't think it is a priority. But its nice to get a feel for possibilities and constraints. cheers -ben
On Thu, Oct 13, 2016 at 9:50 PM, Clément Bera <bera.clem...@gmail.com> wrote: > Well for quick methods it's doable. > > For inlined control flow operations it's quite difficult. Although it > could be possible now with the mustBeBoolean magic thingy... > > > On Thu, Oct 13, 2016 at 3:23 PM, Vitor Medina Cruz <vitormc...@gmail.com> > wrote: > >> 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.clem...@gmail.com> >> wrote: >> >>> The simulation of primitives is done in Context>>#doPrimitive:method:r >>> eceiver: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 <b...@openinworld.com> wrote: >>> >>>> On Tue, Oct 11, 2016 at 9:45 PM, Esteban Lorenzano <esteba...@gmail.com> >>>> wrote: >>>> > >>>> >> On 11 Oct 2016, at 15:43, Vitor Medina Cruz <vitormc...@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 >>>> >>>> >>> >> >
