E
Eric Promislow
The Komodo Ruby debugger was capturing the source for calls to
Kernel.eval by redefining the method, trapping calls to it,
saving the source, and then finally calling the true eval method.
This has two problems:
1. Sometimes I couldn't associate the correct binding with the
call to the true eval -- I posted a note on this a couple of
weeks ago asking if anyone had some insight on this.
2. This also throws off the standard tracer by some kind of
interaction I don't completely understand.
So I'm pulling out support for this. By no means am I an expert
on Ruby internals, but it looks like the args to rb_f_eval()
could be saved on the frame stack in the argc and argv fields,
and then a function would be needed to grab that data on
demand. I'm not sure how such a frame would be identified from
Ruby code, as not all frames appear to trigger a call to the
trace function, so just giving an offset wouldn't suffice.
I'd prefer to use the binding, as it is exposed to the Ruby
code via the source function.
Thanks,
Eric
Kernel.eval by redefining the method, trapping calls to it,
saving the source, and then finally calling the true eval method.
This has two problems:
1. Sometimes I couldn't associate the correct binding with the
call to the true eval -- I posted a note on this a couple of
weeks ago asking if anyone had some insight on this.
2. This also throws off the standard tracer by some kind of
interaction I don't completely understand.
So I'm pulling out support for this. By no means am I an expert
on Ruby internals, but it looks like the args to rb_f_eval()
could be saved on the frame stack in the argc and argv fields,
and then a function would be needed to grab that data on
demand. I'm not sure how such a frame would be identified from
Ruby code, as not all frames appear to trigger a call to the
trace function, so just giving an offset wouldn't suffice.
I'd prefer to use the binding, as it is exposed to the Ruby
code via the source function.
Thanks,
Eric